Most recent kernel where this bug did *NOT* occur: n/a Distribution: n/a Hardware Environment: i386, Pentium M, Sony laptop Software Environment: console shell Problem Description: If a card is in the slot when the tifm_sd is loaded, the card is not recognized. It renders udev hotplug script useless. Steps to reproduce: 1. unload tifm_sd like 'modprobe -r tifm_sd'; 2. insert a mmc/sd card; 3. load tifm_sd like 'modprobe tifm_sd'. Expected result: /dev/mmcblk* created. Actual result: nothing happens. I will attach a script that fails on this bug.
Created attachment 11317 [details] Unit test script [USES SUDO!] It fails like that (just after reboot, a card is in): ~$ check once Loading module tifm_sd ... Checking for a card at /dev/mmcblk0p1 ... failed. Or also in full run: ~$ check ... Unloading module tifm_7xx1 ... Unloading module tifm_sd ... Loading module tifm_7xx1 ... Loading module tifm_sd ... Checking for a card at /dev/mmcblk0p1 ... failed.
Alex, You may choose to own this bug.
This issue was already raised before, and to my impression was fixed. I don't see it my setup (both on 2.6.20 and 2.6.21). The problem may be caused by absent mmc_block, because there's no dependency on it. Loading of tifm_sd will pull in mmc_core, but this is not enough for storage cards to work.
Really strange. mmc_block is inserted by udev script. The driver's behavior is the same whether mmc_block is preloaded or not: * if the card is inserted after tifm_sd is loaded, everything is fine; * if conversely, the card is not detected. May it be fixed AFTER 0.8e?
As I already said, I can't reproduce this problem. Please consider sending me a proper diagnostics: 1. output of 'lsmod' before you do anything 2. output of 'lsmod' after you insert the card 3. output of 'lsmod' after you load the driver 4. Excerpt from the system log, desirably with drivers compiled with -DDEBUG flag (both mmc and tifm).
Created attachment 11356 [details] exert from kern.log with MMCM The steps to reproduce with a MMCM card follow: linux$ date Tue, 01 May 2007 10:30:35 +0300 linux$ lsmod | grep "mmc\|tifm" tifm_7xx1 6976 0 tifm_sd 11208 0 tifm_core 10068 2 tifm_7xx1,tifm_sd mmc_block 8264 0 mmc_core 27156 2 tifm_sd,mmc_block linux$ ls /dev/mmcblk* /dev/mmcblk0 /dev/mmcblk0p1 linux$ sudo modprobe -r tifm_sd tifm_7xx1 linux$ sudo modprobe -a tifm_sd tifm_7xx1 linux$ lsmod | grep "mmc\|tifm" tifm_7xx1 6976 0 tifm_sd 11208 0 tifm_core 10068 2 tifm_7xx1,tifm_sd mmc_block 8264 0 mmc_core 27156 2 tifm_sd,mmc_block linux$ ls /dev/mmcblk* ls: /dev/mmcblk*: No such file or directory linux$ I didn't touch the card. Only the modules. If I remove/insert the card it is detected.The behavior I described above was with a plain MMC card. I don't have it with me, but will file the log when I do.
In reply to the comment #5: > As I already said, I can't reproduce this problem. Please consider sending me a > proper diagnostics: It seems I have found the reason. My test doesn't fail with MMCM, but fails with an MMC, if the card is inserted when the module is not loaded. You seem to probe cards ASYNCHRONOUSLY. 'modprobe tifm_sd' returns before /dev/mmc* are created. But MMCM is so fast, that the block devices are created faster that 'test -b' is executed. This behavior cannot be exposed without a script. I will reopen this bug for the issue in the comment #6. Asynchronous probing is a completely separate topic from this one, so I will file a follow up bug.
Created attachment 11362 [details] Alternative socket power-off sequence. Ok, I see it now. I was under impression that you are unloading the whole bunch of drivers. Indeed, we have not tried to unload tifm_sd while keeping card in place (the expected modus operandi was that module is removed on uevent, which is caused by card swap action). Fortunately, this is not a big deal (patch attached).
Sergey, Did you get chance to test the patch? Everything works now? Thanks.
The patch is in 2.6.22-rcX. Believed to be good.
(In reply to comment #9) > Did you get chance to test the patch? Everything works now? > This seems to works in v2.6.21 with a patch from bug 8052. I haven't tested v2.6.22 yet.
Sergey, I suppose the testing went well, I can close the bug now.
Yes, sure. It is just fine.