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
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.
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)
Problem still exists 2.4.20-24.9 I am also using Adaptec aic7899 with the AIC7xxx driver. Anyone have a work around?
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
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.
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
Created attachment 96352 [details] Patch for mkinitd 3.4.42
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.
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?
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.
This is fixed in FC1 and later mkinitrd