From: Daniel Lenski <dlenski@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd
Date: Fri, 4 Dec 2015 19:13:28 +0000 (UTC) [thread overview]
Message-ID: <loom.20151204T195824-840@post.gmane.org> (raw)
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
next reply other threads:[~2015-12-04 19:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 19:13 Daniel Lenski [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-10-20 16:29 Marcus Overhagen
2015-10-21 12:02 ` Ulf Hansson
2015-10-21 20:23 ` Marcus Overhagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20151204T195824-840@post.gmane.org \
--to=dlenski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®