Multi-Card reader (SD, MMC, etc) and CONFIG_SCSI_MULTI_LUN kernel option in 34.0.2. Workaround
Hi folks,
Im trying to get a multi-card reader on centos (SD, MMC, and so, 4 card slots) and i have read (http://www.cs.sfu.ca/~ggbaker/personal/cf-linux) that CONFIG_SCSI_MULTI_LUN should be enabled on kernel (=Y) but current 34.0.2 doesn't have it enabled by default, is there any particular reason to not be enabled?
By the other hand i've also tweak the /etc/grub.conf file to boot the kernel with max_luns=32 and results are the same, only scsc lun=0 is recognized.
At the same time using the workaround mentioned in the link pasted b4 regarding to modify the /etc/modules.conf to include 'options scsi_mod max_scsi_luns=8' gives the same results, no detection at all for the card slots.
[root@sparkbox ~]# cat /proc/bus/usb/devices T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0644 ProdID=0200 Rev= 4.00 S: Manufacturer=TEAC S: Product=CA-200 S: SerialNumber=0000020307B2 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb- storage E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
and /var/log/dmesg still shows: <...> scsi3 : SCSI emulation for USB Mass Storage devices Vendor: TEAC Model: USB HS-CF Card Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sdc at scsi3, channel 0, id 0, lun 0 USB Mass Storage device found at 7 <...>
Instead of (if i understand well for this scsi3 line) after a
[root@sparkbox]# sg_scan -i (it should show)
/dev/sg2: scsi3 channel=0 id=0 lun=0 [em] type=0 Generic STORAGE DEVICE 0128 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0] /dev/sg3: scsi3 channel=0 id=0 lun=1 [em] type=0 Generic STORAGE DEVICE 0128 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0] /dev/sg4: scsi3 channel=0 id=0 lun=2 [em] type=0 Generic STORAGE DEVICE 0128 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0] /dev/sg5: scsi3 channel=0 id=0 lun=3 [em] type=0 Generic STORAGE DEVICE 0128 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0]
But actually,
[root@sparkbox ~]# sg_scan -i [root@sparkbox ~]# (shows nothing)
And
[root@sparkbox ~]# sg_map Stopping because no sg devices found Strange, could not find device /dev/sda mapped to sg device?? Strange, could not find device /dev/sdb mapped to sg device?? Strange, could not find device /dev/sdc mapped to sg device?? Strange, could not find device /dev/sdd mapped to sg device??
Looking at SCSI:
[root@sparkbox ~]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: HDS728080PLA380 Rev: PF2O Type: Direct-Access ANSI SCSI revision: 05 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: Genesys Model: USB to IDE Disk Rev: 0002 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: TEAC Model: USB HS-CF Card Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: Model: USB DISK Pro Rev: 1.1b Type: Direct-Access ANSI SCSI revision: 02
And finally doing the last workaround found in the link from Greg Baker article for my scsi3 chain:
[root@sparkbox ~]#echo >/proc/scsi/scsi "scsi add-single-device 3 0 0 1" [root@sparkbox ~]#echo >/proc/scsi/scsi "scsi add-single-device 3 0 0 2" [root@sparkbox ~]#echo >/proc/scsi/scsi "scsi add-single-device 3 0 0 3"
Solves the identification:
[root@sparkbox ~]# cat /proc/scsi/scsi Attached devices: <...> Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: TEAC Model: USB HS-CF Card Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 01 Vendor: TEAC Model: USB HS-xD/SM Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 02 Vendor: TEAC Model: USB HS-MS Card Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 03 Vendor: TEAC Model: USB HS-SD Card Rev: 4.00 Type: Direct-Access ANSI SCSI revision: 02
Now, even without update the udev rules with a new rule It seems to work after inserting the SD (1GB card) card on card-reader, from dmesg:
<...> SCSI device sdg: 2012160 512-byte hdwr sectors (1030 MB) sdg: Write Protect is off sdg: Mode Sense: 23 00 00 00 sdg: assuming drive cache: write through SCSI device sdg: 2012160 512-byte hdwr sectors (1030 MB) sdg: Write Protect is off sdg: Mode Sense: 23 00 00 00 sdg: assuming drive cache: write through sdg: sdg1 <...>
Mounting the correct SD card on fstab and only remaining to update permissions/udev or pamconsole (not sure where) to get RW access for user space.
Hope it helps and just to clarify for mentionned CONFIG_SCSI_MULTI_LUN option in kernel.
Jose.
J.J. Garcia wrote:
Hi folks,
Im trying to get a multi-card reader on centos (SD, MMC, and so, 4 card slots) and i have read (http://www.cs.sfu.ca/~ggbaker/personal/cf-linux) that CONFIG_SCSI_MULTI_LUN should be enabled on kernel (=Y) but current 34.0.2 doesn't have it enabled by default, is there any particular reason to not be enabled?
IIRC scanning LUNs freaks out some (real) SCSI hardware. IIRC for Fedora they are creating a whitelist so that known OK devices are scanned.
By the other hand i've also tweak the /etc/grub.conf file to boot the kernel with max_luns=32 and results are the same, only scsc lun=0 is recognized.
At the same time using the workaround mentioned in the link pasted b4 regarding to modify the /etc/modules.conf to include 'options scsi_mod max_scsi_luns=8' gives the same results, no detection at all for the card slots.
Shouldn't that be max_luns=8, not max_scsi_luns=8 ?
El jue, 10-08-2006 a las 08:38 -0400, William Hooper escribió:
J.J. Garcia wrote:
Hi folks,
Im trying to get a multi-card reader on centos (SD, MMC, and so, 4 card slots) and i have read (http://www.cs.sfu.ca/~ggbaker/personal/cf-linux) that CONFIG_SCSI_MULTI_LUN should be enabled on kernel (=Y) but current 34.0.2 doesn't have it enabled by default, is there any particular reason to not be enabled?
IIRC scanning LUNs freaks out some (real) SCSI hardware. IIRC for Fedora they are creating a whitelist so that known OK devices are scanned.
According to following link dated at November 98 i get this idea, don't know if anybody has last news ... this is why i raised the question http://www.uwsg.iu.edu/hypermail/linux/kernel/9811.3/0378.html
"When enabling both CONFIG_SCSI_MULTI_LUN and ide-scsi emulation, the ATAPI devices will usually respond to every LUN. This can lead to an (as yet untraced) oops."
And also in http://www.redhat.com/archives/rhl-beta-list/2004- May/msg00235.html
Mentionning http://www.linuxjournal.com/article/6687
And http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=37935
I had no more time to check the actual patchlevel status in our kernel, feel free to do it.
By the other hand i've also tweak the /etc/grub.conf file to boot the kernel with max_luns=32 and results are the same, only scsc lun=0 is recognized.
At the same time using the workaround mentioned in the link pasted b4 regarding to modify the /etc/modules.conf to include 'options scsi_mod max_scsi_luns=8' gives the same results, no detection at all for the card slots.
Shouldn't that be max_luns=8, not max_scsi_luns=8 ?
I have no idea about it, if you follow the google links you will have options for anybody in anyway, at least what i have found about it:
http://www.redhat.com/archives/rhl-beta-list/2004-May/msg00238.html
And also the main link i posted from Greg Baker:
http://www.cs.sfu.ca/~ggbaker/personal/cf-linux
If you have a better approach to do it, feel free to post it, this mail was only my way to start up ideas with a single quick'n'dirty workaround for me in this case ...
TIA
Jose.
J.J. Garcia wrote: [snip]
At the same time using the workaround mentioned in the link pasted b4 regarding to modify the /etc/modules.conf to include 'options scsi_mod max_scsi_luns=8' gives the same results, no detection at all for the card slots.
Shouldn't that be max_luns=8, not max_scsi_luns=8 ?
I have no idea about it, if you follow the google links you will have options for anybody in anyway, at least what i have found about it:
http://www.redhat.com/archives/rhl-beta-list/2004-May/msg00238.html
That message is in the FC1 timeframe. FC1 was based on a 2.4 kernel and IIRC the option name changed with the 2.6 kernel. This is why I asked.
And also the main link i posted from Greg Baker:
The author specifically states he is talking about a 2.4 kernel and hasn't tested adding the option to the modules.conf.
Quoting "J.J. Garcia" stigmatedbrain@gmail.com:
Hi folks,
Im trying to get a multi-card reader on centos (SD, MMC, and so, 4 card slots) and i have read (http://www.cs.sfu.ca/~ggbaker/personal/cf-linux) that CONFIG_SCSI_MULTI_LUN should be enabled on kernel (=Y) but current 34.0.2 doesn't have it enabled by default, is there any particular reason to not be enabled?
Because some broken SCSI devices choke on that, and you don't really need it.
By the other hand i've also tweak the /etc/grub.conf file to boot the kernel with max_luns=32 and results are the same, only scsc lun=0 is recognized.
Not sure, but on command line you might need to specify for what module the option is (also, it is loadable module, not part of static kernel). Try passing "scsi_mod.max_luns=32" to the kernel.
Have you tried putting it into /etc/modprobe.conf (options scsi_mod max_luns=32) and rebuilding initrd image after that? That's the way I was doing it so far, and it always worked for me.
Also, since it is really USB device, could it be it doesn't have LUNs at all?
El jue, 10-08-2006 a las 09:45 -0500, Aleksandar Milivojevic escribió:
Quoting "J.J. Garcia" stigmatedbrain@gmail.com:
Hi folks,
Im trying to get a multi-card reader on centos (SD, MMC, and so, 4 card slots) and i have read (http://www.cs.sfu.ca/~ggbaker/personal/cf-linux) that CONFIG_SCSI_MULTI_LUN should be enabled on kernel (=Y) but current 34.0.2 doesn't have it enabled by default, is there any particular reason to not be enabled?
Because some broken SCSI devices choke on that, and you don't really need it.
By the other hand i've also tweak the /etc/grub.conf file to boot the kernel with max_luns=32 and results are the same, only scsc lun=0 is recognized.
Not sure, but on command line you might need to specify for what module the option is (also, it is loadable module, not part of static kernel). Try passing "scsi_mod.max_luns=32" to the kernel.
Well, finally i found a link following your steps (same as the Will Hooper mail about 'max_luns' instead of using 'CONFIG_SCSI_MULTI_LUN'):
http://www.redhat.com/archives/kickstart-list/2005-August/msg00058.html
In our case, if i understand correctly
# echo "options scsi_mod max_luns=32" >> /etc/modprobe.conf # cd /boot # cp initrd-2.6.9-34.0.2.EL.img initrd-2.6.9-34.0.2.EL.img.last # mkinitrd -f -v initrd-2.6.9-34.0.2.EL.img 2.6.9-34.0.2.EL # reboot
I did that but in another test machine using centos-plus kernel instead the 2.6.9-34.0.2.EL kernel (i'll do next days on that kernel) and finally after booting IT WORKED as you said !!!
Now in dmesg you have:
<...> SCSI subsystem initialized Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices Vendor: USB2.0 Model: CardReader CF Rev: 0100 Type: Direct-Access ANSI SCSI revision: 02 Vendor: USB2.0 Model: CardReader SM XD Rev: 0100 Type: Direct-Access ANSI SCSI revision: 02 Vendor: USB2.0 Model: CardReader MS Rev: 0100 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi removable disk sdb at scsi0, channel 0, id 0, lun 1 Attached scsi removable disk sdc at scsi0, channel 0, id 0, lun 2 Vendor: USB2.0 Model: CardReader SD Rev: 0100 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sdd at scsi0, channel 0, id 0, lun 3 USB Mass Storage device found at 3 usbcore: registered new driver usb-storage USB Mass Storage support registered. <...>
But since in initrd image im not using the scsi facilities (at least for this subject and after watching the mkinitrd log msg) i replaced the original one with the one i re-created and i just simple left the modprobe.conf with the new conf for scsi_mod max_luns=32, rebooted and the results were the same, the card-reader was recognized since the LUNs were taken in account as expected.
That leads to me to conclude that there's no need in rebuilding the initrd image, correct me if im wrong, but simple tu use the correct parameter for change the LUNs observed in scsi_mod.
Have you tried putting it into /etc/modprobe.conf (options scsi_mod max_luns=32) and rebuilding initrd image after that? That's the way I was doing it so far, and it always worked for me.
Also, since it is really USB device, could it be it doesn't have LUNs at all?
Thank's both you and Will
Jose.
P.S: Nice Photos...
Quoting "J.J. Garcia" stigmatedbrain@gmail.com:
That leads to me to conclude that there's no need in rebuilding the initrd image, correct me if im wrong, but simple tu use the correct parameter for change the LUNs observed in scsi_mod.
Let me guess, your boot drive is on IDE?
You don't have any boot devices that require SCSI support, so scsi_mod was loaded after the boot from the /lib/modules directory. If your boot device was SCSI (or anything else that might require scsi_mod), scsi_mod would be loaded from initrd image (not from /lib/modules) and would use modprobe.conf that is also part of initrd image (not the /etc/modprobe.conf).
El jue, 10-08-2006 a las 09:45 -0500, Aleksandar Milivojevic escribió:
Quoting "J.J. Garcia" stigmatedbrain@gmail.com:
<...>
Have you tried putting it into /etc/modprobe.conf (options scsi_mod max_luns=32) and rebuilding initrd image after that? That's the way I was doing it so far, and it always worked for me.
Question rised:
Is it better the approach of "# echo >/proc/scsi/scsi "scsi add-single- device x 0 0 a" where 'X'=scsi channel, and 'a' value from 1 to n-1 (N=max LUNS in the card reader) than this actual of modifying the kernel module option? I mean, to try to minimize the risks of having kernel oops in automatic probing luns.
Since Fedora folks are whitelisting this units that leads me to that conclusion and im not sure about it and not an expert ...
Ideas allways wellcomed
Jose
Also, since it is really USB device, could it be it doesn't have LUNs at all?
-
Aleksandar Milivojevic -
J.J. Garcia -
William Hooper