andy git 06/15 suspend/resume observations

Andy Green andy at
Mon Jun 16 10:03:33 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy,
| This is great work. I have the following observations...
| Pros:
| display looks so nice now on resume. No flash at all, no degradation
| over time while suspended.

Oho excellent.

| Resume speed seems much better as well.
| I think I had some sort of invalid wakeup before. I thought it was
| because of the GSM but now I am uncertain. I no longer get the
| mysterious resumes.
| Cons:
| audio pop is still there for me. I don't know if you committed changes

No I just started seeing if I could reproduce it late last night.
Happily Joerg saved me from meddling in probably the wrong area in the

| that should affect it. When I do fully resume and write to the device it
| hangs. Perhaps they are both related to something with DMA? I get around
| the hang in the application layer by using a timeout, close, reopen.
| That brings audio back to life.

Ah Hum.  This is likely something to do with the recent locking / power
mode stuff that allows the audio resume to get parallelized out of the
resume critical path.  Mark added it (which I am glad of because I don't
know any of that Alsa stuff).

I have tested it (and just tested it again) with no handles up on alsa
in suspend and it is fine.  I didn't test the case that we have it in
use at the time.  It sounds like previously this would work OK for you?

| Also, still getting hangs where it will not resume. The only thing I can
| do at this point is to ping the device over usb. I have root mounted
| over usb, by the way, but I don't think that is the issue.

Well I think we come down to a real difference it config or something
else now that makes a race I can never see.  I just did:

~  while [ 1 ] ; do sleep 1s ; echo mem >/sys/power/state ; done

for 100 resumes straight, zero problems.  (Even the low probability
"juddery resume display" error didn't come, we can hope the last Glamo
changes got rid of that too.)

If the Ethernet over USB up, has its IP and can do ICMP, we are not in
any global panic, it smells like a deadlock involving one of the resume
callbacks, so it can't advance through all the resumes.  Another way we
saw before to make this kind of issue is to yield / sleep in resume
function when timer is not up yet for scheduler.

If I could reproduce it, I would attack this by moving "light an LED"
code around the resume functions binary chop style, using the dmesg list
of resume ordering as a guide.  It's not much fun but it will identify
where we are sticking.

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


More information about the openmoko-kernel mailing list