of 6 drives each. Each string of drives reports a "Processor" on unit #15.
Why would the scsi layer scan unit #15 for LUN's? it reports a HUGE number of LUN's,
many times more than 511. 0x908789244a030402 LUNs in some cases. The scsi layer then
attempts to ask each of these LUNS what it is doing, overruns the allocated space, and
panics the kernel. This is independent of the controller. AIC79XX (39320A-R) or LSI Fusion
(LSI22320) all see this device, duly report it to the scsi layer, which 75% of the time panics
and then panics during the panic, or OOPSes and then panics in the OOPS.
Mar 18 12:01:11 typhoon kernel: Vendor: ADAPTEC Model: AltEvo U320 Rev: 0028
Mar 18 12:01:11 typhoon kernel: Type: Processor ANSI SCSI revision: 03
If the reported LUN count is odd, don't bother scanning it. If the reported unit is NOT a disk,
don't scan it. drivers/scsi/scsi_scan.c happily scans ALL the given units, and walks over itself.
I used a redhat es4.0 base on an AMD64 dual opteron with vanilla 2.6.9 - 2.6.12-rc1, all will
crash with this hardware being present.
details are available via email. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
