Bug 164665 - ide-cs does not recognize lexar and simple technology CF in cardbus
ide-cs does not recognize lexar and simple technology CF in cardbus
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
https://www.redhat.com/archives/fedor...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-29 16:08 EDT by Paul Dickson
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 063-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-02 23:01:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
kernel-patch (1.41 KB, patch)
2005-07-29 17:41 EDT, Dominik Brodowski
no flags Details | Diff
load modules in the order of how accurate the match is (1.97 KB, patch)
2005-08-01 13:15 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Paul Dickson 2005-07-29 16:08:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050729 Firefox/1.0+

Description of problem:
While the kernel recognizes the SanDisk CF in my cardbus slot, it does NOT recognize the Simple Technology and Lexar Media cards.  No log messages are generated by ide-cs when these cards are inserted, but the SanDisk card is seen and mounted (with corresponding messages logged).

The URL is a link to a dialog on fedora-test about debugging the problem.

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1441_FC5

How reproducible:
Always

Steps to Reproduce:
1. Insert CF card in cardbus adapter.


Actual Results:  Nothing logged and card not mounted.  hda is not added to /sys/block (my hd is on sda, so hda is the first free).

Expected Results:  For the SanDisk card (which does work):

Jul 29 12:35:42 white kernel: hda: SanDisk SDCFB-8, CFA DISK drive
Jul 29 12:35:43 white kernel: ide0 at 0x100-0x107,0x10e on irq 3
Jul 29 12:35:43 white kernel: hda: max request size: 128KiB
Jul 29 12:35:43 white kernel: hda: 15680 sectors (8 MB) w/1KiB Cache, CHS=245/2/32
Jul 29 12:35:43 white kernel: hda: cache flushes not supported
Jul 29 12:35:43 white kernel:  hda: hda1
Jul 29 12:35:43 white kernel: ide-cs: hda: Vcc = 3.3, Vpp = 0.0
Jul 29 12:35:43 white kernel:  hda: hda1
Jul 29 12:35:43 white last message repeated 2 times
Jul 29 12:35:44 white fstab-sync[6162]: added mount point /media/CANON_DC for /dev/hda1
Jul 29 12:35:44 white kernel:  hda: hda1
Jul 29 12:35:54 white fstab-sync[6208]: removed mount point /media/CANON_DC for /dev/hda1

From 'pccardctl ident':
  product info: "SunDisk", "SDP", "5/3 0.6", ""
  manfid: 0x0045, 0x0401
  function: 4 (fixed disk)



Additional info:

Results from 'pccardctl ident' for cards that don't work:

Lexar (16MB):
  product info: "CL ATA FLASH CARD LEXAR  ", "TIDALWV", "V1.00", ""
  manfid: 0x4e01, 0x0200
  function: 4 (fixed disk)

Lexar (160MB):
  product info: "CL ATA FLASH CARD LEXAR  ", "TIDALWV", "V1.01", ""
  manfid: 0x4e01, 0x0200
  function: 4 (fixed disk)

Lexar (512MB):
  product info: "LEXAR ATA FLASH CARD     ", "STORM  ", "ST BM", ""
  manfid: 0x4e01, 0x0200
  function: 4 (fixed disk)

Simple Technology (192MB):
  product info: "STI", "Flash 5.0", "", ""
  manfid: 0x0007, 0x0000
  function: 4 (fixed disk)
Comment 1 Bill Nottingham 2005-07-29 16:58:35 EDT
Out of curiousity, what happens if, after loading the card, you do:

for file in `find /sys -name allow_func_id_match` ; do 
    echo "1" > $file
done

?
Comment 2 Dominik Brodowski 2005-07-29 17:25:59 EDT
Please also post the output of /sys/bus/pcmcia/devices/0.0/modalias for the CF
cards which are not handled automagically yet.
Comment 3 Paul Dickson 2005-07-29 17:28:58 EDT
Results from:
> for file in `find /sys -name allow_func_id_match` ; do 
>     echo "1" > $file
> done

