Created attachment 130927 [details] i915_display_info with dock connected -- Reboot -- Apr 19 13:08:31 xps13 kernel: IP: drm_dp_get_mst_branch_device+0xa2/0x110 [drm_kms_helper] Apr 19 13:08:31 xps13 kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Sadly that is all I have as it freezes here - took a few tries to get any data written to log before reboot. This happens when re-connecting a USB-C display on a dock that has multiple video inputs (only one screen connected in addition to laptop screen though). Hardware: Dell XPS14 9350 / i915 / i7-6560U Kernel tested: 4.10.10 and 4.11rc7 xorg-server: 1.19.3-2 xf86-video-intel: 1:2.99.917+770+gcb6ba2da-1 (git snap) Will try to gather more data when it occurs - tips welcome though
Created attachment 130928 [details] i915_dp_mst_info
I am seeing the same issue on a Dell Precision 5510 when I plug my docking station (with 2 connected screens) into my laptop. The system works if it is started with the dock attached. This is a new issue that has popped up sometime after early March. > May 02 09:47:47 grim kernel: BUG: unable to handle kernel NULL pointer dereference at (null) > May 02 09:47:47 grim kernel: IP: drm_dp_get_mst_branch_device+0xc8/0x110 [drm_kms_helper] > -- Reboot -- Hardware: Dell Precision 5510 / i915 / i7-6820HQ Kernel: 4.10.10-1-default xorg-server: xorg-x11-server-1.19.3-1.1.x86_64 xf86-video-intel: not installed
interestingly, same time frame here I suspect we should bisect the kernel or at least try 4.8 or 4.9
to which i'll add, i now tried 4.9.26 and it does not have this problem.
I haven't had time to do any more testing on this, but I just confirmed that if I plug my laptop into the dock while it is in hibernation state, there are no issues when it comes back online with the dock plugged in. This may be a tolerable workaround until the issue is fixed.
on the bright side something seems to have fixed it after upgrading to kernel 4.12rc1 At least, after a couple of days I did not run into this. Fingers crossed ;-)
There's insufficient info here to go on with. The full oops backtrace would be a start, full dmesg with drm.debug=14 even better. I suspected dupe of bug 97666 but that's been fixed in v4.9.
Seems to be fixed on OpenSUSE TW's 4.11.3-1-default kernel.
(In reply to Blaine Gardner from comment #8) > Seems to be fixed on OpenSUSE TW's 4.11.3-1-default kernel. It seems that the problem has been fixed in recent kernel versions. I'm closing the bug. If there is any change in this case, please share it and change to REOPEN. Thanks.
I just hit this on 4.12.4-041204-generic x86_64 Hardware: Lenovo T440p / i7-4710MQ / NVIDIA GK208 Laptop is connected to a docking station and the two Dell U2515H displays are chained (DP 1.2). The crash was triggered by switching inputs on the display connected directly to the docking station.
Created attachment 133559 [details] t440_oops
Created attachment 133562 [details] t440p_display_info
Created attachment 133563 [details] t400p_dp_mst_info
(In reply to carbenium from comment #10) > I just hit this on 4.12.4-041204-generic x86_64 > > Hardware: Lenovo T440p / i7-4710MQ / NVIDIA GK208 > > Laptop is connected to a docking station and the two Dell U2515H displays > are chained (DP 1.2). > The crash was triggered by switching inputs on the display connected > directly to the docking station. Hello Carbenium, could you try to reproduce with latest kernel versions or tip and if reproducible attach dmesg with debug info: drm.debug=0x1e log_bug_len=2M on grub. Thank you. https://cgit.freedesktop.org/drm-tip https://www.kernel.org
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
I hit it with 4.15.14 right now. I don't know how to reproduce though. What about this (mgr->mst_primary seems to be NULL here)? @@ -1288,7 +1288,10 @@ static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct drm_dp_mst_ } } } - kref_get(&mstb->kref); + if (WARN_ON_ONCE(!mstb)) + ; + else + kref_get(&mstb->kref); out: mutex_unlock(&mgr->lock); return mstb;
Created attachment 138472 [details] [review] debug patch with workaround
More information provided.
JIri, Can you try with latest tip: https://cgit.freedesktop.org/drm-tip. And attach dmesg with debug info with drm.debug=0x1e log_bug_len=2M on grub.
There has been MST fixed in drm-tip lately.
Closing, please re-open if occurs again.
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.