Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Daniel Lenski]

On 21 October 2015 at 12:02, Ulf Hansson <ulf.hansson <at> linaro.org> wrote:

> On 20 October 2015 at 18:29, Marcus Overhagen <marcus.overhagen <at> gmail.com> wrote:
> > I tested again with a 4.2 kernel but the bug is still present and
> > happens more often. So far nobody has responded.
> > I don't know what to do, and whether it's related to usb, mmc or mfd.
> > Please advise.
>
> Sorry for the delay. I was hoping to get some input from Roger as me
> personally don't know much about this HW.
> I can't tell whether this is a regression or not. The rtsx_usb driver
> were added in Linux 3.16. Perhaps you can verify if this is a
> regression or not!?

I have been having a very similar problem, though in my case it *does*
happen with a 32 GB microSDHC card.

[    9.854751] mmc0: new ultra high speed SDR50 SDHC card at address aaaa
[    9.862897] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
[  581.272899] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900

At first I thought the flash memory on the card had become corrupted,
but then realized that it still worked completely fine (a) when
booting Wind8 on the same system, (b) in an Android phone, and (c) in
a Rockbox MP3 player.

> > A 32 GB SDHC does not show data corruption with this card reader.

On my system, the error occurs _almost always_ when trying to access
my 32 GB microSDHC card, but never with 2 GB or 4 GB SD cards.

Running badblocks -n /dev/mmcblk0, it tells me that every single block
on the card is bad.

Per your suggestion, I booted a 3.16 kernel and encountered the exact
same errors.

> As I don't know the HW, I can just provide some guesses of how to narrow down the problem.
>
> If you re-build the kernel and make changes around which MMC_CAPS the host supports, you can try to narrow down the problem if it's related to speed modes.
>
> For example start by using *only* the following MMC_CAPS (updates to be made in rtsx_usb_init_host() - drivers/mmc/host/rtsx_usb.c):
>
> MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED | MMC_CAP_NEEDS_POLL
>
> ..and if no error, try add cap by cap to see what happens.
>
> Sorry, not being able to help you more - but at least this is a start!

Am I right that this has been moved to rtsx_usb_sdmmc in the most
recent kernels?
https://github.com/torvalds/linux/blob/HEAD/drivers/mmc/host/rtsx_usb_sdmmc.c#L1335

Thanks,
Dan

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Daniel Lenski]

On Fri, Dec 4, 2015 at 11:21 AM, Daniel Lenski <dlenski@gmail.com> wrote:
> On 21 October 2015 at 12:02, Ulf Hansson <ulf.hansson <at> linaro.org> wrote:
>> As I don't know the HW, I can just provide some guesses of how to narrow down the problem.
>>
>> If you re-build the kernel and make changes around which MMC_CAPS the host supports, you can try to narrow down the problem if it's related to speed modes.
>>
>> For example start by using *only* the following MMC_CAPS (updates to be made in rtsx_usb_init_host() - drivers/mmc/host/rtsx_usb.c):
>>
>> MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED | MMC_CAP_NEEDS_POLL
>
>> ..and if no error, try add cap by cap to see what happens.

Hi Ulf,
Thanks! I had success with this approach :-)

I started with the stock Ubuntu 4.2.0-21 kernel, and rebuilt ONLY the
rtsx_usb and rtsx_usb_sdmmc modules:

$ uname -a
Linux dlenski-ultra 4.2.0-21-generic #25-Ubuntu SMP Wed Dec 2 18:42:25
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ make -C /lib/modules/`uname -r`/build M=$PWD drivers/mfd/rtsx_usb.ko
$ make -C /lib/modules/`uname -r`/build M=$PWD
drivers/mmc/host/rtsx_usb_sdmmc.ko

First I tried disabling SDR50 only. Looks like SDR25 is a no-go for
this card. I get the same errors as with SDR50 (-110):

[ 4441.001959] mmc0: new ultra high speed SDR25 SDHC card at address aaaa
[ 4441.002292] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
[ 4441.006009]  mmcblk0:
[ 4441.678714] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900

