Re: SDHCI regression since 2.6.39

[Chris Ball <cjb@laptop.org>]

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