Red Hat Bugzilla – Bug 172808
kernel 2.6.14-1.1636_FC4 from "testing" causes video problems on a return from suspend
Last modified: 2015-01-04 17:22:56 EST
Description of problem: With 2.6.14-1.1636_FC4 a laptop (Acer Travelmate 230) returns from a suspension but it looks that it is pretty good chance that X server will not survive that experiment. It may work, but with few tries I got no picture on a (default) vt7 and totally messed up vt1 covered with garbage characters on a gray backgroud while other text consoles were still operational. On another try I got all edges (of icons, or opened windows) "weird" with pixels apparently on-and-off there in a random manner and a dead keyboard although mouse was still ok. Just restarting X server helped in every case but effect of this sort defat to a great extent a purpose of the whole exercise. I do not recall such incidents when using earlier kernels; 2.6.13-1.1526_FC4 and 2.6.13-1.1532_FC4 in particular. Version-Release number of selected component (if applicable): 2.6.14-1.1636_FC4 How reproducible: erratic but happens often enough to be a sure trouble
what video card / driver ?
> what video card / driver ? Ah, sorry. A relevant fragment from /var/log/Xorg.0.log (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (--) Chipset 845G found A "pcibus layout" of this particular laptop can be found if needed, for example, in a text of bug #89990
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
In my first test with 2.6.14-1.1637_FC4 I immediately got starting at me a blank screen where X display should be and the first virtual terminal covered with dots on a light grey background. Other vt's were ok and doing 'killall /sbin/mingetty' actually managed to clear everything. It appears that I was able to work around the issue by adding to my "suspension helper script" 'chvt 1' before going to sleep and 'chvt 2; chvt 7' on a wake-up. This seems to kick video hard enough for a display getting sane. This kind of "voodoo hackery", which is clearly a particular configuration dependent, was not required with earlier kernels. Still - so far it allows to survive the latest updates. This is really a laptop of my wife, and it travels a lot hence I am not always on hand if an intervention is required, so if it will get screwed too much I will be in a big trouble. :-)
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
With kernel 2.6.15-1.1830_FC4 so far I managed to suspend (to memory) and restore four times in a row without video, or other things, going haywire but it looks that 'chvt 2 ; chvt 7' tricks are still needed.
Yeah, we need to do that chvt trick in FC5 too, otherwise X gets upset when you return, and this is the nicest way we have of kicking it into redrawing the screen. Making resume work without this hack is a pretty involved task, as it involves such things as the kernel knowing about mode-setting on each card, and other complicated nonsense. Given there's a workaround, it sounds like this bug is closable ?
> Given there's a workaround, it sounds like this bug is closable ? I think so; unless this is needed as a reference point.
not really, it's pretty well known how bad the situation is with resuming graphics chips :-( Thanks for testing, and the feedback though.