Bug 92263 - Upgrade from RH8.0 to 9.0 Multiple SCSI LUNS for Zero-D X not Found
Upgrade from RH8.0 to 9.0 Multiple SCSI LUNS for Zero-D X not Found
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-04 06:11 EDT by Chris Mayo
Modified: 2007-04-18 12:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-10 01:54:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for mkinitd 3.4.42 (472 bytes, patch)
2003-12-04 15:53 EST, wilburn
no flags Details | Diff

  None (edit)
Description Chris Mayo 2003-06-04 06:11:28 EDT
Description of problem:
On upgrading from RedHat 8.0 to 9.0 (i686 SMP kernel) multiple SCSI LUNS
reported by Zero-D X -3i storage array are not found, despite adding 
options scsi_mod max_scsi_luns=255
to /etc/modules.conf
and making new initrd image.

Still a problem with latest 2.4.20-18.9smp

Compiling a custom kernel from kernel-source-2.4.20-18.9.i386.rpm with
CONFIG_SCSI_MULTI_LUN=y does solve the problem.

Output of cat /proc/scsi/scsi in additional information below.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Add options scsi_mod max_scsi_luns=255 to /etc/modules.conf
2. mkinitrd
3. reboot
    

Actual Results:  Only LUN 0 from storage array seen by Linux.

Expected Results:  All LUNS (partitions) reported by storage array.

Additional info:

cat /proc/scsi/scsi

Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: FUJITSU  Model: MAN3184MC        Rev: 5508
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: PE/PV    Model: 1x3 SCSI BP      Rev: 0.28
  Type:   Processor                        ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 05 Lun: 00
  Vendor: Zero-D X Model: -3i              Rev: 0001
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 05 Lun: 01
  Vendor: Zero-D X Model: -3i              Rev: 0001
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 05 Lun: 02
  Vendor: Zero-D X Model: -3i              Rev: 0001
  Type:   Direct-Access                    ANSI SCSI revision: 03
Comment 1 Tom Coughlan 2003-06-05 14:25:15 EDT
The results with CONFIG_SCSI_MULTI_LUN should be the same as with "options
scsi_mod max_scsi_luns=255".  I will look into it.

I assume there is nothing interesting in /var/log/messages when the system fails
to configure the LUNs > 0 (?).

What HBA and driver are you using?

Aside:  the vendor/model strings look strange.

I would think that
Vendor: Zero-D X Model: -3i   
should be:
Vendor: Zero-D   Model: X-3i   

Looks like they got their Inquiry data messed up.
Comment 2 Chris Mayo 2003-06-06 05:16:38 EDT
It's an Adaptec aic7899, using AIC7XXX driver, /var/log/messages extract below
with no apparent problems.

You are right in that it is a 'Zero-D' X-3i

Thanks


Jun  3 15:09:23 kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER,
Rev 6.2.8
Jun  3 15:09:23 kernel:         <Adaptec aic7899 Ultra160 SCSI adapter>
Jun  3 15:09:23 kernel:         aic7899: Ultra160 Wide Channel A, SCSI Id=7,
32/253 SCBs
Jun  3 15:09:23 kernel: 
Jun  3 15:09:23 kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER,
Rev 6.2.8
Jun  3 15:09:23 kernel:         <Adaptec aic7899 Ultra160 SCSI adapter>
Jun  3 15:09:23 kernel:         aic7899: Ultra160 Wide Channel B, SCSI Id=7,
32/253 SCBs
Jun  3 15:09:23 kernel: 
Jun  3 15:09:23 kernel: blk: queue dfd97014, I/O limit 4095Mb (mask 0xffffffff)
Jun  3 15:09:23 kernel:   Vendor: FUJITSU   Model: MAN3184MC         Rev: 5508
Jun  3 15:09:23 kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 03
Jun  3 15:09:23 kernel: blk: queue dfd97214, I/O limit 4095Mb (mask 0xffffffff)
Jun  3 15:09:23 kernel:   Vendor: PE/PV     Model: 1x3 SCSI BP       Rev: 0.28
Jun  3 15:09:23 kernel:   Type:   Processor                          ANSI SCSI
revision: 02
Jun  3 15:09:23 kernel: blk: queue dfd97614, I/O limit 4095Mb (mask 0xffffffff)
Jun  3 15:09:23 kernel: scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
Jun  3 15:09:24 kernel:   Vendor: Zero-D X  Model: -3i               Rev: 0001
Jun  3 15:09:24 kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 03
Jun  3 15:09:24 kernel: blk: queue dfd97814, I/O limit 4095Mb (mask 0xffffffff)
Jun  3 15:09:24 kernel: scsi1:A:5:0: Tagged Queuing enabled.  Depth 253
Jun  3 15:09:24 kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Jun  3 15:09:24 kernel: Attached scsi disk sdb at scsi1, channel 0, id 5, lun 0
Jun  3 15:09:24 kernel: (scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset
127, 16bit)
Jun  3 15:09:24 kernel: SCSI device sda: 35566478 512-byte hdwr sectors (18210 MB)
Jun  3 15:09:24 kernel: Partition check:
Jun  3 15:09:24 kernel:  sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
Jun  3 15:09:24 kernel: (scsi1:A:5): 160.000MB/s transfers (80.000MHz DT, offset
31, 16bit)
Jun  3 15:09:24 kernel: SCSI device sdb: 192937984 512-byte hdwr sectors (98784 MB)
Comment 3 wilburn 2003-12-03 17:37:38 EST
Problem still exists 2.4.20-24.9 I am also using Adaptec aic7899 with
the AIC7xxx driver.

