Afer Hibernation, I get attached kernel Oopses. This is with the current Debian Kernel from experimental. I was able to login from another machine to access the dmesg log, but an attempt to reboot hangs. sync also hangs.
Created attachment 49732 [details] dmesg log from the oops
What exactly do you do to reproduce the problem? BTW, please don't attach compressed logs. It's _very_ inconvenient to review them in this form and you don't really save any space that would matter this way.
Sorry for the late answer, I missed the bugzilla notification somehow. The Oops occured after a wakeup from suspend to disk, initiated over the KDE start menu, which calls pm-hibernate, which I configured to use in kernel suspend, with HIBERNATE_MODE="shutdown". It was probably not the first hiberation since the last cold boot. Some further information: The notebook is a Lenovo T500, with Switchable Graphics (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller + some ATI) but I'm only using the Intel graphic (set in BIOS). Since the switch to kernel mode-setting, I had various problems with hibernation. At least since 2.6.36, the probability that the wakeup fails went down. However, after a few cycles (2 to 10) after a cold boot, I still end up with some error. Either it is an OOps as reported, or it is screen corruption or as seen a few days ago, filesystem corruption (only root fs (ext3) was affected and e2fsck could fix it + debsums didn't show any errors.) I reported the Oops because it occured the second time with 2.6.37-rc6 when I decided it to report. Interestingly, since then I experienced the filesystem corruption, but I didn't see the Oops again. Another strange experience is that sometimes after a successful wakeup from hibernation, the system feels much slower than after a cold boot - not only a few minutes after the wakeup, really the whole session.) However, I don't know how to give this a metric and I'm not sure whether this is related - that problem might be related to the OnBoard Audio controller.
can you reproduce this issue in 2.6.38? what is the most recent kernel that did not have this problem? can you reproduce with the acpi "video" driver excluded from the system?
So far, I can't reproduce this problem with 2.6.38. I'm using this kernel since a week without a cold reboot. Hopefully, I'm not just currently lucky and the problem is really gone.
Alright, thanks for the update. I'm closing this as unreproducible. If it returns, just post a note.