Next, I disabled SDR25 as well. SDR12 *seems* to work fine at first,
although I get a different error in dmesg immediately when the card is
detected (-32), and then start to get a blizzard of error (-110) when
I try to copy lots of files to the card.

[ 4583.052995] mmc0: new ultra high speed SDR12 SDHC card at address aaaa
[ 4583.053304] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
[ 4583.055852]  mmcblk0:
[ 4583.328276] FAT-fs (mmcblk0): Volume was not properly unmounted.
Some data may be corrupt. Please run fsck.
[ 4691.924909] mmcblk0: error -32 sending stop command, original cmd
response 0x900, card status 0xc00
[ 4695.869462] mmcblk0: error -32 sending stop command, original cmd
response 0x900, card status 0xc00
[ 4709.745164] FAT-fs (mmcblk0): Volume was not properly unmounted.
Some data may be corrupt. Please run fsck.
[ 5082.557400] mmcblk0: error -110 sending status command, retrying
[ 5083.158663] mmcblk0: error -110 sending status command, aborting

Finally, I disabled SDR12 as well. And now the card works just fine:

mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED |
          MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
          /* MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 |*/
          MMC_CAP_NEEDS_POLL;

[ 5196.200933] mmc0: new high speed SDHC card at address aaaa
[ 5196.201239] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
[ 5196.203600]  mmcblk0:
[ 5196.462521] FAT-fs (mmcblk0): Volume was not properly unmounted.
Some data may be corrupt. Please run fsck.

In conclusion... it seems that the kernel is attempting to drive this
card faster than it can actually work. What I'm trying to figure out
now:
- How does the kernel attempt to figure out the capability of a given
SD card? Where is that in the kernel source tree?
- Is it possible to make the list of supported caps a module
parameter, to more easily throttle high-speed modes that don't work
with a particular card?

Thanks,
Dan

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Ulf Hansson]

On 4 December 2015 at 21:34, Daniel Lenski <dlenski@gmail.com> wrote:
> On Fri, Dec 4, 2015 at 11:21 AM, Daniel Lenski <dlenski@gmail.com> wrote:
>> On 21 October 2015 at 12:02, Ulf Hansson <ulf.hansson <at> linaro.org> wrote:
>>> As I don't know the HW, I can just provide some guesses of how to narrow down the problem.
>>>
>>> If you re-build the kernel and make changes around which MMC_CAPS the host supports, you can try to narrow down the problem if it's related to speed modes.
>>>
>>> For example start by using *only* the following MMC_CAPS (updates to be made in rtsx_usb_init_host() - drivers/mmc/host/rtsx_usb.c):
>>>
>>> MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED | MMC_CAP_NEEDS_POLL
>>
>>> ..and if no error, try add cap by cap to see what happens.
>
> Hi Ulf,
> Thanks! I had success with this approach :-)
>
> I started with the stock Ubuntu 4.2.0-21 kernel, and rebuilt ONLY the
> rtsx_usb and rtsx_usb_sdmmc modules:
>
> $ uname -a
> Linux dlenski-ultra 4.2.0-21-generic #25-Ubuntu SMP Wed Dec 2 18:42:25
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> $ make -C /lib/modules/`uname -r`/build M=$PWD drivers/mfd/rtsx_usb.ko
> $ make -C /lib/modules/`uname -r`/build M=$PWD
> drivers/mmc/host/rtsx_usb_sdmmc.ko
>
> First I tried disabling SDR50 only. Looks like SDR25 is a no-go for
> this card. I get the same errors as with SDR50 (-110):
>
> [ 4441.001959] mmc0: new ultra high speed SDR25 SDHC card at address aaaa
> [ 4441.002292] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
> [ 4441.006009]  mmcblk0:
> [ 4441.678714] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
>
> Next, I disabled SDR25 as well. SDR12 *seems* to work fine at first,
> although I get a different error in dmesg immediately when the card is
> detected (-32), and then start to get a blizzard of error (-110) when
> I try to copy lots of files to the card.
>
> [ 4583.052995] mmc0: new ultra high speed SDR12 SDHC card at address aaaa
> [ 4583.053304] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
> [ 4583.055852]  mmcblk0:
> [ 4583.328276] FAT-fs (mmcblk0): Volume was not properly unmounted.
> Some data may be corrupt. Please run fsck.
> [ 4691.924909] mmcblk0: error -32 sending stop command, original cmd
> response 0x900, card status 0xc00
> [ 4695.869462] mmcblk0: error -32 sending stop command, original cmd
> response 0x900, card status 0xc00
> [ 4709.745164] FAT-fs (mmcblk0): Volume was not properly unmounted.
> Some data may be corrupt. Please run fsck.
> [ 5082.557400] mmcblk0: error -110 sending status command, retrying
> [ 5083.158663] mmcblk0: error -110 sending status command, aborting
>
> Finally, I disabled SDR12 as well. And now the card works just fine:
>
> mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED |
>           MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
>           /* MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 |*/
>           MMC_CAP_NEEDS_POLL;
>
> [ 5196.200933] mmc0: new high speed SDHC card at address aaaa
> [ 5196.201239] mmcblk0: mmc0:aaaa SU32G 29.7 GiB
> [ 5196.203600]  mmcblk0:
> [ 5196.462521] FAT-fs (mmcblk0): Volume was not properly unmounted.
> Some data may be corrupt. Please run fsck.
>
> In conclusion... it seems that the kernel is attempting to drive this
> card faster than it can actually work. What I'm trying to figure out
> now:
> - How does the kernel attempt to figure out the capability of a given
> SD card? Where is that in the kernel source tree?

