Bug 8393

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.