Horrible video output upon resume from suspend

zachera · 2013-07-28 19:13:00

Hello,

I'm running i3wm with Arch Linux on an HP ProBook 6360b and since a few days ago, I've been getting horrible video output when resuming from a suspended state. I use 'systemctl suspend' to suspend, and this is what happens when I try to resume: http://i.imgur.com/XwIcOa7.jpg (this is an output of 'mount' in xterm). I am able to see everything clearly upon logging out and back in (killing off the X server, I suppose). Any ideas as to what's going on?

Thank you,
Zack

andy123 · 2013-07-29 00:09:02

What graphics chip and driver are in this laptop? Since when has this been happening? Whan kernel version are you running? Please try to include information like those in your posts in the future to make answering your questions easier.
In case you are using the closed source calatyst/fglrx driver and this has only started happening with the latest beta, then I have the same problem but no solution besides downgrading or switching to the open-source driver, yet.

zachera · 2013-07-29 03:06:54

I'm just using xf86-video-intel package with 3.10.3-1 kernel

"lspci | grep VGA" output:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

Last edited by zachera (2013-07-29 03:07:45)

ewaller · 2013-07-29 03:36:57

Well, I am running an HP DV4 Pavilion; Intel Core Duo, xf86-video-intel, 3.10.3-1 kernel, i3-wm. Works like a charm here.

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

How are you suspending? systemd (I am), ACPI, or something else.

pks · 2013-07-29 06:16:56

