Summary: | Freeze during activation of external display on Lenovo X260 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Dennis Wassenberg <dennis.wassenberg> | ||||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
Severity: | blocker | ||||||||
Priority: | medium | CC: | dennis.wassenberg, gary.c.wang, intel-gfx-bugs, mail | ||||||
Version: | unspecified | ||||||||
Hardware: | x86-64 (AMD64) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | SKL | i915 features: | display/DP, display/HDMI | ||||||
Attachments: |
|
Description
Dennis Wassenberg
2016-04-14 06:45:47 UTC
Created attachment 122923 [details]
dmesg
I found the commit which causes the freeze. It is: commit 4e0963c7663b0538b5a21fb49d17ea4ad64de861 Author: Matt Roper <matthew.d.roper@intel.com> Date: Thu Sep 24 15:53:15 2015 -0700 drm/i915: Calculate pipe watermarks into CRTC state (v3) After some investigation I found discussion here: http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/71377 and here https://bugs.freedesktop.org/show_bug.cgi?id=92355 There it is talked about that commit 4e0963c7663b0538b5a21fb49d17ea4ad64de861 causes some regressions. Thats why there was a partial revert of some watermarks commits. This end up with commits 2791a16ca43302d07ac74cbe7c048e367c4632c4 and fc6f93bce582ccf76335843584e6a797ac72813c: commit 2791a16ca43302d07ac74cbe7c048e367c4632c4 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Oct 9 18:22:43 2015 -0300 drm/i915: revert a few more watermark commits This is a squash of the following commits: Revert "drm/i915: Drop intel_update_sprite_watermarks" This reverts commit 47c99438b52d12df50e182583634a4cfede3c920. Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check" This reverts commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b. Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)" This reverts commit 3a05f5e2e78eab7ffe816abb59b6769e331a1957. With these reverts, SKL finally stops failing every single FBC test with FIFO underrun error messages. After some brief testing, it also seems that this commit prevents the machine from completely freezing when we run igt/kms_fbc_crc (see fd.o #92355). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> commit fc6f93bce582ccf76335843584e6a797ac72813c Author: Bob Paauwe <bob.j.paauwe@intel.com> Date: Mon Aug 31 14:03:30 2015 -0700 drm/i915/skl+: Enable pipe CSC on cursor planes. (v2) commit fc6f93bce582ccf76335843584e6a797ac72813c Author: Bob Paauwe <bob.j.paauwe@intel.com> Date: Mon Aug 31 14:03:30 2015 -0700 drm/i915/skl+: Enable pipe CSC on cursor planes. (v2) This commits should fix the regression. At Lenovo T460s it really fix this issue. But the Lenovo X260 is still freezing! Is there anything I can do to help on this issue? Anything I can check or test? I got a Lenovo X260 with Intel i7-6600U. There everything is fine. No freeze will occur. So it looks like that this issue will happen with i7-6500U CPUs only. I assume that the CPU or GPU are not the root cause because the GPUs are the same. The CPUs differ mostly in clock speeds. Additionally the i7-6600U CPU supports AMT. So maybe it is a race condition inside the i915 code which appears at i7-6500U CPU only because of the different clock speeds?!? I did some additional checks: I reverted the commit 4e0963c7663b0538b5a21fb49d17ea4ad64de861 in that way that I removed the union and use the 2 structs instead (like before this commit). Still freezing... Because the patch affects wakermarking I applied the following patch: https://patchwork.freedesktop.org/patch/69417/ to enable the possibility to disable wartermarking for debugging purposes. After disable watermarking, it is still freezing... This confirms the assumption that it might be a race condition. Any ideas? I can not reproduce this crash at drm-intel-nightly since 25th April. So it seems to be fixed now. (In reply to Dennis Wassenberg from comment #4) > I can not reproduce this crash at drm-intel-nightly since 25th April. So it > seems to be fixed now. Thanks for the follow-up, apologies for failing to respond promptly. |
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.