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
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):
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),
(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.
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.
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.