Bug 91906

Summary: [ILK] With Linux 4.1.6 and 4.2 Xorg can't start, then kernel module crash, then system completely freeze
Product: DRI Reporter: russianneuromancer
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
intel_reg dump
none
dmesg
none
Xorg log
none
dmesg none

Description russianneuromancer 2015-09-07 13:51:07 UTC 
With Linux 4.2.0 in the moment when SDDM show show login prompt, there is just black screen and no even Xorg.0.log file (every boot).
However, with SDDM autostart disabled it's possible to boot system normally, except for graphics. When I start SDDM manually, there is Xorg.0.log and errors in dmesg (attached). Few minutes later system may completely freeze, but that happen not every time when I boot like that (with not automatic but manual SDDM start).
With Linux 4.1 and previous releases there is no such issue.

Kubuntu 15.10 x86_64
Acer Aspire One 753
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)

Attached logs gathered with drm-intel-nightly (4.2.0-994.201509042200 from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/ ) but issue is reproducible with normal release build of Linux 4.2.0 too.
/sys/class/drm/card0/error is empty.
In this particular case issue is reproduced with SNA and DRI3, but it also reproduced with SNA and DRI2, and GLAMOR and DRI2 and so on (I tried different combinations).
Comment 1 russianneuromancer 2015-09-07 13:51:36 UTC 
Created attachment 118123 [details]
intel_reg dump
Comment 2 russianneuromancer 2015-09-07 13:51:52 UTC 
Created attachment 118124 [details]
dmesg
Comment 3 russianneuromancer 2015-09-07 13:52:06 UTC 
Created attachment 118125 [details]
Xorg log
Comment 4 Chris Wilson 2015-09-07 14:45:54 UTC 
The trigger is the TIMESTAMP probe inside mesa, using the reg_read_ioctl. That for some reason is causing a soft lockup inside the reader, so I presume it is the retry if unstable logic? If you revert:

commit ee0a227b7ac6e75f28e10269f81c7ec6eb600952
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 15 09:50:42 2015 +0100

    drm/i915: Replace WARN inside I915_READ64_2x32 with retry loop

does the system recover?
Comment 5 russianneuromancer 2015-09-07 16:20:22 UTC 
> If you revert ee0a227b7ac6e75f28e10269f81c7ec6eb600952 does the system recover?
I doesn't know how to compile kernel, but I do notice that ee0a227b7ac6e75f28e10269f81c7ec6eb600952 is included in Linux 4.1.6, but not included in Linux 4.1.5, so I compare this two builds:
Linux 4.1.5 - normal behaviour, normal boot.
Linux 4.1.6 - same behaviour as with Linux 4.2.0. I can provide all debug logs, if necessary.
Comment 6 Chris Wilson 2015-09-07 17:26:22 UTC 
Hmm, the new version of the reg_read ioctl is in v4.1.5, can you please attach your dmesg from that kernel. I expect to see a warn instead.
Comment 7 russianneuromancer 2015-09-07 18:07:42 UTC 
Created attachment 118129 [details]
dmesg

Boot with Linux 4.1.5 and manual SDDM launch.
Comment 8 russianneuromancer 2015-09-27 17:59:29 UTC 
Seems like fixed with 4.2.1.

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.