drivers/mmc/core/*

It's kind of complicated, but please go ahead and have a look.

> - Is it possible to make the list of supported caps a module
> parameter, to more easily throttle high-speed modes that don't work
> with a particular card?

Maybe a sysfs/debugfs interface would be better, but I like the idea!

Currently there is no way for userspace to disable some of these
"speed mode" caps, which would be very useful in cases like yours.

I don't know if I ever will get time to hack on such code, so feel
free to have a try yourself!

Regarding how to fix this problem right now, I guess we should remove
the caps which the host driver wrongly claims to support. Do you want
to send a patch for that?

Kind regards
Uffe

Fwd: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Daniel Lenski]

On Dec 8, 2015 6:11 AM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote:
>
> On 4 December 2015 at 21:34, Daniel Lenski <dlenski@gmail.com> wrote:
> > In conclusion... it seems that the kernel is attempting to drive this
> > card faster than it can actually work. What I'm trying to figure out
> > now:
> > - How does the kernel attempt to figure out the capability of a given
> > SD card? Where is that in the kernel source tree?
>
> drivers/mmc/core/*
>
> It's kind of complicated, but please go ahead and have a look.

Will do.

> > - Is it possible to make the list of supported caps a module
> > parameter, to more easily throttle high-speed modes that don't work
> > with a particular card?
>
> Maybe a sysfs/debugfs interface would be better, but I like the idea!
>
> Currently there is no way for userspace to disable some of these
> "speed mode" caps, which would be very useful in cases like yours.
>
> I don't know if I ever will get time to hack on such code, so feel
> free to have a try yourself!

Ideally, would it be better to have a userspace control at the level
of the individual host control drivers, or for the entire mmc/SD
subsystem?

> Regarding how to fix this problem right now, I guess we should remove
> the caps which the host driver wrongly claims to support. Do you want
> to send a patch for that?

I can do that, but am unsure whether it is truly an issue with the
host driver, or the card itself, in my case.

Is there any information which I can use to clearly rule one or the
other case out?

If I understood Marcus Overhagen's original post correctly, he was
successful with a UHS SDHC card and this same controller.

Thanks,
Dan

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Ulf Hansson]

On 8 December 2015 at 17:34, Daniel Lenski <dlenski@gmail.com> wrote:
> On Dec 8, 2015 6:11 AM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote:
>>
>> On 4 December 2015 at 21:34, Daniel Lenski <dlenski@gmail.com> wrote:
>> > In conclusion... it seems that the kernel is attempting to drive this
>> > card faster than it can actually work. What I'm trying to figure out
>> > now:
>> > - How does the kernel attempt to figure out the capability of a given
>> > SD card? Where is that in the kernel source tree?
>>
>> drivers/mmc/core/*
>>
>> It's kind of complicated, but please go ahead and have a look.
>
> Will do.
>
>> > - Is it possible to make the list of supported caps a module
>> > parameter, to more easily throttle high-speed modes that don't work
>> > with a particular card?
>>
>> Maybe a sysfs/debugfs interface would be better, but I like the idea!
>>
>> Currently there is no way for userspace to disable some of these
>> "speed mode" caps, which would be very useful in cases like yours.
>>
>> I don't know if I ever will get time to hack on such code, so feel
>> free to have a try yourself!
>
> Ideally, would it be better to have a userspace control at the level of the
> individual host control drivers, or for the entire mmc/SD subsystem?

I think per host controller would be the best.

>
>> Regarding how to fix this problem right now, I guess we should remove
>> the caps which the host driver wrongly claims to support. Do you want
>> to send a patch for that?
>
> I can do that, but am unsure whether it is truly an issue with the host
> driver, or the card itself, in my case.
>
> Is there any information which I can use to clearly rule one or the other
> case out?

Well, you can try other SDHC cards and you may also try the failing
card to see if it works with another host controller.

>
> If I understood Marcus Overhagen's original post correctly, he was
> successful with a UHS SDHC card and this same controller.

Okay. It may be that this card need some special treatment or that the
UHS support for rtsx is fragile.

>
> Thanks,
> Dan

Kind regards
Uffe

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Daniel Lenski]

On 21 October 2015 at 12:02, Ulf Hansson <ulf.hansson <at> linaro.org> 
wrote:

> On 20 October 2015 at 18:29, Marcus Overhagen <marcus.overhagen <at> 
gmail.com> wrote:
> > I tested again with a 4.2 kernel but the bug is still present and
> > happens more often. So far nobody has responded.
> > I don't know what to do, and whether it's related to usb, mmc or mfd.
> > Please advise.
> 
> Sorry for the delay. I was hoping to get some input from Roger as me
> personally don't know much about this HW.
> I can't tell whether this is a regression or not. The rtsx_usb driver
> were added in Linux 3.16. Perhaps you can verify if this is a
> regression or not!?

I have been having a very similar problem, though in my case it *does* 
happen with a 32 GB microSDHC card.

[    9.854751] mmc0: new ultra high speed SDR50 SDHC card at address aaaa
[    9.862897] mmcblk0: mmc0:aaaa SU32G 29.7 GiB 
[  581.272899] mmcblk0: error -110 sending stop command, original cmd 
response 0x900, card status 0x900

At first I thought the flash memory on the card had become corrupted, but 
then realized that it still worked completely fine (a) when booting Wind8 
on the same system, (b) in an Android phone, and (c) in a Rockbox MP3 
player.

> > A 32 GB SDHC does not show data corruption with this card reader.

On my system, the error occurs _almost always_ when trying to access my 32 
GB microSDHC card, but never with 2 GB or 4 GB SD cards.

Running badblocks -n /dev/mmcblk0, it tells me that every single block on 
the card is bad.

Per your suggestion, I booted a 3.16 kernel and encountered the exact same 
errors.

> As I don't know the HW, I can just provide some guesses of how to narrow 
down the problem.
>
> If you re-build the kernel and make changes around which MMC_CAPS the 
host supports, you can try to narrow down the problem if it's related to 
speed modes.
>
> For example start by using *only* the following MMC_CAPS (updates to be 
made in rtsx_usb_init_host() - drivers/mmc/host/rtsx_usb.c):
> 
> MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED | MMC_CAP_NEEDS_POLL
> 
> ..and if no error, try add cap by cap to see what happens.
> 
> Sorry, not being able to help you more - but at least this is a start!

Am I right that this has been moved to rtsx_usb_sdmmc in the most recent 
kernels?
https://github.com/torvalds/linux/blob/HEAD/drivers/mmc/host/rtsx_usb_sdmmc
.c#L1335

Thanks,
Dan

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Marcus Overhagen]

On Wed, Oct 21, 2015 at 2:02 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:

> were added in Linux 3.16. Perhaps you can verify if this is a regression or not!?
I will try this.

> Have you tried other SDXC cards which supports the "ultra high speed SDR50" mode?
I think only have a single large card that supports this mode.
Although I have some older 32 and 8 GB cards that I will test, I don't
expect them to support that mode.

> If you re-build the kernel and make changes around which MMC_CAPS the
I will try that during the weekend

> Sorry, not being able to help you more - but at least this is a start!
Thank you for your response, I'll report my findings back next week.

regards
Marcus

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Ulf Hansson]

On 20 October 2015 at 18:29, Marcus Overhagen
<marcus.overhagen@gmail.com> wrote:
> I tested again with a 4.2 kernel but the bug is still present and
> happens more often. So far nobody has responded.
> I don't know what to do, and whether it's related to usb, mmc or mfd.
> Please advise.

Sorry for the delay. I was hoping to get some input from Roger as me
personally don't know much about this HW.
I can't tell whether this is a regression or not. The rtsx_usb driver
were added in Linux 3.16. Perhaps you can verify if this is a
regression or not!?

>
> When using the RTS5129 card reader (USB2 but internal to Samsung
> NP7230U3E series 7 ultrabook) and a Samsung 128 GB SDXC microsd the
> data that is read or written is always corrupted.

Have you tried other SDXC cards which supports the "ultra high speed
SDR50" mode? BTW, the speed mode is logged when the card is detected.

> A 32 GB SDHC does not show data corruption with this card reader.

As I don't know the HW, I can just provide some guesses of how to
narrow down the problem.

If you re-build the kernel and make changes around which MMC_CAPS the
host supports, you can try to narrow down the problem if it's related
to speed modes.

For example start by using *only* the following MMC_CAPS (updates to
be made in rtsx_usb_init_host() - drivers/mmc/host/rtsx_usb.c):

MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED | MMC_CAP_NEEDS_POLL

..and if no error, try add cap by cap to see what happens.

Sorry, not being able to help you more - but at least this is a start!

Kind regards
Uffe

>
> [root@goetterdaemmerung f3-5.0]# uname -a
> Linux goetterdaemmerung 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50
> CEST 2015 x86_64 GNU/Linux
> [root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
>                   SECTORS      ok/corrupted/changed/overwritten
> Validating file 1.h2w ... 1752476/   279302/      9/  65365
> Validating file 2.h2w ... 1755153/   164013/      7/ 177979
> Validating file 3.h2w ... 1751003/   126213/     16/ 219920
> Validating file 4.h2w ...  123986/    15442/      0/  12348^C
> [root@goetterdaemmerung f3-5.0]#
>
> many errors logged, but always the same:
>
> [39143.853105] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
> [39143.860019] mmcblk0: mmc0:59b4 00000 119 GiB
> [39143.862649]  mmcblk0: p1
> [39144.654751] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39145.322333] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39161.533429] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39174.344246] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39174.961629] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39175.602352] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39176.229774] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39176.853664] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39177.468247] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39178.071814] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39178.672414] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39179.279727] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [39179.890435] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
>
> regards
> Marcus
>
> ---------- Forwarded message ----------
> From: Marcus Overhagen <marcus.overhagen@gmail.com>
> Date: Mon, Sep 28, 2015 at 9:42 PM
> Subject: Fwd: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
> To: kernel list <linux-kernel@vger.kernel.org>
> Cc: linux-mmc@vger.kernel.org, Lee Jones <lee.jones@linaro.org>
>
>
> Can somebody help me with this issue? Linux is corrupting data when
> using the SD card reader!
>
> I already sent it to linux-mmc on September 11th, and on September
> 17th forwarded it to Roger Tseng (author of rtsx_usb) and Samuel Ortiz
> (maintainer of MFD) but have received no response,
>
> ---------- Forwarded message ----------
> From: Marcus Overhagen <marcus.overhagen@gmail.com>
> Date: Fri, Sep 11, 2015 at 3:26 PM
> Subject: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
> To: linux-mmc@vger.kernel.org
>
>
> I have a data corruption problem with RTS5129 sd card reader and a
> 128GB Samsung EVO microsd.
>
> This is not a fake card, its tested ok with H2testw in another windows machine.
> The card also works when I put it in an external microSD=>USB card reader.
>
> Previously I was using a 32 GB Sandisk Ultra microsd UHS-I without
> noticing any issues.
> With the 128GB card, playback of dashcam videos shows many broken
> frames, but is ok when using external card reader.
>
> A test with F3 software shows "overwritten" sectors, I think in this
> case they indicate that the wrong sector is read.
>
> Bus 003 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
> Card Reader Controller
>
> [root@goetterdaemmerung marcus]# uname -a
> Linux goetterdaemmerung 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17
> 08:52:28 CEST 2015 x86_64 GNU/Linux
>
> [    1.033568] xhci_hcd 0000:00:14.0: xHCI Host Controller
> [    1.033575] xhci_hcd 0000:00:14.0: new USB bus registered, assigned
> bus number 3
> [    1.033673] xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci
> version 0x100 quirks 0x0000b930
> [    1.033682] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
> [    1.033931] hub 3-0:1.0: USB hub found
>
> [    1.393530] usb 3-3: new high-speed USB device number 2 using xhci_hcd
> [    1.451468] hub 1-1:1.0: USB hub found
> [    1.451580] hub 1-1:1.0: 6 ports detected
> [    1.464698] hub 2-1:1.0: USB hub found
> [    1.464847] hub 2-1:1.0: 6 ports detected
> [    1.572914] usbcore: registered new interface driver rtsx_usb
>
> [67697.876276] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
> [67697.876720] mmcblk0: mmc0:59b4 00000 119 GiB
> [67697.881189]  mmcblk0: p1
>
> some errors are loggged during card access:
>
> [68223.345521] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [68224.446561] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
> [68247.455199] mmcblk0: error -110 sending stop command, original cmd
> response 0x900, card status 0x900
>
> read test errors:
>
> [root@goetterdaemmerung f3-5.0]# mount /dev/mmcblk0p1 /mnt/dashcam1/
> FUSE exfat 1.1.0
> [root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
>                   SECTORS      ok/corrupted/changed/overwritten
> Validating file 1.h2w ... 2096266/      184/      0/    702
> Validating file 2.h2w ... 2096567/        2/      0/    583
> Validating file 3.h2w ... 2097151/        1/      0/      0
> Validating file 4.h2w ...  213984/        0/      0/      0^C
>
> after unmounting and mounting it again, the result is different:
>
> FUSE exfat 1.1.0
> [root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
>                   SECTORS      ok/corrupted/changed/overwritten
> Validating file 1.h2w ... 2096546/      370/      0/    236
> Validating file 2.h2w ... 2096074/        6/      0/   1072
> Validating file 3.h2w ... 2095924/      252/      0/    976
> Validating file 4.h2w ... 1295451/        0/      0/    901^C
>
> I got the impression yesterday that writing to the card results in
> much more errors.
> Thus today for this tests, data on the card was written with the other
> windows machine and is 100% correct.
>
> What can I do? What other information should I provide?
>
> For comparision, this is the working external sd-card=>USB hardware :
>
> Bus 003 Device 011: ID aaaa:8816 MXT
> or
> Bus 003 Device 014: ID 0781:b7b1 SanDisk Corp.
>
> [64645.868255] usb 3-4: new high-speed USB device number 15 using xhci_hcd
> [64646.057349] usb-storage 3-4:1.0: USB Mass Storage device detected
> [64646.057594] scsi host14: usb-storage 3-4:1.0
> [64647.060934] scsi 14:0:0:0: Direct-Access     Generic  STORAGE
> DEVICE   9407 PQ: 0 ANSI: 0
> [64647.682113] sd 14:0:0:0: [sdb] 251131904 512-byte logical blocks:
> (128 GB/119 GiB)
> [64647.682986] sd 14:0:0:0: [sdb] Write Protect is off
> [64647.682993] sd 14:0:0:0: [sdb] Mode Sense: 03 00 00 00
> [64647.683957] sd 14:0:0:0: [sdb] No Caching mode page found
> [64647.683966] sd 14:0:0:0: [sdb] Assuming drive cache: write through
> [64647.690645]  sdb: sdb1
> [64647.693784] sd 14:0:0:0: [sdb] Attached SCSI removable disk
>
> [root@goetterdaemmerung f3-5.0]# mount /dev/sdb1 /mnt/dashcam1/
> FUSE exfat 1.1.0
> [root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
>                   SECTORS      ok/corrupted/changed/overwritten
> Validating file 1.h2w ... 2097152/        0/      0/      0
> Validating file 2.h2w ... 2097152/        0/      0/      0
> Validating file 3.h2w ... 2097152/        0/      0/      0
> Validating file 4.h2w ... 2097152/        0/      0/      0
> Validating file 5.h2w ... 2097152/        0/      0/      0
> Validating file 6.h2w ... 2097152/        0/      0/      0
> Validating file 7.h2w ... 2097152/        0/      0/      0
> Validating file 8.h2w ... 2097152/        0/      0/      0
> Validating file 9.h2w ... 2097152/        0/      0/      0
> Validating file 10.h2w ... 2097152/        0/      0/      0
> Validating file 11.h2w ... 1080288/        0/      0/      0^C
> [root@goetterdaemmerung f3-5.0]#
>
> And this is when I tested the microSD card with another machine using
> H2testw in windows and it's ok:
>
>> Achtung: Nur 122590 von 122591 MByte getestet.
>> Fertig, kein Fehler aufgetreten.
>> Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
>> nochmals überprüfen.
>> Schreibrate: 18,6 MByte/s
>> Leserate: 41,3 MByte/s
>> H2testw v1.4
>
> regards
> Marcus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Marcus Overhagen]

I tested again with a 4.2 kernel but the bug is still present and
happens more often. So far nobody has responded.
I don't know what to do, and whether it's related to usb, mmc or mfd.
Please advise.

When using the RTS5129 card reader (USB2 but internal to Samsung
NP7230U3E series 7 ultrabook) and a Samsung 128 GB SDXC microsd the
data that is read or written is always corrupted.
A 32 GB SDHC does not show data corruption with this card reader.

[root@goetterdaemmerung f3-5.0]# uname -a
Linux goetterdaemmerung 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50
CEST 2015 x86_64 GNU/Linux
[root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 1752476/   279302/      9/  65365
Validating file 2.h2w ... 1755153/   164013/      7/ 177979
Validating file 3.h2w ... 1751003/   126213/     16/ 219920
Validating file 4.h2w ...  123986/    15442/      0/  12348^C
[root@goetterdaemmerung f3-5.0]#

many errors logged, but always the same:

[39143.853105] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[39143.860019] mmcblk0: mmc0:59b4 00000 119 GiB
[39143.862649]  mmcblk0: p1
[39144.654751] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39145.322333] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39161.533429] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39174.344246] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39174.961629] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39175.602352] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39176.229774] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39176.853664] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39177.468247] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39178.071814] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39178.672414] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39179.279727] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39179.890435] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900

regards
Marcus

---------- Forwarded message ----------
From: Marcus Overhagen <marcus.overhagen@gmail.com>
Date: Mon, Sep 28, 2015 at 9:42 PM
Subject: Fwd: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
To: kernel list <linux-kernel@vger.kernel.org>
Cc: linux-mmc@vger.kernel.org, Lee Jones <lee.jones@linaro.org>


Can somebody help me with this issue? Linux is corrupting data when
using the SD card reader!

I already sent it to linux-mmc on September 11th, and on September
17th forwarded it to Roger Tseng (author of rtsx_usb) and Samuel Ortiz
(maintainer of MFD) but have received no response,

---------- Forwarded message ----------
From: Marcus Overhagen <marcus.overhagen@gmail.com>
Date: Fri, Sep 11, 2015 at 3:26 PM
Subject: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
To: linux-mmc@vger.kernel.org


I have a data corruption problem with RTS5129 sd card reader and a
128GB Samsung EVO microsd.

This is not a fake card, its tested ok with H2testw in another windows machine.
The card also works when I put it in an external microSD=>USB card reader.

Previously I was using a 32 GB Sandisk Ultra microsd UHS-I without
noticing any issues.
With the 128GB card, playback of dashcam videos shows many broken
frames, but is ok when using external card reader.

A test with F3 software shows "overwritten" sectors, I think in this
case they indicate that the wrong sector is read.

Bus 003 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
Card Reader Controller

[root@goetterdaemmerung marcus]# uname -a
Linux goetterdaemmerung 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17
08:52:28 CEST 2015 x86_64 GNU/Linux

[    1.033568] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    1.033575] xhci_hcd 0000:00:14.0: new USB bus registered, assigned
bus number 3
[    1.033673] xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci
version 0x100 quirks 0x0000b930
[    1.033682] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[    1.033931] hub 3-0:1.0: USB hub found

[    1.393530] usb 3-3: new high-speed USB device number 2 using xhci_hcd
[    1.451468] hub 1-1:1.0: USB hub found
[    1.451580] hub 1-1:1.0: 6 ports detected
[    1.464698] hub 2-1:1.0: USB hub found
[    1.464847] hub 2-1:1.0: 6 ports detected
[    1.572914] usbcore: registered new interface driver rtsx_usb

[67697.876276] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[67697.876720] mmcblk0: mmc0:59b4 00000 119 GiB
[67697.881189]  mmcblk0: p1

some errors are loggged during card access:

[68223.345521] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[68224.446561] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[68247.455199] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900

read test errors:

[root@goetterdaemmerung f3-5.0]# mount /dev/mmcblk0p1 /mnt/dashcam1/
FUSE exfat 1.1.0
[root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2096266/      184/      0/    702
Validating file 2.h2w ... 2096567/        2/      0/    583
Validating file 3.h2w ... 2097151/        1/      0/      0
Validating file 4.h2w ...  213984/        0/      0/      0^C

after unmounting and mounting it again, the result is different:

FUSE exfat 1.1.0
[root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2096546/      370/      0/    236
Validating file 2.h2w ... 2096074/        6/      0/   1072
Validating file 3.h2w ... 2095924/      252/      0/    976
Validating file 4.h2w ... 1295451/        0/      0/    901^C

I got the impression yesterday that writing to the card results in
much more errors.
Thus today for this tests, data on the card was written with the other
windows machine and is 100% correct.

What can I do? What other information should I provide?

For comparision, this is the working external sd-card=>USB hardware :

Bus 003 Device 011: ID aaaa:8816 MXT
or
Bus 003 Device 014: ID 0781:b7b1 SanDisk Corp.

[64645.868255] usb 3-4: new high-speed USB device number 15 using xhci_hcd
[64646.057349] usb-storage 3-4:1.0: USB Mass Storage device detected
[64646.057594] scsi host14: usb-storage 3-4:1.0
[64647.060934] scsi 14:0:0:0: Direct-Access     Generic  STORAGE
DEVICE   9407 PQ: 0 ANSI: 0
[64647.682113] sd 14:0:0:0: [sdb] 251131904 512-byte logical blocks:
(128 GB/119 GiB)
[64647.682986] sd 14:0:0:0: [sdb] Write Protect is off
[64647.682993] sd 14:0:0:0: [sdb] Mode Sense: 03 00 00 00
[64647.683957] sd 14:0:0:0: [sdb] No Caching mode page found
[64647.683966] sd 14:0:0:0: [sdb] Assuming drive cache: write through
[64647.690645]  sdb: sdb1
[64647.693784] sd 14:0:0:0: [sdb] Attached SCSI removable disk

[root@goetterdaemmerung f3-5.0]# mount /dev/sdb1 /mnt/dashcam1/
FUSE exfat 1.1.0
[root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0
Validating file 9.h2w ... 2097152/        0/      0/      0
Validating file 10.h2w ... 2097152/        0/      0/      0
Validating file 11.h2w ... 1080288/        0/      0/      0^C
[root@goetterdaemmerung f3-5.0]#

And this is when I tested the microSD card with another machine using
H2testw in windows and it's ok:

> Achtung: Nur 122590 von 122591 MByte getestet.
> Fertig, kein Fehler aufgetreten.
> Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
> nochmals überprüfen.
> Schreibrate: 18,6 MByte/s
> Leserate: 41,3 MByte/s
> H2testw v1.4

regards
Marcus