Description of problem: The stock kernel is lacking multiple LUN probing. When attaching a USB multi-slot memory card reader, the stock kernels only see the first slot. The kernel then needs to be reconfigured to with a resulting config file containing: CONFIG_SCSI_MULTI_LUN=y Version-Release number of selected component (if applicable): All current kernel releases. How reproducible: Steps to Reproduce: 1. Attach multi-slot card reader 2. Insert memory cards in each slot 3. Attempt to mount resulting filesystem Actual results: System sees device, assigns (in my case) /dev/sdb (which corresponds on my SmartDisk 6IN1USB reader to the SecureDigital slot) to the first slot. Attempting to read cards in the other slots (in my case, SmartMedia and Compact Flash, respectively) yield messages that there's no media, the device is write protected, and/or that the device is not a valid block device. Attempts to mount partitions on /dev/sdc or /dev/sdd also yield messages that they're not block devices. USB device detection, upon attaching the card reader, only lists /dev/sdb as even being detected. Expected results: Upon connection of the card reader, the USB detection process should show devices sdb, sdc and sdd (for the SD, SM and CF slots, respectively. Additional info: After compiling with the "CONFIG_SCSI_MULTI_LUN=y" configuration option, the same reader is recognized with all three slots being assigned their respective device names, and I am able to mount the filesystems from the respective memory cards. My thought is that the multi-lun option should probably be defaulted to enabled for the stock kernels...especially given the increasing popularity of not only the USB flash memory readers, but the multi-slot, multiple media readers.
Changing to kernel component (kernelcfg was a tool in old releases to edit modules.conf). Read ya, Phil
we can't enable this option by default since several scsi devices crash the scsi bus when this is turned on. However this is a runtime option which you can change by setting up a module option. Also if you can attach the contents of the /proc/scsi/scsi file we can whitelist your device for this to be automatic.
Following are the contents of /proc/scsi/scsi: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170 Rev: SAH0 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: Model: USB Card Reader Rev: 1.01 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 01 Vendor: Model: USB Card Reader Rev: 1.01 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 02 Vendor: Model: USB Card Reader Rev: 1.01 Type: Direct-Access ANSI SCSI revision: 02 The important part, of course, is the scsi1 section. This is a "SmartDisk 6IN1USB" card reader. I don't suspect that it really uses much else that's different from other multi-slot card readers. Also, I'd be happy to try out the module option, going with a stock kernel, if you'd care to provide it. Thanks for looking into this.
- When using RAID storage configured with Logical Unit Numbers (LUNs) greater than zero, it is necessary to enable LUN support by adding the following entry to the /etc/modules.conf file: options scsi_mod max_scsi_luns=255 After modifying modules.conf, it is necessary to rebuild the initial ramdisk using `mkinitrd`. Refer to The Official Red Hat Linux Customization Guide for more information about creating the ramdisk image with mkinitrd.
Humm. The vendor ID shown above is blank. The whitelist in Linux scsi_scan.c identifies products that are capable of certain capabilities, like support for LUN > 0, by matching the vendor ID and the product ID in the standard SCSI Inquiry data. This device is apparently somewhat lacking in its emulation of the SCSI Inquiry data. I don't think it would be a good idea to whitelist "USB Card Reader" from all vendors. So, unless the Inquiry data gets fixed, it looks like you will need to stick with the scsi_mod parameter for this device.
Unfortunately, adding "options scsi_mod max-scsi_luns=255" to /etc/modules.conf and recreating the initrd didn't seem to work. I upgraded to the latest errata kernel, and then implemented the suggestion, and the system isn't seeing the reader's other 2 slots. The option seems to load, but when I attach the card reader, it still only gives me access to one slot, labelling it as /dev/sdb. Output of modinfo: modinfo scsi_mod -p scsi_logging_level_Raf3dd7dc int, description "SCSI logging level; should be zero or nonzero" scsihosts string max_scsi_luns int, description "last scsi LUN (should be between 1 and 2^32-1)" scsi_allow_ghost_devices int, description "allow devices marked as being offline to be accessed anyway (0 = off, else allow ghosts on lun 0 through allow_ghost_devices - 1" Any other suggestions?
Have a look at Bug 92263 for more information.
As noted in bug #92263, adding ".o" to the module name to the options line in /etc/modules.conf does cause the options line to work. It was noted in that bug that the mkinitrd behavior changed between RHL8 and RHL9, in that up to and including RHL8, the ".o" was not required on the options line, and that now, in RHL9, it is. Is this a bug introduced with the mkinitrd included in RHL9, or a purposeful change in mkinitrd's behavior? And, if it is a bug, will it be addressed? Thanks.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/