linux-kernel - Re: mmc sdhci mmcblk0: error -110 sending status command, retrying

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B11A480-8122-4A0B-A0EE-E1E95477F985@marvell.com>
Date:	Fri, 10 Feb 2012 12:28:10 -0800
From:	Philip Rakity <prakity@...vell.com>
To:	Jeff Chua <jeff.chua.linux@...il.com>
CC:	Jaehoon Chung <jh80.chung@...sung.com>,
	Chris Ball <cjb@...top.org>, Pierre Ossman <pierre@...man.eu>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"arindam.nath@....com" <arindam.nath@....com>,
	"zhangfei.gao@...il.com" <zhangfei.gao@...il.com>
Subject: Re: mmc sdhci mmcblk0: error -110 sending status command, retrying


On Feb 10, 2012, at 8:18 AM, Jeff Chua wrote:

> On Thu, Feb 9, 2012 at 3:09 AM, Philip Rakity <prakity@...vell.com> wrote:
>> 
>> 
>> Jeff,
>> 
>> I think the sdhci.c clock setting code was changed a while ago.   Maybe revert that mod and see what happens.
>> 
>> The card is a 24MHz which is rather slow so I would be surprised if that was it.
>> The other option is the force enable the High Speed bit in the  controller (used when speed is 25MHz or faster).  Will give the system more time (in theory) to work.
> 
> That's a good point to start looking. I poked around and by setting
> host->ios.clock to 10000000 instead of 25000000, read from a 16GB card
> is no longer giving any error.
> 
> I still don't dare to do any write. Already burn one 16GB SD and not
> ready to trash another. I asked earlier but haven't got any reply as
> to how to recover an SD that says "No medium found". Any chance of
> recovering it?
> 
> Here's what I did. If set too low (1000000) or too high (25000000),
> random errors appeared.
> 
> --- linux/drivers/mmc/core/core.c.org   2012-02-10 23:57:49.000000000 +0800
> +++ linux/drivers/mmc/core/core.c       2012-02-10 23:53:59.000000000 +0800
> @@ -881,7 +881,7 @@
>        if (hz > host->f_max)
>                hz = host->f_max;
> 
> -       host->ios.clock = hz;
> +       host->ios.clock = 10000000;
>        mmc_set_ios(host);
> }
> 
> 

good news.  The other possibility but unlikely is that the timeout is too low for the card.

There is a quirk for this.

SDHCI_BROKEN_TIMEOUT_VAL

my guess is that you will need to measure the clk pin and see if it matches the frequency being programmed.  (could be less).

a simple hack is to add a printk to set_ios() or set_clock() and print out the clock rate clock register (divider) and see if they match what you should be seeing.
It is possible the bug is NOT in this area but in the platform code where an incorrect base freq is being setup for the controller.

Philip

> 
> Thanks,
> Jeff

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/