I had the same problem with my Intel graphics chipset. It is a known issue (can't remember the Kernel bug number though). I was able to fix that problem by reversing a specific commit in the Linux kernel. I've pasted that patch online. You have to build a custom kernel with that patch to fix that bug.

zachera · 2013-07-29 20:00:43

ewaller wrote:

Well, I am running an HP DV4 Pavilion; Intel Core Duo, xf86-video-intel, 3.10.3-1 kernel, i3-wm. Works like a charm here.
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
How are you suspending? systemd (I am), ACPI, or something else.

Through my XF86Sleep key, which is programmed to do the following through i3:

bindsym XF86Sleep exec "systemctl suspend"

pks wrote:

I had the same problem with my Intel graphics chipset. It is a known issue (can't remember the Kernel bug number though). I was able to fix that problem by reversing a specific commit in the Linux kernel. I've pasted that patch online. You have to build a custom kernel with that patch to fix that bug.

This is probably the same issue I'm having because it seems that this started to occur after I updated the linux package a few days ago. I also read somewhere in the news that Arch Linux is one of the few distributions with a stable release of the 3.10 kernel?

Last edited by zachera (2013-07-29 20:01:07)

cfr · 2013-07-29 21:43:34

Since upgrading linux to 3.10.3-1 yesterday, I'm also seeing corruption following suspend. I saw some with 3.10.2 but it is much worse with 3.10.3. Before, I only saw corruption on the background of the password-entry screen where I unlock the session but now I'm also seeing it persist in X after I unlock it. The only work around I've found is logging out and in again i.e. presumably killing X.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

I am suspending by closing the laptop lid. In X, this is handled by KDE and not by systemd. systemd is set to respect the inhibitor lock KDE sets even for lid close since two suspend cycles are triggered otherwise.

I can post screenshots if helpful but basically I get black horizontal lines attached to the left of whatever window has the focus. Switch to a different window, it gets the lines. Switch back, the lines revert to the original window. The same black horizontal lines were permanently attached to all windows as far as I could tell while those windows were in focus.

I am using the default acceleration method which I believe is UXA and default power savings for the gpu. Before this, I got occasional artefacts but they were not persistent e.g. I could switch windows and back to get rid of anything which came up.

Links:
https://lkml.org/lkml/2013/7/6/120
https://bugzilla.kernel.org/show_bug.cgi?id=60530 - looks like the issue is fixed but not for unpatched kernels 3.10.{3,4}. Since Arch tries not to patch, I hope this gets into 3.10.5 mainline and that filters through to us soon!

Last edited by cfr (2013-07-29 22:55:40)

zachera · 2013-07-30 06:09:49

It's good to know that I'm not the only one having this issue. Thanks, cfr.

pks · 2013-07-30 06:11:41

cfr wrote:

...
Links:
https://lkml.org/lkml/2013/7/6/120
https://bugzilla.kernel.org/show_bug.cgi?id=60530 - looks like the issue is fixed but not for unpatched kernels 3.10.{3,4}. Since Arch tries not to patch, I hope this gets into 3.10.5 mainline and that filters through to us soon!

Exactly, this was the bug I had been talking about. Did you try compiling the kernel with the patch I posted?

Edit: one more fix was to switch from UXA acceleration to the newer SNA acceleration method, iirc. Look here for a method to do that.

Last edited by pks (2013-07-30 06:13:05)

thrashrokz33 · 2013-07-30 20:55:21

I'm also having this issue on a Lenovo Y470, integrated Intel card.

Last edited by thrashrokz33 (2013-07-30 20:56:12)

pks · 2013-07-30 20:56:48

thrashrokz33 wrote:

I'm also having this issue on a Lenovo Y470, integrated Intel card.

Did you try any of the workarounds I mentioned above?

cfr · 2013-07-31 00:03:12

Hmm... It is not consistent for me. I woke from sleep earlier and everything was fine. I noticed I just got updated video drivers but that was after the resume so definitely not connected.

I switched to UXA after having problems with SNA but I will try again if the issue persists. No I haven't tried compiling with the patch. First, I am not sure which patch you meant you posted and, second, I'm fed up with compiling kernels. Though obviously if the problem persists and is bad, I'll do that and hopefully obviously, my being fed up with compiling kernels is my problem and nobody else's. I'm just explaining my motivational deficiency. Also, I've never tried to compile a kernel I actually intended to use which might be more daunting than trying to compile one I merely hoped to boot!

cfr · 2013-08-04 14:03:43

I just had graphical glitches and a hung X. The system wasn't hung - I killed X with ctrl-alt-backspace and it restarted automatically fine. Unlike some other reports, occurrences of mei_me in the logs look normal (no different from successful sleep-resume) but I did find many repeated instances of

kernel: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

The first instance of this is followed by

[drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state

Does anybody know what I'm meant to do with this file? cat can't read it because it cannot allocate memory (!). less can read it but it appears to include large amounts of data rather than text and seems to be huge. file claims it is an empty file and ls -l shows it has 0 bytes! The top of the file contains some text:

^@<A0><93><F2>^A<88><FF><FF><90>g{^@^@^@^@^@ s 23391^@us
Kerni915_error_state^@^@^@^@^@^@^@^@: 0x0116
EIR: 0x00000000
IER: 0x8c749081
PGTBL_ER: 0x00000000
FORCEWAKE: 0x00000001
DERRMR: 0x0000ffff
CCID: 0x0350010d
  fence[0] = 97902b0047a001
  fence[1] = fffff3ff0b5b4001
  fence[2] = fffff3ff0c9dd001
  fence[3] = 63ef003063e0001
  fence[4] = b5f50030b5f2001
  fence[5] = cd230030cd14001
  fence[6] = fffff3ff0b5ae001
  fence[7] = fffff3ff0b5ee001
  fence[8] = fffff3ff06398001
  fence[9] = 3904003038f9001
  fence[10] = ce3a0030ce2f001
  fence[11] = ce460030ce3b001
  fence[12] = 00000000
  fence[13] = 00000000
  fence[14] = 00000000
  fence[15] = 00000000
  INSTDONE_0: 0xfffffffb
  INSTDONE_1: 0x9bf8ffe7
  INSTDONE_2: 0x00000000
  INSTDONE_3: 0x00000000
ERROR: 0x00000000
DONE_REG: 0x00000000
render command stream:
  HEAD: 0x000031b0
  TAIL: 0x00003218
  CTL: 0x0001f001
  ACTHD: 0x0b56f674
  IPEIR: 0x00000000
  IPEHR: 0x7a000002
  INSTDONE: 0xfffffffb
  BBADDR: 0xb56f6758000020b
  INSTPS: 0x8000020b
  INSTPM: 0x00000080
  FADDR: 0x0b56f800
  RC PSMI: 0x00000010
  FAULT_REG: 0x00000000
  SYNC_0: 0x00000000 [last synced 0x00000000]
  SYNC_1: 0xfffff08d [last synced 0xfffff090]
  seqno: 0xfffff08f
  waiting: no
  ring->head: 0x00000000
  ring->tail: 0x00003218
bsd command stream:
  HEAD: 0x00000000
  TAIL: 0x00000000
  CTL: 0x0001f001
  ACTHD: 0x00000000
  IPEIR: 0x00000000
  IPEHR: 0x00000000
  INSTDONE: 0xffeffffe
  INSTPS: 0x00000000
  INSTPM: 0x00000000
  FADDR: 0x00023000
  RC PSMI: 0x00000018
  FAULT_REG: 0x00000000
  SYNC_0: 0xfffff08d [last synced 0x00000000]
  SYNC_1: 0xfffff08f [last synced 0x00000000]
  seqno: 0xffffeffe
  waiting: no
  ring->head: 0x00000000
  ring->tail: 0x00000000
blt command stream:
  HEAD: 0x00001bd0
  TAIL: 0x00001c80
  CTL: 0x0001f401
  ACTHD: 0x00001bdc
  IPEIR: 0x00000000
  IPEHR: 0x0b140001
  INSTDONE: 0xfffffff7
  INSTPS: 0x00000000
  INSTPM: 0x00000000
  FADDR: 0x00045bf8
  RC PSMI: 0x00000010
  FAULT_REG: 0x00000000
  SYNC_0: 0xfffff08f [last synced 0xfffff08d]
  SYNC_1: 0x00000000 [last synced 0x00000000]
  seqno: 0xfffff08d
  waiting: yes
  ring->head: 0x00000000
  ring->tail: 0x00001c80
Active [21]:
  02fee000     4096 36 10 fffff090 fffff090 dirty render snooped (LLC)
  0cef8000    16384 37 00 fffff090 0 dirty render snooped (LLC)
  0dc8a000   229376 36 02 fffff090 fffff090 X dirty render snooped (LLC)
  35975000  5242880 36 00 fffff090 fffff08f X dirty render snooped (LLC)
  4156f000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  04a30000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  16b65000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  16b66000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  0763d000    16384 37 00 fffff090 0 render snooped (LLC)
  16b67000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  16b68000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  03749000   196608 36 00 fffff090 fffff08d X dirty render snooped (LLC) (name: 6)
  41492000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  41493000     4096 76 00 fffff090 0 dirty render snooped (LLC)
  0b56f000    32768 3f 00 fffff090 0 dirty render snooped (LLC)
  0047a000  5242880 36 02 fffff091 fffff091 P X dirty blt uncached (name: 2) (fence: 0)
  02ff0000  5242880 36 00 fffff091 fffff090 X dirty blt snooped (LLC) (name: 3)
  00e82000    16384 7e 00 fffff091 0 dirty blt snooped (LLC)
  12c51000   327680 36 02 fffff092 fffff092 X dirty blt snooped (LLC)
  0ce55000     4096 36 02 fffff092 fffff092 dirty blt snooped (LLC)
  00e87000    16384 7e 00 fffff092 0 dirty blt snooped (LLC)
Pinned [12]:
  00070000     8192 10 00 0 0 P dirty snooped (LLC)
  00072000  4227072 76 00 0 0 P uncached (name: 1)
  0047a000  5242880 36 02 fffff091 fffff091 P X dirty blt uncached (name: 2) (fence: 0)
  0097e000    16384 40 40 0 0 P dirty uncached
  03500000     8192 50 00 0 0 P dirty snooped (LLC)
  00000000     4096 01 01 0 0 P snooped (LLC)
  00001000   131072 40 40 0 0 P dirty snooped (LLC)
  00021000     4096 01 01 0 0 P snooped (LLC)
  00022000     4096 01 01 0 0 P snooped (LLC)
  00023000   131072 40 40 0 0 P dirty sno

After that it all appears to be gobbledygook.

pks · 2013-08-04 20:49:26

The just released stable update to 3.10.5 contains some fixes regarding i915, especially some that fix restoring fences. The update fixed the issue for me.

cfr · 2013-08-04 22:11:19

That sounds very promising. Hope it makes it to the repos soon!

Arch Linux

#1 2013-07-28 19:13:00

Horrible video output upon resume from suspend

#2 2013-07-29 00:09:02

Re: Horrible video output upon resume from suspend

#3 2013-07-29 03:06:54

Re: Horrible video output upon resume from suspend

#4 2013-07-29 03:36:57

Re: Horrible video output upon resume from suspend

#5 2013-07-29 06:16:56

Re: Horrible video output upon resume from suspend

#6 2013-07-29 20:00:43

Re: Horrible video output upon resume from suspend

#7 2013-07-29 21:43:34

Re: Horrible video output upon resume from suspend

#8 2013-07-30 06:09:49

Re: Horrible video output upon resume from suspend

#9 2013-07-30 06:11:41

Re: Horrible video output upon resume from suspend

#10 2013-07-30 20:55:21

Re: Horrible video output upon resume from suspend

#11 2013-07-30 20:56:48

Re: Horrible video output upon resume from suspend

#12 2013-07-31 00:03:12

Re: Horrible video output upon resume from suspend

#13 2013-08-04 14:03:43

Re: Horrible video output upon resume from suspend

#14 2013-08-04 20:49:26

Re: Horrible video output upon resume from suspend

#15 2013-08-04 22:11:19

Re: Horrible video output upon resume from suspend

Board footer