Comment 28 for bug 247819

@Richard: I can confirm that increasing the timeout to 500 ms from the default 250 ms in Intrepid's 2.6.27-8-generic (amd64) kernel works much better.

As a test, I copied 1.5 GB to my 2 GB card while simultaneously running two VirtualBox VMs (for at least some of the time, one was booting up, the other was performing a build), copying 6 GB from one USB drive to another, performing a "grep -r 2.6.27-8 *" in the /usr/src/linux-2.6.27 folder, and running a 3D game under wine. Normally just one of these would be enough to cause great distress to the mmc_blk driver.

It took quite a long time to complete the copy, but no errors were reported and a diff showed no differences.

I guess they're already trying increasing the write timeout since your 2.6.28 kernel is using 350 ms instead of 250 ms. I checked the source for kernel 2.6.24 and it uses 250 ms, just like 2.6.27. But since 2.6.27 is much more reliable for me than 2.6.24 (it's only when the system is under load that it falls over, whereas 2.6.24 would fall over most of the time), I guess something else improved and the higher timeout is more of a workaround than a fix.

But, hey, I'm all for workarounds that let me use my SD card without data loss! I hope they include it in the 2.6.27-9 kernel because rebuilding the kernel is a bit of a hassle.

It's still a worry that the Ubuntu file system doesn't tell you when these timeout errors occur, because it means that Ubuntu can cause data loss, and reliable data transfer is surely a core function of any OS. Even with a timeout of 500 ms I imagine it will still be possible for the timeout error to occur.