>Here first are the dmesgs from suspending with a vanilla 2.6.16-rc5. I
>did only one cycle so that it didn't hang and I could edit this email
>without rebooting (but later suspends produce the same method
>calls, I'm
>90% sure):
>
># the sleep dmesgs
>PM: Preparing system for mem sleep
>Stopping tasks:
>=======================================================|
Did you see any methods before and after this line in hang case on
screen?
If yeas, do you recall what they are?
>> PM: Preparing system for mem sleep
>> Stopping tasks:
>> =======================================================|
> Did you see any methods before and after this line in hang case on
> screen? If yes, do you recall what they are?
I capture across a serial console, so here are the exact msgs (I just
ran the second sleep and got the usual hang). This is with vanilla
2.6.16-rc5 (and vanilla DSDT):
Stopping tasks: =========================================================|
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
Execute Method: [\_S3_] (Node c157a988)
Execute Method: [\_PTS] (Node c157ab48)
The screen itself is full of garbage because the first sleep/wake messes
up the console. Along with a giant white square that fills most of the
screen, I see a fuzzy, dotted version of the above messages, plus one
more line "ACPI" and then a flashing underscore cursor after that. I
don't know if it was trying to printk "ACPI" but then the rest of the
message got lost, or it hung before printing it, or whether the ACPI is
from a previous dmesg (i.e. the first sleep/wake) that didn't get
cleared properly.
-Sanjoy