>Number:         20100
>Category:       kern
>Synopsis:       Quntum Fireball drive fails with 1.6 (patch included)
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 28 12:21:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Michael Haardt
>Release:        1.6
>Organization:
>Environment:
NetBSD galadriel-alt 1.6 NetBSD 1.6 (GENERIC) #3: Tue Jan 28 20:58:49 CET 2003     root@galadriel:/usr/src/sys/arch/sparc/compile/GENERIC sparc

>Description:
My SS1+ works fine with 1.5.3; the disk is detected as:

sd0 at scsibus0 target 1 lun 0: <QUANTUM, FIREBALL SE2.1S, PJ09> SCSI2 0/direct$
sd0: 2051 MB, 7637 cyl, 2 head, 275 sec, 512 bytes/sect x 4201304 sectors

But with 1.6 and -current, I can not use the disk any more:

sd0 at scsibus0 target 1 lun 0: <QUANTUM, FIREBALL SE2.1S, PJ09> disk fixed
sd0: 2051 MB, 7637 cyl, 2 head, 275 sec, 512 bytes/sect x 4201304 sectors
sd0: async, 8-bit transfers, tagged queueing
root on sd0a dumps on sd0b
root file system type: ffs
esp0: identify failed, state 3, intr 0c
sd0: async, 8-bit transfers
<dropping msg byte 0>esp0: unexpected disconnect; sending REQUEST SENSE
esp0: target didn't send tag: 0 bytes in fifo
sd0(esp0:0:1:0):  Check Condition on CDB: 0x08 00 7b 66 10 00
    SENSE KEY:  Not Ready
   INFO FIELD:  31414
     ASC/ASCQ:  Logical Unit Not Ready, Cause Not Reportable

sd0(esp0:0:1:0):  Check Condition on CDB: 0x08 00 ae 1e 02 00
    SENSE KEY:  Not Ready
   INFO FIELD:  31414
     ASC/ASCQ:  Logical Unit Not Ready, Cause Not Reportable

And that's it, because /usr/libexec/getty can not be executed due to
the above errors and after a segfault booting stops.

I don't know if the drive being detected as 'async' device is correct
or not.  Someone suggested that I turn off tagged command queueing and 
indeed that fixes my problem and the machine boots fine again.  I found
some references at google that indicate certain Quantum Fireball drives
had problems with tagged commands, but no reference to this specific
model.

>How-To-Repeat:
Heavy traffic triggers the problem, e.g. when   
all daemons start at boot time.  Booting diskless and doing simple file
operations on the mounted drive works.
>Fix:
--- /sys/dev/scsipi/scsiconf.c.original Tue Jan 28 20:38:09 2003
+++ /sys/dev/scsipi/scsiconf.c  Tue Jan 28 20:58:15 2003
@@ -564,6 +564,8 @@
        {{T_DIRECT, T_FIXED,
         "QUANTUM ", "PD210S   SUN0207", ""},     PQUIRK_NOLUNS},
        {{T_DIRECT, T_FIXED,
+        "QUANTUM ", "FIREBALL SE2.1S",  "PJ09"}, PQUIRK_NOTAG},
+       {{T_DIRECT, T_FIXED,
         "RODIME  ", "RO3000S         ", ""},     PQUIRK_NOLUNS},
        {{T_DIRECT, T_FIXED,
         "SEAGATE ", "ST125N          ", ""},     PQUIRK_NOLUNS},

>Release-Note:
>Audit-Trail:
>Unformatted: