Description

As the title suggests, suspend/resume corrupts the partition table of my SD card every time. May or may not be related to ticket #1743, as changing the SD clock at least partially affects this behavior.

Here's the last part of the dmesg output after a resume that corrupted the partition table:

Change History

I just noticed something. It seems the reason/method of the resume has an effect on this issue. In my debugging, I added scripts to /etc/apm/suspend.d/ and /etc/apm/resume.d/ that would unmount and remount my partitions. This didn't seem to make any difference. However, I'm currently in an area that has no cell signal and therefore doesn't get woken up by those pesky cell broadcast messages. So, my Neo is waking up from pressing the power button only now. When it does that, combined with the unmount/remount hack, the partition table is not affected.

I have the same problem with a 8GB SanDisk?-card, even when the 2008.8 is installed on the micro-SC. Since I have a Qtopia in the flash (to have a stable phone) I backed up the partitiontable via
dd if=/dev/mmcblk0 of=/home/root/backup.img bs=512 count=1
and put the restore-command
dd of=/dev/mmcblk0 if=/home/root/backup.img bs=512 count=1
to any bootup-script in Qtopia, in my case to the top of:
/etc/init.d/mountall.sh
so it fixes itself once I boot my Qtopia.

I had a quick look at Andy's fix which from what i can see is just turning the SD clock on at Suspend and back off on Resume. This may work but i am not sure it is the proper fix. The Simplified SD Spec states that at power up
"
• The host shall supply power to the card so that the voltage is reached to Vdd_min within 250ms and

start to supply at least 74 SD clocks to the SD card with keeping CMD line to high. In case of SPI
mode, CS shall be held to high during 74 clock cycles.

"

I just wonder if this is being done or not?

I don't have the SDHC spec, so am not sure if it is the same for SDHC. If someone could point me to a copy of the SDHC spec i will check it out.

The glamo driver is aware about it, in the io config callback export to mmc layer it figures out if we are applying power and if so sets the clock going and waits "1ms" which typically means 50ms.

The mci layer should take care about powering us up and down logically, but in 2.6.24 in fact the PMU gets to go to suspend first, and pulls the power to SD Card before the mci stack does the deed. But still it should get called later in suspend and do the wait with clock up thing.

MCI stuff feels racy anyway, there is async mmc_rescan() thread going on behind all this on resume. My guess is the trouble ultimately comes from a race in this area in mainline mci stuff.