thank you GrapefruiTgirl and H_TeXMeX_H, i'vegot backed up @ work and haven't had a chance to read on udev yet. I'll update the thread with the new information, just allow me 2-3 days :)
Andrew

ok. here what i have done so far:
where values in bold went into rules:
which became a rule 39:
the messages:
all this is fine, but i don't see that the actual matching occurs correctly. And, as a confirmation, i don't see /dev/cardreader/sd to be created at all.

Ok, cool. Looks like you're on the right track. I am going to make a couple suggestions here, some of which you may already know, and maybe some that will help otherwise anyway.

1) Make sure that after editing any of your udev rules files and saving it, you do a couple things:
First, restart udevd and/or tell it to reload the rules, so it picks up your change(s).
Second, give the command to udevd to freshly, forcefully repopulate the /dev directory. You need to force it to do this, or otherwise it won't refresh everything in there.

The basic routine for your testing should be something like follows:

0-- open a file manager to the /dev directory where you expect your new node to appear, so you can watch.
1-- start the udev monitor;
2-- plug in the card;
3-- if you see your new node appear (might need to refresh the file browser), and the monitor shows your rule being applied, then you're done!
4-- if not, unplug the card and continue to step #5
5-- edit your rule + save the file; reload the rules; give udev the force-reload command, repeat from step #2

So, if you didn't do the above, try it again with your rule as is.

