linux-kernel - Re: SDHCI regression since 2.6.39

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]

Date:	Wed, 14 Sep 2011 14:38:38 -0400
From:	Chris Ball <cjb@...top.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Philip Rakity <prakity@...vell.com>,
	"linux-mmc\@vger.kernel.org" <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Manoj Iyer <manoj.iyer@...onical.com>
Subject: Re: SDHCI regression since 2.6.39

Hi,

On Wed, Sep 14 2011, Jeremy Fitzhardinge wrote:
> I powered it off with battery unplugged for about an hour, and rebooted
> into the known-working kernel, making sure that any fancy power mgmt
> features were disabled (like aspm), but it still failed in the same way.
>
> I'm wondering if it's simply something like the socket has failed, and
> one or more of the terminals isn't connecting to the card?  Though that
> would only show problems on card insertion, but I gather the driver is
> having problems from the moment it detects the controller?

I don't think it's true that we're having any problems talking to the
controller other than with a card inserted -- do you see any errors in
dmesg before inserting a card?

It could indeed be some kind of signal integrity issue.  The easy way to
investigate that would be to boot Windows and see if it works there, and
the hard way would be to find a friendly hardware hacker with a nice scope.

(In your dmesg with debug turned on, all we see is the card no longer
responding to any command: "mmc0: req done (CMD18): -110: 00000000
00000000 00000000 00000000" where -110 is ETIMEDOUT, and in your
original mail we also see some -84, EILSEQ, which is either the
controller raising a CRC error -- suggesting a bad physical connection
or poor signal quality -- or responding with data out of sequence.  You
could find out which by instrumenting sdhci.c's "error = -EILSEQ" lines
with printks, but it's probably not practically useful to know.)

Thanks,

- Chris.
-- 
Chris Ball   <cjb@...top.org>   <http://printf.net/>
One Laptop Per Child
--
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/