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
