Hi, I have a device with an Intel Poulsbo SDHCI controller and an eMMC, and I get constant spam of: mmc2: Too large timeout requested for CMD25 whenever I write to the device. I looked into this and worked out what the card's CSD parameters suggest the write timeout should be, and unfortunately it's so large it's not only impossible for the SDHCI controller to reach, but actually causes an integer overflow during the timeout calculation in mmc_set_data_timeout. :) The TACC specifies a read time of 20ms, and R2W_FACTOR is 128, which means it's claiming a write takes two and a half seconds, which is then multiplied by ten to get the timeout - but this is a 32-bit machine, so data->timeout_ns is an unsigned int and this overflows. This looks like a bug in the MMC stack; even if this value is ridiculous it seems to be allowed for by the spec, so it should probably be taking care to avoid overflow here. Even with the overflow the value wraps to 4.125 seconds, which is still larger than the 48MHz timeout clock will allow, and thus it continues to spam the too large timeout warning. I'm sceptical that this warning is actually useful; unless I'm missing something, there's nothing you can actually *do* about it other than throw the card out and get one with saner values in CSD, which is tricky with an eMMC. At most it should be sufficient to complain about this when CSD is read, instead of during every command? Is there anything I can sensibly do about this other than convince syslog to filter the message out? I don't want to run a patched kernel on this device forever. Would a patch to calculate the worst case timeout at card detect time and just warn about it once be accepted? Thanks in advance for any tips (and please leave me in CC as I am not subscribed to the list), -- Torne Wuff torne@xxxxxxxxxxxxxxxx -- 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
