You are not logged in.
I'm not sure whether this is related but I'm also having a problem with suspend. In contrast, mine is mainly about waking up from suspend: https://bbs.archlinux.org/viewtopic.php … 0#p1144200 Could be that it's not related at all, but I thought that my logs may point to a bug that is maybe also causing your problem. Additionally, I'm also working on a Lenovo T420.
Note: I was using the powerdown script (https://aur.archlinux.org/packages.php?ID=57421) by taylorchu when the error happened. This could have also been the origin for causing this problem. So, one hour ago, I reinstalled pm-utils to inspect this. If it solves the problem I have, I'll tell you.
Offline
I'm on intel integrated graphics, as set via BIOS. I think someone in the thread earlier posted that they were using nvidia, though.
Offline
I tried many things: different kernels (LTS from arch, and tradiional compilation of 3.0.4, 3.5, 3.5.1), removed acpid, cancelled the automatic awakening of the laptop when opening the lid. Even tried to roll-back to a previous xserver but that caused to many issues so i had to abondan that idea.
A workaround, however, seems to work: instead of pm-suspend, use pm-hibernate. I use hibernate in combination with a swap partitation and so far (knock on wood!) I haven't had any Xserver crashes anymore after resuming (I still don't use acpid, and no automatic resume with opening the lid). Down side is that hibernate takes much longer (about 40 seconds from pressing the powe button, mainly caused by loading the bios) to resume than suspend-to-ram. But for now i keep it this way as at least the Xserver doesn't crash (nor, do i need to kill the xserver which would anyway destroy all my open files, as suggested in comment #93)
EDIT: after 2d 19h uptime and only using pm-hibernate, i got the crash again
0: /usr/bin/X (xorg_backtrace+0x49) [0x81b75d9]
1: /usr/bin/X (0x8048000+0x173366) [0x81bb366]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb77cf40c]
3: /usr/bin/X (XIChangeDeviceProperty+0x198) [0x8152aa8]
4: /usr/bin/X (0x8048000+0x10b149) [0x8153149]
5: /usr/bin/X (0x8048000+0x1020e4) [0x814a0e4]
6: /usr/bin/X (0x8048000+0x2f195) [0x8077195]
7: /usr/bin/X (0x8048000+0x1cd85) [0x8064d85]
8: /lib/libc.so.6 (__libc_start_main+0xf5) [0xb743a605]
9: /usr/bin/X (0x8048000+0x1d0c9) [0x80650c9]
Segmentation fault at address 0x9
Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting
Last edited by btorb (2012-08-20 19:02:15)
Offline
OK see what we have so far.
-> Only happens when closing the lid
-> Doesn't matter if acpid or gnome-power-manager or xfce-power-manager catches the event
-> Older kernels do /not/ make a difference
-> X always seems to crash when (after? just before?) this happens
-> Seems to be related to intel graphics
-> The only thing we haven't tried is downgrade the X server and xf86-intel-video to adequately old versions.
My only workaround is to kill the X server every now and then (every 10-12 hours). This way, I got more than a week of uptime.
My intuition is that this is related to the X server somehow: the kernel waits for the graphics driver to complete something but since X crashes unexpectedly that something never finishes so the kernel just doesn't continue suspending.
I'm out of ideas...
Offline
I'll install nouveau and switch my BIOS settings to use the nvidia card. Just to see if it's really intel. I'll report back if it happens to me under nvidia. That way we can eliminate that variable for sure, too.
Last edited by Essl (2012-08-21 10:08:35)
Offline
OK, here is the /var/log/Xorg.0.log of the crash:
https://dl.dropbox.com/u/63420/Xorg.0.log.txt
And these are the last 30000 lines of the strace I attached to X (2.9MB):
https://dl.dropbox.com/u/63420/Xtrace.log.txt
Anyone can make anything out of these?
Offline
Ok, the thing just happened to me under nouveau. It's not the intel driver, unless it's nouveau as well.
Offline
Ok, the thing just happened to me under nouveau. It's not the intel driver, unless it's nouveau as well.
So, the common ground is that we all have X crash at the time and suspend by closing the lid.
Today I sat and did the following: I've located the point in the source of linux-3.4.9 that prints "PM: preparing system for mem sleep" and the one that prints "PM: Freezing user space processes" (which never happens). It seems that there are a couple of function calls in between and at least one semaphore operation (atomic_inc()). One of them blocks and never continues, I want to know which. So I've added tracking messages to the kernel, recompiled it, and now I've got a bunch of messages stating the kernel's progress between those two statements on every suspend.
Tomorrow (when this will happen again) I will know which call blocks, maybe we can try to pinpoint the source from that....
Anyway, my belief that this is X-related is getting stronger....
Offline
I am also having the same problem right now. Another thing that has started happening is if the battery is below 25% and I plug in the charger - the display goes blank. I have to shut the lid and then open again to get display. Now with this bug, if I close the lid the sleep icon starts to flash.
A probable solution that my friend suggested was use uxa acceleration instead of sna. After making that change, I am closing in on 48 hours of uptime with no issues.
I have enabled TPM and have not disabled MEI. I keep getting MEI warnings - so I don't think that is an issue.
Running Gnome, standard kernel and intel graphics.
Offline
The thing happened under nouveau again. Switched back to intel now, since nouveau doesn't let you regulate display brightness anymore after a successful sleep.
Of note is that under nouveau, if you open the laptop again, just briefly pressing the off button will make the pc resume sleep, then when you wake it up, it shuts down. It wasn't like that on intel for me, but I also installed acpid recently so I'm not sure if it's that.
I also want to share this error message from my kernel.log:
Aug 24 13:55:53 localhost kernel: [95609.813928] PM: Syncing filesystems ... done.
Aug 24 13:55:53 localhost kernel: [95609.822399] PM: Preparing system for mem sleep
Aug 24 13:56:55 localhost kernel: [95672.345554] [drm] nouveau 0000:01:00.0: PFIFO: unknown status 0x40000000
Aug 24 14:49:23 localhost kernel: [98815.711349] e1000e 0000:00:19.0: irq 50 for MSI/MSI-X
which was visible when opening the lid again. Not sure if it's relevant at all.
Last edited by Essl (2012-08-24 12:58:14)
Offline
This is definitely something graphics-related, the system just waits for something that never happens.
I'm scanning for the source a bit deeply but so far I've got that the backtrace in the kernel is:
drivers/tty/vt/vt_ioctl.c:1426: vt_waitactive
kernel/power/console.c:19: vt_move_to_console
kernel/power/suspend.c:98: pm_prepare_console
suspend_prepare() called(source lines are from linux-3.4.9)
Execution stops inside vt_waitactive. I'm tracking what is happening inside and will report back (and to linux kernel mailing list, why not!)
Last edited by yourself (2012-08-24 20:20:53)
Offline
Ok, one step further:
drivers/tty/vt/vt_ioctl.c:133: wait_event_interruptible
drivers/tty/vt/vt_ioctl.c:1426: vt_waitactive
kernel/power/console.c:19: vt_move_to_console
kernel/power/suspend.c:98: pm_prepare_consoleWhatsmore, I have been using the following handler in /etc/acpi/handler.sh
in lid close:
chvt 1
pm-suspendin lid open
chvt 7which, of course, does not make any difference at all :-)
Offline
A probable solution that my friend suggested was use uxa acceleration instead of sna. After making that change, I am closing in on 48 hours of uptime with no issues.
How did you do that?
Because I tried it by creating the file /etc/X11/xorg.conf.d/10-intel.conf with the following contents
Section "Device"
Identifier "intel HD3000"
Driver "intel"
Option "AccelMethod" "uxa"
EndSectionAnd as I recall, noticed absolutely no difference at all!
Offline
^^ That is exactly what I did.
My current uptime stands at 4 days and 4 hours.
Maybe it got fixed? //hopeful.
I am using the battery hack kernel parameters described on the wiki.
i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1
That's it for now. Nothing else changed.
Offline
a workaround that *seems* to work is to avoid interference between any signal from the lid (to the video driver) and pm-utils. In effect that means that I now have a keystroke to suspend/hibernate my laptop and only close the lid after the laptop in suspend/hibernate. when waking up i remove the automatic wake-up after opening the lid, and press the power button (define in /proc/acpi/wakeup). this *seems* to run smooth with causes the crashes... (although i am a bit hesistant as i had some "workarounds" before that turned out to be bogus after more uptime)
In a related post i asked how to avoid blanking the screen when closing the lid as this seems to be the culprit. however, no solution there yet. (remember the big warning at the top the acpid wiki )
Offline
a workaround that *seems* to work is to avoid interference between any signal from the lid (to the video driver) and pm-utils. In effect that means that I now have a keystroke to suspend/hibernate my laptop and only close the lid after the laptop in suspend/hibernate. when waking up i remove the automatic wake-up after opening the lid, and press the power button (define in /proc/acpi/wakeup). this *seems* to run smooth with causes the crashes... (although i am a bit hesistant as i had some "workarounds" before that turned out to be bogus after more uptime)
In a related post i asked how to avoid blanking the screen when closing the lid as this seems to be the culprit. however, no solution there yet. (remember the big warning at the top the acpid wiki )
Well, year-long habits are hard to break, it is just too easy opening/closing the lid. But yes, if you avoid suspending by closing the lid, you avoid the problems altogether. In any case, it's not *us* who will change, it's this bug that will go away :-)
As far acpid and the warning, I have disabled XFCE power management and handle it completely from acpid.
Offline
I'm on a different system (Mint 13 with Cinnamon on a Thinkpad T410i), but after a few searches this thread is by far the one with the most information in it. I'm not sure if they are of any use, but here are some observations I've made:
After being booted from the session, upon logging back in the wireless is unmanaged.
Using a keystroke to go into sleep does not work for me. I tried using the sleep shortcut key, but pressing it kicked me back to the login screen rather than sleeping.
Is there anything that I can provide that might be of use?
Last edited by heuristicus (2012-08-26 11:48:06)
Offline
^^ That is exactly what I did.
My current uptime stands at 4 days and 4 hours.Maybe it got fixed? //hopeful.
I am using the battery hack kernel parameters described on the wiki.
i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1That's it for now. Nothing else changed.
UXA did not work for me :-(
But I remember having those kernel parameters and removing them when (3.4?) I learnt that the kernel automatically enabled RC6 for i915. So I will re-enable them and see where it gets me...
Offline
I'm on a different system (Mint 13 with Cinnamon on a Thinkpad T410i), but after a few searches this thread is by far the one with the most information in it. I'm not sure if they are of any use, but here are some observations I've made:
After being booted from the session, upon logging back in the wireless is unmanaged.
Using a keystroke to go into sleep does not work for me. I tried using the sleep shortcut key, but pressing it kicked me back to the login screen rather than sleeping.
Is there anything that I can provide that might be of use?
Well, the thing about the wireless is that maybe the module is removed before entering suspend and since the procedure never completes, it is never inserted again. The same thing happens to me, but a simple
# modprobe iwlwififixes it. (you have to replace iwlwifi with your module)
Last edited by yourself (2012-08-26 21:49:46)
Offline
I just moved to systemd. The systemd wiki suggests that I need to change the system hooks now. I will see if not using pm-utils has any effect at all. If it does - then we have a solution. Systemd performance also seems to be much better.
Offline
I just moved to systemd. The systemd wiki suggests that I need to change the system hooks now. I will see if not using pm-utils has any effect at all. If it does - then we have a solution. Systemd performance also seems to be much better.
Nice idea. But can suspend/resume work without it? In any case, we're waiting for your results!!!
Offline
@yourself
Well, seems to be going smooth till now but I have had many reboots. Another thing I noticed in the Xorg log was,
[ 18.159] (II) intel(0): Printing DDC gathered Modelines:
[ 18.159] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 18.159] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 24.311] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 24.311] (II) intel(0): Printing DDC gathered Modelines:
[ 24.312] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 24.312] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 36.711] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 36.711] (II) intel(0): Printing DDC gathered Modelines:
[ 36.711] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 36.711] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 38.212] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 38.212] (II) intel(0): Printing DDC gathered Modelines:
[ 38.212] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 38.212] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 40.412] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 40.412] (II) intel(0): Printing DDC gathered Modelines:
[ 40.412] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 40.412] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 826.406] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 826.406] (II) intel(0): Printing DDC gathered Modelines:
[ 826.406] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 826.406] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)
[ 10185.058] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 10186.191] (II) AIGLX: Resuming AIGLX clients after VT switch
[ 10186.242] (II) intel(0): EDID vendor "AUO", prod id 8510
[ 10186.242] (II) intel(0): Printing DDC gathered Modelines:
[ 10186.242] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP)
[ 10186.243] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)That seems to be taking an enormous time to get back from sleep or boot. Not sure if related.
Offline
Bad news guys!
I have done a clean install on a non-ssd (shouldn't matter, but just in case) disk and installed X (with xf86-video-intel), GNOME and XFCE. Nothing else.
Configuration-wise:
-> /etc/mkinitcpio.conf: I enabled i915 in the MODULES
-> /etc/default/grub: I commented out GRUB_GFXPAYLOAD_LINUX=keep so that i915 would set its own video mode and enabled GRUB_TERMINAL_OUTPUT=console.
...and the same thing happened. Today seems like a bad day to be us... :-(
I opened a kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=45451
and an Xserver bug here: https://bugs.freedesktop.org/show_bug.cgi?id=53593
Offline
@yourself
Well, seems to be going smooth till now but I have had many reboots. Another thing I noticed in the Xorg log was,
[ 18.159] (II) intel(0): Printing DDC gathered Modelines: [ 18.159] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 18.159] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 24.311] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 24.311] (II) intel(0): Printing DDC gathered Modelines: [ 24.312] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 24.312] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 36.711] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 36.711] (II) intel(0): Printing DDC gathered Modelines: [ 36.711] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 36.711] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 38.212] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 38.212] (II) intel(0): Printing DDC gathered Modelines: [ 38.212] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 38.212] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 40.412] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 40.412] (II) intel(0): Printing DDC gathered Modelines: [ 40.412] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 40.412] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 826.406] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 826.406] (II) intel(0): Printing DDC gathered Modelines: [ 826.406] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 826.406] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e) [ 10185.058] (II) AIGLX: Suspending AIGLX clients for VT switch [ 10186.191] (II) AIGLX: Resuming AIGLX clients after VT switch [ 10186.242] (II) intel(0): EDID vendor "AUO", prod id 8510 [ 10186.242] (II) intel(0): Printing DDC gathered Modelines: [ 10186.242] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (54.7 kHz eP) [ 10186.243] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 2010 900 903 906 912 -hsync -vsync (36.5 kHz e)That seems to be taking an enormous time to get back from sleep or boot. Not sure if related.
I can't spot anything weird in that log. What was that triggered your attention?
Offline
OK, new versions of xorg-server (1.12.4) and xf86-video-intel (2.20.5) did not address this.
Shit.
Offline