SdCard Corruption With Suspend/hibernate On Laptop

[htl2001]

EDIT: <_< I just realized the title is misleading and I can't change it... can someone do that please so it doesnt look like this is a pandora problem


My laptop (w/ build int SD/mmc reader) just had this issue and I thought I'd share with devs

there seems to be some issue with SD cards and suspend/resume in some systems, where the filesystem can sometimes become corrupted, with less severe bugs occuring more frequently
By "less severe bugs" I mean:
/dev/mmcblk0* dying, the /media/ mountpoint becoming dead, and a kernel failure report (SD card reappears as /dev/mmcblk1 and /media/ mountpoint has a "_" added to the end of its name)
sometimes this also caused issues when trying to suspend the computer again (gets stuck, probably because running sync would also get stuck) or when shutting down (hangs at "halting system", sometimes shows problems unmounting the new SD card mountpoint or (?) others such as /, /home...)

Reports about this issue are kind of scattered, mostly appearing on OLPC bug report ( http://dev.laptop.org/ticket/6532 )
I've also seen the issue reported on eeePC, and some windows mobile phones. I'm assuming this is because not much hardware exists where you'd constantly leave an SD card plugged in.

 

[Squidge]

Strange fault. I don't think the Pandora will suffer from it hopefully. We'll certainly test for it!

I've added "On Laptop" to your post title, and added a secondary title.

 

[ledow]

It'll be a bug in the driver for the MMC/SD device not supporting suspend properly. It's hardly a rare occurence for that to happen in a driver. I gave up on any sort of suspend/hibernation back in 2000 because even though things said they supported it, there was always one bit of hardware or one driver that bugged out and didn't work after a suspend or even prevented you going into suspend in the first place.

That's the sort of things that are fixed by an updated kernel, in the Linux world.

It's not surprising - you have to "serialise" the state of the entire machine at an exact instant and then be able to carry on when the machine is resumed later - so as far as the programs are concerned, they have to be stopped dead without losing their open files, filesystems, devices, network connections, etc., frozen into RAM, and then wake up and survive the several-hour instantaneous jump in time where all their network connections are dead, all the I/O writes/reads have timed out, all the hardware has had to be reinitialised and powered back up and had all of its state put back where it was from a cold start (just because the CPU can run powered, doesn't mean that the SD reader chip doesn't get switched off completely, or at least time-out on its connections).

If you're a programmer, think about what you're asking the computer to do - instantaneously stop all opcode execution, with open files and other handles, and then resume it as if nothing had happened after a complete restart / re-detect / re-mount of all filesystems (some of which may not even exist any more) without giving the program / libraries / operating system hardly any warning at all. Not to mention things like network connections which WILL have died, network adaptors that WILL need a complete restart to resync to the network signals, chips that HAVE to be turned off and back on and have their state perfectly preserved because they don't have in-built support for suspend etc.

I suspect that more modern hardware and newer kernels make this a non-problem for something like the Pandora, because most things in the embedded space now support proper suspend/resume because they were designed with it in mind.

 

[htl2001]

just some stats on what I'm using
Laptop: Compaq nw8440 (college issued)
OS: Fedora 10
$ uname -r
2.6.27.9-159.fc10.i686
SD card: Transcend 16GB Class 6
SD card slot:
$ lspci | grep -i card
02:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
02:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/)
02:06.4 Communication controller: Texas Instruments PCIxx12 GemCore based SmartCard controller


for this error, I've seen it described in that bug report's discussion as the driver wakes up BEFORE the card reader, asks the reader for the card info, and doesn't get a response (because it hasn't had time to resume yet). The fix is just waiting (400ms in the case of the OLPC) so that the SD/MMC card reader has time to wake up before you start asking it for stuff

EDIT: btw, suspend works fine otherwise, occasionally see what looks like the output of dmesg for a split second when I resume, but thats it