after resuming from hibernate (seems to be no problem with suspend-to-ram, only suspend-to-disk is affected) I have vesafb process eating up 100% cpu time, and in fact fully utilizing one of my cpu cores. I have vesafb-tng in framebuffer and nvidia driver (1.0.9755-r1) in X11. The only way to solve it is to reboot. While switching to any VT I get vesafb: BUG, returned from vm86 with 0 (EIP: 0xc0fa2) vesafb: mode switch failed (eax: 0x4f02) in system log Reproducible: Sometimes Steps to Reproduce: 1. hibernate 2. wake up notebook Actual Results: vesafb eats all resources Expected Results: vesafb is mostly idle
Is this new for 2.6.22? Worked with 2.6.21-r6?
I haven't used 2.6.21 a lot (due to #177952), but I don't remember having such problems. I'm sure it was not in 2.6.20 though.
Exactly which 2.6.20?
2.6.20-r6
Did you had CONFIG_FB_VGA16 in 2.6.20 kernel?
no
Hello spock, I need your help here... I don't see any relevant change in your code, but the kernel behaves differently. Maybe something to do with suspend handling which affected other components on kernel?
This BUG message isn't very encouraging.. My bet would be that this is caused by some change in the arch or power code. The best way to identify the problem would to run git bisect and narrow it down to a specific patch. I'm note sure it's worth the effort though -- perhaps switching to uvesafb would be an easier solution (I don't plan on working on vesafb-tng any longer and would like to concentrate on uvesafb instead) :)
Great! Does this new implementation available in gentoo-sources?
switched to uvesafb. I had enough fun with bisect trying to find acpi s5 bug ;) I'll report if I have any issues with this implementation.
I have more info regarding uvesafb and suspend2 (tuxonice). suspend-to-disk seems to work ok, but suspend-to-ram *always* fails for VT: when I switch from X session to VT I see blue-colored garbage (blue-back-blue stripes in fact). X11 works ok.
spock?
Have you tried the vbetool-related options in the hibernate script?
spock: He had no problems with vesafb-tng and s2ram and getting somekind of picture with uvesafb, so I don't think vbetool is not required in this case.
Hello Vladimir, Let's try to make spock feel more comfortable :) Suspend to ram has nothing to do with suspend2. So if you can reproduce this using gentoo-sources I think people will find this issue more interesting...
Vladimir, can you please test this with gentoo-sources?
Ok, I'll test it ASAP, currently the hardware is lying with dead BIOS EEPROM.
*** Bug 179820 has been marked as a duplicate of this bug. ***
Please reopen when you are able to work on this. Thanks!