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.
This is
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 to
> 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
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> > Alex Dubov wrote:
> > > And today: yet another problem with mmc.
> > > It so happens that after resume mmc layer issues requests to the device
> > > befor
And today: yet another problem with mmc.
It so happens that after resume mmc layer issues requests to the device before
mmc_resume_host is
called at all. Moreover, this prevents the machine from resuming, unless worked
around, because
software timer does not work at this stage of the resume and
And today: yet another problem with mmc.
It so happens that after resume mmc layer issues requests to the device before
mmc_resume_host is
called at all. Moreover, this prevents the machine from resuming, unless worked
around, because
software timer does not work at this stage of the resume and
--- Pavel Machek [EMAIL PROTECTED] wrote:
On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
Alex Dubov wrote:
And today: yet another problem with mmc.
It so happens that after resume mmc layer issues requests to the device
before
mmc_resume_host is
called at all. Moreover
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 requests.
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
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 call
--- 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 f
--- 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 little
--- 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, and after
>
> 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
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:
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 lame.
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:
Greetings.
It seems that the recent shower of error reports was caused by my not so
thorough testing of the
R6 handling problems (I've sent you a patch for this).
However, there is this other problem with mmc_host_remove while transfer is in
progress.
First, I disabled my "sleep on remove"
Greetings.
It seems that the recent shower of error reports was caused by my not so
thorough testing of the
R6 handling problems (I've sent you a patch for this).
However, there is this other problem with mmc_host_remove while transfer is in
progress.
First, I disabled my sleep on remove hack.
unloaded and machine freshly rebooted (not resumed).
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov is the maintainer of tifm, not me.
>
> Andreas Steinmetz wrote:
> > Hi,
> > I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
> > is
unloaded and machine freshly rebooted (not resumed).
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Alex Dubov is the maintainer of tifm, not me.
Andreas Steinmetz wrote:
Hi,
I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
is working with 2.6.18.2 and the out of tree tifm
The patch looks ok.
However, due to certain peculiarities with memorystick and xd I have to emulate
a scatter-gather
in software. Considering that this particular aspect of implementation is the
same for all card
types on this TI chip, it can be shared by tifm_sd driver as well. In this case
The patch looks ok.
However, due to certain peculiarities with memorystick and xd I have to emulate
a scatter-gather
in software. Considering that this particular aspect of implementation is the
same for all card
types on this TI chip, it can be shared by tifm_sd driver as well. In this case
Memorystick support is not yet implemented (work in progress).
--- [EMAIL PROTECTED] wrote:
> Running recent kernels the insertion of a MemoryStick into the card
> reader of a Sony Vaio VGNSZ3XWP is detected but the card does not seem
> to be probed for partitions and hence is not made available
Memorystick support is not yet implemented (work in progress).
--- [EMAIL PROTECTED] wrote:
Running recent kernels the insertion of a MemoryStick into the card
reader of a Sony Vaio VGNSZ3XWP is detected but the card does not seem
to be probed for partitions and hence is not made available to
> That shouldn't be possible. Are you using the block queue fixes I wrote?
> Otherwise you will get problems like this.
>
> Basically, when you call mmc_host_remove(), it will remove all card
> devices. That shouldn't complete until all card drivers have released
> control of the card. At that
That shouldn't be possible. Are you using the block queue fixes I wrote?
Otherwise you will get problems like this.
Basically, when you call mmc_host_remove(), it will remove all card
devices. That shouldn't complete until all card drivers have released
control of the card. At that point
Greetings.
It appears to me that under certain circumstances mmc layer will issue requests
to the host after
mmc_host_remove returns. This happens, for example, in tifm_sd driver because
mmc_host may be
removed mid-transfer, as the socket shall be freed for possible reuse by
different media
Greetings.
It appears to me that under certain circumstances mmc layer will issue requests
to the host after
mmc_host_remove returns. This happens, for example, in tifm_sd driver because
mmc_host may be
removed mid-transfer, as the socket shall be freed for possible reuse by
different media
I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
101 - 132 of 132 matches
Mail list logo
