System unusable after resume from suspend or hibernate [i945]

Bug #133677 reported by Rohan Dhruva
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
acpi-support (Ubuntu)
Invalid
Undecided
Unassigned
linux (Ubuntu)
Fix Released
Medium
Unassigned
xserver-xorg-video-intel (Ubuntu)
Invalid
High
Unassigned

Bug Description

I'm using an Acer TravelMate 3260 laptop; OS - fully updated kubuntu feisty fawn. (Now gutsy !)
The graphics card is intel 945gm and I'm using the i810 driver with 915resolution.

I boot the system, log into KDE via KDM, then select suspend from the log-off dialog. The system seems to hibernate and suspend fine. The power LED glows "orange" when suspended, and is off when hibernated. This is expected.

On resume, sometimes everything just works. But more often than not, my xorg is left completely corrupted. It shows weird corrupted blocks, xorg restarts repeatedly. Though I can use the mouse and keyboard during that period, so pressing the power button sometimes shuts off the computer normally. In very rare cases, resume is so broken that I need to hold down power button for 5 seconds to turn it off the ugly way.

Also a point to note is that when resuming either from hibernate or suspend, the power led keeps flashing orange - this is not expected. It should be a solid green on resume.

Suspend and resume work perfectly with uswsusp. Using s2ram, I need to use the options "s2ram -f -p -m" to have proper behaviour. I will be attaching the various debug output files shortly.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

My BIOS is up to date, and uname -a shows:

Linux ubuntu 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

After disabling SAVE_VIDEO_PCI_STATE as suggested by mjg59 on IRC, suspend and resume works properly. However, hibernate doesn't work at all - system doesn't go into hibernation. The process starts, and after sometime I'm again presented the login box.. And now after resume from system, the power LED is solid green, as expected ..

Matthew Garrett (mjg59)
Changed in acpi-support:
status: New → Fix Committed
Revision history for this message
unggnu (unggnu) wrote :

Could you please recheck it with latest Ubuntu Gutsy Gibbon 7.10 or the Live CD?

Changed in acpi-support:
status: Fix Committed → Incomplete
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Yes, I'm already running Kubuntu Gutsy (fresh install). In gutsy, after suspending, resume is random, and doesn't always work. More often than not, while resuming, my hard disk LED shows full activity, and screen is completely blank. The mouse and keyboard both don't respond. I need to press the power button for 4 seconds to turn off the laptop.

I've yet to try hibernate. I'll try it and report back here.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Please ignore my last comment - I have done some more experimenting.
First and foremost, hibernate works fine every time I tried.

After suspending, when I try to resume, as I mentioned, the hard disk LED is solid bright, screen blank, and keyboard/mouse unresponsive. However, if I still press the power key 3-4 times, the hard disk led stops blanks out, and I need to press Ctrl-Alt-F7 to get to X. Now each time I did this , there were varying results:

1) Once, I got the KDE session locked screen, but my keymap/keyboard was all messed up. For example, o key resulted in backspace, u key resulted in moving the cursor to the left etc. I had to login from tty1, and somehow I rebooted the computer.

2) Next time I used the power-key-after-resume trick to resume, and pressed ctrl-alt-f7, I got the KDM login screen, and whenever I tried to login, X restarted.

In short, resuming from suspend is highly erratic and unpredictable. Can I provide some more debug info to help out with the issue ?
Thanks !

unggnu (unggnu)
Changed in acpi-support:
status: Incomplete → New
Revision history for this message
unggnu (unggnu) wrote :

Please try a suspend, try to "recover" X and attach the files '/etc/X11/xorg.conf', '/var/log/Xorg.0.log', '/var/log/Xorg.0.log.old' and '~/.xsession-errors' and the output of 'lspci -vvnn'?

Changed in acpi-support:
status: New → Incomplete
Revision history for this message
unggnu (unggnu) wrote :

And please attach the output of 'dmesg' and the file '/var/log/syslog' after resume.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Ok, this time I "recovered" X and system worked very strangely. This is the 3rd time I've observed my system work this way after resume. I don't know how to describe it .. First instead of my kde session, it threw me back to the kdm login screen. After that, when I entered password and clicked on login, nothing happened until I move the mouse, or use the keyboard .. Similarly if I issue some terminal command like "mv foo bar" and press enter, it won't take place until I move the mouse .. Also when I restarted the system, I had to constantly move the mouse to get the system to restart. After reboot, the system works perfectly. This is the first time I've ever seen this behavior on any linux system ! Also, after resume net wasn't working. However, I've managed to copy the files which you required, and I'll be attaching them soon.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

I'm attaching all the files in one gzip, for convenience. After that I'll attach them one by one too, so that you can view them directly online :)

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

dmesg after resume.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Output of lspci -vvnn

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :
Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

One thing of interest is that suspend resume works perfectly using s2ram. I had submitted the whitelist entry for it, upstream - http://suspend.cvs.sourceforge.net/suspend/suspend/whitelist.c?view=log - the relevant section is :

/* Rohan Dhruva <email address hidden> */
{ "Acer, inc.", "TravelMate 3260 ", "", "", VBE_POST|VBE_MODE },

Which says my card requires VBE_POST and VBE_MODE quirks. The same entry is present on the hal quirks site for my laptop. Maybe this bug is occurring on ubuntu due to lack of these quirks on a plain ubuntu install ?
Please tell me how can I help more in getting this bug closed :)

Revision history for this message
unggnu (unggnu) wrote :

Have you tried to edit the file '/etc/default/acpi-support' ? Maybe this would help.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Can you please tell me which specific option(s) to enable or disable ? I tried enabling DOUBLE_CONSOLE_SWITCH but that did not help.
SAVE_VIDEO_PCI_STATE is disabled by default on gutsy. Is there any other option in that file acpi-support which corresponds to s2ram's VBE_POST and VBE_MODE ?

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Ok, I experimented with USE_DPMS and RESET_DRIVE too, which did not help either. Waiting from suggestions from you.

Revision history for this message
unggnu (unggnu) wrote :

I thought experimenting with POST_VIDEO=true, SAVE_VBE_STATE=true and SAVE_VIDEO_PCI_STATE=true could help but I don't know. I haven't used s2ram.
Maybe you could recheck the manpage of s2ram if there detailed descriptions of your working options.

Changed in acpi-support:
status: Incomplete → New
Revision history for this message
unggnu (unggnu) wrote :

You haven't attached your Xorg.0.log.old directly, only compressed.

I guess the important lines are:
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x007bf000 (pgoffset 1983)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x03038000 (pgoffset 12344)
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x04000000 (pgoffset 16384)
(II) intel(0): xf86BindGARTMemory: bind key 3 at 0x05000000 (pgoffset 20480)
(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x08000000 (pgoffset 32768)
(WW) intel(0): ESR is 0x00000001, instruction error
(WW) intel(0): Existing errors found in hardware state.

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x81) [0x80c9581]
1: [0xffffe420]
2: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b69022]
3: /usr/bin/X(xf86CrtcSetMode+0x279) [0x80faf49]
4: /usr/bin/X(xf86SetDesiredModes+0x139) [0x80fb2f9]
5: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b6c9e9]
6: /usr/lib/xorg/modules//libxaa.so [0xb79d64b2]
7: /usr/bin/X [0x80d18fc]
8: /usr/bin/X [0x80ded68]
9: /usr/lib/xorg/modules/extensions//libglx.so [0xb7c00b1a]
10: /usr/bin/X(xf86Wakeup+0x3bd) [0x80cacad]
11: /usr/bin/X(WakeupHandler+0x59) [0x8093269]
12: /usr/bin/X(WaitForSomething+0x1ae) [0x81bc89e]
13: /usr/bin/X(Dispatch+0x8d) [0x808f35d]
14: /usr/bin/X(main+0x495) [0x8076f05]
15: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d2c050]
16: /usr/bin/X(FontFileCompleteXLFD+0x1e1) [0x8076241]

Fatal server error:
Caught signal 11. Server aborting

(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4

Do you have compiz enabled? Have you tried it without?

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Here is the S2RAM page -- http://en.opensuse.org/S2ram
The options which make suspend work for my pc are : (ignore -f, that is just used to force to suspend if machine is not in whitelist)
-p, --vbe_post: VBE POST the graphics card after resume
-m, --vbe_mode: get VBE mode before suspend and set it after resume

I don't have compiz installed (neither beryl nor compiz-fusion nor metisse nor any other 3d desktop ;) )
However, glxinfo says direct rendering is enabled. With the above two s2ram options, I've tested in suse, suspend works with direct rendering enabled. However when compiz is enabled, many problems are caused (in suse).

Can you please tell me how do I emulate the -p and -m options using acpi-support ?

> You haven't attached your Xorg.0.log.old directly, only compressed.
My mistake, sorry :) Also, xsession-errors file is there in the compressed tarball, but I forgot to un-hide it !

Revision history for this message
unggnu (unggnu) wrote :

I am no expert but I would try it with uncommenting out SAVE_VIDEO_PCI_STATE=true. Another solution could be to check for a bios upgrade for your laptop. Otherwise you just have to wait for an driver/kernel upgrade, I don't know.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

