Red Hat Bugzilla – Bug 127434
Kernel not detecting multiple LUNs on SCSI aic7xxx
Last modified: 2015-01-04 17:07:43 EST
Description of problem:
Previously running RH9 on a system with dual Intel Xeon 3.0 processors
and an Adaptec SCSI Card 39320D, connecting to an external raid which
is divided into two LUNs (Logical Unit Numbers). The first LUN (LUN
0) is 2 TBytes in size and the other (LUN 1) is 1.3 TBytes. Prior to
our system disk dying, this worked fine under RH9. The first LUN was
and is at about 90% usage, and the smaller device was about 60%
We replaced the system disk and decided this might be a good time to
try to move to Fedora Core 2. Everything seems to be fine, with the
exception of the fact that we can no longer see the second LUN (LUN
1). We were instructed by our vendor contact to custom rebuild the
kernel and to add Multiple LUN support. That did not seem to make a
difference, with the only change to the kernel config being the
addition of multiple LUN Support. That suggestion included the
addition of "options scsi_mod.o scsi_max_luns=255" to
the /etc/modules.conf file. We still do not see the second LUN. I
have included below the dmesg from the custom build of kernel-2.6.6-
i686-smp.config for the kernel version 2.6.6-1.435custom. Our vendor
contact seemed to think this is an issue with the 2.6.X kernel.
You might note the section of the dmesg where it says the SCSI "has a
LUN larger than currently supported." Note also that the larger of
two LUNs (LUN 0) mounts just fine. Both LUNs show up during system
startup at the bios level with LUN sizes proper noted when the SCSI
devices are scanned. So it is the kernel that is apparently not
picking up the configuration. During boot, at the bios level when
SCSI devices are scanned, the system identifies this raid as having
0 and LUN 1. Previously in RH9, each LUN appeared to the system
kernel as individual SCSI devices /dev/sdc and /dev/sdd, which were
partitioned as two large individual partitions /dev/sdc1 (2 TBytes)
and /dev/sdd1 (1.3 TBytes) respectively.
In the dmesg included below, it looks like the driver is
misinterpreting data relating the LUNs. Instead of reporting small
integers like the 0 and 1 as I would expect, it has these huge hex
numbers associated with it. See attached.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install Fedora Core 2 with an external raid configured with
3.Check dmesg, or fdisk -l for additional LUN
You only see the first LUN. fdisk appears as though the existing LUN
consists of the entire RAID.
Expect to see LUN 0 and LUN 1 as was previously seen before the
system disk crashed, when it was running RedHat 9.0.
Created attachment 101711 [details]
In the dmesg included, it looks like the driver is misinterpreting data
relating the LUNs. Instead of reporting small integers like the 0 and 1 as I
would expect, it has these huge hex numbers associated with it. See below.
Just so you know, for a 2.6 kernel you need to edit /etc/modprobe.conf
Thank you for your response. I had to drop my system back down to
Fedora Core 1, which is working. I actually did try both the
/etc/modprobe.conf and the /etc/modules.conf with no success in either
case. My understanding was that the custom kernel build with Multiple
LUN support added, would not require the either one of those files.
However, I believe I built the custom kernel with the entries also.
Even though we are back to Fedora Core 1, we would still like to get
this resolved. The only problem is that right now I don't have a test
system to experiment. I could possibly get our vendor contact to try
a few things if you believe you have a potential solution.
There are newer test kernels available from the following places:
+ rawhide (a.k.a. fc-devel)
+ FC3 test 1
You could try one of these newer kernels and see if it's something
that's been fixed upstream (and therefore in these kernels). (My
experience is that it's actually possible to use these kernels on FC1
much of the time, so you may be able to test without having to upgrade
your system to FC2.) I don't know how likely this is to fix your
The only other suggestion I have is to try asking on the linux-scsi
My apologees. I thought I had included it in my original attachment
that I had also tried additional kernels of version 2.6.7-X with no
additional success there either. Thanks for the direction on the
linux-scsi list. I had tried another list with not much response as
A vendor contact has informed me that in their testing, this is
apparently a kernel 2.6.X problem, and not specific to the adaptec
drivers. The large hexadecimal LUN numbers noted in the dmesg output
show up even with a single LUN, if the raid size is greater than about
1 TB. They have also observed this behavior with cards other than
I think this is related to using REPORT_LUNS, rather than sequential
scanning, where the REPORT_LUNS response is getting mis-read. The
kernel will fall back to sequential scanning if REPORT_LUNS fails (see
scsi_scan.c), but it doesn't see the huge LUN values as errors.
The REPORT_LUNS bug should be fixed, but there should probably be a
kernel option to force sequential scanning.
I'm having this problem on FC3. I will try disabling REPORT_LUNS in
the source, and see if LUN 1 becomes available.
Workaround: Hey, I figured out that you can manually scan individual
LUNs via /procfs with:
echo scsi add-single-device HOST CHANNEL ID LUN >/proc/scsi/scsi
For example, this gets my disk back online:
echo scsi add-single-device 1 0 8 1 >/proc/scsi/scsi
any improvements with the latest updates ?
As an additional datapoint, I see the same-appearing error on a box with the
kernel 2.6.9-5.0.3.ELsmp x86_64
two 3ware 9500S-12MI cards
24x 400GB disks attached to 3ware cards
latest 3w-9xxx driver from 3ware website
dual Xeon EM64T
In my case, I only have one LUN per SCSI ID, one SCSI ID per 400GB disk, and
the real LUN is seen fine, so I have no problems using my disks.
Is there anything else I can give you to help track this down?
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.