Anyone have a work around?
Comment 4 wilburn 2003-12-03 17:47:58 EST
This is not specific to the Zero-D X. My device reports as (extracted
from /proc/scsi/scsi)

Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: THINK CO Model: MPUTER           Rev: 0001
  Type:   Direct-Access                    ANSI SCSI revision: 03


Should have another enter for LUN 1
Comment 5 Tom Coughlan 2003-12-04 11:13:34 EST
Both of these devices seem to have badly formated Inquiry data:

Vendor: Zero-D X Model: -3i  should be:
Vendor: Zero-D   Model: X-3i

Vendor: THINK CO Model: MPUTER should be:
Vendor: THINK    Model: COMPUTER 

It might be worthwhile to get a dump of the Inquiry data to see
whether other fields are misplaced.  This could confuse aic7xxx or the
SCSI mid-layer.  The sg_utils at 
http://www.torque.net/sg/u_index.html
can be used to dump the Inquiry data.

You might also try a newer version of the aic7xxx driver.
Comment 6 wilburn 2003-12-04 13:51:10 EST
The problem may be with mkinitrd

I compared two machines, one RH8 one RH9. Since I don't have a RH8
with a SCSI adapter, I picked a RH9 w/o SCSI as well.

Steps (both machines):

1. Add 'options scsi_mod max_scsi_luns=255' to /etc/modules.conf

2. Run 'mkinitrd --with=scsi_mod test.img.gz 2.4.20-24.8'
    or 'mkinitrd --with=scsi_mod test.img.gz 2.4.20-24.9'
   Option needed since no SCSI adapters.

3. gzip -d test.img.gz

4. mount -o loop test.img /mnt/temp

5. cat /mnt/temp/linuxrc

Results:

For RH8 machine, line in the script that loads scsi_mod looks like

    insmod /lib/scsi_mod.o max_scsi_luns=255

For RH9 machine it looks like

    insmod /lib/scsi_mod.o
Comment 7 wilburn 2003-12-04 15:53:12 EST
Created attachment 96352 [details]
Patch for mkinitd 3.4.42
Comment 8 wilburn 2003-12-06 10:05:13 EST
One more thing I should point out:

This bug will prevent ANY options in modules.conf from being picked up
by mkinitrd.

The basic problem is that mkinitrd is looking in modules.conf for
entries of the form:

    options {module}.o {options}

instead of

    options {module} {options}

Bug 98024 is probably related.
Comment 9 Mike Burger 2003-12-06 10:46:48 EST
98024 does, indeed, appear to be related.

Adding the ".o" to my options line did take care of my problem.

Why the change in mkinitrd's behavior between 8 and 9?  Is it a bug,
or a purposeful change?  If it is a bug, will it be remedied, is it
remedied by the attached patch, or are we now going to have to make
sure that .o is added to the module name whenever we need to specify
options, like this?
Comment 10 wilburn 2003-12-06 11:33:46 EST
While modifying the modules.conf file works around this bug, it may
cause other problems, for example with modprobe.

The real solution will be to fix mkinitrd.

The relevant change to mkinitrd between RH8 RH9 involves the string
$module which used to be set to the module name, but now includes the
.o extension. The extension is needed to generate the insmod line in
the linuxrc script of the initrd. Previously, .o was appended when
generating this line, now it is a part of $module. I don't know why
this change was made, but an unintended consequence was screwing up
the scan for options in modules.conf. My patch simply goes back to the
old behaviour for $module (w/o the .o) so that the search for options
works, and then sets $module in the new way (with the .o) so the rest
of the script works. I'm sure there is a logically cleaner way to do
this, but that will be up to the RH guys.
Comment 11 Jeremy Katz 2003-12-10 01:54:36 EST
This is fixed in FC1 and later mkinitrd

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