From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; SunOS 5.6 sun4u)
Description of problem:
Parameter max_scsi_luns=<n> (where n>1) to boot kernel does not cause scsi
probe past lun 0. System is using the aic7xxx.o module.
Steps to Reproduce:
1. Setup system with multiple scsi disks on a single target
2. Boot from 7.1 installation boot floppy
3. At the boot: prompt enter "linux max_scsi_luns=128"
4. cat /proc/scsi/scsi or cat /proc/partitions
Actual Results: cat /proc/scsi/scsi showed three devices. One on target
0, lun 0, one on target 1, lun 0 and one on target 2, lun 0. No devices
past lun 0 were discovered.
Expected Results: expected to see devices at target 0, lun 1; target 0,
lun 2; target 0, lun 3, etc...
It's a quite big problem for Server.Most of tape autoloader use SCSI LUN.
I hope it will be fixed urgently.
I confirmed that parameter max_scsi_luns=1 also doesn't work.
We are seeing the same behavior with a 3584 library and QLogic fibre channel HBAs -- the problem is not isolated to the Adaptec module. We are
currently using the manual workaround, which is *only* suitable in our development environment:
echo "scsi add-single device h b t l" > /proc/scsi/scsi
Where <h,b,t,l> is your SCSI host id, bus, target id, and LUN, respectively.
Thing is, aic7xxx and the other scsi code are modules, and as a result
the lilo option does not apply.
If you add
options scsi_mod max_scsi_luns=128
to /etc/modules.conf and then remake the initrd, it should work.
I tried the module option to the mid-level scsi_mod, and it partially worked -- it does scan higher LUNs. However, it now reports non-existant devices on
an external DASD (IBM FAStT200).
The FAStT200 is a RAID device that supports partitioning the disks into multiple virtual disks, each on a separate LUN. Our current configuration should
only show SCSI devices on LUNs 0-4 and 31. Unfortunately, devices are being reported on all LUNs 0-31. Under RH7 on the same machine, only the
devices we expect are showing up. Can anyone else corroborate this?
As for max_scsi_luns being a lilo option, it did work that way in RH7 and RH6.2; does that mean that the mid-level SCSI support was built into the kernel
in those releases? We never recompiled the kernel.
As to the FAStT200 part, yes I've heard of that problem before. You can blame
inconsistent usage of the Online bit in the SCSI INQUIRY return data for this
particular problem. Evidently, your array uses the bit the same way that the
AMI MegaRAID driver does logical drives. Of course, once we change the SCSI mid
layer to work with your array and the AMI stuff, the EMC arrays start having
problems :-( A more robust solution to this problem is in the works.
The second question, the answer is yes. In earlier versions of Red Hat the SCSI
code was compiled directly into the kernel instead of as a module.
Any ETA for a fix? I don't see any dates associated with this bug.
For which fix? If you are referring to the max_scsi_luns=x doesn't work at the
lilo command line, then that isn't a bug and won't be fixed. If you are
referring to the scanning of SCSI devices by the mid layer code, then that
represents a change to the mid layer SCSI code and won't be done for a bit still
In fact, since this bug was originally about the max_scsi_luns thing, I'm
closing this bug out as NOTABUG. For those people interested in the problems
related to scanning of devices and whether or not an offline device is detected
or ignored, please go see bug report 54333 and add yourself to the Cc: list
there to be kept up to date.
Please open up the permissions on bug 54333 so we can follow it.