Bug 125458 - Thinkpad X40 suspend problems
Thinkpad X40 suspend problems
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Depends On:
  Show dependency treegraph
Reported: 2004-06-07 13:04 EDT by Jason Tibbitts
Modified: 2015-01-04 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 00:15:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Boot messages from normal ACPI boot (2.6.6-1.422 kernel) (10.93 KB, text/plain)
2004-06-07 13:06 EDT, Jason Tibbitts
no flags Details
Normal X startup log (62.98 KB, text/plain)
2004-06-07 13:06 EDT, Jason Tibbitts
no flags Details
X startup log after a (partially) successful ACPI resume (18.55 KB, text/plain)
2004-06-07 13:07 EDT, Jason Tibbitts
no flags Details

  None (edit)
Description Jason Tibbitts 2004-06-07 13:04:45 EDT
This report is probably exceedingly confusing; there are many
variables I'm trying to test (ACPI/APM, two kernels, text/graphics)
but I'll try to be as concise as possible.

I have a Thinkpad X40 installed with FC2.  The system runs fine, but
it will not suspend and resume properly.


Under APM (i.e. booted with acpi=off):

In text mode (init 3), the machine suspends when the lid is closed and
resumes when it is opened.  The resume seems to work but upon
attempting to start X I find the graphics system seems to be wedged,
and the following lines repeate endlessly on the console as the X
server fails to start:

(kernel 2.6.5-1.358)
Jun  7 11:01:03 rashi kernel: mtrr: base(0xe0020000) is not aligned on
a size(0x300000) boundary
Jun  7 11:01:03 rashi kernel: PCI: Found IRQ 11 for device 0000:00:02.0
Jun  7 11:01:03 rashi kernel: PCI: Sharing IRQ 11 with 0000:00:1d.0
Jun  7 11:01:03 rashi kernel: PCI: Sharing IRQ 11 with 0000:02:00.0
Jun  7 11:01:10 rashi kernel: [drm:i830_wait_ring] *ERROR* space:
130648 wanted 131064
Jun  7 11:01:10 rashi kernel: [drm:i830_wait_ring] *ERROR* lockup
Jun  7 11:01:12 rashi kdm[3141]: X server for display :0 terminated

Under kernel 2.6.6-1.422, the lines about IRQs do not appear, but upon
resuming the following line appears that does not appear under 358:

rashi kernel: Warning: CPU frequency out of sync: cpufreq and timing
core thinks of 1100000, is 1200000

After a suspend in graphical mode (i.e. with X running and being
displayed), the machine hangs hard (no respond to pings or sysrq)
under either kernel.  

After a suspend with the X server running but the console switched to
a text VT, the X server continues to run but the graphics are oddly
corrupted.  It's hard to describe but it's as if background fills
don't work; menus that would normally be white are shown with a border
and text, but with the background showing through.  The machine is
otherwise stable and the X server doesn't seem to complain.


Running under ACPI (i.e. no acpi=off) the situation is worse.  I
believe it is known that ACPI is busted on many Thinkpads but I'll
include my observations here for completeness.

Closing the lid puts the machine to sleep.  In graphical mode this
results in ~50 pixels of corruption at the top of the screen. 
Switching to text mode and back fixes it.  In text mode everything is
fine.  The following message appears on the console as the system is

ACPI breakpoint: Executed AML Breakpoint opcode

Putting the machine to sleep via "echo 3 > /proc/acpi/sleep" results
in the following under 2.6.5-1.358:
Stopping tasks: ==========================|
PM Entering state.  (that's all I can see)

and the screen goes blank.  Holding down the power button for a couple
of seconds revives it (the lid does not) but the display is completely
dead (backlight off).  It seems OK from the network.  It does not
matter whether the X server is running and displayed, running and
switched away, or not running.  The following appears in the logs:

Back to C!
zapping low mappings.
PM: Finishing up.
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
ehci_hcd 0000:00:1d.7: HC died; cleaning up
blk: queue 2155ee00, I/O limit 4095Mb (mask 0xffffffff)
usb 1-1: USB disconnect, address 2
Restarting tasks... done
inserting floppy driver for 2.6.5-1.358
e1000: eth0 NIC Link is Up 100 Mbps Full Duplex
floppy0: no floppy controllers found

I can attempt to restart the X server,at this point, but it fails.  I
will attach the log as X.log-acpi-resumed.

And under 2.6.6-1.422 (graphical or text modes):
Stopping tasks: ==========================|
PCI: Setting latency timer of device 0000:00:1d:7 to 64
Could not suspend devide 000:00:1d:7: error -5

(1d:7 is the EHCI controller).  The screen and backlight stay on,
although the backlight shuts off when the lid is closed.

The machine is completely hung at this point.  It must be reset by
holding down the power button for several seconds.

I have access to this laptop for a few more days and am happy to test
out any suggestions you may have.
Comment 1 Jason Tibbitts 2004-06-07 13:06:01 EDT
Created attachment 100925 [details]
Boot messages from normal ACPI boot (2.6.6-1.422 kernel)
Comment 2 Jason Tibbitts 2004-06-07 13:06:36 EDT
Created attachment 100926 [details]
Normal X startup log
Comment 3 Jason Tibbitts 2004-06-07 13:07:13 EDT
Created attachment 100927 [details]
X startup log after a (partially) successful ACPI resume
Comment 4 Giuseppe Castagna 2004-06-07 14:27:47 EDT
I can confirm most of the above (I manage two X40, both have the same
problems, the only difference is that with acpi=off the system does
not ends to boot (but no error message in /var/log). 
   I add that the same pixel corruption on the top of the screen
appears whenever I pres  Fn-F5 and redirect the output on the external
monitor. This makes the laptop completely useless for presentations.

Comment 5 Jason Tibbitts 2004-06-08 10:27:17 EDT
A quick update:

After reading old bug reports and recalling a problem I had with a
Dell C400 a long time ago, I removed the i686 kernels and installed
the i586 ones.  The ACPI situation did not change; suspending is
completely broken under 2.6.6-1.422 and only kills the graphics under

APM, however, is a different story.  It seems to work just fine under
the 358 kernel.  (!!)

Under the 422 kernel it seems to work most of the time but will hang
occasionally.  (I have a hunch that there is come correlation between
the clock speed; suspend/resume with the 422 kernel don't seem to work
well when the clock has been scaled back.  The logged messages about
clocks being out of sync would seem to have some bearing, but I
haven't rigorously tested this.)

Anyway, the bottom line is that the combination of APM and the i586
2.6.5-1.358 kernel seems to work.  The 422 kernel seems to have a few
regressions in the area of power management, at least on this machine.

So, what's different in the i586 kernel?  The 4G/4G split, perhaps? 
Should I try to build a custom kernel with any options tweaked?
Comment 6 Jason Tibbitts 2004-06-09 10:19:56 EDT
Just a note that the behavior has regressed slightly further with the
2.6.6-1.424 kernel.  ACPI results are unchanged, as are APM results
with the i686 kernel.  But now the i586 kernel now experiences the
same sort of graphics corruption upon resume as the i686 kernel does.
Comment 7 Dimitris 2004-08-08 02:46:09 EDT
The graphics corruption is due to garbage in memory. it happens on
most systems and its a graphics driver problem (thats why the console
is always fine after suspend, no corruption).

I've got an A31p which suspends and resumes fine.... except USB dies
after it resumes :(

i've tried to 'rmmod' the usb driver and 'modprobe' it after i resume
but that doesn't help, something is messed up in the IRQ's judging by
the /var/log/messages.
Comment 8 Dave Jones 2005-04-16 00:15:11 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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