Bug 41009 - parameter max_scsi_luns=<n> (where n>1) to boot kernel does not cause scsi probe past lun 0
parameter max_scsi_luns=<n> (where n>1) to boot kernel does not cause scsi p...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
high Severity high
: ---
: ---
Assigned To: Doug Ledford
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-16 17:25 EDT by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-11 18:36:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-05-16 17:25:01 EDT
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:
Comment 1 Need Real Name 2001-05-18 13:42:59 EDT
It's a quite big problem for Server.Most of tape autoloader use SCSI LUN.
I hope it will be fixed urgently.
Comment 2 Need Real Name 2001-05-18 13:45:10 EDT
I confirmed that parameter max_scsi_luns=1 also doesn't work.
Comment 3 Justin A Irwin 2001-05-21 16:24:27 EDT
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.
Comment 4 Arjan van de Ven 2001-06-06 09:47:19 EDT
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.
Comment 5 Justin A Irwin 2001-06-07 13:31:21 EDT
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.
Comment 6 Doug Ledford 2001-08-23 20:04:05 EDT
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.
Comment 7 Jim McKinstry 2001-10-11 15:57:03 EDT
Any ETA for a fix?  I don't see any dates associated with this bug.
Thanks.
Comment 8 Doug Ledford 2001-10-11 18:36:05 EDT
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.
Comment 9 Doug Ledford 2001-10-11 18:37:50 EDT
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.
Comment 10 Mark Tsombakos 2001-10-25 16:28:07 EDT
Please open up the permissions on bug 54333 so we can follow it.

Note You need to log in before you can comment on or make changes to this bug.