Bug 185674 – sys-kernel/suspend2-sources-2.6.22 leaves vesafb in weird state after resume

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Vladimir Pouzanov 2007-07-17 16:55:00 UTC]

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

[Comment 1 Alon Bar-Lev (RETIRED) 2007-07-17 17:37:50 UTC]

Is this new for 2.6.22?
Worked with 2.6.21-r6?

[Comment 2 Vladimir Pouzanov 2007-07-17 17:54:40 UTC]

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.

[Comment 3 Alon Bar-Lev (RETIRED) 2007-07-17 17:57:24 UTC]

Exactly which 2.6.20?

[Comment 4 Vladimir Pouzanov 2007-07-17 18:05:07 UTC]

2.6.20-r6

[Comment 5 Alon Bar-Lev (RETIRED) 2007-07-19 16:38:47 UTC]

Did you had CONFIG_FB_VGA16 in 2.6.20 kernel?

[Comment 6 Vladimir Pouzanov 2007-07-19 16:43:51 UTC]

no

[Comment 7 Alon Bar-Lev (RETIRED) 2007-07-19 16:51:21 UTC]

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?

[Comment 8 Michal Januszewski (RETIRED) 2007-07-19 19:52:48 UTC]

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) :)

[Comment 9 Alon Bar-Lev (RETIRED) 2007-07-19 19:54:47 UTC]

Great!
Does this new implementation available in gentoo-sources?

[Comment 10 Vladimir Pouzanov 2007-07-19 21:05:32 UTC]

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.

[Comment 11 Vladimir Pouzanov 2007-07-21 18:26:43 UTC]

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.

[Comment 12 Alon Bar-Lev (RETIRED) 2007-07-24 18:34:03 UTC]

spock?

[Comment 13 Michal Januszewski (RETIRED) 2007-07-24 22:52:41 UTC]

Have you tried the vbetool-related options in the hibernate script? 

[Comment 14 Alon Bar-Lev (RETIRED) 2007-07-25 03:11:42 UTC]

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.

[Comment 15 Alon Bar-Lev (RETIRED) 2007-08-07 13:31:05 UTC]

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...

[Comment 16 Alon Bar-Lev (RETIRED) 2007-08-31 07:29:18 UTC]

Vladimir, can you please test this with gentoo-sources?

[Comment 17 Vladimir Pouzanov 2007-08-31 09:00:19 UTC]

Ok, I'll test it ASAP, currently the hardware is lying with dead BIOS EEPROM.

[Comment 18 Alon Bar-Lev (RETIRED) 2007-09-04 04:36:02 UTC]

*** Bug 179820 has been marked as a duplicate of this bug. ***

[Comment 19 Alon Bar-Lev (RETIRED) 2007-09-28 17:33:42 UTC]

Please reopen when you are able to work on this.
Thanks!