Bug 89290

Summary: [gen4] Daily or sometimes less system will lock up with only black screen and movable cursor
Product: DRI Reporter: Chris <cpollock>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED WORKSFORME QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: low CC: gary.c.wang, intel-gfx-bugs
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: G45 i915 features: GPU hang
Attachments:
Description Flags
Output of lshw
none
Output of dmidecode
none
dmesg output drm.debug=0x06
none
Xorg GDB backtrace output
none
Gnome-Shell GDB backtrace output
none
kern.log from 28 July 2015 freeze
none
Current Xorg.0.log none

Description Chris 2015-02-23 21:34:30 UTC
Created attachment 113775 [details]
Output of lshw

Adding to the above all background processes continue to run such as Fetchmail, Procmail, SpamAssassin, ClamAV and so on. I have been able to get to a log-in screen with CTRL>ALT>ESC and log-in and do a 'sudo reboot'. My system is Ubuntu 14.04.2 LTS on a Dell OptiPlex 780 with 4Gb ram. The kernel I'm running is 3.19.0-031900-generic #201502091451 SMP Mon Feb 9 14:52:52 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux. Throughout the day I see this in my syslog, not only when the system locks-up:

Feb 22 18:00:46 localhost kernel: [ 9088.033815]
[drm:intel_crtc_cursor_set_obj] cursor off
Feb 22 18:00:46 localhost kernel: [ 9088.033821] [drm:g4x_check_srwm] SR
watermark: display plane 92, cursor 2
Feb 22 18:00:46 localhost kernel: [ 9088.033822] [drm:g4x_check_srwm]
display watermark is too large(92/63), disabling
Feb 22 18:00:46 localhost kernel: [ 9088.033824]
[drm:intel_set_memory_cxsr] memory self-refresh is disabled
Feb 22 18:00:46 localhost kernel: [ 9088.033826] [drm:g4x_update_wm]
Setting FIFO watermarks - A: plane=40, cursor=2, B: plane=2, cursor=2,
SR: plane=0, cursor=0

I'm attaching the output of the latest dmesg output, lshw and dmidecode. If I can provide any other information please let me know.
Comment 1 Chris 2015-02-23 21:35:09 UTC
Created attachment 113776 [details]
Output of dmidecode
Comment 2 Chris 2015-02-23 21:35:52 UTC
Created attachment 113777 [details]
dmesg output drm.debug=0x06
Comment 3 Chris Wilson 2015-02-23 21:52:25 UTC
We need the logs from after the "lock up".
Comment 4 Chris 2015-02-23 22:17:09 UTC
The dmesg log is after the lockup this morning, do you want me to run lshw and dmidecode and attach or do you want the actual syslog entries? This happened during the night sometime so I don't know exactly when but I did do the reboot at a bit after 7am this morning.
Comment 5 Chris Wilson 2015-02-24 08:04:48 UTC
The dmesg looks like it was captured after the reboot and not the lockup.
Comment 6 Chris 2015-02-24 12:22:44 UTC
Understand, next time there is a lockup I'll attempt to log-in and save the current dmesg file to another name before I reboot.
Comment 7 Chris 2015-07-28 12:40:43 UTC
I'd like to update a bit about this. The frequency of the 'freezes' has changed and is something lie 5 or so days now between them. Currently it has been 8 days, 20hrs since the last freeze. There is no longer the 'black screen with movable cursor' I think that may have come from when I was using X-Screensaver and it would freeze when switching between screensavers being used. What will happen now is I will be Firefox scrolling through my Facebook news feed or scrolling through tweets on Twitter I will notice the freeze. I'm able to SSH into my computer from my Amazon Fire Tablet and have done so each time doing backtraces on both Gnome-Shell and on Firefox. I have forwarded all the output files to Chris Wilson. If they need to be posted here I can do that. I am currently running kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux and  Module intel: vendor="X.Org Foundation"[    49.404] 	compiled for 1.15.1, module version = 2.99.917
Comment 8 Jani Nikula 2015-08-18 13:13:24 UTC
Please attach the relevant logs here too if this is still an issue.
Comment 9 Chris 2015-08-18 13:30:42 UTC
This is still an issue. The last freeze was on 12 Aug, 2015. I did not have time to do a gdb backtrace of Xorg or Gnome-Shell however running 

cat /sys/class/drm/card0/error it showed 'no error state collected'

and

cat /sys/kernel/debug/dri/0/i915_swizzle_info and got

bit6 swizzle for X-tiling = none
bit6 swizzle for Y-tiling = none
DDC = 0x00200010
DDC2 = 0x00300030
C0DRB3 = 0x0030
C1DRB3 = 0x0010

I don't know if this is any help or not. I'm attaching the gdb backtrace outputs of kern.log, Xorg and Gnome-Shell on the previous freeze that happened on 28 July 2015. 

This is really getting frustrating as I don't seem to be getting any feedback lately from anyone with advice on what to try next or even saying there is nothing that can be done.
Comment 10 Chris 2015-08-18 13:32:31 UTC
Created attachment 117760 [details]
Xorg GDB backtrace output
Comment 11 Chris 2015-08-18 13:33:07 UTC
Created attachment 117761 [details]
Gnome-Shell GDB backtrace output
Comment 12 Chris 2015-08-18 13:34:13 UTC
Created attachment 117762 [details]
kern.log from 28 July 2015 freeze
Comment 13 Chris 2015-08-18 13:35:39 UTC
Created attachment 117763 [details]
Current Xorg.0.log
Comment 14 yann 2017-02-21 09:32:30 UTC
(In reply to Chris from comment #13)
> Created attachment 117763 [details]
> Current Xorg.0.log

Chris is this issue still occurring with latest component version?
Comment 15 Chris 2017-02-21 14:12:55 UTC
Not in a very long time. I'm embarrassed, I'd forgotten about this bug I'd submitted and should have posted a comment when the problem stopped so it could be closed out.
Comment 16 yann 2017-02-21 15:23:23 UTC
(In reply to Chris from comment #15)
> Not in a very long time. I'm embarrassed, I'd forgotten about this bug I'd
> submitted and should have posted a comment when the problem stopped so it
> could be closed out.

np :) so closing it now

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.