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@xxxxxxxxxx> <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html