[Intel-gfx] [REGRESSION] i915 drm oopsing again on T440p docking station attached
Hello, with the latest commit batch to drm-intel-nightly from friday night, my lenovo t440p again starts to oops as soon as I attach it to the docking station. this image http://imgur.com/mxtLaxW shows the oops trace. Can someone with a T440/540 and docking station confirm this? Regards Dieter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/16] drm/i915: disable FBC on FIFO underruns
On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
> If we want to try to enable FBC by default on any platform we need to
> be on the safe side and disable it in case we get an underrun while
> FBC is enabled on the corresponding pipe. We currently already have
> other reasons for FIFO underruns on our driver, but the ones I saw
> with FBC lead to black screens that only go away when you disable FBC.
>
> The current FIFO underrun I see happens when the CFB is using the top
> 8mb of stolen memory. This is reproducible with a 2560x1440 DP Monitor
> on a system with 32mb of stolen memory. On this case, all the IGT
> tests fail while checking the screen CRC. A later patch on this series
> will fix this problem for real.
>
> With this patch, the tests will start failing while checking if FBC is
> enabled instead of failing while comparing the CRC of the black screen
> against the correct CRC. So this patch is not hiding any IGT bugs: the
> tests still fail, but now they fail with a different reason.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h| 5 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 61
> ++
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +
> 4 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4fd7858..e74a844 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -926,6 +926,11 @@ struct i915_fbc {
> struct drm_framebuffer *fb;
> } *fbc_work;
>
> + struct intel_fbc_underrun_work {
> + struct work_struct work;
> + struct intel_crtc *crtc;
> + } underrun_work;
It's a singleshot (perhaps a couple in flight during the switch off), so
there's no need for a permanent allocation. Fight the bloat!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/16] Revert "drm/i915: Allocate fbcon from stolen memory"
On Fri, Aug 14, 2015 at 06:34:20PM -0300, Paulo Zanoni wrote: > This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb. > > Technology has evolved and now we have eDP panels with 3200x1800 > resolution. In the meantime, the BIOS guys didn't change the default > 32mb for stolen memory. And we can't assume our users will be able to > increase the default stolen memory size to more than 32mb - I'm not > even sure all BIOSes allow that. > > So just the fbcon buffer alone eats 22mb of my stolen memroy, and due > to the BDW/SKL restriction of not using the last 8mb of stolen memory, > all that's left for FBC is 2mb! Since fbcon is not the coolest feature > ever, I think it's better to save our precious stolen resource to FBC > and the other guys. > > Besides, neither the original commit message nor the review comments > showed any arguments in favor of actually allocating fbcon from > stolen. Pardon? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/16] drm/i915: avoid the last 8mb of stolen on BDW/SKL
On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote: > The FBC hardware for these platforms doesn't have access to the > bios_reserved range, so it always assumes the maximum (8mb) is used. > So avoid this range while allocating. > > This solves a bunch of FIFO underruns that happen if you end up > putting the CFB in that memory range. On my machine, with 32mb of > stolen, I need a 2560x1440 mode for that. If the restriction applies only to FBC, apply it to only fbc. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/16] drm/i915: don't use the first stolen page on Broadwell
On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote: > The spec says we just can't use it. But what about when we inherit a framebuffer at that address? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not check or a stalled pageflip prior to it being queued
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7156 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -2 283/283 281/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: Add WA for disable gather at set shader bit
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7158 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: Add WA for disable gather at set shader bit
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7158 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black
On 08/04/2015 02:29 PM, Toralf Förster wrote: > On 08/02/2015 09:43 AM, Pavel Machek wrote: >> Any chance to bisect it? > Did it. > > FWIW: the mentioned commit was introduced between 3.18 and 3.19. > But my system (hardened 64 bit Gentoo) did not suffer from it till version > 4.0.8. > The hardened kernel 4.1.x was the first where the bug was visible at my > docked environment too. > > > > commit e7d6f7d708290da1b7c92f533444b042c79412e0 > Author: Dave Airlie > Date: Mon Dec 8 13:23:37 2014 +1000 > FWIW the issue happens only if the system is docked. Plugging in the VGA connector in parallel to the already plugged in DVI-D conenctor after wakeup from s2ram helps as a work around. In this case then the external monitor shows again the KDE desktop. After few seconds I can then plug off the VGA connector from the docking station and can continue with my work. -- Toralf, pgp key: 872AE508 0076E94E ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make SDVO deal with HDMI pixel repeat
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7184 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp/mst: Remove port after removing connector.
On Sat, Aug 15, 2015 at 02:56:57PM +1000, Dave Airlie wrote: > On 11 August 2015 at 17:54, Maarten Lankhorst > wrote: > > The port is removed synchronously, but the connector delayed. > > This causes a use after free which can cause a kernel BUG with > > slug_debug=FPZU. This is fixed by freeing the port after the > > connector. > > Where is the use after free btw? I'm not sure I like delaying the port > destruction, there should be no need to. > > The connector->port pointer shouldn't be used without validation > anywhere, and if it is that is a bug. > > I'd like to reproduce this before pulling this in. The remove function needs to lock at the connector->port to shut down the dp mst link. Before your patch that was done _before_ the final kfree on the port, but with your patch that's now the other way round: First we synchronously kfree the port, then we call the driver's connector cleanup function asynchronously. And that is very unhappy that the port is now gone. So perfectly ok regression fix imo to restore the ordering we had before your patch in the cleanup code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Video freezes continue
I'm still continuing to experience video lockups though not quite as frequent as before. The most recent was 12 August. I'm running the kernel as shown in my sig. I've attached my Xorg.0.log. I'm able to SSH into my desktop from my tablet and running cat /sys/class/drm/card0/error shows 'no error state collected'. Running cat /sys/kernel/debug/dri/0/i915_swizzle_info outputs bit6 swizzle for X-tiling = none bit6 swizzle for Y-tiling = none DDC = 0x00200010 DDC2 = 0x00300030 C0DRB3 = 0x0030 C1DRB3 = 0x0010 This has been going on for a few months less than a year now. When this happens the video is frozen however the mouse cursor will continue to move and all background processes such as fetchmail, procmail, postfix and all cronjobs continue running. This is a Dell Optiplex 780 with BIOS A15 4gb of ram. Periodically this would show in the syslog about the same time as the freeze Jul 28 16:02:28 localhost kernel: [793861.820048] [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer elapsed... render ring idle The above was the last time the 'Hangcheck' error was noted. I'm running Gnome 3.12.2 and Ubuntu 14.04.3 LTS Any advice will be appreciated. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 16:55:17 up 3 days, 10:12, 1 user, load average: 0.78, 0.51, 0.45 Ubuntu 14.04.3 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015 Xorg.0.log.xz Description: application/xz ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7198 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/mm: Do DRM_MM_CREATE_TOP adj_start calculation after color_adjust
The adj_start calculation for DRM_MM_CREATE_TOP should happen after
mm->color_adjust. There was an inconsistency between
drm_mm_insert_helper_range
and drm_mm_insert_helper, as the later was already updating after
color_adjust.
Didn't spot it before, as color_adjust is only done in systems without
LLC. But I'm not aware of anybody using this test case yet.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/drm_mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3427b11..04de6fd 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -267,12 +267,12 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
if (adj_end > end)
adj_end = end;
- if (flags & DRM_MM_CREATE_TOP)
- adj_start = adj_end - size;
-
if (mm->color_adjust)
mm->color_adjust(hole_node, color, &adj_start, &adj_end);
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start = adj_end - size;
+
if (alignment) {
u64 tmp = adj_start;
unsigned rem;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 11/11] drm/i915: Max DOT clock frequency to debugfs
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7199 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
