Created attachment 32192 [details] dmesg from an about to hang system im not sure if this is 1 out of 30, more, less, or what actually triggers this issue. but with this laptop. every once in a while, after resuming (system comes back) xorg freezes after several seconds. this has been happening since...2.6.20's kernels, but i have never been able to detect the issue or it was something else entirely and it got introduced in later versions. ive been trying to collect data in the past to report this but i have been unable to do so due to the hardness of the locking. (alt-sysrq does not work when it locks). now ive accelerated the resume cycle disabling some actions. and managed to grab a dmesg dump, which im attaching if i switch back to a vt before the hang, i can use the system (with partially working hardware, eg. wireless does not work). the dmesg has a stack trace in it. if there is any other info i can provide, please let me know.
We have just merged a patch that may help your box resume correctly. It is attached to bug #16396.
To test it on top of 2.6.35 you need to apply attachment #27170 [details] first and then attachment #31422 [details]. Alternatively, you can wait for 2.6.36-rc7 and test that kernel when it's out.
marking RESOLVED, as a patch to test is available
so none of you read who reported that bug? thats a different issue. that was a 100% reproducible bug. this is a 1 in 20 case having added nonvs does no fix it. the screen when this happens actually turns on. the freeze occurs in X.
I admit that Len was a bit too quick to mark this bug as resolved, but your response is not really encouraging. I don't really remember who reported what and why, I only look for similarities. When I saw the name of your machine in the log, I thought of the other bug. Anything which is 1 in 20 or so and has never worked is probably beyond our debugging capabilities. Since you're saying it was happening with 2.6.20 and now happens with 2.6.35, it doesn't seem to depend on what graphics driver is used (I guess you're using KMS graphics drivers). Have you changed user space (most importantly X) since when it started to happen?
BTW, please attach a dmesg output from that box, preferably also the output of "lspci -vv" and the Xorg server's log.
Rafael, sorry if my post sounded harsh. it wasnt meant to, i just reread it and realized it could be taken badly. concerning the issue. i know its quite hard to debug, and i havent posted a report before since i had nothing to show till now. what i meant when i said it happened with 2.6.20 and 2.6.35... i meant from 2.6.20ish through all kernel upgrades till 2.6.35.. (2.6.36-rc too) all i can say is the wireless adapter goes nuts when this happens (which triggers me to switch to a vt and rapidly copy the dmesg). of course im using KMS, but this used to happen with UMS too, im almost sure this is not a video issue. im more inclined in usb or wireless. although i already tried removing usb modules (and any module that depends on them) before suspending and it does not help. for userspace....what X was available with the 2.6.20 kernels? 1.5? im now at 1.8RC2 and downloading 1.9 as we speak.
Created attachment 32332 [details] lspc -vv there already is a dmesg from the system with a kernel stack trace in it. if you need another one, please let me know
Created attachment 32342 [details] xorg.log
and ive been using xorg 1.9 already
OK Well, the box is Intel-based so I'm not really expecting problems with the graphics. This wireless thing appears to be on USB. Is this correct? What happens if you disconnect it before suspending?
disconnecting it isnt an option, since its a usb device, but its plugged inside the notebook the same way a so-dimm memory is. i did try removing the kernel modules concerning wireless and usb but it does not help.
Created attachment 34122 [details] dmesg from an oops right after hibernate (suspend to ram) im not sure if this is actually useful, but im attaching a new dmesg. it might shed some light on the issue. this line seems suspicious right before the stack trace. rt73usb 1-2:1.0: no reset_resume for driver rt73usb?
It's great that kernel bugzilla is back. can you please verify if the problem still exists in the latest upstream kernel?
SDHCI device is crap on this system, blacklisting the k.module fixes this and i have no plans to try and fix the sdhci reader (which breaks windows suspend too afaik) closing