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.