My BIOS is up to date .. I'll try out with that option enabled.

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Ouch, that did not work either .. Suspend/resume just doesn't work as good as s2ram :( Even my internet (ethernet, not wireless) is not up after suspend - though that is easily solved by removing and inserting the lan card module (sky2). And the biggest problem is still that move-mouse-to-prompt-action .. I am really stumped by that issue ! I've _never_ seen anything like that happening !

description: updated
Revision history for this message
Peter Clifton (pcjc2) wrote : Re: [Bug 133677] Re: System unusable after resume from suspend or hibernate [i945]

On Sun, 2007-11-04 at 11:18 +0000, Rohan Dhruva wrote:
> Ouch, that did not work either .. Suspend/resume just doesn't work as
> good as s2ram :( Even my internet (ethernet, not wireless) is not up
> after suspend - though that is easily solved by removing and inserting
> the lan card module (sky2). And the biggest problem is still that move-
> mouse-to-prompt-action .. I am really stumped by that issue ! I've
> _never_ seen anything like that happening !

Me neither, but it _sounds_ like it could be related to IRQs not coming
back properly after suspend (a timer or something?). The mouse will
happily provide interrupts as you move it, whether that is what's
dragging the system along and letting it execute things, I don't know.

Disclaimer... I'm no expert on suspend / resume, so the above suggestion
may be complete rubbish. It's where I'd start looking if I were seeing
the issue.

Does cat /proc/interrupts show various interrupt counts increasing after
the resume? Are any static which were increasing before the suspend?

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

With some preliminary diagnosing, I've found out that acpi interrupt increases only on mouse-move after resume from suspend. Does this mean anything ? Any more suggestions for me to try ?

Revision history for this message
Peter Clifton (pcjc2) wrote :

My ACPI interrupt only seems to increase with ACPI related events, such as pressing the lid button.

I have my "timer" and "LOC" listings ticking up continually, as is the one shared by wireless / ethernet / video on my machine.
( watch -n 0.5 cat /proc/interrupts )

It is the timer interrupt which I thought might be an issue.

Are there any errors reported in your dmesg log? (Perhaps you could attach that).

I'm guessing the next steps to take might be to open a new bug with the kernel package for this issue, as it doesn't "seem" to be X11 related, and / or report this upstream with the kenel bugzilla. (I guess one of the Ubuntu kernel people might be able to help with that).

Revision history for this message
Peter Clifton (pcjc2) wrote :

You might try booting the kernel with:

pci=noacpi
or
pci=routeirq
or
noapic

Revision history for this message
Bryce Harrington (bryce) wrote :

I've collected the reports about failures during mode switching (e.g. suspend/resume), such as bugs 138256 and 150109:

https://wiki.ubuntu.com/X/Bugs/ScreenModeChange

I'd encourage anyone with Intel graphics having problems with blank, black, or frozen screens after resume from suspend, hibernate, tty switch, and so on, to add data to that page, so we can get a more complete feel for what the bugs are.

I've also created a page summarizing how to analyze and work around these issues. It would be worthwhile for anyone experiencing these issues to review and try these steps, and then report their findings on the appropriate bug

https://wiki.ubuntu.com/X/Debugging#head-0b6e9c6b60fa07cda4013a1c51239f1c14c4f89d

Revision history for this message
Oleksij Rempel (olerem) wrote :

according to bugzilla.kernel.org

"It is impossible to make video work after a resume from RAM (S3 resume) on all
herdware configurations at the kernel level. However, there is a userland tool
for that called s2ram (see http://en.opensuse.org/S2ram). Please try to use it."

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

Frankly speaking, I don't understand the use of doing so much debugging, when s2ram solves the issue perfectly. Suspend/resume works out of box on suse here, because it uses s2ram. (-p -m are the required options on my laptop) - http://suspend.sourceforge.net/
Also, I think from hardy onwards this issue will be solved, because ubuntu will migrate to hal/pm-suspend infrastructure. Even there, most machines are supported out of box - http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

Ubuntu IMHO is just trying to over-complicate things by using acpi-support and what not !

Changed in linux:
status: Unknown → In Progress
Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Bryce Harrington (bryce) wrote :

This seems like a kernel bug. Reassigning and closing the X.org component.

Changed in xserver-xorg-video-intel:
status: Confirmed → Invalid
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Hardy Heron Alpha series was recently released. Alpha2 and subsequent releases contain an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. Note you will only be able to test Suspend from the LiveCD, not Hibernate. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks!

Changed in linux-source-2.6.22:
status: New → Incomplete
Revision history for this message
Oleksij Rempel (olerem) wrote :

This issue is not fixed for me with hardy.

I have this bug for long time with ubuntu, and i newer had a time to look what can i do, but now:

it worked for me with s2ram ... so what s2ram do and ubuntu-suspend not...

according to:
http://en.opensuse.org/S2ram
"Machines with Intel graphics chipsets often work with "s2ram -f -a3", even when using vesafb framebuffer."

    -f, --force: force suspending, even on unknown machines. -- not important
    -a, --acpi_sleep: set the acpi_sleep parameter before suspend <--- !!! important
                      1=s3_bios, 2=s3_mode, 3=both

"Since kernel 2.6.16, the acpi_sleep parameter can be set during runtime (no reboot needed) in /proc/sys/kernel/acpi_video_flags, with "1" for s3_bios, "2" for s3_mode and "3" for both. More information about those hacks can be found in the kernel-source (usually installed in /usr/src/linux) in the file Documentation/power/video.txt."

So ubuntu-suspend do not set acpi_video_flags !!! It should be implemented before it hardy geting stable.

=============!!! try this !!! ================

echo 3 > /proc/sys/kernel/acpi_video_flags
/etc/acpi/sleep.sh force

===========!!! it working for me !!! ============

my hardware:
dmidecode
        Manufacturer: ASUSTeK Computer INC.
        Product Name: P5LD2-VM

video 945g
lspci -nvvs 00:02.0
00:02.0 0300: 8086:2772 (rev 02) (prog-if 00 [VGA controller])
 Subsystem: 1043:817a
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at cfe00000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at 8800 [size=8]
 Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at cfe80000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
  Address: 00000000 Data: 0000
 Capabilities: [d0] Power Management version 2
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Revision history for this message
Oleksij Rempel (olerem) wrote :

I created file:
~$ cat /etc/acpi/suspend.d/06-acpi-video-flag.sh
#!/bin/sh
echo 3 > /proc/sys/kernel/acpi_video_flags
---------------------------------------------------

so it can be done by default. Can some one confirm if it solve you
problem?

Revision history for this message
Chris Cheney (ccheney) wrote :

For my i945 laptop I get the following results (on both 32/64bit):

0 failure to restore screen
1 restores screen
2 failure to restore screen
3 restores screen

I did the above testing from single user mode without X running.

Chris

Changed in linux:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

acpi-support is no longer used on Hardy for suspend/resume - marking task 'Invalid'.

Changed in acpi-support:
status: New → Invalid
Revision history for this message
Chris Cheney (ccheney) wrote :

For Hardy that probably should be pm-utils then instead.

My question for mjg59 tomorrow is: Should the kernel handle my laptop case properly or is my laptop buggy and need a /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-toshiba.fdi quirk entry. It did work in Gutsy out of the box but that was using the old style of suspend/resume. So if it needs an entry that means that there are an unknown number of Gutsy users whose laptops suspend may break when upgrading to Hardy... So we will need to push extra hard for testing on laptops before Hardy release.

Chris Cheney (calc)

Revision history for this message
Rohan Dhruva (rohandhruva) wrote :

As Leann Ogasawara suggested, I tried the Hardy Alpha CD. Suspend and resume WORKS PERFECTLY on that cd, I tried 5-6 times. As he said, I couldn't try hibernate, but now that Hardy uses the hal-info backend, this bug is resolved for me (my machine is present in the hal-info database).

Thanks a lot, and cheers to ubuntu developers :)

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Rohan, thanks for testing and the update. I'm glad to hear things are working for you with the Hardy Alpha release. I'm going to go ahead and close this report for now.

Chris and fishor, if you guys are still having issues with the latest Hardy kernel care to open a new bug report?

Thanks!

Changed in linux:
status: Triaged → Fix Released
Revision history for this message
Sebastian (sebastianhaselbeck) wrote :

I think most people know but I just want to point out that this whole hibernate/suspend issue is also the most "popular" problem on Ubuntu brainstorm.

Revision history for this message
nutznboltz (nutznboltz-deactivatedaccount) wrote :

If your suspend and resume is still broken, can you please test and report if this works?

memory_corruption_check_size=128K

in the boot options.

The default is

memory_corruption_check_size=64K

but it seems that's not enough for some systems.

Thanks

If you don't know how to set BootOptions read

https://help.ubuntu.com/community/BootOptions

Also this thread is very important to anyone looking at this bug

http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-07/msg04621.html

Changed in linux (Ubuntu):
assignee: Ubuntu Kernel ACPI Team (ubuntu-kernel-acpi) → nobody
Changed in linux:
status: In Progress → Fix Released
Changed in linux:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.