Andy Green wrote: [...] > Hey don't lose hope. There are two issues. First is just some big > cards are too slow to respond at default 16MHz clock with Glamo 16-bit > clock count timeout counter. See this > > https://docs.openmoko.org/trac/ticket/1743 > > Suspend / resume (partition overwrite is only a suspend / resume issue) > has been fundamentally broken on GTA02 since before I got here last > December, it didn't work at all until a series of deathmatches with it. > ~ The biggest deathmatch of all to clean and fix it is going on at the > minute on 2.6.26 branch here and it exposed the biggest underlying > problem for us which is Glamo behaviours. Assuming I kill it before it > kills me, we will have a far less racy and more complete suspend and > resume ordering situation then.
yay! > Other projects using Linux also have that problem of partition overwrite > on resume, but I suspect resume ordering and racing is behind their > problems too. When we clear that in the 2.6.26 branch we stand a chance > to synthesize random or moving delays in resume action and try to flush > out where it comes from. 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? -- Joachim Steiger Openmoko Central Services _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community