* Adaptec SC4100 AltEvo reports 64 bits of LUN - kernel panics (2.6.9-2.6.12)
@ 2005-03-18 18:26 Mr. Berkley Shands
0 siblings, 0 replies; only message in thread
From: Mr. Berkley Shands @ 2005-03-18 18:26 UTC (permalink / raw)
To: linux-scsi
I have an Adaptec 12 bay U320 scsi disk array. It is divided in this
case into 2 sections
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.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2005-03-18 18:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-18 18:26 Adaptec SC4100 AltEvo reports 64 bits of LUN - kernel panics (2.6.9-2.6.12) Mr. Berkley Shands
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox