| Summary: | [SKL mobile] Some flickering then complete system freeze after HDMI hotplug | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Oskar Berggren <oskar.berggren> | ||||||||
| Component: | DRM/Intel | Assignee: | 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: |
|
||||||||||
Created attachment 122429 [details]
dmesg with freeze after the second HDMI hotplug
Created attachment 122430 [details]
xrandr-after-hotplug
Created attachment 122431 [details]
lspci
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… 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). Oskar, please try patch set, this should fix the issue: https://patchwork.freedesktop.org/series/10276/ (download and apply mbox) (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. (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 (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. ping... Has the patch series been merged upstream? Can retesting take place? (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) Still issue valid? 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. (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 (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? Timeout - Assuming to be fixed. Please reopen the bug if you problem persist on the latest environments as given on comment 14. 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.
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.