Bug 91490 - restore-from-disk hangs IBM Thinkpads if X is running
Summary: restore-from-disk hangs IBM Thinkpads if X is running
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-23 06:46 UTC by andrew m. boardman
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-06 19:36:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description andrew m. boardman 2003-05-23 06:46:23 UTC
On various IBM Thinkpad models (including at least the X31 and T40), suspending
to disk and then restoring from disk causes the machine to hang hard.  (Fixable
only with the power switch.)  Shutting down X avoids the problem.  Switching to
a text vty while X is still running does *not* fix the problem.  The only other
symptom (and it may not be a symptom, just creative memory use; see below) is
that a band at the top of the screen is filled with garbage, as though random
crap were being written to the beginning of video memory.  Package versions are
stoch RH9, kernel-2.4.20-13.9 and XFree86-4.3.0-2.

Under 7.3 (kernel-2.4.18-17.7.x, XFree86-4.2.0-8), the same procedure works
perfectly; the band of garbage does appear at the top of the screen on restore,
but it is almost instantly redrawn as it should be.


Steps to Reproduce:
1.Install RH 9 on a Thinkpad.
2.Start X.
3.Suspend to disk.
4.Restore from disk.

Comment 1 Alan Cox 2003-06-05 15:42:01 UTC
This is between the BIOS and XFree86 - could be XFree86 is now using mode setups
the BIOS mishandles.

Comment 2 Mike A. Harris 2003-06-06 19:36:50 UTC
This type of problem is almost universally impossible to diagnose precicely
without physically having the hardware and spending a fair amount of time
deep debugging, possibly disassembling BIOS code - which is likely at fault
for not saving and restoring the video hardware properly.

XFree86 has no knowledge whatsoever what the BIOS suspend to disk stuff is
doing.  If the BIOS doesn't save/restore something properly, then you can
have any number of problems.  The simple solution, is do not use suspend
to disk via the BIOS and/or to contact your vendor about BIOS updates.

Since I feel strongly that this is a BIOS problem, and not an XFree86 bug,
you may feel free to open a bug report in XFree86 bugzilla upstream at
http://bugs.xfree86.org for a second opinion from the upstream project if
you wish, and include the URL here, and I will track their responses.  Should
they turn out to disagree with me, and determine there is indeed an XFree86
bug, perhaps we can work together to find a solution.

Closing as NOTABUG.

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