[Intel-gfx] [PATCH v2] iommu/vt-d: fix overflow of iommu->domains array
The valid range of 'did' in get_iommu_domain(*iommu, did)
is 0..cap_ndoms(iommu->cap), so don't exceed that
range in free_all_cpu_cached_iovas().
The user-visible impact of the out-of-bounds access is the machine
hanging on suspend-to-ram. It is, in fact, a kernel panic, but due
to already suspended devices, that's often not visible to the user.
Fixes: 22e2f9fa63b0 ("iommu/vt-d: Use per-cpu IOVA caching")
Signed-off-by: Jan Niehusmann
Tested-By: Marius Vlad
---
Added some details and Tested-By to the commit message. Patch is unchanged.
Posted to intel-gfx@lists.freedesktop.org and io...@lists.linux-foundation.org
where the issue was discussed.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a644d0c..82989d4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4600,7 +4600,7 @@ static void free_all_cpu_cached_iovas(unsigned int cpu)
if (!iommu)
continue;
- for (did = 0; did < 0x; did++) {
+ for (did = 0; did < cap_ndoms(iommu->cap); did++) {
domain = get_iommu_domain(iommu, did);
if (!domain)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Flicker caused by "drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)"
Hi,
On Thu, Sep 24, 2015 at 03:53:07PM -0700, Matt Roper wrote:
> Just pull the info out of the plane state structure rather than staging
> it in an additional structure.
>
> v2: Add 'visible' condition to sprites_scaled so that we don't limit the
> WM level when the sprite isn't enabled. (Ville)
It looks like this patch - specifically the visible condition in
ilk_compute_cur_wm - causes screen flicker when moving the cursor from
one screen to another one in a multi-screen setup.
My hardware is a Thinkpad x201s
(http://www.thinkwiki.org/wiki/Category:X201s)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor
Integrated Graphics Controller [8086:0046] (rev 02),
CPU is an i7-620LM.
The screen flickering is the one the coursor is leaving. In most cases,
parts of the screen just blank for a very short moment. In some rare
cases, the screen even stays blanked until I move the cursor back to
that screen. No stability issues were observed, this seems to be a
purely cosmetic issue.
I bisected the issue to 43d59eda1f69631c267e06ab6b94ed3c14f1f6d1. As I
knew the flickering was cursor-related, I tried the following minimal
patch, which actually fixed the symptom, when applied to 4.4-rc8:
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f091ad1..1ef0c54 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1791,7 +1791,7 @@ static uint32_t ilk_compute_cur_wm(const struct
intel_crtc_state *cstate,
{
int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
- if (!cstate->base.active || !pstate->visible)
+ if (!cstate->base.active)
return 0;
return ilk_wm_method2(ilk_pipe_pixel_rate(cstate),
I have no idea at all if this is actually fixing anything or if it's
just hiding the real bug. All I can say is that the flickering doesn't
occur any longer.
Jan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Flicker caused by "drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)"
Hi Matt, On Tue, Jan 05, 2016 at 01:58:19PM -0800, Matt Roper wrote: > Hi Jan. I think the flicker you're seeing is caused by our current lack > of two-stage watermark updates on platforms that use ILK-style > watermarks. I have a patch series at > http://patchwork.freedesktop.org/bundle/mattrope/atomic_wm_ilk/ that's > supposed to address this, but it's still awaiting review at the moment Yes, thanks! That patch set fixes the flickering, as well. Applied the patches, some of them manually, to 4.4-rc8, after re-appling the reverted watermark commits from 2791a16ca43302d07ac74cbe7c048e367c4632c4 and 261a27d11fa1dec47c47ece6968eaaba55861eca. I didn't do much testing, but the resulting kernel boots fine and the flickering is gone. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Short stalls of xorg display updates
Hi, this is just some random observation which may be interesting to you as a data point, not a call for help, as I already solved / worked around the problem, at least for my computer. TL;DR: Switching from uxa to sna made the issue go away. On a Thinkpad X201s with a i7-620L CPU I had a major usability issue with xorg: Quite often (like every few seconds, during normal desktop usage) display updates 'hung' for a short moment. The system itself did continue to run, so it wasn't a full lockup. As I didn't find a way to measure this, I don't have accurate numbers, but I'd say the stalls had a length of about 1/2 second. This didn't make the computer unusable, but was very annoying, and made the GUI feel really slow. The issue didn't happen with all workloads: Video playback did work quite well, while switching between two windows quickly (using keyboard repeat) did trigger the issue reliably. Strangly, I think the problem didn't show up before I upgraded the BIOS from 1.05 to 1.40. But I'm not 100% sure about this, as I only had the notebook for a few days before upgrading. The software on this computer is based on debian wheezy, but with a self-compiled kernel: Linux kernel 3.9.6 xserver-xorg-core 2:1.12.4-6 xserver-xorg-video-intel 2:2.19.0-6 (xorg versions are the full debian version numbers) I did try several things like upgrading to the latest 3.10 RC kernel, upgrading the xorg intel driver to 2.20.14 (from debian experimental) etc. without success. The change that finally helped was setting the AccelMethod to "sna" in xorg.conf. Please don't waste your time on this, as my workaround works perfectly fine for me. But if someone else reports similar issues, perhaps this may help pinpointing the cause. And, of course, feel free to ask in case you need more information I may provide. Regards, Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel-gtt: fix memory corruption with GM965 and >4GB RAM
On Thu, Feb 24, 2011 at 12:30:22AM +0100, Jan Niehusmann wrote to
linux-ker...@vger.kernel.org:
> On a Thinkpad x61s, I noticed some memory corruption when
> plugging/unplugging the external VGA connection.
>
> Symptoms:
> -
>
> 4 bytes at the beginning of a page get overwritten by zeroes.
> The address of the corruption varies when rebooting the machine, but
> stays constant while it's running (so it's possible to repeatedly write
> some data and then corrupt it again by plugging the cable).
Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0x), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.
So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this corrupts
unrelated memory.
The corruption was observed on a Thinkpad x61s, using the Mobile Intel
GM965 Express Chipset. The first four bytes of the wrong page are
overwritten with zeroes whenever the VGA cable gets plugged or unplugged.
This patch simply works around this issue by confining the dma memory
to 32 bits.
It's not known if other chipsets are affected as well.
---
drivers/char/agp/intel-gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 29ac6d4..f7977f2 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1379,7 +1379,7 @@ static const struct intel_gtt_driver i965_gtt_driver = {
.setup = i9xx_setup,
.cleanup = i9xx_cleanup,
.write_entry = i965_write_entry,
- .dma_mask_size = 36,
+ .dma_mask_size = 32,
.check_flags = i830_check_flags,
.chipset_flush = i9xx_chipset_flush,
};
--
1.7.2.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel-gtt: fix memory corruption with GM965 and >4GB RAM
Hi Chris, On Fri, Feb 25, 2011 at 08:22:53PM +, Chris Wilson wrote: > On Fri, 25 Feb 2011 13:30:56 +0100, Jan Niehusmann wrote: > > Further investigation revealed that the corrupted address is > > (dev_priv->status_page_dmah->busaddr & 0x), ie. the beginning of > > the hardware status page of the i965 graphics card, cut to 32 bits. > > 965GM explicitly supports 36bits of addressing in the PTE. The only > exception is that general state (part of the 3D engine) must be located in > the lower 4GiB. I'm not claiming that 965GM doesn't do 36 bits. In fact I actually see activity in /sys/kernel/debug/dri/64/i915_gem_hws, and everything seems to be working well, when the status page is above 4GB - if one ignores the tiny detail that the wrong memory location gets overwritten, sometimes... > Simply ignoring the upper 4bits is the wrong approach and means that the > PTE then point to random pages, and completely irrelevant to the physical > address used in the hardware status page address register. Doesn't setting DMA_BIT_MASK(32) only change the region DMA memory is allocated from? I made that change just to make sure one gets addresses which are safe even if the chipset sometimes ignores address bit 32. The only negative impact I could think of is the allocation may fail if no appropriate memory is available. Am I wrong? > I have been considering: > + if (IS_BRROADWATER(dev) || IS_CRESTLINE(dev)) > + dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32)); > to prevent hitting the erratum. So is there a known erratum about these chips? I didn't find errata documents online, but I only did a short google search and may have missed them. > However your bug looks to be: > - if (INTEL_INFO(dev)->gen >= 4) > - dev_priv->dma_status_page |= (dev_priv->dma_status_page >> > 28) & > -0xf0; > + if (INTEL_INFO(dev)->gen >= 4) /* 36-bit addressing */ > + dev_priv->dma_status_page |= > + (dev_priv->status_page_dmah->busaddr >> 28) & 0xf0; Don't think so. dev_priv->dma_status_page gets initialized to dev_priv->status_page_dmah->busaddr a few lines above, and it's 64 bit, so that diff doesn't change the result of the computation. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix memory corruption with GM965 and >4GB RAM
On Sat, Feb 26, 2011 at 12:05:27AM +0100, Daniel Vetter wrote:
> Actually, on style points I prefer your patch: The hw status page is
> allocated with drm_pci_alloc which calls dma_alloc_coherent, so setting
> the coherent mask is sufficient. The dma mask set in the gtt is
> essentially useless, because we call get_user_pages on everything anyway
> (in gem - iirc agp uses it). I just think it's confusing to limit the
> general dma mask and continue to happily map pages above 4G.
Indeed, setting dma_alloc_coherent should be sufficient, AFAIKT. After
all, only the HWS seems to be affected, which is allocated with
drm_pci_alloc, which in turn uses dma_alloc_coherent.
I just tried the patch below, it also works for me (as expected). Added
the comment because otherwise it wouldn't be obvious why the mask gets
set to 32 bit.
What I don't know is if really only Broadwater and Crestline chips are
affected. The tests were done with a Crestline one. But I think it's a
fair guess that the bug would have been noticed earlier if more recent
chips were affected, as >4GB RAM have become much more common since then.
Signed-off-by: Jan Niehusmann
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 17bd766..1961580 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1895,6 +1895,12 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (IS_GEN2(dev))
dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(30));
+ /* 965GM sometimes incorrectly writes to hardware status page (HWS)
+* using 32bit addressing, overwriting memory if HWS is located
+* above 4GB. */
+ if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
+ dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32));
+
mmio_bar = IS_GEN2(dev) ? 1 : 0;
dev_priv->regs = pci_iomap(dev->pdev, mmio_bar, 0);
if (!dev_priv->regs) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 2.6.38-rc8 regressions
Hello, just to provide some testing feedback. I didn't have time (and probably not even the necessary skills) to further diagnose these issues. But as I don't remember seeing these problems with 2.6.37, maybe the observations are interesting to you: With 2.6.38-rc8 I see the following graphics related regressions (relative to 2.6.37) on a Thinkpad X61s with "Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller" (PCI ID 8086:2a02). Userspace is debian/squeeze. 1) Every now and then, terminal windows (urxvt) do not properly update their contents. After issueing a command like 'ls', which writes several lines of text at once, some lines are completely missing. It's not garbled glyphs, but full lines of text completely missing. Interestingly, sometimes the correct contents of the full window become visible for a split second. So they seem to be 'somewhere' accessible to the GPU, just not shown on the screen. When a single character in an affected line gets updated (e.g. by marking it with the cursor - or even by an update in a different console window next to the one affected) the correct contents of the full line become and stay visible. When this problem occurs, it does so reproducibly: About every third command writing to the terminal shows the behaviour. In that situation, just closing and reopening the lid solves the problem: Console windows work as expected again, and AFAICT the problem doesn't reoccur until the next reboot or suspend/resume cycle. 2) I just had a full hang of the GPU (black screen) after opening a web page containing a video. kernel.log contains the following messages: Mar 14 09:09:37 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 14 09:09:37 x61s kernel: [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 10172 at 10171, next 10173) Mar 14 09:09:37 x61s kernel: [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start Mar 14 09:09:44 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 14 09:09:44 x61s kernel: [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start Mar 14 09:09:44 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:44 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:44 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:44 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:44 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling [...] Mar 14 09:09:45 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:45 x61s kernel: [drm:i915_do_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling Mar 14 09:09:45 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 14 09:09:45 x61s kernel: [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 10180 at 10171, next 10181) Mar 14 09:09:45 x61s kernel: [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! Mar 14 09:09:45 x61s kernel: [drm:i915_reset] *ERROR* Failed to reset chip. The same (probably) happened ten days ago with 2.6.38-rc6: Mar 4 10:06:22 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 4 10:06:22 x61s kernel: [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 50785 at 50784, next 50786) Mar 4 10:06:22 x61s kernel: [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start Mar 4 10:06:28 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 4 10:06:28 x61s kernel: [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start Mar 4 10:06:31 x61s kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 4 10:06:31 x61s kernel: [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! Mar 4 10:06:31 x61s kernel: [drm:i915_reset] *ERROR* Failed to reset chip. So it doesn't happen particularly often, but still too often to just ignore it. Regards, Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 2.6.38-rc8 regressions
Hi Chris, On Mon, Mar 14, 2011 at 09:53:36AM +, Chris Wilson wrote: > On Mon, 14 Mar 2011 10:08:12 +0100, Jan Niehusmann wrote: > > 1) Every now and then, terminal windows (urxvt) do not properly update > > their contents. After issueing a command like 'ls', which writes > > several lines of text at once, some lines are completely missing. It's > > not garbled glyphs, but full lines of text completely missing. [...] > There was a bug in the DDX where we missing a flush (for precisely this > style of bug): > > commit 4a186a612376bdd6f86c026e8b8b442108868a0a > Author: Chris Wilson > Date: Tue Dec 7 16:56:57 2010 + > > Always flush the batch before blocking for new X requests > > This should prevent any lag when waiting upon user input, for example > whilst logging in with gdm. > > Signed-off-by: Chris Wilson > I cherry-picked this patch into the source code of 2.13.0, as provided by the debian package xserver-xorg-video-intel version 2.13.0-5. With that patch applied, I still observed the described behaviour. Additionally, some java application had display update problems. (But java generally has some problems because I'm using a non-reparenting window manager, 'awesome', which java doesn't like). What do you think, would it be worthwhile to try a more recent version of xf86-video-intel? Regards, Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 2.6.38-rc8 regressions
On Wed, Mar 16, 2011 at 06:34:57PM +, Chris Wilson wrote: > On Wed, 16 Mar 2011 18:46:55 +0100, Jan Niehusmann wrote: > > With that patch applied, I still observed the described behaviour. > > Additionally, some java application had display update problems. (But > > java generally has some problems because I'm using a non-reparenting > > window manager, 'awesome', which java doesn't like). > > > > What do you think, would it be worthwhile to try a more recent version > > of xf86-video-intel? > > Ok, that's more worrying. That bug certainly matched what you describe, > and I don't offhand know of another commit since 2.13 that is relevant. It > would be good to double-check first though. Same with 2.14.901 from debian/experimental. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 2.6.38-rc8 regressions
On Wed, Mar 16, 2011 at 06:34:57PM +, Chris Wilson wrote: > On Wed, 16 Mar 2011 18:46:55 +0100, Jan Niehusmann wrote: > > With that patch applied, I still observed the described behaviour. > > Additionally, some java application had display update problems. (But > > java generally has some problems because I'm using a non-reparenting > > window manager, 'awesome', which java doesn't like). > > > > What do you think, would it be worthwhile to try a more recent version > > of xf86-video-intel? > > Ok, that's more worrying. That bug certainly matched what you describe, > and I don't offhand know of another commit since 2.13 that is relevant. It > would be good to double-check first though. I bisected the display update issues to start between 0b0b053a and c64f7ba5. fe669bf8 doesn't work at all (black screen after X startup), and I didn't try 1b6064d7 yet: bad:c64f7ba agp/intel: Remove confusion of stolen entries not stolen memory not tried: 1b6064d agp/intel: Remove the artificial cap on stolen size crashes:fe669bf drm/i915: Compute physical addresses from base of stolen memory good: 0b0b053 drm/i915/panel: Restore saved value of BLC_PWM_CTL Another observation I made is that everything is fine while I am using a dual-screen setup. As dual-screen disables frame buffer compression, I tried to i915.powersave=0, and indeed, with this parameter I was unable to reproduce the issues, as well. Is there anything else I could try? Unfortunately, because of conflicting changes, it's not easily possible to just revert these commits from 2.6.38. Regards, Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 2.6.38-rc8 regressions
On Mon, Mar 14, 2011 at 10:08:12AM +0100, Jan Niehusmann wrote:
> 1) Every now and then, terminal windows (urxvt) do not properly update
> their contents. After issueing a command like 'ls', which writes
> several lines of text at once, some lines are completely missing. It's
> not garbled glyphs, but full lines of text completely missing.
Just a quick update on the issue I reported a while ago: While I still
see this problem with 2.6.38.2, it seems like it's fixed with current
2.6.39 development tree at commit 40bd8ea1.
Out of curiosity, I reverted 36d527de ("Restore missing command flush
before interrupt on BLT ring") from that, and was able to reproduce the
bug, again.
So it looks like this is fixed now.
Jan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 2.6.38-rc8 regressions
On Sun, Apr 10, 2011 at 02:25:36PM +0200, Jan Niehusmann wrote: > Just a quick update on the issue I reported a while ago: While I still > see this problem with 2.6.38.2, it seems like it's fixed with current > 2.6.39 development tree at commit 40bd8ea1. [...] > So it looks like this is fixed now. Sorry, I have to take this back: I just observed the screen corruption with 2.6.39-rc2. So it may just be more difficult to trigger. (Or it's just coincidence that I wasn't able to reproduce it at first.) Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH/RFC] i915: fix screen flickering
On Wed, Apr 29, 2015 at 12:23:43AM +0200, Thomas Gummerer wrote: > I forgot to mention, the bug only occurs after suspending the system and > waking it up again. In that case, moving the mouse pointer around on > the build in laptop screen triggers the flickering, while the external > monitor works just fine. My Lenovo X201s shows the same symptoms with v4.1.0-rc1, and your patch seems to help. Another detail: The flickering only happens when both outputs are active, using xrandr to disable one output makes the other one working fine, again. > Might be unrelated, but I only managed to trigger the bug when the > system is suspended after the synergy server has started. I don't have synergy installed, so this can't be a strict requirement for triggering the bug. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG/REGRESSION] Screen flickering
Hi, On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote: > Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ? The visible effect in the video is similar to what I see on the LVDS display. I also see some influence of the mouse pointer position on the blanked areas. The effect on the external screen is more like single scan lines jumping to the right and back, at a high (but still visible) frequency. What I'm missing in the report, are some log entries I'm seeing on my notebook: Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG/REGRESSION] Screen flickering
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote: > > What I'm missing in the report, are some log entries I'm seeing on my > > notebook: > > > > Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler > > [i915]] *ERROR* CPU pipe B FIFO underrun > > Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler > > [i915]] *ERROR* PCH transcoder B FIFO underrun > > Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler > > [i915]] *ERROR* CPU pipe A FIFO underrun > > Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler > > [i915]] *ERROR* PCH transcoder A FIFO underrun > hi, > I also have the similar entries in my dmesg, though my problem is a > little different from yours and my bisect lead to another commit. > And that also is still not fixed (last tested with 4.0). (Please note that I didn't do a bisect - that was Thomas. I only noted that I can confirm his observations and that his patch helps to prevent or hide the issue.) Perhaps these are two completely unrelated issues? Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
