Bug 435974 - [EMC/QLogic 5.2 bug] When using qla2462 only 512 LUNS discoverd.
[EMC/QLogic 5.2 bug] When using qla2462 only 512 LUNS discoverd.
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Tom Coughlan
Martin Jenner
: OtherQA, Reopened
Depends On:
Blocks: 216992 217106
  Show dependency treegraph
Reported: 2008-03-04 13:46 EST by Marcus Barrow
Modified: 2009-06-19 22:33 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-07 16:52:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marcus Barrow 2008-03-04 13:46:07 EST
In RHEL 5.1 EMC is finding they are unable to discover more then 512 LUNS. The system is a Symm and it 
is configured to provide LUNS 257-2048.

Tested with:
$ cat /proc/scsi/scsi |grep scsi8 | wc –l

Output of a driver with debugging attached.

It is not yet clear if this is a driver or system problem, but will ascertain and update...
Comment 1 Marcus Barrow 2008-03-04 14:56:48 EST
It appears there are boot time parameters to the RHEL Linux scsi module that control this behaviour.

This may not have been discovered during testing because a single target was not used to provide all the 

Haifeng, could you try modifying your boot command line in /boot/grub.conf to include something like:


Comment 2 Andrius Benokraitis 2008-03-04 15:03:23 EST
Marcus, I'm assuming this isn't a regression from RHEL 5.0?
Comment 3 Marcus Barrow 2008-03-04 15:24:56 EST
At the moment it just looks like we need a release note or documentation. It seems the kernel needs
a boot parameter to find more then 512 LUNS from a single target. It appears the testing for number of 
LUNS was done with multiple targets contributing to the total.

So not a regression...

Either Haifeng will get back to us or I will be able to work with QA here to look at the problem soon...

Comment 4 Wayne Berthiaume 2008-03-07 09:18:11 EST
We were able to set max_report_luns in /etc/modprobe.conf and scan 1000+ 
devices. We've tried passing scsi_mod.max_scsi_report_luns on the grub boot 
line but it fails saying it's an unknown parameter. 
Comment 5 Tom Coughlan 2008-03-07 09:46:50 EST
(In reply to comment #4)

>  We've tried passing scsi_mod.max_scsi_report_luns on the grub boot 
> line but it fails saying it's an unknown parameter. 

That was probably caused by my mistake in an mail on the subject. The parameter
name is max_report_luns. The value it is stored in in the code is

module_param_named(max_report_luns, max_scsi_report_luns, int, S_IRUGO|S_IWUSR);
                 "REPORT LUNS maximum number of LUNS received (should be"
                 " between 1 and 16384)");

So, scsi_mod.max_scsi_luns should work.
Comment 6 Tom Coughlan 2008-03-07 09:49:21 EST
(In reply to comment #5)

> So, scsi_mod.max_scsi_luns should work.

That should be scsi_mod.max_report_luns. Brother.

Comment 7 Wayne Berthiaume 2008-03-07 12:09:14 EST
I've prematurely closed this BZ. We were unable to get this to pass on the grub 
boot command line, see comment 6. We did use scsi_mod.max_report_luns=4096 and 
it returned the error. Please advise.
Comment 9 Tom Coughlan 2008-03-07 16:52:59 EST
Documentation/kernel-parameters.txt says:

Module parameters for loadable modules are specified only as the
parameter name with optional '=' and value as appropriate, such as:

        modprobe usbcore blinkenlights=1

Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate, such as:



Our problem is that scsi_mod is not built in to the kernel. It is loaded after
the kernel, too late for the command-line options to be applied. Looks like
modprobe.conf is the way to go. Sorry about that.

By the way, you can have the user check to make sure the parameter took effect
by looking at 

cat /sys/module/scsi_mod/parameters/max_report_luns

A user can also change it there

echo 4096 > /sys/module/scsi_mod/parameters/max_report_luns

after the module is loaded. But then they would have to use additional sysfs
writes to cause a rescan of the targets. Not very practical. 

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