Now about the rule you made (here's yours:)
When you're selecting items from the output of udevinfo -a -p `udevinfo -q path -n /dev/sdb1` to use in your rule, I have found that selecting items from only ONE of the chunks of information, is necessary. Even though udevinfo says you can select stuff from the device, PLUS one parent device, I suggest you remove a couple items to simplify the rule. Basically use only enough items to guarantee to match the correct device. If you look at the rule(s) I showed earlier that I made for my cardreader, you see I only used 4 items:
Also, notice the bold part above. See how "SUBSYSTEMS" is pluralized, even though it is NOT pluralized in the udevinfo output? If I remember right, that means the rule can match the EXACT subsystem, or another subsystem along the chain of parent devices. (It's been a while, so I may be slightly off about this exact meaning, but no matter, hang in there for a moment.) Also, the udev rule items OTHER THAN the sysfs items, for some reason, are not (in my experience) verbatim of what comes out of udevinfo which leads to confusion. What I mean is, in my own rule for example, where I match for "SUBSYSTEMS" was actually either "SUBSYSTEM" or "BUS" in the udevinfo output. I don't know why none of the docs tell us this; maybe they have been updated since I went through all this, but they were misleading at the time, even the tutorial I linked to earlier, was not exactly correct; I had to frig around a lot to get it to work.

Anyhow, let's try making your rule more like mine (a tiny bit simpler, and with an adjustment to the SUBSYSTEM line) and see what happens; after all, your device is nearly identical to mine. Try this (I'm going to break this line in half or so, for readability on this forum page, but don't do that in real life):
So I've removed the match for "KERNEL==" and changed "BUS" to "SUBSYSTEMS".

If you'd try that out, following the steps 0-6 above, and see what happens :)

NOTE: I'm not sure exactly the udev commands are for "restart" or "reload rules', or for how to "force-reload" on your system, so you'll have to check the man page or some documentation specific to your distro.

Also, if you continue to have difficulty, I will grab the SD card out of my camera (it's the only card I have here) and I will go through the whole procedure on my Slack 11 OS and show you all the outputs and stuff as I do it, so you can see exactly how I get the info for my rules, and what it was called in `udevinfo` vs. what it's called in the rule.

Good luck!
Sasha

Sasha,
I think it's about the time to bring more details about my system into this discussion: I'm running centos 5,kernel 2.6.18-164.el5 #1 SMP. Udev (rpm) is udev-095-14.20.el5_3.
the man for udev does NOT list the "SUBSYSTEMS" as a parameter, only "SUBSYSTEM". messages also indicate that SUSBYSTEM IS not valid key:
you might want to check the version - we may have different ones installed.

the udevmonitor shows:
its not clear what rules if any applied to the sdb1.
I also restarted the udev by running start_udev.
and with the following rule :
I'm getting :
if you recall i have only one partition on the sdb -sdb1. so why exactly am i getting bunch of cardreader entries in the /dev and why an i getting tons of entries under /cardreader/SD - i'm not clear.
UPDATE:
RTFM! all_partitions creates all possible partitions. doh.
all right then, i understand all SD[number], but not sure about the cardreader[number] entries.

now, i changed the rules to :
and well it hang the machine for starters :), but after reboot i can see only sdb[numbers] and a single cardreader/SD ->/dev/sdb been created. no partitions - SD[number].. hmmm

I want to have sdb{numbers} and appropriate symlinks (/cardreader/sd{numbers}).
any clues, please?
Andrew

here is the final rule that seemed to satisfy me:
this produces all sdb[partition] entires and corresponding links :
the disadvantage of this rule - [DEL]i can't do a straight mount [/DEL]- i would have to create several lines in fstab for each of the partitions, but i'm not too concern. i prefer to have a clear understanding of how many partitions i have available on a card. I guess it's a matter of personal preference.

SUMUP:
1. i won't be able to get through this without Sasha's and help.
2. post #2 has a good guide. I also used this and Drake's article. Man pages were helpful since they have a correct, up-to-date information.
3. note the kernel and rpm version of the software used : 2.6.18-164.el5, udev-095-14.20.el5_3. It's all "stock" no mods were done.
4. It appears that presence (in memory) of all 3 modules - ehci_hcd, uhci_hcd and ohci_hcd leads to odd behavior - inserted card is not detected by udev. At this point the following sequence of steps seemed to (partially) eliminate the problem - start with unload all 3 modules. Load ehci first and ohci after it. The only functionality that will be lost is in XWindow - no pop-ups asking what to do with a new media.

I think that's all :)
thank you!
Andrew

Hi Andrew,

First: yes, I was pretty sure the whole time, that our udev versions were different; that's why I suggested that if you still were having troubles, that I would boot up my Slack11 system and run through the rule generation again, because that installation has a udev version that is much closer to the one you are running, and it would hopefully have the same commands & tools at its disposal. On my NEW system here, I'm running a waay newer version of udev, which as we have seen, is fairly different.

Udev has gone through a lot of changes and maturity during its lifetime, so versions definitely tend to differ from one another. Of course, these differences happen everywhere, including the RULES, and the associated tools in /sbin that come with udev.
-------------
Now, I may just be repeating stuff from your last 2 posts, but bear with me (I think you pretty much have a good grip on all this by now ;) ) as I just want to hopefully clarify both for myself, and for you, AND for some other unfortunate soul who finds themselves here and can't make heads nor tails of what's going on:

In my situation, I didn't use the "symlink" option, so I don't get all the /dev/sd** items, I only get my cardreader* items in /dev/.

You did use the symlink option; that's why you're getting both cardreader* items AND sd** items in /dev. Since in your rule, you use %k in your NAME{all partitions}, this makes all the nodes have the same name as what the kernel calls them (sd**). Your symlink statement then causes creation of the /dev/cardreader* items.

Now, regarding your post#20 - a couple questions:

1) I don't understand what you mean: "I can't do a straight mount" -- can you explain that? If you have an fstab entry that corresponds to the partition(s) on the card, you can do either a mount in the console like:

shell# mount /dev/cardreader1
or
shell# mount /dev/sdb1

or you can mount the card using your file manager. Do some of these methods not work?

--

2) The fact that NAME{all partitions} produces 16 device nodes, does not necessarily mean that your card has 16 partitions on it. It just means that if there WERE as many as 16 partitions, you would automatically have a node for each one. I think 16 is a default set by something somewhere, and likely it could be changed if need be. by default though, there's a good chance that your card has only one partition. (Of course I can be wrong here -- I really don't know much about what kind of card you're using, so I'm just speculating, based on the way my own camera card is partitioned.)

Kind regards,
Sasha

Sasha,
#1 :
I updated the post #20. - my wording was not clear. Hope updated version is better.
#2 :
i agree with you - 16 is default. Actually, if you take a closer look you will see that symlinks are created only for existing partitions. I think it's pretty cool. as you can see from the example above - i have 2 partitions on that card ( cannon memory card SDC-16, 16M). originally i had only one partition, but for testing i changed that to 2, to see if it will create additional SD link.

Andrew

The above quote is interesting! Does that module still cause a problem with your situation? Good work at discovering it.

Yes, I understand now :) thanks for the clarification. With the fstab entries, you can mount more easily, but you still can do a manual mount in a console, if you should need to mount maybe to a different mount-point or something.

