Bug 98024 - Kernels are not configured/compiled with SCSI Multiple LUN probing.ghost
Kernels are not configured/compiled with SCSI Multiple LUN probing.ghost
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-25 12:09 EDT by Mike Burger
Modified: 2007-04-18 12:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Burger 2003-06-25 12:09:10 EDT
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.
Comment 1 Phil Knirsch 2003-07-07 09:44:48 EDT
Changing to kernel component (kernelcfg was a tool in old releases to edit
modules.conf).

Read ya, Phil
Comment 2 Arjan van de Ven 2003-07-07 09:48:44 EDT
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.
Comment 3 Mike Burger 2003-07-07 10:32:22 EDT
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.
Comment 4 Arjan van de Ven 2003-07-07 10:36:33 EDT
  - 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.
Comment 5 Tom Coughlan 2003-07-07 18:04:23 EDT
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.
Comment 6 Mike Burger 2003-07-23 09:27:19 EDT
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?
Comment 7 wilburn 2003-12-06 10:07:22 EST
Have a look at Bug 92263 for more information.
Comment 8 Mike Burger 2003-12-06 10:53:05 EST
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.
Comment 9 Bugzilla owner 2004-09-30 11:41:12 EDT
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/

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