| Summary: | [regression, bisected] [i915] setting initial watermarks on gen 7 IVYBRIDGE causes blank lines on monitor | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Andrea <andreatclist> | ||||||||||||||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||
| Priority: | high | CC: | intel-gfx-bugs, ville.syrjala | ||||||||||||||||||||
| Version: | DRI git | ||||||||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||||||||||||||||
| i915 platform: | IVB | i915 features: | display/watermark | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
Please boot with drm.deubug=0xe passed to the kernel cmdline and attach the resulting dmesg. Also output from intel_watermark (from igt-gpu-tools) when the problem is visible could be helpful. Created attachment 143239 [details]
dmesg drm.debug=0xe
Created attachment 143240 [details]
intel_watermark with issue
Created attachment 143241 [details]
intel_watermark without issue
(In reply to Ville Syrjala from comment #1) > Please boot with drm.deubug=0xe passed to the kernel cmdline and attach the > resulting dmesg. > > Also output from intel_watermark (from igt-gpu-tools) when the problem is > visible could be helpful. Thanks. Please see the new information attached. All the numbers look very much correct :/ Does the corruption go away if you start X (or whatever) that enables the hardware cursor? The watermark dumps at least seemed to be w/o the cursor. I see the BIOS is pretty old. Can you try to update it? Let's also try to figure out which watermark level is the problem. Please do these tests with drm-tip because it might not work with an older kernel. First let's rule out LP3: # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency $ xset dpms force off ; xset dpms force on Still corrupted? Then LP2: # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency $ xset dpms force off ; xset dpms force on Still corrupted? And finally LP1: # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency $ xset dpms force off ; xset dpms force on Still corrupted? (In reply to Ville Syrjala from comment #6) > All the numbers look very much correct :/ > > Does the corruption go away if you start X (or whatever) that enables the > hardware cursor? The watermark dumps at least seemed to be w/o the cursor. The corruption is present since boot-time, and stays there when the X starts. Sometimes it disappears (e.g., in response to a window/desktop switch), but in a non-deterministic way and the corruption comes back later. > I see the BIOS is pretty old. Can you try to update it? I will try in the next days, but from a first look it seems all updates require Windows (which I've not on this system). > Let's also try to figure out which watermark level is the problem. > Please do these tests with drm-tip because it might not work with an older > kernel. > > First let's rule out LP3: > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > $ xset dpms force off ; xset dpms force on > Still corrupted? Yes > Then LP2: > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > $ xset dpms force off ; xset dpms force on > Still corrupted? Yes > And finally LP1: > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > $ xset dpms force off ; xset dpms force on > Still corrupted? No, the corruption is gone. Switching windows, desktops, focus etc seems to work fine. And it doesn't re-appear after > 10 mins. (In reply to Andrea from comment #7) > (In reply to Ville Syrjala from comment #6) > > All the numbers look very much correct :/ > > > > Does the corruption go away if you start X (or whatever) that enables the > > hardware cursor? The watermark dumps at least seemed to be w/o the cursor. > > The corruption is present since boot-time, and stays there when the X > starts. Sometimes it disappears (e.g., in response to a window/desktop > switch), but in a non-deterministic way and the corruption comes back later. > > > I see the BIOS is pretty old. Can you try to update it? > > I will try in the next days, but from a first look it seems all updates > require Windows (which I've not on this system). Dunno if this is the right one, but some T431s seems to have ISOs available for BIOS update: https://download.lenovo.com/pccbbs/mobiles/ghuj20us.iso > > > Let's also try to figure out which watermark level is the problem. > > Please do these tests with drm-tip because it might not work with an older > > kernel. > > > > First let's rule out LP3: > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > $ xset dpms force off ; xset dpms force on > > Still corrupted? > > Yes > > > Then LP2: > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > $ xset dpms force off ; xset dpms force on > > Still corrupted? > > Yes > > > And finally LP1: > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > $ xset dpms force off ; xset dpms force on > > Still corrupted? > > No, the corruption is gone. Switching windows, desktops, focus etc seems to > work fine. And it doesn't re-appear after > 10 mins. Hmm. That machine seems very broken when even LP1 doesn't work. (In reply to Ville Syrjala from comment #8) > (In reply to Andrea from comment #7) > > (In reply to Ville Syrjala from comment #6) > > > All the numbers look very much correct :/ > > > > > > Does the corruption go away if you start X (or whatever) that enables the > > > hardware cursor? The watermark dumps at least seemed to be w/o the cursor. > > > > The corruption is present since boot-time, and stays there when the X > > starts. Sometimes it disappears (e.g., in response to a window/desktop > > switch), but in a non-deterministic way and the corruption comes back later. > > > > > I see the BIOS is pretty old. Can you try to update it? > > > > I will try in the next days, but from a first look it seems all updates > > require Windows (which I've not on this system). > > Dunno if this is the right one, but some T431s seems to have ISOs available > for BIOS update: > https://download.lenovo.com/pccbbs/mobiles/ghuj20us.iso > > > > > > Let's also try to figure out which watermark level is the problem. > > > Please do these tests with drm-tip because it might not work with an older > > > kernel. > > > > > > First let's rule out LP3: > > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > > $ xset dpms force off ; xset dpms force on > > > Still corrupted? > > > > Yes > > > > > Then LP2: > > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > > $ xset dpms force off ; xset dpms force on > > > Still corrupted? > > > > Yes > > > > > And finally LP1: > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > > $ xset dpms force off ; xset dpms force on > > > Still corrupted? > > > > No, the corruption is gone. Switching windows, desktops, focus etc seems to > > work fine. And it doesn't re-appear after > 10 mins. > > Hmm. That machine seems very broken when even LP1 doesn't work. Umm, I guess there might be a misunderstanding: after setting LP1 with the values you suggested, the corruption is gone and everything seems to be OK as before the regression. Anyway, I'll also try the BIOS update and post the results (thanks for the pointer, I'll check). (In reply to Andrea from comment #9) > (In reply to Ville Syrjala from comment #8) > > (In reply to Andrea from comment #7) > > > (In reply to Ville Syrjala from comment #6) > > > > All the numbers look very much correct :/ ... > > > > And finally LP1: > > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency > > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency > > > > $ xset dpms force off ; xset dpms force on > > > > Still corrupted? > > > > > > No, the corruption is gone. Switching windows, desktops, focus etc seems to > > > work fine. And it doesn't re-appear after > 10 mins. > > > > Hmm. That machine seems very broken when even LP1 doesn't work. > > Umm, I guess there might be a misunderstanding: after setting LP1 with the > values you suggested, the corruption is gone and everything seems to be OK > as before the regression. > > Anyway, I'll also try the BIOS update and post the results (thanks for the > pointer, I'll check). JFTR, I've updated to "DMI: LENOVO 20AA0016GE/20AA0016GE, BIOS GHET41WW (1.26 ) 11/21/2018", same results: - the monitor starts corrupted - setting echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency ... "fixes" the issue.
>
> Hmm. That machine seems very broken when even LP1 doesn't work.
Ville, LP1 does work and no corruption noticed. How to proceed further?
Created attachment 143441 [details] [review] [PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s This patch should disable LP1+ watermarks on the affected machine automagically. Please test and also attach the output of intel_watermarks when using the patch so that I can double check that everything looks correct. (In reply to Ville Syrjala from comment #12) > Created attachment 143441 [details] [review] [review] > [PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s > > This patch should disable LP1+ watermarks on the affected machine > automagically. Please test and also attach the output of intel_watermarks > when using the patch so that I can double check that everything looks > correct. I checked out the last drm-tip to apply the patch, but drm-tip doesn't show the problem anymore. The drm-tip I used: commit 348fd7b7fa6584957fa6a5143058b3fbb319806b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 1 18:32:47 2019 +0000 drm-tip: 2019y-03m-01d-18h-31m-34s UTC integration manifest The commit that seems to fix the issue is: "drm/i915/fbdev: Actually configure untiled displays" d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 Reverting it makes the problem appear again. intel_watermark with d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 (good): WM_PIPE_A = 0x000b0000 WM_PIPE_B = 0x00000000 WM_PIPE_C = 0x00000000 WM_LP1 = 0x84301100 WM_LP2 = 0x90303c00 WM_LP3 = 0xa0406600 WM_LP1_SPR = 0x00000000 WM_LP2_SPR = 0x00000000 WM_LP3_SPR = 0x00000000 ARB_CTL = 0xd6663056 ARB_CTL2 = 0x00000000 WM_PIPE_A: primary=11, cursor=0, sprite=0 WM_PIPE_B: primary=0, cursor=0, sprite=0 WM_PIPE_C: primary=0, cursor=0, sprite=0 WM_LP1: enabled, latency=4, fbc=3, primary=17, cursor=0, sprite=0 WM_LP2: enabled, latency=16, fbc=3, primary=60, cursor=0, sprite=0 WM_LP3: enabled, latency=32, fbc=4, primary=102, cursor=0, sprite=0 Primary A trickle feed = disabled Sprite A trickle feed = enabled Primary B trickle feed = disabled Sprite B trickle feed = enabled Primary C trickle feed = enabled Sprite C trickle feed = enabled DDB partitioning = 1/2 FBC watermark = enabled intel_watermark without d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 (bad): WM_PIPE_A = 0x000b0000 WM_PIPE_B = 0x00000000 WM_PIPE_C = 0x00000000 WM_LP1 = 0x84301100 WM_LP2 = 0x90303c00 WM_LP3 = 0xa0406600 WM_LP1_SPR = 0x00000000 WM_LP2_SPR = 0x00000000 WM_LP3_SPR = 0x00000000 ARB_CTL = 0xd6663056 ARB_CTL2 = 0x00000000 WM_PIPE_A: primary=11, cursor=0, sprite=0 WM_PIPE_B: primary=0, cursor=0, sprite=0 WM_PIPE_C: primary=0, cursor=0, sprite=0 WM_LP1: enabled, latency=4, fbc=3, primary=17, cursor=0, sprite=0 WM_LP2: enabled, latency=16, fbc=3, primary=60, cursor=0, sprite=0 WM_LP3: enabled, latency=32, fbc=4, primary=102, cursor=0, sprite=0 Primary A trickle feed = disabled Sprite A trickle feed = enabled Primary B trickle feed = disabled Sprite B trickle feed = enabled Primary C trickle feed = disabled Sprite C trickle feed = enabled DDB partitioning = 1/2 FBC watermark = enabled Primary C trickle feed is different. (In reply to Ville Syrjala from comment #12) > Created attachment 143441 [details] [review] [review] > [PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s > > This patch should disable LP1+ watermarks on the affected machine > automagically. Please test and also attach the output of intel_watermarks > when using the patch so that I can double check that everything looks > correct. More info: your patch applied on top of the reverted d179b88deb also fixes the issue. > $ git log --oneline > drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s > Revert "drm/i915/fbdev: Actually configure untiled displays" intel_watermarks: (good) WM_PIPE_A = 0x000b0000 WM_PIPE_B = 0x00000000 WM_PIPE_C = 0x00000000 WM_LP1 = 0x00000000 WM_LP2 = 0x00000000 WM_LP3 = 0x00000000 WM_LP1_SPR = 0x00000000 WM_LP2_SPR = 0x00000000 WM_LP3_SPR = 0x00000000 ARB_CTL = 0xd6663056 ARB_CTL2 = 0x00000000 WM_PIPE_A: primary=11, cursor=0, sprite=0 WM_PIPE_B: primary=0, cursor=0, sprite=0 WM_PIPE_C: primary=0, cursor=0, sprite=0 WM_LP1: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0 WM_LP2: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0 WM_LP3: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0 Primary A trickle feed = disabled Sprite A trickle feed = enabled Primary B trickle feed = disabled Sprite B trickle feed = enabled Primary C trickle feed = disabled Sprite C trickle feed = enabled DDB partitioning = 1/2 FBC watermark = enabled Marking as fixed based on Andrea's feedback that the issue no longer exists on drm-tip In 5.0.11 linux-stable the issue appeared again since the commit that "fixed" it in 5.0.0-rc8 was reverted. Setting echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency still "fixes" the issue. The patch in https://bugs.freedesktop.org/attachment.cgi?id=143441 does not apply cleanly anymore. The commit that reverted the "fix" is: commit 3e869fd348565c3bab7a6c61cc4b66c3594e6db2 Author: Dave Airlie <airlied@redhat.com> Date: Wed Apr 24 10:47:56 2019 +1000 Revert "drm/i915/fbdev: Actually configure untiled displays" commit 9fa246256e09dc30820524401cdbeeaadee94025 upstream. This reverts commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5. This commit is documented to break userspace X.org modesetting driver in certain configurations. The X.org modesetting userspace driver is broken. No fixes are available yet. In order for this patch to be applied it either needs a config option or a workaround developed. This has been reported a few times, saying it's a userspace problem is clearly against the regression rules. This thing is super mysterious.
Please grab
intel_reg read 0x70080 0x71080 0x72080 0x70280 0x71280 0x72280
intel_reg dump
intel_watermark
before and after
3e869fd34856 ("Revert "drm/i915/fbdev: Actually configure untiled displays"")
I see DMAR is also active. Try booting with 'intel_iommu=igfx_off' passed to the kernel cmdline to see if that has any effect.
Thanks for the help. Attached (2019-05-08*) the requested info before and after 3e869fd34856. Also attached the same info if I do "echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency", and with igfx_off. The issue disappears either: 1) before 3e869fd34856 2) with echo '12 ...' 3) by disabling DMA remapping (i.e., adding intel_iommu=igfx_off) If it helps, the DMAR output extracted from dmesg: [ 0.002921] ACPI: DMAR 0x00000000DAFDB000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) [ 0.243778] DMAR: Disable GFX device mapping [ 0.391075] DMAR: Host address width 36 [ 0.391079] DMAR: DRHD base: 0x000000fed90000 flags: 0x0 [ 0.391089] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a [ 0.391093] DMAR: DRHD base: 0x000000fed91000 flags: 0x1 [ 0.391099] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a [ 0.391103] DMAR: RMRR base: 0x000000da43c000 end: 0x000000da452fff [ 0.391106] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff [ 0.391116] DMAR: No ATSR found [ 0.391165] DMAR: dmar1: Using Queued invalidation [ 0.391178] DMAR: Setting RMRR: [ 0.391242] DMAR: Setting identity map for device 0000:00:14.0 [0xda43c000 - 0xda452fff] [ 0.391313] DMAR: Setting identity map for device 0000:00:1a.0 [0xda43c000 - 0xda452fff] [ 0.391403] DMAR: Setting identity map for device 0000:00:1d.0 [0xda43c000 - 0xda452fff] [ 0.391420] DMAR: Prepare 0-16MiB unity mapping for LPC [ 0.391477] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff] [ 0.391632] DMAR: Intel(R) Virtualization Technology for Directed I/O And without igfx_off: [ 0.003155] ACPI: DMAR 0x00000000DAFDB000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) [ 0.391918] DMAR: Host address width 36 [ 0.391923] DMAR: DRHD base: 0x000000fed90000 flags: 0x0 [ 0.391932] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a [ 0.391935] DMAR: DRHD base: 0x000000fed91000 flags: 0x1 [ 0.391942] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a [ 0.391946] DMAR: RMRR base: 0x000000da43c000 end: 0x000000da452fff [ 0.391949] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff [ 0.391959] DMAR: No ATSR found [ 0.392008] DMAR: dmar0: Using Queued invalidation [ 0.392018] DMAR: dmar1: Using Queued invalidation [ 0.392255] DMAR: Setting RMRR: [ 0.392320] DMAR: Setting identity map for device 0000:00:02.0 [0xdb800000 - 0xdf9fffff] [ 0.392878] DMAR: Setting identity map for device 0000:00:14.0 [0xda43c000 - 0xda452fff] [ 0.392964] DMAR: Setting identity map for device 0000:00:1a.0 [0xda43c000 - 0xda452fff] [ 0.393031] DMAR: Setting identity map for device 0000:00:1d.0 [0xda43c000 - 0xda452fff] [ 0.393047] DMAR: Prepare 0-16MiB unity mapping for LPC [ 0.393103] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff] [ 0.393500] DMAR: Intel(R) Virtualization Technology for Directed I/O [ 0.415290] [drm] DMAR active, disabling use of stolen memory Created attachment 144199 [details]
2019-05-08_after_3e869fd34856
Created attachment 144200 [details]
2019-05-08_after_3e869fd34856_igfx_off
Created attachment 144201 [details]
2019-05-08_revert_3e869fd34856
Created attachment 144202 [details]
2019-05-08_echo12
@Ville, what's the next step? @Ville, how to proceed further with this issue? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/216. |
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.
Created attachment 143236 [details] output corruption I've seen a regression on linux-stable since this commit (merged on stable between 4.19.2 and 4.19.3) # first bad commit: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes I've a gen 7: Platform: IVYBRIDGE PCI ID: 0x0166 PCI Revision: 0x09 PCI Subsystem: 17aa:2208 graphic card on a Lenovo T431s, which has "has_gmch_display: no", but apparently it doesn't fully support setting the initial_watermarks(). See screenshot for the output corruption. See git bisect log, and the lspci for the card. Excluding the call to initial_watermarks() "fixes" the issue: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3bd44d042a1d..1c1b2ee556ef 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12639,12 +12639,14 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state) intel_check_cpu_fifo_underruns(dev_priv); intel_check_pch_fifo_underruns(dev_priv); +#if 0 /* FIXME unify this for all platforms */ if (!new_crtc_state->active && !HAS_GMCH_DISPLAY(dev_priv) && dev_priv->display.initial_watermarks) dev_priv->display.initial_watermarks(intel_state, to_intel_crtc_state(new_crtc_state)); +#endif } } For completeness, I've tried the drm-tip: commit bc2fcdf82a5b94f015126dfa9db03f88feb9ae17 Date: Mon Jan 28 11:15:42 2019 +0100 but the issue is still present. ### git bisect log git bisect start # bad: [73aa1c86c6ec67931abf0c6b96b6853578b07db5] Linux 4.19.3 git bisect bad 73aa1c86c6ec67931abf0c6b96b6853578b07db5 # good: [7950eb316adf792283cac5743dfe5a11e74833dc] Linux 4.19.2 git bisect good 7950eb316adf792283cac5743dfe5a11e74833dc # good: [67a19f87a02beec6a676ed427fbe3c1f5f00d9f4] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings git bisect good 67a19f87a02beec6a676ed427fbe3c1f5f00d9f4 # good: [401182ae096bfb16693bcfb8fcab1bc128a5c6bc] kdb: print real address of pointers instead of hashed addresses git bisect good 401182ae096bfb16693bcfb8fcab1bc128a5c6bc # good: [3ff21b59ffd294c04fd83994e71417247f0d2ee7] drm/etnaviv: fix bogus fence complete check in timeout handler git bisect good 3ff21b59ffd294c04fd83994e71417247f0d2ee7 # good: [1a25e1a1be71a49ee7f34fb14b5a26191e6cf501] drm/i915: Mark up GTT sizes as u64 git bisect good 1a25e1a1be71a49ee7f34fb14b5a26191e6cf501 # bad: [828271c43b7850748b3cd18e769367a244875acf] drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 git bisect bad 828271c43b7850748b3cd18e769367a244875acf # bad: [b4aa9db0b24f8504ee8e4de36bc84eae4f9fad63] drm/i915: Compare user's 64b GTT offset even on 32b git bisect bad b4aa9db0b24f8504ee8e4de36bc84eae4f9fad63 # bad: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes git bisect bad a46a7350b1e85fe78580f6a4c809a876867a9df8 # good: [6d6e718e454b65448bbb50c876e5040f5d05db6d] drm/i915: Fix error handling for the NV12 fb dimensions check git bisect good 6d6e718e454b65448bbb50c876e5040f5d05db6d # first bad commit: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes ### lspci -vvv -x 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 3rd Gen Core processor Graphics Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 26 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 4000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee08004 Data: 4025 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 00: 86 80 66 01 07 04 90 00 09 00 00 03 00 00 00 00 10: 04 00 00 f0 00 00 00 00 0c 00 00 e0 00 00 00 00 20: 01 40 00 00 00 00 00 00 00 00 00 00 aa 17 08 22 30: 00 00 00 00 90 00 00 00 00 00 00 00 ff 01 00 00