Bug 94625

Summary: [SKL mobile] Some flickering then complete system freeze after HDMI hotplug
Product: DRI Reporter: Oskar Berggren <oskar.berggren>
Component: DRM/IntelAssignee: Oskar Berggren <oskar.berggren>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium CC: intel-gfx-bugs, przanoni, q3aiml
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: SKL i915 features: display/HDMI
Attachments:
Description Flags
dmesg with freeze after the second HDMI hotplug
none
xrandr-after-hotplug
none
lspci none

Description Oskar Berggren 2016-03-19 15:13:52 UTC
When connecting an HDMI monitor, the external monitor lights up, but the laptop's internal panel will flicker, usually until I type a key (have an open xterm focused already) or move the mouse pointer slightly. The display is then stable and I might be able to move the mouse pointer around and start some programs, but after a while the system freeze completely (doesn't respond to ping).


System is Dell XPS 15 9550, i7-6700HQ, stepping 3, microcode 0x74.

Internal panel is eDP1, 3840x2160.
External is 1920x1200. I've tried the HDMI port, and also with a TB3->DP
and TB3->HDMI adapters, all with same results.

This system also has NVIDIA GM107M, but I've disabled both the nouveau and the nvidia driver to rule that out.

"move the mouse pointer" means using the built-in touchpad.

With
    Fedora 23 plus kernel drm-intel-nightly as of 2016-03-10 21:00 UTC
the system will typically freeze hard within 10 seconds of inserting the HDMI cable (in the laptops fixed HDMI port). It feels like the freeze happens when I touch the mouse, but I'm not sure if that's just coincidence.


With
    Fedora 23 plus kernel drm-intel-nightly as of 2016-03-19 13:00 UTC
the behaviour is slightly improved. I'm now been able to use the system for minutes after hotplugging the external monitor. I still get the flickering of the internal panel when inserting the cable - this disappears when I touch the mouse. I'm then able to type, use the mouse, move windows between internal and external display, etc, with no freeze happening. After a while with no apparent problems, I disconnected the external monitor - still no problems - then reconnected it again. The external display lights up as expected, but now the complete freeze occurred within a few seconds.

Some more attempts indicate that it can still freeze (shortly after) the first hotplug, but sometimes not until after the second or third. So it seems reproducible around 3 out of 4 times.

It can also freeze if I use the Gnome Display control panel to disable the external monitor, then enabling it again (without removing the cable).

Sometimes the flickering that occurs after hotplug will go away if I touch the touchpad slightly, and pressing a key doesn't help. Other times it's the reverse - pressing a key will stop the flickering, but then moving the mouse pointer slightly will set it off again.

During these tests it's happened that the internal panel remains black. At one point it behaved like this:
  a) move the mouse pointer to the EXTERNAL panel => internal panel lights up.
  b) move the mouse pointer back to the INTERNAL panel => internal panel goes black.
During this maneuver, the external panel consistently showed a correct image.
Comment 1 Oskar Berggren 2016-03-19 15:16:26 UTC
Created attachment 122429 [details]
dmesg with freeze after the second HDMI hotplug
Comment 2 Oskar Berggren 2016-03-19 15:17:28 UTC
Created attachment 122430 [details]
xrandr-after-hotplug
Comment 3 Oskar Berggren 2016-03-19 15:18:09 UTC
Created attachment 122431 [details]
lspci
Comment 4 Lyude Paul 2016-05-17 15:05:33 UTC
Hi! MST was more or less unusable for a while in the kernel, but we've been committing a lot of fixes to it as of late that should make it leagues more stable then it was when you tested this. Unfortunately some of them are still queued for stable, and I've been as well told apparently you haven't had any more luck with Fedora's 4.5.4 kernel. Would you mind trying the kernel here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=14044183

And seeing if it helps at all? This is the kernel I've been using myself that has all of the queued patches, and I've been able to do redocking for a while using it without any issues. The only issue that should leave unfixed is the !WM_CHANGED warnings that occasionally cause problems with MST…
Comment 5 Oskar Berggren 2016-05-23 08:08:42 UTC
Thanks Lyude, I've finally found some time to test the custom built kernel. Sadly, it didn't help, behaviour is more or less the same. Sometimes it doesn't hang immediately when plugging in the cable - this time I could press ALT-F1 to open the Gnome overlay, but this action caused the internal eDP to be turned off. System was still running at this point. I moved the mouse pointer from the internal eDP to the external monitor, this action reenabled the eDP, so I got a display on both monitors, but then the system hung completely. All this took place in maybe 5 seconds.

