Bug 172808 - kernel 2.6.14-1.1636_FC4 from "testing" causes video problems on a return from suspend
Summary: kernel 2.6.14-1.1636_FC4 from "testing" causes video problems on a return fro...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-09 22:53 UTC by Michal Jaegermann
Modified: 2015-01-04 22:22 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-02-04 00:08:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2005-11-09 22:53:26 UTC
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

Comment 1 Dave Jones 2005-11-10 06:20:14 UTC
what video card / driver ?


Comment 2 Michal Jaegermann 2005-11-10 07:00:29 UTC
> 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

Comment 3 Dave Jones 2005-11-10 19:59:07 UTC
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.


Comment 4 Michal Jaegermann 2005-11-11 20:09:16 UTC
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. :-)

Comment 5 Dave Jones 2006-02-03 07:09:44 UTC
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.


Comment 6 Michal Jaegermann 2006-02-03 20:36:09 UTC
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.

Comment 7 Dave Jones 2006-02-03 21:29:50 UTC
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 ?


Comment 8 Michal Jaegermann 2006-02-03 22:03:06 UTC
> Given there's a workaround, it sounds like this bug is closable ?

I think so; unless this is needed as a reference point.

Comment 9 Dave Jones 2006-02-04 00:08:09 UTC
not really, it's pretty well known how bad the situation is with resuming
graphics chips :-(

Thanks for testing, and the feedback though.



Note You need to log in before you can comment on or make changes to this bug.