Bug 84581

Summary: [mst] Kernel Panic when switching X servers
Product: Drivers Reporter: Matthew Gyurgyik (pyther)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED INSUFFICIENT_DATA    
Severity: normal CC: chris, intel-gfx-bugs
Priority: P3    
Hardware: All   
OS: Linux   
Kernel Version: 3.17.0-rc4git+ Subsystem:
Regression: No Bisected commit-id:
Attachments: kernel panic
kernel crash with drm.debug=0x6

Description Matthew Gyurgyik 2014-09-14 14:44:36 UTC
Created attachment 150221 [details]
kernel panic

Apologies if the title is misleading, there is some magic going on behind the scene that I am unaware of. 

Problem: When "switching users" in gnome3, Xorg will crash and a kernel panic will occur. I suspect gnome is spawning a second X server.

Operating System: Fedora 20 x86_64
Hardware: X1 Carbon 2nd Generation / 2014
          Thinkpad One Link Pro Dock

Physical Displays
  eDP1 connected 2560x1440+0+0 (laptop LCD)
  DP3 connected primary 1680x1050+2560+0 (Acer 22" Wide)
  DP4 connected 1440x900+4240+0 (Dell 19" Wide)
  

Reproduction 1:
Intel Driver: xorg-x11-drv-intel-2.99.916-1 (I compiled from the latest source code)
Kernel: 3.17.0-0.rc4.git1.1.fc22.x86_64

1) Lock Screen
2) Select "Switch User" on Lock Screen
3) Kernel Panic / X crash

Reproduction 2 (some improvement with latest git kernel): 

Intel Driver: xorg-x11-drv-intel-2.99.916-1 (I compiled from the latest source code)
Kernel: 3.17.0-rc4git+ (1536340e7c67694b134cbbc07168e5a524e49d08)

1) Lock Screen
2) Select "Switch User" on Lock Screen
3) Log in as new user
4) Do stuff
5) Logout
6) Kernel Panic / X Crash

Attached is the kernel panic trace.

Please let me know what additional information I can include and if there is anything I can do further to help.
Comment 1 Matthew Gyurgyik 2014-09-14 15:23:38 UTC
I forgot to mention I am running Gnome 3.12 (due to better support for HiDPI displays).
Comment 2 Jani Nikula 2014-09-15 07:43:15 UTC
Chris, any ideas?
Comment 3 Jani Nikula 2014-09-15 07:44:24 UTC
BUG_ON(vma->pin_count == 0) in i915_gem_object_ggtt_unpin().
Comment 4 Chris Wilson 2014-09-15 08:35:13 UTC
It either begins with the erroneous modeset on the stale connector, or before when the MST connector is unplugged. I expect that drm.debug=0x6 would show when that framebuffer first disappears.
Comment 5 Matthew Gyurgyik 2014-09-16 02:07:25 UTC
Created attachment 150451 [details]
kernel crash with drm.debug=0x6
Comment 6 Matthew Gyurgyik 2014-09-16 02:11:59 UTC
I booted with drm.debug=0x6. I found it was a little bit harder to reproduce the bug, but switching users a couple of times triggered it. I have attached the log. I debated whether or not to compress the log, I hope the uncompressed version is acceptable.
Comment 7 Jani Nikula 2014-09-23 13:56:54 UTC
Uncompressed version is not only acceptable, it's preferrable. Thanks.

Please attach the dmesg all the way from boot to ensure we're seeing the first reported problem.
Comment 8 Jani Nikula 2015-01-28 14:08:48 UTC
Timeout, closing. Please feel free to reopen with results on latest kernels. Thanks.