|Summary:||Want CONFIG_SCSI_MULTI_LUN=y for usb mass storage|
|Product:||[Retired] Red Hat Linux||Reporter:||Need Real Name <sam>|
|Component:||kernel||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-03-26 00:16:59 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Need Real Name 2002-11-13 15:00:03 UTC
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: I wish the kernel were built with: CONFIG_SCSI_MULTI_LUN=y This is becoming more important as compact flash, memory stick etc become more popular and more users buy USB drives for smart medias. Because USB media is treated as SCSI and single products often contain many devices we need CONFIG_SCSI_MULTI_LUN=y for all devices to be discovered. Perhaps you know why CONFIG_SCSI_MULTI_LUN=y is a bad idea? Cos I can't think why it should be disabled. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Follow instructions at http://www.fredshome.org/Linux/UnoMas/ Actual Results: $ cat /proc/scsi/scsi Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: OEI-USB Model: MMC/SD Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 02 most devices are not seen. Expected Results: $ cat /proc/scsi/scsi Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: OEI-USB Model: MMC/SD Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 00 Lun: 01 Vendor: OEI-USB Model: SmartMedia Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 00 Lun: 02 Vendor: OEI-USB Model: CompactFlash Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 00 Lun: 03 Vendor: OEI-USB Model: Memory Stick Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 02 All luns detected Additional info:
Comment 1 Arjan van de Ven 2002-11-13 15:04:54 UTC
it is a bad idea because it breaks several scsi devices (mostly scanners) In addition to that: this is a runtime option! add options scsi_mod max_scsi_luns=127 to /etc/modules.conf
Comment 2 Brian Brock 2003-03-26 00:16:59 UTC
Explanation seems good, resolving as not a bug.
Comment 3 Stephen Walton 2004-02-28 22:53:56 UTC
I know this is ancient history, but I just hit this issue and a minor comment seems in order. After adding the "options" line to /etc/modules.conf, you'll have to rebuild the initrd and reboot for it to take effect. Rebooting with the old initrd but with the options line changed has no effect.
Comment 4 Need Real Name 2004-02-29 08:39:59 UTC
This is a very good point you make. For completeness I record the suggestion that you also need to rebuild initrd because the scsi module is loaded from the ramdisk, possibly because you boot from scsi disks. Folk without scsi boot devices who dont load the scsi module from initrd won't need to do this.
Comment 5 Jerry Uanino 2005-12-27 15:35:03 UTC
Just some additional comments, you can cat commands directly to /proc/scsi/scsi and accomplish this without a reboot... if you are just using some flash card readers, you can always have those commands cat'd in an init script. (see scsi programming howto on ldp for more info).