Alex Dubov wrote:
>
> correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host -
> noticed it only now
>
Ok, good. Then things are as they should on your part.
>
> That's why I think that simply flushing the workqueue is enough. If workqueue
> is empty we know for
> sure that d
> >
> > mmc_rescan
> > mmc_register_card
> > device_add
> > mmc_block_probe
> > mmc_block_alloc
> > -> queue thread starts running
> > add_disk
> > -> issues a lot of requests; card fails, my drivers calls
> > mmc_remove_host, which in
correction
Alex Dubov wrote:
>
> mmc_rescan
> mmc_register_card
> device_add
> mmc_block_probe
> mmc_block_alloc
> -> queue thread starts running
> add_disk
> -> issues a lot of requests; card fails, my drivers calls
> mmc_remove_host, which in
>
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of
> > requests (reads
> partition
> > table, fs superblocks and such - plenty of room for critical errors). Then,
> > driver's remove
> method
> > will
Alex Dubov wrote:
>
> You'll agree, I think, that add_disk in mmc_block_probe issues a lot of
> requests (reads partition
> table, fs superblocks and such - plenty of room for critical errors). Then,
> driver's remove method
> will not be called before driver's probe method had finished. So mmc_
> > This is hard to trigger problem, so I'll spare you the rather lengthy log.
> > It happens if card timeouts and mmc_remove_host is called while
> > mmc_register_card is still in
> > progress (the hint was in crash dump). If I sleep before remove, it gives
> > the
> mmc_register_card
> > chance
Alex Dubov wrote:
> This is hard to trigger problem, so I'll spare you the rather lengthy log.
> It happens if card timeouts and mmc_remove_host is called while
> mmc_register_card is still in
> progress (the hint was in crash dump). If I sleep before remove, it gives the
> mmc_register_card
> ch
>
> I don't see how that is possible. mmc_block's remove routine waits for mmcqd
> to
> exit, so there can't be any code still alive that has a request going. (I am
> also completely unable to reproduce this problem here).
>
> Add more printk:s do verify how the code in mmc_block executes.
>
Th
Alex Dubov wrote:
>> I don't actually think that is what happening. The block errors tend to
>> trail a
>> bit behind, so the errors you are seeing are probably the result of the queue
>> being flushed out as you remove the card. I don't see any mmc debug messages
>> that indicate that is trying t
> I don't actually think that is what happening. The block errors tend to trail
> a
> bit behind, so the errors you are seeing are probably the result of the queue
> being flushed out as you remove the card. I don't see any mmc debug messages
> that indicate that is trying to send more mmc request
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
>
Alex Dubov wrote:
> If we are already on the topic, I would like to report two additional issues
> with mmc_block:
>
> 1. If, for some reason, device driver cannot return the requested data
> amount, but does not sets
> any error, mmc_block would retry indefinitely. Of course, its always a devic
If we are already on the topic, I would like to report two additional issues
with mmc_block:
1. If, for some reason, device driver cannot return the requested data amount,
but does not sets
any error, mmc_block would retry indefinitely. Of course, its always a device
driver's fault, but
may be
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> > I removed that line altogether (it does not really needed as mmc host will
> > not be accessed
> > anymore). The problem is more elaborate. Here, the card fails,
> > mmc_host_remove is called
> without
> > sleep beforehand, an
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
>
Brad Campbell wrote:
> Alex, it's still hit and miss getting this card detected. I had to
> insert/remove the card over 10 times with random driver load/unloads
> until it created the device entries..
And for me it's still worse, no matter what I try with 2.6.20:
speedy:~ # find /sys/devices | gr
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > It just occurred to me that my synopsis of the problem was utterly lame.
> > Here, the correct description:
> > When the card is pulled out, I mark the host as "ejected" (so it fast-fails
> > all the requests),
> > sleep a
Pierre Ossman wrote:
Brad Campbell wrote:
[EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
.:
total 0
drwxr-xr-x 6 root root0 2007-02-11 23:29 .
drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
-r--r--r-- 1 root root 4096 2007-02-11 23:28 dev
lrwxrwxrwx 1 root root0 2007-02-11 23:27 devi
Brad Campbell wrote:
> [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
> .:
> total 0
> drwxr-xr-x 6 root root0 2007-02-11 23:29 .
> drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
> -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev
> lrwxrwxrwx 1 root root0 2007-02-11 23:27 device ->
> ..
Pierre Ossman wrote:
Brad Campbell wrote:
[EMAIL PROTECTED]:/$ find sys/devices | grep mmc
sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0
This is strange. You should be getting more entries below that.
I believe that should be the case..
/sys/block/mmcblk0/devic
Alex Dubov wrote:
>
> It just occurred to me that my synopsis of the problem was utterly lame.
> Here, the correct description:
> When the card is pulled out, I mark the host as "ejected" (so it fast-fails
> all the requests),
> sleep a little for it to relax and then call mmc_remove_host. Otherw
Brad Campbell wrote:
>
> [EMAIL PROTECTED]:/$ find sys/devices | grep mmc
> sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0
>
This is strange. You should be getting more entries below that.
> /sys/block/mmcblk0/device
Where does this point?
Rgds
--
-- Pierre Os
Pierre Ossman wrote:
Brad Campbell wrote:
I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail
the same way.
hald reports that the device has no parent and decides to ignore it.
Works fine here. The device tree is:
/sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcbl
Brad Campbell wrote:
>
> I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail
> the same way.
> hald reports that the device has no parent and decides to ignore it.
>
Works fine here. The device tree is:
/sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/
and hal
Hi.
I can see this problem too. I have CONFIG_SYSFS_DEPRECATED set.
It happens only with SD cards, with MMC everything is OK.
Fabio
On 2/11/07, Brad Campbell <[EMAIL PROTECTED]> wrote:
Pierre Ossman wrote:
> Alex Dubov wrote:
>> One more problem (you may already know about it) - I was contacte
Pierre Ossman wrote:
Alex Dubov wrote:
One more problem (you may already know about it) - I was contacted by somebody
from the hald
project and indeed I can confirm that on 2.6.20 kernel hald fails to take
action on card
insertion. I can't see anything in my code so this may be a general mmc p
>
> This looks like the problem with races in mmc_block again. Add some printk:s
> in
> the remove function so that you can see if this oops is after the remove
> function (shouldn't be possible, but will cause crash if it is).
It just occurred to me that my synopsis of the problem was utterly l
Alex Dubov wrote:
> One more problem (you may already know about it) - I was contacted by
> somebody from the hald
> project and indeed I can confirm that on 2.6.20 kernel hald fails to take
> action on card
> insertion. I can't see anything in my code so this may be a general mmc
> problem.
> T
One more problem (you may already know about it) - I was contacted by somebody
from the hald
project and indeed I can confirm that on 2.6.20 kernel hald fails to take
action on card
insertion. I can't see anything in my code so this may be a general mmc problem.
The problem is described here:
htt
Alex Dubov wrote:
> I'm continuing to look for possible problems in my code.
>
This looks like the problem with races in mmc_block again. Add some printk:s in
the remove function so that you can see if this oops is after the remove
function (shouldn't be possible, but will cause crash if it is).
30 matches
Mail list logo
