Rev 1.147 of cam_xpt.c kills me (fwd)

[Kenneth D. Merry]

On Mon, Jan 24, 2005 at 15:27:56 +0100, Michael Reifenberger wrote:
> Hi,
> anyone else sees this?
> 
> ---------- Forwarded message ----------
> Date: Sun, 23 Jan 2005 18:23:25 +0100 (CET)
> From: Michael Reifenberger <mike at reifenberger.com>
> To: mjacob at FreeBSD.org
> Subject: Rev 1.147 of cam_xpt.c kills me
> 
> Hi,
> I have an internal IDE to U2W SCSI RAID subsystem with 5 IDE-Disks in RAID5 
> which hangs on an Adaptec 2940.
> All is with an 4G, 3200+, ASUS A8V-deluxe.
> 
> With your above patch a new kernel hangs after finding a da1 on LUN
> 32. (Seems that da1 is the same device as da0).
> Then I get bus resets and broken SCB's...
> I can reboot but have to power down the system to get the RAID subsystem 
> working again.
> 
> Dmesg with Rev. 1.146 of cam_xpt.c:
> ...
> ahc0: <Adaptec 2940 Ultra2 SCSI adapter (OEM)> port 0xb000-0xb0ff
>  mem 0xfad00000-0xfad00fff irq 19 at device 14.0 on pci0
> ahc0: [GIANT-LOCKED]
> aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs:
> ...
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <easyRAID Volume Set # 00 R001> Fixed Direct Access SCSI-3 device
> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing 
> Enabled
> da0: 953899MB (1953585152 512 byte sectors: 255H 63S/T 121605C)
> ...

The device firmware is probably broken with respect to higher LUNs...

> It seems to report itself as SCSI-3 but dislikes to get probed for too many 
> LUN's...

You can disable probing high LUNs by putting a CAM_QUIRK_NOHILUNS quirk in
cam_xpt.c for that device.

We knew there was the possibility that the change would break a device or
two (thus the reason Matt put in the quirk entry), but hopefully there
won't be too many devices broken by that change.

Ken
-- 
Kenneth Merry
ken at kdm.org