I have I/O errors with Transcend SD highspeed card 2GB/150x when it's
mounted in r/w mode (cardreader on sharp sl-c1000)
It works well if I reverse mmcv4 patch commited to 2.6.19-git2
(http://lkml.org/lkml/2006/10/4/27)
I'm not experienced in mmc, but I figured out that problem is
somewhere in mmc_read_switch_caps() and when i change cmd.arg value
from 0x80FFFFF1 to 0x00FFFFF1 it works fine too
What argument should have SD_SWITCH opcode?
--- linux-2.6.20/drivers/mmc/mmc.c 2007-02-14 04:13:23.644408219 +0300
+++ linux-2.6.20.g/drivers/mmc/mmc.c 2007-02-14 04:19:09.642624022 +0300
@@ -1225,7 +1225,7 @@
memset(&cmd, 0, sizeof(struct mmc_command));
cmd.opcode = SD_SWITCH;
- cmd.arg = 0x80FFFFF1;
+ cmd.arg = 0x00FFFFF1;
cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
memset(&data, 0, sizeof(struct mmc_data));
Eugene Ilkov wrote:
> I have I/O errors with Transcend SD highspeed card 2GB/150x when it's
> mounted in r/w mode (cardreader on sharp sl-c1000)
> It works well if I reverse mmcv4 patch commited to 2.6.19-git2
> (http://lkml.org/lkml/2006/10/4/27)
That patch is not the same as you are referencing in the rest of your mail.
> I'm not experienced in mmc, but I figured out that problem is
> somewhere in mmc_read_switch_caps() and when i change cmd.arg value
> from 0x80FFFFF1 to 0x00FFFFF1 it works fine too
> What argument should have SD_SWITCH opcode?
>
The argument is correct, so I'm guessing that your controller might be a bit
flaky and not handle the new timing. Can you enable MMC_DEBUG and send over the
dmesg?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
On 2/15/07, Pierre Ossman <[email protected]> wrote:
> Eugene Ilkov wrote:
> > I have I/O errors with Transcend SD highspeed card 2GB/150x when it's
> > mounted in r/w mode (cardreader on sharp sl-c1000)
> > It works well if I reverse mmcv4 patch commited to 2.6.19-git2
> > (http://lkml.org/lkml/2006/10/4/27)
>
> That patch is not the same as you are referencing in the rest of your mail.
I geuss changes was started from that patch, I mean changes that comes
with that:
http://www.linuxhq.com/kernel/v2.6/19-git2/drivers/mmc/mmc.c
I found another related patch
http://mailman.laptop.org/pipermail/commits-kernel/2007-January/000554.html
so i guess i'm not alone
>
> > I'm not experienced in mmc, but I figured out that problem is
> > somewhere in mmc_read_switch_caps() and when i change cmd.arg value
> > from 0x80FFFFF1 to 0x00FFFFF1 it works fine too
> > What argument should have SD_SWITCH opcode?
> >
>
> The argument is correct, so I'm guessing that your controller might be a bit
> flaky and not handle the new timing.
> Can you enable MMC_DEBUG and send over the
> dmesg?
mmc debug output is too noisy
and i can give you only this:
mmc0: starting CMD18 arg 30007e00 flags 00000035
PXAMCI: irq 00000004 stat 00002140
PXAMCI: irq 00000005 stat 00002940
PXAMCI: irq 00000007 stat 00003940
mmc0: req done (CMD18): 0/0/0: 00000900 5f5a83d5 2db7ffbf 96800012
mmc0: starting CMD18 arg 0000ae00 flags 00000035
PXAMCI: irq 00000004 stat 00002140
PXAMCI: irq 00000005 stat 00002940
PXAMCI: irq 00000007 stat 00003940
mmc0: req done (CMD18): 0/0/0: 00000900 5f5a83d5 2db7ffbf 96800012
mmc0: starting CMD18 arg 0ab49e00 flags 00000035
PXAMCI: irq 00000004 stat 00002140
PXAMCI: irq 00000005 stat 00002940
PXAMCI: irq 00000007 stat 00003940
mmc0: req done (CMD18): 0/0/0: 00000900 5f5a83d5 2db7ffbf 96800012
mmc0: starting CMD18 arg 0ab4ae00 flags 00000035
PXAMCI: irq 00000004 stat 00002140
PXAMCI: irq 00000005 stat 00002940
PXAMCI: irq 00000007 stat 00003940
mmc0: req done (CMD18): 0/0/0: 00000900 5f5a83d5 2db7ffbf 96800012
with desabled mmc debug :
Linux version 2.6.20-rc1-mm1-z2 (root@fly) (gcc version 4.1.1 (Gentoo 4.1.1-r3))
#58 PREEMPT Thu Feb 15 13:49:39 MSK 2007
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f
Machine: SHARP Akita
[..skipped..]
mmcblk0: mmc0:b368 SDC 2009600KiB
mmcblk0: p1
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
kjournald starting. Commit interval 5 seconds
mmcblk0: error 2 transferring data
EXT3 FS on mmcblk0p1, internal journal
EXT3-fs: recovery complete.
mmcblk0: error 2 transferring data
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 72K
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
mmcblk0: error 2 transferring data
i boot into root fs on SD, and it just hangs on remounting to rw, so
it's not easy to get full dmesg output with i/o error and mmc debug
info, but i'll try if it helps
Eugene Ilkov wrote:
>
> I found another related patch
> http://mailman.laptop.org/pipermail/commits-kernel/2007-January/000554.html
>
> so i guess i'm not alone
>
You'd better pray that's not the problem you have because that revert
was because the hardware under development had problems.
>
> mmc debug output is too noisy
> and i can give you only this:
>
That dump doesn't cover the problem, so I can't draw any conclusions
from it.
> i boot into root fs on SD, and it just hangs on remounting to rw, so
> it's not easy to get full dmesg output with i/o error and mmc debug
> info, but i'll try if it helps
I'm afraid I can't help you without a dmesg dump. This problem is most
likely crappy hardware at some point, and I need details to make any
guess about what it doesn't like.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Eugene Ilkov wrote:
> PXAMCI: irq 00000004 stat 00002140
Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings
aren't overlapping properly with the new stuff... I'm going to have to
recheck my diagrams.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Pierre Ossman wrote:
> Eugene Ilkov wrote:
>> PXAMCI: irq 00000004 stat 00002140
>
> Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings
> aren't overlapping properly with the new stuff... I'm going to have to
> recheck my diagrams.
Hmm... depending on where you look, you get different timing schematics. The
MMCA 4.2 specification (which should be authoritative) does indicate that things
are incompatible though.
I'll put together a patch that you can try out.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
On 2/15/07, Pierre Ossman <[email protected]> wrote:
> Pierre Ossman wrote:
> > Eugene Ilkov wrote:
> >> PXAMCI: irq 00000004 stat 00002140
> >
> > Hang on. PXAMCI is a MMC controller, right?
yes, pxa2xx-mci driver
>
> Hmm... depending on where you look, you get different timing schematics. The
> MMCA 4.2 specification (which should be authoritative) does indicate that things
> are incompatible though.
>
> I'll put together a patch that you can try out.
ok