Hash: SHA1

Somebody in the thread at some point said:

| As I think this seems to be quite a good clue to what's really
happening here,
| quote from the OLPC ticket #6532:
| (HTH)
| cc dilinger added
|  I've spend some time digging deep into the bowels of the VFS and
block layer
| and gathering some debug output and have an explanation for the partition
| table corruption:

That's a great post you found Joerg and it is to the point.  But what is
killing me is this was "working" seemingly until we followed Sean
McNeil's lead about removing printks of all things from PMU driver while
trying to find the GSM crash in resume problem.  That's not to blame his
insight; clearly if we only work because async printks let it work,
we're not really working at all.  Previous to that, enabling synchronous
low level debug in the kernel forced the bad behaviour and disabling it
gave the good behaviour.

This is ultimately a resume race of some kind, the VFS layer corruption
and taking a whiz on block 0 (noticeable as it is) is downstream of
whatever is truly responsible.

I have made half the device a child of the PMU device now reflecting the
relationship more clearly and this is honoured by the suspend / resume
ordering now.  It means that we still have power at the SD Card while
glamo-mci driver is suspending, but we still fail to get a good result
from the last command sent on suspend, cmd7 to deselect the card.  I
have to fix more problems today before I can see how MMC resumes from it.

I'm also doing this on 2.6.26 in case MCI layer changes make a different

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


Openmoko community mailing list

Reply via email to