On Tuesday 24 August 2010 20:46:40 Andreas Schwab wrote:
> Arnd Bergmann writes:
>
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 4a66201..76d98f4 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -506,9 +506,9 @@ long drm_ioct
Arnd Bergmann writes:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4a66201..76d98f4 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -506,9 +506,9 @@ long drm_ioctl(struct file *filp,
> if (ioctl->flags & DRM_UNLOCKED)
>
On Sunday 01 August 2010 17:17:54 Roberto Oppedisano wrote:
> On 01/08/2010 15:14, Paul Rolland wrote:
> > My machine has :
> > 00:02.0 0300: 8086:2a42 (rev 07)
> > 00:02.1 0380: 8086:2a43 (rev 07)
> >
> > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> > Chipset Integrate
(E17 init)
E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0
E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896
(output blinking starts)
E17 INIT: XINERAMA SCREEN: [0], 1280x1024+0+0
E17 INIT: XINERAMA CHOSEN: [153045780], 0x153045764+0+153046580
(e17 crash, try to recover)
E17 INIT: XINERAMA
On Mon, 2010-08-23 at 17:35 +0200, Stephane Casset wrote:
> Hi,
Hi,
>
> Since 2.6.36-rc1 I have an oops when loading the nouveau driver.
> The system woks ok expect for the nouveau driver and the console gets
> corrupted :(
>
> I attach relevant informations in attached files :
> o dmesg output
On Tue, Aug 24, 2010 at 11:05:04AM -0400, Kristian H?gsberg wrote:
> > ?/** Wrapper around agp_unbind_memory() */
> > ?int drm_unbind_agp(DRM_AGP_MEM * handle)
> > ?{
> > - ? ? ? return drm_agp_unbind_memory(handle);
> > + ? ? ? return agp_unbind_memory(handle);
> > ?}
> > ?EXPORT_SYMBOL(drm_unbind
https://bugs.freedesktop.org/show_bug.cgi?id=29137
--- Comment #17 from Marek Olšák 2010-08-24 18:07:05 PDT ---
So I've implemented elimination of unused constants (and remapping their
indices to fit in the constant file in hw, and other compiler improvements) in
r300g. Wine support should be muc
https://bugs.freedesktop.org/show_bug.cgi?id=29137
--- Comment #17 from Marek Ol??k 2010-08-24 18:07:05 PDT
---
So I've implemented elimination of unused constants (and remapping their
indices to fit in the constant file in hw, and other compiler improvements) in
r300g. Wine support should be mu
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 |6
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.
Signe
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
https://bugs.freedesktop.org/show_bug.cgi?id=26999
--- Comment #8 from Julien Viard de Galbert
2010-08-24 14:54:43 PDT ---
Created an attachment (id=38132)
View: https://bugs.freedesktop.org/attachment.cgi?id=38132
Review: https://bugs.freedesktop.org/review?bug=26999&attachment=38132
prelimi
https://bugs.freedesktop.org/show_bug.cgi?id=26999
--- Comment #8 from Julien Viard de Galbert
2010-08-24 14:54:43 PDT ---
Created an attachment (id=38132)
View: https://bugs.freedesktop.org/attachment.cgi?id=38132
Review: https://bugs.freedesktop.org/review?bug=26999&attachment=38132
prelimi
On Tue, 24 Aug 2010 07:16:26 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:55:54 +0100
> Chris Wilson wrote:
>
> > In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe
> > would be interesting to see what the pixel clock is.
> >
> > Can you grab one before the bad co
https://bugs.freedesktop.org/show_bug.cgi?id=22852
Arno Schuring changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=22852
Arno Schuring changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tuesday 24 August 2010 20:46:40 Andreas Schwab wrote:
> Arnd Bergmann writes:
>
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 4a66201..76d98f4 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -506,9 +506,9 @@ long drm_ioct
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #6 from Till Matthiesen 2010-08-24 13:29:05
PDT ---
Bisection pointed me to the merged drm-core-next branch which does not really
came unexpected.
commit fc1caf6eafb30ea185720e29f7f5eccca61ecd60
Merge: 9779714 96576a9
Author: Linus
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #6 from Till Matthiesen 2010-08-24
13:29:05 PDT ---
Bisection pointed me to the merged drm-core-next branch which does not really
came unexpected.
commit fc1caf6eafb30ea185720e29f7f5eccca61ecd60
Merge: 9779714 96576a9
Author: Linus
On Tue, 2010-08-24 at 10:21 +0100, Chris Wilson wrote:
> Ivan, can you try this patch?
>
I've patched it, unfortunately it doesn't help. :( Dmesg is in
attachement. Symptoms are the same.
> Linus is going to make some more snide comments if he sees just how many
> of these trivial-ish patches th
https://bugs.freedesktop.org/show_bug.cgi?id=29787
Summary: random XRandR failures (i2c related?)
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
https://bugs.freedesktop.org/show_bug.cgi?id=29787
Summary: random XRandR failures (i2c related?)
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
Arnd Bergmann writes:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4a66201..76d98f4 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -506,9 +506,9 @@ long drm_ioctl(struct file *filp,
> if (ioctl->flags & DRM_UNLOCKED)
>
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x
On Sunday 01 August 2010 17:17:54 Roberto Oppedisano wrote:
> On 01/08/2010 15:14, Paul Rolland wrote:
> > My machine has :
> > 00:02.0 0300: 8086:2a42 (rev 07)
> > 00:02.1 0380: 8086:2a43 (rev 07)
> >
> > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> > Chipset Integrate
On Tue, 2010-08-24 at 09:50 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic
> wrote:
> > Above patches didn't help when applied to 2.6.36-rc2.
>
> Would be useful to double check reverting the bad commit helps.
>
> > I'm going to compare dmesg between 2.6.35.3
On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter
wrote:
> There's no point in jumping through two indirections. So kill one
> and call the kernels agp functions directly.
>
> Signed-off-by: Daniel Vetter
> ---
> ?drivers/gpu/drm/drm_agpsupport.c | ? 40 +++--
> ?driv
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
On Tue, 2010-08-24 at 08:49 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic
> wrote:
> > While in init3, resolution is native, KMS works fine, no problems at
> > all. As soon as gdm starts it seems that TV1 output is recognized as
> > connected even if it isn't so
Ivan, can you try this patch?
Linus is going to make some more snide comments if he sees just how many
of these trivial-ish patches that I have pending...
---
If we need to wait until the next vblank for the register to be updated
and to take effect, make sure the write is actually flushed to th
On Tue, 24 Aug 2010 09:49:02 +0100, Sitsofe Wheeler
wrote:
> 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 res
On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic wrote:
> Above patches didn't help when applied to 2.6.36-rc2.
Would be useful to double check reverting the bad commit helps.
> I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with
> drm.debug=0x6. Thanks,
Aye that would be a usefu
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, 24 Aug 2010 16:53:59 +0100
Sitsofe Wheeler wrote:
> 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
On Tue, 24 Aug 2010 16:53:59 +0100
Sitsofe Wheeler wrote:
> 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
On Tue, 24 Aug 2010 16:56:16 +0100
Sitsofe Wheeler wrote:
> 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-o
On Tue, 24 Aug 2010 16:56:16 +0100
Sitsofe Wheeler wrote:
> 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-o
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 |6
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
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.
Signe
On Tue, Aug 24, 2010 at 11:05:04AM -0400, Kristian Høgsberg wrote:
> > /** Wrapper around agp_unbind_memory() */
> > int drm_unbind_agp(DRM_AGP_MEM * handle)
> > {
> > - return drm_agp_unbind_memory(handle);
> > + return agp_unbind_memory(handle);
> > }
> > EXPORT_SYMBOL(drm_unbind
On Tue, 24 Aug 2010 08:57:41 +0100, Sitsofe Wheeler
wrote:
> The stalls became a bit better with the patch but there were still very
> small pauses but the tearing with more recent X bits is definitely still
> there. Additionally videos in totem would play as a tiny one pixel high
> row about a q
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, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 10
On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter wrote:
> There's no point in jumping through two indirections. So kill one
> and call the kernels agp functions directly.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_agpsupport.c | 40 +++--
> drive
rg/archives/dri-devel/attachments/20100824/43973a5d/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: drm.bad
Type: application/octet-stream
Size: 34704 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
On Tue, 24 Aug 2010 07:16:26 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:55:54 +0100
> Chris Wilson wrote:
>
> > In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe
> > would be interesting to see what the pixel clock is.
> >
> > Can you grab one before the bad co
https://bugs.freedesktop.org/show_bug.cgi?id=29652
--- Comment #2 from Jon Severinsson 2010-08-24 03:53:05
PDT ---
Created an attachment (id=38122)
View: https://bugs.freedesktop.org/attachment.cgi?id=38122
Review: https://bugs.freedesktop.org/review?bug=29652&attachment=38122
r600: Partially
https://bugs.freedesktop.org/show_bug.cgi?id=29652
--- Comment #2 from Jon Severinsson 2010-08-24
03:53:05 PDT ---
Created an attachment (id=38122)
View: https://bugs.freedesktop.org/attachment.cgi?id=38122
Review: https://bugs.freedesktop.org/review?bug=29652&attachment=38122
r600: Partially
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
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, 2010-08-24 at 08:49 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic wrote:
> > While in init3, resolution is native, KMS works fine, no problems at
> > all. As soon as gdm starts it seems that TV1 output is recognized as
> > connected even if it isn't so re
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
While in init3, resolution is native, KMS works fine, no problems at
all. As soon as gdm starts it seems that TV1 output is recognized as
connected even if it isn't so resolution on VGA output is degraded from
native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d b
Ivan, can you try this patch?
Linus is going to make some more snide comments if he sees just how many
of these trivial-ish patches that I have pending...
---
If we need to wait until the next vblank for the register to be updated
and to take effect, make sure the write is actually flushed to th
https://bugs.freedesktop.org/show_bug.cgi?id=29703
--- Comment #1 from Michal Suchanek 2010-08-24 02:04:21
PDT ---
after latest changes
- shadowtex works (the shadows are pixelated somewhat and the m option has
seams - not sure if that is error in rendering or the demo is too simplistic to
get
https://bugs.freedesktop.org/show_bug.cgi?id=29703
--- Comment #1 from Michal Suchanek 2010-08-24
02:04:21 PDT ---
after latest changes
- shadowtex works (the shadows are pixelated somewhat and the m option has
seams - not sure if that is error in rendering or the demo is too simplistic to
get
On Tue, 24 Aug 2010 09:49:02 +0100, Sitsofe Wheeler wrote:
> 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 rest
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x
On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic wrote:
> Above patches didn't help when applied to 2.6.36-rc2.
Would be useful to double check reverting the bad commit helps.
> I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with
> drm.debug=0x6. Thanks,
Aye that would be a usef
On Tue, 24 Aug 2010 08:57:41 +0100, Sitsofe Wheeler wrote:
> The stalls became a bit better with the patch but there were still very
> small pauses but the tearing with more recent X bits is definitely still
> there. Additionally videos in totem would play as a tiny one pixel high
> row about a qu
On Tue, 24 Aug 2010 00:35:51 +0100, Sitsofe Wheeler
wrote:
> 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.
On Mon, 23 Aug 2010 17:46:41 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:37:52 +0100
> Chris Wilson wrote:
>
> > drm.debug=0x4 should print the right information for this bug.
>
> That doesn't seem to give me any output at all.
>
> One thing I noticed, though, is that I occasionally
On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 10
On Mon, 23 Aug 2010 17:32:25 -0600, Jonathan Corbet wrote:
> On Mon, 23 Aug 2010 23:36:55 +0100
> Chris Wilson wrote:
>
> > Taking the patch at face value, the cause should be a mistake in error
> > handling. So the first step would be to identify which i2c_transfer()
> > failed.
>
> OK, I trie
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
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 the EeePC 900.)
Do the stalls and tearing go away with:
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index
67 matches
Mail list logo
