andy git 06/15 suspend/resume observations
sean at mcneil.com
Mon Jun 16 23:31:56 CEST 2008
Andy Green wrote:
> 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?
Sorry I didn't clarify, but this has been the case for quite a while now
(audio hang on resume). I only mentioned the problem now as it occurred
to me that they might be related somehow. I could see a pop happening if
the dma is resumed improperly and it also being responsible for the
hang. Looks like the culprit on the hang has already been identified,
> | 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.)
Are you looking at only button pushes as the resume reason? I get the
hang when I do not do a resume for an extended period of time. Seems
like everything is OK if I keep manually resuming. If I leave alone I
see the unit waking up on occasion because of GSM and then eventually
nothing will wake it up.
> 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.
Could this happen if a suspend is initiated before the resume is
completed? I'm using a kernel driver that calls
pm_suspend(PM_SUSPEND_MEM) and perhaps pm_suspend returns before
everything is resumed? If the driver finds no reason for the resume, it
will call suspend again quite quickly.
> 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.
Yes, that sounds like a good plan. I may be able to find the time to try
this with your guidance if it becomes necessary.
More information about the openmoko-kernel