Red Hat Bugzilla – Bug 41009
parameter max_scsi_luns=<n> (where n>1) to boot kernel does not cause scsi probe past lun 0
Last modified: 2005-10-31 17:00:50 EST
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. How reproducible: Always 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... Additional info:
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. Thanks.
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 yet.
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.