With a tree that is close to 3.15 final I'm regularly seeing the
following on my EeePC 900 when starting ioquake3:
[drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits
(expected 32768, found 0)
[ cut here ]
WARNING: CPU: 0 PID: 1594 at drivers/gpu
On Tue, Jun 10, 2014 at 08:26:55AM +0200, Daniel Vetter wrote:
> On Sun, Jun 08, 2014 at 10:30:15PM +0100, Sitsofe Wheeler wrote:
> > With a tree that is close to 3.15 final I'm regularly seeing the
> > following on my EeePC 900 when starting ioquake3:
> >
> >
(resending because Daniel was dropped from the reply list - I don't know
why)
On Wed, Jun 11, 2014 at 06:46:40AM +0100, Sitsofe Wheeler wrote:
> On Tue, Jun 10, 2014 at 08:26:55AM +0200, Daniel Vetter wrote:
> > On Sun, Jun 08, 2014 at 10:30:15PM +0100, Sitsofe Wheeler wrote:
>
On Wed, Jun 11, 2014 at 11:32:29AM +0200, Daniel Vetter wrote:
> On Wed, Jun 11, 2014 at 07:03:39AM +0100, Sitsofe Wheeler wrote:
> >
> > On Wed, Jun 11, 2014 at 06:46:40AM +0100, Sitsofe Wheeler wrote:
> > > On Tue, Jun 10, 2014 at 08:26:55AM +0200, Daniel Vetter wrote
Hello,
(Apologies if I have CC'd the wrong people/places - I just went by
what get_maintainer.pl -f drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
said)
I recently upgraded from Ubuntu 20.04 (5.15.0-119.129~20.04.1-generic
kernel) to Ubuntu 24.04 (6.8.0-44-generic kernel) and found that while
booting th
Hi,
I've been finding that kmemleak reports that i915 is leaking gem
buffers (although it takes about 20 minutes before the supposed leaks
occur). The leaks normally occur in batches of 13 and seem to require
chrome to be running looking at a page like google.com while a
gnome-terminal is also pr
Hi,
With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
900 with an i915.
Attempts to bisect the issue are not successful - most kernels in
between rc1 and rc2 just make the system come up with a black scr
On Tue, Aug 24, 2010 at 01:12:22AM +0100, Chris Wilson wrote:
>
> From the error message, I'd suggest we'd tackle hangcheck - it simply
> shouldn't be firing at all under normal circumstances. (Looking at it we
> don't handle the introduction of the BSD ring correctly, but that is
> irrelevant on
On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
>
> Ok, I'm a little happier that the hangcheck could be just another symptom
> of the problem...
>
> I think it is safe to assume that the bug is in i915, so restricting the
> bisect to just drm seems plausible:
>
> git bisect start
On Tue, Aug 24, 2010 at 10:00:47AM +0100, Chris Wilson wrote:
>
> I was hoping that git would be more intelligent than that. Is there a
> way to simply bisect down one side of a merge?
Seemingly not...
> The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde.
> A trivial pat
.
Signed-off-by: Sitsofe Wheeler
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 23157e1..116d938 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b
In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were
converted into vblank waits. One of these caused tearing, mode detection
and redraw issues on an EeePC 900 with a more recent intel userspace (
http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves
the issue.
---
d
With the extra intel_wait_for_vblank added in commit
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being
triggered (which were detected by i915_hangcheck_elapsed). Partially
revert this change for now.
Signed-off-by: Sitsofe Wheeler
---
drivers/gpu/drm/i915/intel_display.c
On Sun, Aug 29, 2010 at 02:32:41PM +0300, Pekka Enberg wrote:
>
> The "insufficient FIFO for plane" problem seems to have gone away with
> latest Linus' git. I suppose commit
> 9559fcdbff4f93d29af04478bbc48294519424f5 ("drm/i915: fix vblank wait
> test condition") fixed it although I don't see any
On Sun, Aug 29, 2010 at 02:29:32PM +0300, Pekka Enberg wrote:
>
> I'm still seeing wrong resolution with my i915 Macbook with latest
> Linus' git. Is there a fix in the pipeline or should we start looking
> for a commit to revert? As a slab maintainer, I'm supposed to be able
> to work with -rc ke
Hi,
I've been finding that kmemleak reports that i915 is leaking gem
buffers (although it takes about 20 minutes before the supposed leaks
occur). The leaks normally occur in batches of 13 and seem to require
chrome to be running looking at a page like google.com while a
gnome-terminal is also pr
Hi,
With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
900 with an i915.
Attempts to bisect the issue are not successful - most kernels in
between rc1 and rc2 just make the system come up with a black scr
On Tue, Aug 24, 2010 at 01:12:22AM +0100, Chris Wilson wrote:
>
> From the error message, I'd suggest we'd tackle hangcheck - it simply
> shouldn't be firing at all under normal circumstances. (Looking at it we
> don't handle the introduction of the BSD ring correctly, but that is
> irrelevant on
On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
>
> Ok, I'm a little happier that the hangcheck could be just another symptom
> of the problem...
>
> I think it is safe to assume that the bug is in i915, so restricting the
> bisect to just drm seems plausible:
>
> git bisect start
On Tue, Aug 24, 2010 at 10:00:47AM +0100, Chris Wilson wrote:
>
> I was hoping that git would be more intelligent than that. Is there a
> way to simply bisect down one side of a merge?
Seemingly not...
> The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde.
> A trivial pat
.
Signed-off-by: Sitsofe Wheeler
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 23157e1..116d938 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b
In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were
converted into vblank waits. One of these caused tearing, mode detection
and redraw issues on an EeePC 900 with a more recent intel userspace (
http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves
the issue.
---
d
With the extra intel_wait_for_vblank added in commit
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being
triggered (which were detected by i915_hangcheck_elapsed). Partially
revert this change for now.
Signed-off-by: Sitsofe Wheeler
---
drivers/gpu/drm/i915/intel_display.c
On Sun, Aug 29, 2010 at 02:32:41PM +0300, Pekka Enberg wrote:
>
> The "insufficient FIFO for plane" problem seems to have gone away with
> latest Linus' git. I suppose commit
> 9559fcdbff4f93d29af04478bbc48294519424f5 ("drm/i915: fix vblank wait
> test condition") fixed it although I don't see any
On Sun, Aug 29, 2010 at 02:29:32PM +0300, Pekka Enberg wrote:
>
> I'm still seeing wrong resolution with my i915 Macbook with latest
> Linus' git. Is there a fix in the pipeline or should we start looking
> for a commit to revert? As a slab maintainer, I'm supposed to be able
> to work with -rc ke
(CC'ing Hans de Goede who recently wrote a blog post
(https://hansdegoede.dreamwidth.org/28552.html ) which sounds like the
same issue I'm seeing)
On Sun, 15 Sept 2024 at 21:30, Sitsofe Wheeler wrote:
>
> Hello,
>
> (Apologies if I have CC'd the wrong people/pla
Hi,
On Tue, 17 Sept 2024 at 22:43, Alex Deucher wrote:
>
> Do you have secureboot enabled? If so, perhaps this is relevant:
> https://bugzilla.kernel.org/show_bug.cgi?id=219229
The system is an old HP MicroServer N36L with no UEFI support so
there's no secureboot.
--
Sitsofe
27 matches
Mail list logo