I had not noticed that, nor did I know that :) So there you go, I learned something here too (probably more than just *something* in fact) -- ahhh, the never-ending wonders of Linux!

Hopefully you will have little or no trouble from here on; and this thread will definitely be of help to others .

Nice work & congrats!

PS - If I can help any further, I check my subscribed threads regularly to see what's happening here if/when you update this thread.

Best regards,
Sasha

Yes, it does. that's the reason why i mantioned it in the sumup. It was confusing - devices were identified and appropriate dev entries were created, but media is not detected.

Thank you! I think i've got what i wanted. finally got to learn what the udev actually is %)
Thank you!
Andrew

Excellent :)

All the best,

Sasha

ID 058f:6377 Alcor Micro Corp. Multimedia Card Reader
 

I recently bought a similar reader and stumbled across this informative thread. It's also an Alcor, but a slightly different model - ID 058f:6377 Alcor Micro Corp. Multimedia Card Reader. Unfortunately, I still haven't been able to get it to mount, and am close to considering returning it to MicroCenter.

Like DBabo's original post, my device shows up but cannot be mounted. fdisk -l does not list the card. Unlike him though, even if I leave the card in the reader when I reboot, I still cannot mount it.

This one also includes a USB port on it, which is mostly useless, except as proof that the device is not setup correctly. If I insert an old USB Flash Drive into a normal USB port, it works and automounts immediately. If I insert it into the MMC's extra port, nothing happens.

Your comment about uhci_hcd was interesting. I followed your advice and tried removing all three modules, and only re-adding ehci and ohci, but no change. I still have no results when inserting/removing an SD card, microSD card, or even a flash drive from the MMC reader with udev running. As a sanity check, I did confirm that I get output when plugging a flash drive into a real USB port.

Am I missing something?

Thanks,
- David



Dmesg shows:
Other output:
Executing udevinfo -a -p `udevinfo -q path -n /dev/sdc` shows a device with the "SD Reader" name, however there is no sdc1.

I've started looking through the udev rules your talking about, which I'm sure I will need, but I don't expect that to lead me anywhere until I can at least get it to mount manually.


System: MythBuntu 9.04 x64

David,
maybe the unit is defective? I don't like that
Merry Christmas!

I was wondering about that line to ...

I'm not certain what, if anything, I did, but I did eventually get it to work. I think the combination of a Kernel update, and cleaning the case and reconnecting the port made the difference. Though even after that, it didn't work immediately, but then suddenly started working a week later if I remember correctly.

Happy Holidays and thanks for the response (better late then never as I always say :-)

-------------------------------
OK, Ten+ years later.
Linux reports present and account for.
16Meg or 16Gig Cannon chip?
FIRST - can your hardware handle a 16G chip? Check your manual! Old ones DO NOT!

"...can't mount any of the sd*..."
Do you have factory drivers for the hardware? gotta ask, may not be needed.
If the USB is present it may be assigned sdb
If so the Card reader should start as sdc and if a SDCard is present it would
. be mounted by mount /dev/sdc1 /mnt/sdc1 (or where_ever you choose)
. test rest of chip types (if you can) and see if they are sdd, sde...
Chip has to be inserted to be tested. IF they are not sdc, sdd... you will need
. the factory driver(s) for Linux. Linux considers each port a separate drive so
. it can use partition numbers within the chip if present.

Of special note: Case: Used SD Card and it worked fine as sdb1 yesterday.
. Fired up today and put a MS Chip in, only one there.
. IT WILL BE SDB and is to be mounted sdb1 and so forth.
. First come - First served!!!
The order of attachment usually controls the assigned designation.
Depending on specific Linux OS (distros do make tweeks) if the USBs attached
change with order then the same happens with the device in question. Some tweeks
assign ..b ..c ..d to the ports in the order of usage and retain it for the
duration of the System Up time. ie... turn it off and next on can be different
designations to same ports. Mine assigns b->whatever on first served basis and
next device the next in sequence UNLESS I unplug the ..b BEFORE plugging in another
device in any port. If ..b is present and ..c added and ..b then removed,
then ..d will be next attached. Even if I plug in the just was ..b (even to the
same port it was just in) it gets to be the ..d Keep that in mind.
And YES - It plays havoc with scripts!
If scripts are used, they need to use Vol.IDs to avoid screw ups.
How do I do that? Another subject. Another time. It does work and work well.

Norseman01