Bug 85851 - Cardreader problem and CONFIG_SCSI_MULTI_LUN in .config file
Cardreader problem and CONFIG_SCSI_MULTI_LUN in .config file
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-09 07:38 EST by Henry Leung
Modified: 2007-04-18 12:51 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-02 00:30:32 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 Henry Leung 2003-03-09 07:38:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Dear developers,

  I got a Filand 6-in-1 cardreader with multiple slots. It's upper slot is SCSI
LUN 0, and the lower slot is LUN 1. Therefore to make it works properly, the
kernel must support multiple SCSI LUN, i.e. set CONFIG_SCSI_MULTI_LUN=y in the
.config file.

  Unfortunately the RHL kernel has turned it off. However, as this kind of
cardreaders are getting popular, I suggest the kernel should enable multiple LUN
by default.


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


How reproducible:
Always

Steps to Reproduce:
1. Press Ctrl-Alt-F1 and login as root.
2. Attach a Filand 6-in-1 cardreader to one of the USB ports (actually the
situation should be the same for all kinds of cardreaders those support multiple
card types)
3. Type cat /proc/scsi/scsi
4. Observe the LUN number detected.
    

Actual Results:  The kernel only detects LUN 0 (the LUN of the upper slot). The
lower slot cannot be detected

Expected Results:  To make the lower slot working, it should be able to detect
LUN 1.

Additional info:

To make this work, I have to set the parameter CONFIG_SCSI_MULTI_LUN=y in the
config file and re-compile the kernel. Then it works:

[hleung@localhost linux.20-ac2]$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor:          Model: USB Card Reader  Rev: 3.02
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 00 Lun: 01
  Vendor:          Model: USB Card Reader  Rev: 3.02
  Type:   Direct-Access                    ANSI SCSI revision: 02

[hleung@localhost linux.20-ac2]$
Comment 1 Arjan van de Ven 2003-03-09 07:41:50 EST
there is a problme with making this the default: there are quite a few scsi
devices that will just lock up the scsi bus when this is in use. HOWEVER the
good news is that this is a runtime option....
Comment 2 Dan Berger 2003-08-17 01:43:17 EDT
following up on the last update:

this can be configured at runtime - add the following to /etc/modules.conf:

options scsi_mod max_scsi_luns=8

If you have something with more than 8 luns, change 8 to something higher.  (4
is probably a reasonable value as well, 8 is pretty arbitrary.)

The problem is that if you have a real scsi controller - this won't have any
effect.  See, if you have scsi hardware mkinitrd will include mod_scsi in your
initial ramdisk - so the module will get loaded without being passed that parameter.

One solution is to pass mkinitrd the --omit-scsi-modules - the other is to pass
the argument to the kernel via the bootloader. 

Unfortunately, these card readers are becoming more common - and this sort of
"black magic" to get them working is really annoying to a "normal user" (read
windows convert) not accustomed to tweaking config files.
  
Comment 3 Arjan van de Ven 2003-08-17 10:04:22 EDT
this is why we add all "known good" ones to the whitelist so that this becomes
automatic
Comment 4 Ben FrantzDale 2004-05-04 04:35:55 EDT
Another for the whitelist: 
vend/prod 0x781/0x830 is a SanDistk ImageMate. For more, see
http://www.linuxjournal.com/article.php?sid=6687
Comment 5 Tom Coughlan 2004-05-04 08:21:17 EDT
Ben,

Thanks for the information.  In order to update the whitelist I need
the exact vendor ID and product ID from the SCSI Inquiry data.  This
is shown by Linux in the /proc/scsi/scsi file after the device is
configured.  Does this device show exactly "SanDisk" and "ImageMate"
(case matters)?

Thanks.
Comment 6 Ben FrantzDale 2004-05-04 10:54:43 EDT
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: SanDisk  Model: ImageMate CF-SD1 Rev: 0100
  Type:   Direct-Access                    ANSI SCSI revision: 02
Comment 7 Jason Knight 2004-05-05 21:40:39 EDT
Another for whitelist (Cbox 3 5 1/2 bay with 6in1 card reader):

Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: CBOX3    Model: USB Storage-SMC  Rev: 300A
  Type:   Direct-Access                    ANSI SCSI revision: 02
Comment 8 Ben FrantzDale 2004-05-06 03:14:17 EDT
Out of curiosity, where does this whitelist live? Is it a file or is
it compiled into the driver or kernel?
Comment 9 Tom Coughlan 2004-05-06 09:10:59 EDT
For the 2.4 kernel, the whitelist is in drivers/scsi/scsi_scan.c

This is compiled and linked into scsi_mod.o.
Comment 10 Ernie Petrides 2004-06-16 03:25:23 EDT
A fix for this problem has just been committed to the RHEL3 U3
patch pool this evening (in kernel version 2.4.21-15.12.EL).
Comment 11 Tom Coughlan 2004-06-16 08:17:44 EDT
To be clear, the requests in comment #4 through 7 have been taken care
of in RHEL 3 U3:

+       {"SanDisk", "ImageMate", "*", BLIST_FORCELUN},
+       {"CBOX3", "USB", "*", BLIST_FORCELUN}, 

We will not be able to add the USB cardreader that was initially
requested in this BZ, because the "vendor" field in the Inquiry data
is blank.   
Comment 12 Jason Knight 2004-06-18 23:04:03 EDT
Will this also be taken care of in Fedora? Or should I create another
bug report for that? 
Comment 13 John Flanagan 2004-09-02 00:30:32 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-433.html

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