Suspend and Resume traces

Sean McNeil sean at
Thu Jun 12 22:05:39 CEST 2008

I'm in the same situation here now. I thought I had tried it and it was 
ok, but now it crashes on resume.

Ah, I see what that is doing now. It is saving off the irqs for the 
reason why it was waking up from the suspend. So it should be checked to 
see if it was suspended, not resumed. It probably shouldn't be modifying 
the value of the variable either. Also, I see the possibility of another 
race condition where you get a resume but then another suspend before 
the lcd is completely resumed as it is deferred.

What I see now is that I suspend just fine. But then I get resumed for 
some reason that eludes me. usb? and it crashes. Not completely because 
ping still works, but I can't ssh in or get any other response except ping.

Do you keep the phone plugged in to usb when you try your suspend/resume 
tests? I have root mounted as nfs while testing.

Andy Green wrote:
> Somebody in the thread at some point said:
> | How about this:
> |
> | diff --git a/drivers/i2c/chips/pcf50633.c b/drivers/i2c/chips/pcf50633.c
> | index 90edce0..fa39463 100644
> | --- a/drivers/i2c/chips/pcf50633.c
> | +++ b/drivers/i2c/chips/pcf50633.c
> | @@ -687,7 +687,7 @@ static void pcf50633_work(struct work_struct *work)
> |
> |        /* hey did we just resume? */
> |
> | -       if (pcf->have_been_suspended) {
> | +       if (pcf->have_been_suspended == 2) {
> |                pcf->have_been_suspended = 0;
> |                /*
> |                 * grab a copy of resume interrupt reasons
> |
> |
> Huh.  This gave me the "crashing on resume" disease when I tried to
> amend it to require an == 3 "resume completion" concept in the work
> function, and likewise it continued to crash with any such qualification
> in it, which makes no actual sense unless some hidden tiger-dragon is in
> there (no doubt same as causes apparent double execution of suspends and
> so on).  That's the first time in a long while I have seen this kind of
> behaviour and there is no normal explanation for it.
> So it's the same as the "printk's make me crash" reports.
> -Andy

More information about the openmoko-kernel mailing list