Jul 29 14:24:32 white kernel: hda: LEXAR ATA_FLASH, CFA DISK drive
Jul 29 14:24:33 white kernel: ide0 at 0x100-0x107,0x10e on irq 3
Jul 29 14:24:33 white kernel: hda: max request size: 128KiB
Jul 29 14:24:33 white kernel: hda: 32128 sectors (16 MB) w/1KiB Cache, CHS=502/2/32
Jul 29 14:24:33 white kernel: hda: cache flushes not supported
Jul 29 14:24:33 white kernel:  hda: hda1
Jul 29 14:24:33 white kernel: ide-cs: hda: Vcc = 3.3, Vpp = 0.0
Jul 29 14:24:33 white kernel:  hda: hda1
Jul 29 14:24:34 white last message repeated 2 times
Jul 29 14:24:34 white fstab-sync[7507]: added mount point /media/FSCK0000DIA for
/dev/hda1
Jul 29 14:24:34 white kernel:  hda: hda1


It mounted!
Comment 4 Paul Dickson 2005-07-29 17:35:49 EDT
From 'cat /sys/bus/pcmcia/devices/0.0/modalias' for each failed card:

Lexar 16MB
pcmcia:m4E01c0200f04fn00pfn00pa144506E2pb7F641C27pc3488C81Apd00000000

Lexar 160MB
pcmcia:m4E01c0200f04fn00pfn00pa144506E2pb7F641C27pc438FF88Cpd00000000

Lexar 512MB
pcmcia:m4E01c0200f04fn00pfn00paAC17E994pbE82DAB83pcC9B37BA4pd00000000

Simple 192MB
pcmcia:m0007c0000f04fn00pfn00paBF2DF18Dpb8CB57A0Epc00000000pd00000000
Comment 5 Dominik Brodowski 2005-07-29 17:41:45 EDT
Created attachment 117300 [details]
kernel-patch

This patch (on top of 2.6.13-rc4-git1) adds the proper device table entries for
these cards. However, the function ID matching method should have picked them
up automatically, with no manual interaction (such as the shell script Bill
Nottingham posted) necessary. Any idea what went wrong in
/etc/hotplug/pcmcia.agent ?
Comment 6 Paul Dickson 2005-07-29 17:49:26 EDT
> Any idea what went wrong in /etc/hotplug/pcmcia.agent ?

File does not exist.
Comment 7 Bill Nottingham 2005-07-29 17:56:42 EDT
We're just using straight udev rules:

ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="*", \
        RUN+="/sbin/modprobe $modalias"

Not to ask a stupid question, but why does that sysfs attribute even exist? If
it defaults to handling all devices of that function, it really shouldn't
require extra steps to claim devices it matches.
Comment 8 Dominik Brodowski 2005-07-29 18:02:28 EDT
We need to distinguish two types of priority in matching the devices to drivers.
If we have a MANFID/CARDID or PRODID match, we can safely use the driver.
However, FUNCID matches are much more fuzzy: it can generate "false positives".
Therefore, these need to be delayed until all other, possibly more appropriate
modules have had a chance to bind themselves to the driver.
Comment 9 Bill Nottingham 2005-07-29 18:09:46 EDT
What's to prevent the pcmcia.agent continuing and setting that field while still
waiting for some other driver (loaded with a MODALIAS that matches multiple
modules) to decide whether or not to match it?
Comment 10 Dominik Brodowski 2005-07-29 18:15:10 EDT
well, "modprobe $MODALIAS" only returns if all drivers are loaded and fully
initialized. This includes running the drivers' _init() function, which calls
pcmcia_register_driver(), which might eventually call the probe callback. All in
the same process/thread, so we're safe in this regard.
Comment 11 Marcel Mol 2005-07-30 11:48:16 EDT
Same problem for my Dane-Elec CF cards.

