strange problem with Intenso 4GB SDHC card

Andy Green andy at
Mon Aug 11 22:31:34 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| i played with it a bit and came to the conclusion that it eats exactly
| 1024byte from the beginning of the 'physical' blockdevice. atleast when
| i backup these to nand, write them back via dd after loosing it and do a
| ioctl via fdisk /dev/mmcblk0 -> press w to trigger the block layer
| rereading the device i am fine.
| sounds weird.. is a buffer getting nulled on suspend, and gets written
| back to disk even if it shouldnt?

Huh.  Well SD is predicated around 512 byte blocks, so it is a 2-block
transaction.  When I dump what the driver sees for requests, they are
usually 2 or 8 512 byte blocks (1KBytes or 4KBytes).  So that part isn't
very foreign to the kind of transactions that are seen.

In 2.6.24 the PMU is taken down real early in suspend, it yanks SD Card
power (and CPU core power LOL) long before the MCI / MMC / SD driver and
stack try to deselect the card nicely.  One of the changes in
andy-2.6.26 is to make Glamo (and other things) a child of the PMU, so
the ordering is all changed around and SD Card can complete suspend
sanely with the card still powered.  The PMU goes down towards the end
of all the suspend actions too which is much better considering CPU core

The main striking thing about the SD Card overwrite issue for me is that
we got rid of it for a long time just by removing the synchronous low
level debug config... we could literally make this overwrite issue come
and go by basically changing timing of suspend and resume actions alone.
~ So I believe that we deal with races at the heart of all this.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the community mailing list