Note that it's not just MST, I also have problems on DP 1.1 and HDMI (all with the same Dell monitor). Today's failing test was with HDMI on a different monitor (BENQ).
Comment 6 yann 2016-08-01 14:35:41 UTC
Oskar, please try patch set, this should fix the issue: https://patchwork.freedesktop.org/series/10276/ (download and apply mbox)
Comment 7 Oskar Berggren 2016-08-08 05:35:29 UTC
(In reply to yann from comment #6)
> Oskar, please try patch set, this should fix the issue:
> https://patchwork.freedesktop.org/series/10276/ (download and apply mbox)

Yes, that patch set looks interesting, but apply to what? I've tried basing it on 4.6.5 and also 4.7.0 and getting various rejections unfortunately.
Comment 8 Lyude Paul 2016-08-08 05:58:16 UTC
(In reply to Oskar Berggren from comment #7)
> (In reply to yann from comment #6)
> > Oskar, please try patch set, this should fix the issue:
> > https://patchwork.freedesktop.org/series/10276/ (download and apply mbox)
> 
> Yes, that patch set looks interesting, but apply to what? I've tried basing
> it on 4.6.5 and also 4.7.0 and getting various rejections unfortunately.

Hi, this patch series is close to being merged and when that happens I'll be backporting it to stable for 4.6
Comment 9 Oskar Berggren 2016-08-08 06:08:33 UTC
(In reply to Lyude from comment #8)
> (In reply to Oskar Berggren from comment #7)
> > (In reply to yann from comment #6)
> > > Oskar, please try patch set, this should fix the issue:
> > > https://patchwork.freedesktop.org/series/10276/ (download and apply mbox)
> > 
> > Yes, that patch set looks interesting, but apply to what? I've tried basing
> > it on 4.6.5 and also 4.7.0 and getting various rejections unfortunately.
> 
> Hi, this patch series is close to being merged and when that happens I'll be
> backporting it to stable for 4.6

Excellent. Unless you want more testing I'll wait for that then.
Comment 10 dog 2016-10-06 22:39:02 UTC
ping...
Has the patch series been merged upstream?  Can retesting take place?
Comment 11 yann 2016-10-07 07:44:45 UTC
(In reply to dog from comment #10)
> ping...
> Has the patch series been merged upstream?  Can retesting take place?

All code is merged and therefore upstreamed.
As reference here is the commit ids:

drm/i915/gen6+: Interpret mailbox error flags
author	Lyude <cpaul@redhat.com>	2016-08-17 19:55:53 (GMT)
committer	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>	2016-08-22 10:54:41 (GMT)
commit	87660502f1a4d51fb043e89a45d30c9917787c22 (patch)

drm/i915/skl: Add support for the SAGV, fix underrun hangs
author	Lyude <cpaul@redhat.com>	2016-08-17 19:55:54 (GMT)
committer	Jani Nikula <jani.nikula@intel.com>	2016-08-22 13:07:44 (GMT)
commit	f403372658fc7b652a77885a4141e58e57d9c75a (patch)

drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
author	Matt Roper <matthew.d.roper@intel.com>	2016-08-17 19:55:55 (GMT)
committer	Jani Nikula <jani.nikula@intel.com>	2016-08-22 13:07:56 (GMT)
commit	9909113cc48a7ce6e772573e3cc82a3f03ffa8ef (patch)

drm/i915/skl: Update DDB values atomically with wms/plane attrs
author	Lyude <cpaul@redhat.com>	2016-08-24 05:48:10 (GMT)
committer	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>	2016-08-25 09:08:37 (GMT)
commit	27082493e9c6371b05370a619ab9d2877c5f4726 (patch)

drm/i915/skl: Ensure pipes with changed wms get added to the state
author	Lyude <cpaul@redhat.com>	2016-08-17 19:55:57 (GMT)
committer	Jani Nikula <jani.nikula@intel.com>	2016-08-22 13:08:09 (GMT)
commit id: 762c60ab0257d25eea8db3e3fec85ed53b5330fe (patch)

drm/i915: Move CRTC updating in atomic_commit into it's own hook
author	Lyude <cpaul@redhat.com>	2016-08-24 05:48:09 (GMT)
committer	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>	2016-08-25 09:08:10 (GMT)
commit	896e5bb022bce64e29ce2e1b2fc2a7476d311a15 (patch)
Comment 12 Jani Saarinen 2016-12-09 08:45:40 UTC
Still issue valid?
Comment 13 Oskar Berggren 2016-12-09 09:55:15 UTC
Can someone please comment what kernel versions have these changes, or backports of them?

I did test with Fedora 24 a while ago and things seemed better, but that kernel version appeared to NOT contain any commits similar to those shown in comment #11.
Comment 14 Paulo Zanoni 2016-12-13 20:19:48 UTC
(In reply to Oskar Berggren from comment #13)
> Can someone please comment what kernel versions have these changes, or
> backports of them?
> 
> I did test with Fedora 24 a while ago and things seemed better, but that
> kernel version appeared to NOT contain any commits similar to those shown in
> comment #11.

According to [0], Kernel 4.8 should have these + some additional fixes for screen flickering.

If that doesn't fix the problem, please try the latest drm-tip tree: https://cgit.freedesktop.org/drm-tip (branch drm-tip).

If that doesn't fix the problem, please try the following patches:
https://patchwork.freedesktop.org/series/16757/

Thanks,
Paulo

[0]: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/gpu/drm/i915/intel_pm.c?h=linux-4.8.y
Comment 15 Elio 2017-03-06 19:17:00 UTC
(In reply to Oskar Berggren from comment #13)
> Can someone please comment what kernel versions have these changes, or
> backports of them?
> 
> I did test with Fedora 24 a while ago and things seemed better, but that
> kernel version appeared to NOT contain any commits similar to those shown in
> comment #11.

Hello Oscar, did you have chance to verify the behavior using that kernel?
Comment 16 Jari Tahvanainen 2017-04-10 07:45:25 UTC
Timeout - Assuming to be fixed. Please reopen the bug if you problem persist on the latest environments as given on comment 14.
Comment 17 Oskar Berggren 2017-04-11 22:55:28 UTC
Sorry, haven't had time to get around to systematic testing as I did before. However, with current Fedora kernel (4.10) I have been able to casually use the external HDMI so yeah, I agree it seems fixed.

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.