# pccardctl ident
Socket 0:
  product info: "TOSHIBA THNCF256MMA ", "", "", ""
  manfid: 0x0098, 0x0000
  function: 4 (fixed disk)
Socket 1:
  no product info available

nothing in syslog or /etc/fstab

# echo 1 > /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0f.0/0.0/allow_func_id_match
Jul 30 17:30:23 brian kernel: Probing IDE interface ide2...
Jul 30 17:30:23 brian kernel: hde: TOSHIBA THNCF256MMA, CFA DISK drive
Jul 30 17:30:24 brian kernel: ide2 at 0xd000-0xd007,0xd00e on irq 3
Jul 30 17:30:24 brian kernel: hde: max request size: 128KiB
Jul 30 17:30:24 brian kernel: hde: 500736 sectors (256 MB) w/2KiB Cache,
CHS=978/16/32
Jul 30 17:30:24 brian kernel: hde: cache flushes not supported
Jul 30 17:30:24 brian kernel:  hde: hde1
Jul 30 17:30:24 brian kernel: ide-cs: hde: Vcc = 3.3, Vpp = 0.0
Jul 30 17:30:24 brian kernel:  hde: hde1
Jul 30 17:30:24 brian last message repeated 2 times
Jul 30 17:30:25 brian fstab-sync[4006]: added mount point /media/TOSHIBA256M1
for /dev/hde1

# cat /sys/bus/pcmcia/devices/0.0/modalias
pcmcia:m0098c0000f04fn00pfn00paF378DB98pb00000000pc00000000pd00000000
 
My scandisk CF card works fine.

PS: is there a way to define the mount point manually instead of the generated
/media/TOSHIBA256M1 or /media/idedisk3 (for the scandisk card)?

-Marcel
Comment 12 Paul Dickson 2005-07-31 11:35:44 EDT
Should I open a new bugzilla entry against pcmciautils-007-1 so that
/etc/hotplug/pcmcia.agent gets included in the RPM?
Comment 13 Dominik Brodowski 2005-08-01 08:07:29 EDT
I've added the ID for Dane-Elec CF (comment #11) to the patch I'll submit for
kernel 2.6.14-rc1. However allow_func_id_match still needs to be handled
correctly, else we'll see many more failures similar to the ones observed here.
Comment 14 Bill Nottingham 2005-08-01 13:15:27 EDT
Created attachment 117347 [details]
load modules in the order of how accurate the match is

Dominik: so, if the delay & echo from userspace is there to ensure that ide-cs
would be the last driver to bind to the device, would you accept something like
the following?

The attached patch for module-init-tools orders modules by how specific the
match is against the passed in id - basically, the match with the least number
of wildcards is loaded first, and so on.

This would ensure that something like ide_cs/serial_cs/parport_cs is loaded
last, and binds last, without having another trip to userspace for a magic
flag.

Is this an acceptable solution to have the sysfs flag removed? :)

(As an aside, is this really a problem where there are other, better, matches
for ide-cs? Or is that primarily for serial_cs/parport_cs?)
Comment 15 Dominik Brodowski 2005-08-01 13:28:06 EDT
This isn't a valid option -- one PROD_ID match is much better than one FUNC_ID
match. Why don't you do something like
ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="*", \
        RUN+="/sbin/modprobe $modalias && \
     echo 42 > /sys/bus/pcmcia/devices/$SOMETHING/allow_func_id_match"
instead?
Comment 16 Bill Nottingham 2005-08-01 14:04:25 EDT
Well, RUN+= is done with exec(), so you can't *quite* do it like that. But it's
doable, yes.

It's mainly the interface which I find cumbersome/hackish. What sorts of cards
are these where matching on function is bad? Ignoring the fact that the kernel
system doesn't support exporting this, is it something that's better handled by
blacklisting those cards in ide_cs/etc rather than whitelisting the
vendor/device of all the cards that *are* handled by ide_cs?
Comment 17 Bill Nottingham 2005-08-02 23:01:45 EDT
Added a rule in udev-063-5.

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