[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Kirill Smelkov]

On Tue, Aug 09, 2011 at 09:56:01AM -0700, Ray Lee wrote:
> On Tue, Aug 9, 2011 at 9:32 AM, Kirill Smelkov  wrote:
> > Quite frankly, I don't understand intel-gfx developers attitude: why is
> > it me, just random user who is nitpicking here? Why there is no
> > interest/will to analyze now obviously buggy/duplicate code and fix it?
> 
> Because they don't have an infinite amount of manpower.?Actual bugs
> hitting actual users take precedence over 'cleanups' which always have
> a chance of causing regressions, as you're well aware. Code churn for
> the sake of abstract prettiness is discouraged, as it has a potential
> cost for little potential gain.
> 
> If you like, submit a patch. You may now be more up-to-date on those
> particular code paths than most of the intel-gfx developers.

Ray, I'd agree with you if the topic was about cleanups.

But here I was talking about copy-pasty commit which introduced
regressions and bugs, and if now it's a user dilemma to either "clean up"
it after developers himself, or accept that something is broken because
developers lack manpower and so plug things in a hurry increasing
entropy, I'd like to remind a good rule, at least to me one more time,
not to break things in the first place.

I'm not talking about cleanup here. I'm talking about original commit
which introduced problems, and that there is no need to clean it up, but
better revert and redo properly to avoid subsequent code churn in lots
of fixes.


Sorry, I won't submit a patch. If there is a need to find/fix/cleanup
obvious things after company's developers, I have better things to do,
and a todo item to re-evaluate hardware for my next project.


Thanks,
Kirill

[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

--- Comment #3 from runetmember at gmail.com 2011-08-09 21:13:02 PDT ---
Created an attachment (id=50086)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=50086)
Example of error message

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

runetmember at gmail.com changed:

   What|Removed |Added

Summary|R600g Evergreen: GPU lockup |R600g Evergreen: GPU lockup
   |after launch of StarCraft   |after launch of Bioshock
   |II  |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39902] R600g Evergreen: GPU lockup after launch of StarCraft II

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

--- Comment #2 from runetmember at gmail.com 2011-08-09 21:12:11 PDT ---
You was right, there are probably problem with packaging of x86_64 of the
driver.
https://bugs.freedesktop.org/show_bug.cgi?id=39897#c12
I can not reproduce StarCraft II GPU lockup on pure x86 setup. Works fine on
low settings by the way.

But now I have another lockup-problem when I try to launch Bioshock or Metro
2033. 
How to reproduce:
1. Install Bioshock demo: http://www.gamefront.com/files/8363410
2. Launch Bioshock. Wait few seconds.
3. Switch to any other text console, and after that switch back to graphics
console.
So now you should able to get GPU lockup. Log attached.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Kirill Smelkov]

On Tue, Aug 09, 2011 at 07:02:59PM +0300, Vasily Khoruzhick wrote:
> On Tuesday 09 August 2011 18:34:46 Kirill Smelkov wrote:
> > On Tue, Aug 09, 2011 at 06:09:57PM +0300, Vasily Khoruzhick wrote:
> > > On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
> > > > On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
> > > > > On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> > > > > > On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > > > > > > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > > > > > > Keith,
> > > > > > > > 
> > > > > > > > first of all thanks for your prompt reply. Then...
> > > > > > > > 
> > > > > > > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > > > > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > > > > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > > > > > And now after v3.0 is out, I've tested it again, and yes,
> > > > > > > > > > like it was broken on v3.0-rc5, it is (now even more)
> > > > > > > > > > broken on v3.0 -- after first
> > > > > > > > > 
> > > > > > > > > > bad io access the system freezes completely:
> > > > > > > > > I looked at this when I first saw it (a couple of weeks ago),
> > > > > > > > > and I couldn't see any obvious reason this patch would cause
> > > > > > > > > this particular problem. I didn't want to revert the patch
> > > > > > > > > at that point as I feared it would cause other subtle
> > > > > > > > > problems. Given that you've got a work-around, it seemed
> > > > > > > > > best to just push this off past 3.0.
> > > > > > > > 
> > > > > > > > What kind of a workaround are you talking about? Sorry, to me
> > > > > > > > it all looked like "UMS is being ignored forever". Anyway,
> > > > > > > > let's move on to try to solve the issue.
> > > > > > > > 
> > > > > > > > > Given the failing address passed to ioread32, this seems like
> > > > > > > > > it's probably the call to READ_BREADCRUMB --
> > > > > > > > > I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
> > > > > > > > > units within the hardware status page. If the
> > > > > > > > > status_page.page_addr value was zero, then the computed
> > > > > > > > > address would end up being 0x84.
> > > > > > > > > 
> > > > > > > > > And, it looks like status_page.page_addr *will* end up being
> > > > > > > > > zero as a result of the patch in question. The patch resets
> > > > > > > > > the entire ring structure contents back to the initial
> > > > > > > > > values, which includes smashing the status_page structure to
> > > > > > > > > zero, clearing the value of status_page.page_addr set in
> > > > > > > > > i915_init_phys_hws.
> > > > > > > > > 
> > > > > > > > > Here's an untested patch which moves the initialization of
> > > > > > > > > status_page.page_addr into intel_render_ring_init_dri. I note
> > > > > > > > > that intel_init_render_ring_buffer *already* has the setting
> > > > > > > > > of the status_page.page_addr value, and so I've removed the
> > > > > > > > > setting of status_page.page_addr from i915_init_phys_hws.
> > > > > > > > > 
> > > > > > > > > I suspect we could remove the memset from
> > > > > > > > > intel_init_render_ring_buffer; it seems entirely superfluous
> > > > > > > > > given the memset in i915_init_phys_hws.
> > > > > > > > > 
> > > > > > > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17
> > > > > > > > > 00:00:00 2001 From: Keith Packard 
> > > > > > > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > > > > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page
> > > > > > > > > address in
> > > > > > > > > 
> > > > > > > > >  intel_render_ring_init_dri
> > > > > > > > > 
> > > > > > > > > Physically-addressed hardware status pages are initialized
> > > > > > > > > early in the driver load process by i915_init_phys_hws. For
> > > > > > > > > UMS environments, the ring structure is not initialized
> > > > > > > > > until the X server starts. At that point, the entire ring
> > > > > > > > > structure is re-initialized with all new values. Any values
> > > > > > > > > set in the ring structure (including
> > > > > > > > > ring->status_page.page_addr) will be lost when the ring is
> > > > > > > > > re-initialized.
> > > > > > > > > 
> > > > > > > > > This patch moves the initialization of the
> > > > > > > > > status_page.page_addr value to intel_render_ring_init_dri.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Keith Packard 
> > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > > > > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > > > > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c
> > > > > > > > > 100644 --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > > > +++ 

[Bug 40762] Kernel crashes when activation powersaving feature of mobility radeon x1400

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=40762


Rafael J. Wysocki  changed:

   What|Removed |Added

 CC||rjw at sisk.pl
  Component|Other   |Video(DRI - non Intel)
 AssignedTo|power-management_other at kern |drivers_video-dri at 
kernel-bu
   |el-bugs.osdl.org|gs.osdl.org
Product|Power Management|Drivers




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Kirill Smelkov]

On Tue, Aug 09, 2011 at 06:09:57PM +0300, Vasily Khoruzhick wrote:
> On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
> > On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
> > > On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> > > > On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > > > > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > > > > Keith,
> > > > > > 
> > > > > > first of all thanks for your prompt reply. Then...
> > > > > > 
> > > > > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > > > > > > 
> > > 
> > > wrote:
> > > > > > > > And now after v3.0 is out, I've tested it again, and yes, like
> > > > > > > > it was broken on v3.0-rc5, it is (now even more) broken on
> > > > > > > > v3.0 -- after first
> > > > > > > 
> > > > > > > > bad io access the system freezes completely:
> > > > > > > I looked at this when I first saw it (a couple of weeks ago), and
> > > > > > > I couldn't see any obvious reason this patch would cause this
> > > > > > > particular problem. I didn't want to revert the patch at that
> > > > > > > point as I feared it would cause other subtle problems. Given
> > > > > > > that you've got a work-around, it seemed best to just push this
> > > > > > > off past 3.0.
> > > > > > 
> > > > > > What kind of a workaround are you talking about? Sorry, to me it
> > > > > > all looked like "UMS is being ignored forever". Anyway, let's move
> > > > > > on to try to solve the issue.
> > > > > > 
> > > > > > > Given the failing address passed to ioread32, this seems like
> > > > > > > it's probably the call to READ_BREADCRUMB --
> > > > > > > I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
> > > > > > > units within the hardware status page. If the
> > > > > > > status_page.page_addr value was zero, then the computed address
> > > > > > > would end up being 0x84.
> > > > > > > 
> > > > > > > And, it looks like status_page.page_addr *will* end up being zero
> > > > > > > as a result of the patch in question. The patch resets the
> > > > > > > entire ring structure contents back to the initial values, which
> > > > > > > includes smashing the status_page structure to zero, clearing
> > > > > > > the value of status_page.page_addr set in i915_init_phys_hws.
> > > > > > > 
> > > > > > > Here's an untested patch which moves the initialization of
> > > > > > > status_page.page_addr into intel_render_ring_init_dri. I note
> > > > > > > that intel_init_render_ring_buffer *already* has the setting of
> > > > > > > the status_page.page_addr value, and so I've removed the setting
> > > > > > > of status_page.page_addr from i915_init_phys_hws.
> > > > > > > 
> > > > > > > I suspect we could remove the memset from
> > > > > > > intel_init_render_ring_buffer; it seems entirely superfluous
> > > > > > > given the memset in i915_init_phys_hws.
> > > > > > > 
> > > > > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
> > > > > > > 2001 From: Keith Packard 
> > > > > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page
> > > > > > > address in
> > > > > > > 
> > > > > > >  intel_render_ring_init_dri
> > > > > > > 
> > > > > > > Physically-addressed hardware status pages are initialized early
> > > > > > > in the driver load process by i915_init_phys_hws. For UMS
> > > > > > > environments, the ring structure is not initialized until the X
> > > > > > > server starts. At that point, the entire ring structure is
> > > > > > > re-initialized with all new values. Any values set in the ring
> > > > > > > structure (including
> > > > > > > ring->status_page.page_addr) will be lost when the ring is
> > > > > > > re-initialized.
> > > > > > > 
> > > > > > > This patch moves the initialization of the status_page.page_addr
> > > > > > > value to intel_render_ring_init_dri.
> > > > > > > 
> > > > > > > Signed-off-by: Keith Packard 
> > > > > > > ---
> > > > > > > 
> > > > > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct
> > > > > > > drm_device *dev)
> > > > > > > 
> > > > > > >  static int i915_init_phys_hws(struct drm_device *dev)
> > > > > > >  {
> > > > > > >  
> > > > > > >   drm_i915_private_t *dev_priv = dev->dev_private;
> > > > > > > 
> > > > > > > - struct intel_ring_buffer *ring = LP_RING(dev_priv);
> > > > > > > 
> > > > > > >   /* Program Hardware Status Page */
> > > > > > >   

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Vasily Khoruzhick]

On Tuesday 09 August 2011 18:34:46 Kirill Smelkov wrote:
> On Tue, Aug 09, 2011 at 06:09:57PM +0300, Vasily Khoruzhick wrote:
> > On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
> > > On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
> > > > On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> > > > > On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > > > > > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > > > > > Keith,
> > > > > > > 
> > > > > > > first of all thanks for your prompt reply. Then...
> > > > > > > 
> > > > > > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > > > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > > > > > > > 
> > > > 
> > > > wrote:
> > > > > > > > > And now after v3.0 is out, I've tested it again, and yes,
> > > > > > > > > like it was broken on v3.0-rc5, it is (now even more)
> > > > > > > > > broken on v3.0 -- after first
> > > > > > > > 
> > > > > > > > > bad io access the system freezes completely:
> > > > > > > > I looked at this when I first saw it (a couple of weeks ago),
> > > > > > > > and I couldn't see any obvious reason this patch would cause
> > > > > > > > this particular problem. I didn't want to revert the patch
> > > > > > > > at that point as I feared it would cause other subtle
> > > > > > > > problems. Given that you've got a work-around, it seemed
> > > > > > > > best to just push this off past 3.0.
> > > > > > > 
> > > > > > > What kind of a workaround are you talking about? Sorry, to me
> > > > > > > it all looked like "UMS is being ignored forever". Anyway,
> > > > > > > let's move on to try to solve the issue.
> > > > > > > 
> > > > > > > > Given the failing address passed to ioread32, this seems like
> > > > > > > > it's probably the call to READ_BREADCRUMB --
> > > > > > > > I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
> > > > > > > > units within the hardware status page. If the
> > > > > > > > status_page.page_addr value was zero, then the computed
> > > > > > > > address would end up being 0x84.
> > > > > > > > 
> > > > > > > > And, it looks like status_page.page_addr *will* end up being
> > > > > > > > zero as a result of the patch in question. The patch resets
> > > > > > > > the entire ring structure contents back to the initial
> > > > > > > > values, which includes smashing the status_page structure to
> > > > > > > > zero, clearing the value of status_page.page_addr set in
> > > > > > > > i915_init_phys_hws.
> > > > > > > > 
> > > > > > > > Here's an untested patch which moves the initialization of
> > > > > > > > status_page.page_addr into intel_render_ring_init_dri. I note
> > > > > > > > that intel_init_render_ring_buffer *already* has the setting
> > > > > > > > of the status_page.page_addr value, and so I've removed the
> > > > > > > > setting of status_page.page_addr from i915_init_phys_hws.
> > > > > > > > 
> > > > > > > > I suspect we could remove the memset from
> > > > > > > > intel_init_render_ring_buffer; it seems entirely superfluous
> > > > > > > > given the memset in i915_init_phys_hws.
> > > > > > > > 
> > > > > > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17
> > > > > > > > 00:00:00 2001 From: Keith Packard 
> > > > > > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > > > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page
> > > > > > > > address in
> > > > > > > > 
> > > > > > > >  intel_render_ring_init_dri
> > > > > > > > 
> > > > > > > > Physically-addressed hardware status pages are initialized
> > > > > > > > early in the driver load process by i915_init_phys_hws. For
> > > > > > > > UMS environments, the ring structure is not initialized
> > > > > > > > until the X server starts. At that point, the entire ring
> > > > > > > > structure is re-initialized with all new values. Any values
> > > > > > > > set in the ring structure (including
> > > > > > > > ring->status_page.page_addr) will be lost when the ring is
> > > > > > > > re-initialized.
> > > > > > > > 
> > > > > > > > This patch moves the initialization of the
> > > > > > > > status_page.page_addr value to intel_render_ring_init_dri.
> > > > > > > > 
> > > > > > > > Signed-off-by: Keith Packard 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > > > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > > > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c
> > > > > > > > 100644 --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > > > > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct
> > > > > > > > drm_device *dev)
> > > > > > > > 
> > > > > > > >  static int i915_init_phys_hws(struct drm_device *dev)
> > > > > > > >  {
> > > > > > > 

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Kirill Smelkov]

On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
> On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> > On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > > Keith,
> > > > 
> > > > first of all thanks for your prompt reply. Then...
> > > > 
> > > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov  > > > > mns.spb.ru> 
> wrote:
> > > > > > And now after v3.0 is out, I've tested it again, and yes, like it
> > > > > > was broken on v3.0-rc5, it is (now even more) broken on v3.0 --
> > > > > > after first
> > > > > 
> > > > > > bad io access the system freezes completely:
> > > > > I looked at this when I first saw it (a couple of weeks ago), and I
> > > > > couldn't see any obvious reason this patch would cause this
> > > > > particular problem. I didn't want to revert the patch at that point
> > > > > as I feared it would cause other subtle problems. Given that you've
> > > > > got a work-around, it seemed best to just push this off past 3.0.
> > > > 
> > > > What kind of a workaround are you talking about? Sorry, to me it all
> > > > looked like "UMS is being ignored forever". Anyway, let's move on to
> > > > try to solve the issue.
> > > > 
> > > > > Given the failing address passed to ioread32, this seems like it's
> > > > > probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is
> > > > > 0x21, which is an offset in 32-bit units within the hardware status
> > > > > page. If the status_page.page_addr value was zero, then the computed
> > > > > address would end up being 0x84.
> > > > > 
> > > > > And, it looks like status_page.page_addr *will* end up being zero as
> > > > > a result of the patch in question. The patch resets the entire ring
> > > > > structure contents back to the initial values, which includes
> > > > > smashing the status_page structure to zero, clearing the value of
> > > > > status_page.page_addr set in i915_init_phys_hws.
> > > > > 
> > > > > Here's an untested patch which moves the initialization of
> > > > > status_page.page_addr into intel_render_ring_init_dri. I note that
> > > > > intel_init_render_ring_buffer *already* has the setting of the
> > > > > status_page.page_addr value, and so I've removed the setting of
> > > > > status_page.page_addr from i915_init_phys_hws.
> > > > > 
> > > > > I suspect we could remove the memset from
> > > > > intel_init_render_ring_buffer; it seems entirely superfluous given
> > > > > the memset in i915_init_phys_hws.
> > > > > 
> > > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
> > > > > 2001 From: Keith Packard 
> > > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page address in
> > > > > 
> > > > >  intel_render_ring_init_dri
> > > > > 
> > > > > Physically-addressed hardware status pages are initialized early in
> > > > > the driver load process by i915_init_phys_hws. For UMS environments,
> > > > > the ring structure is not initialized until the X server starts. At
> > > > > that point, the entire ring structure is re-initialized with all new
> > > > > values. Any values set in the ring structure (including
> > > > > ring->status_page.page_addr) will be lost when the ring is
> > > > > re-initialized.
> > > > > 
> > > > > This patch moves the initialization of the status_page.page_addr
> > > > > value to intel_render_ring_init_dri.
> > > > > 
> > > > > Signed-off-by: Keith Packard 
> > > > > ---
> > > > > 
> > > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device
> > > > > *dev)
> > > > > 
> > > > >  static int i915_init_phys_hws(struct drm_device *dev)
> > > > >  {
> > > > >  
> > > > >   drm_i915_private_t *dev_priv = dev->dev_private;
> > > > > 
> > > > > - struct intel_ring_buffer *ring = LP_RING(dev_priv);
> > > > > 
> > > > >   /* Program Hardware Status Page */
> > > > >   dev_priv->status_page_dmah =
> > > > > 
> > > > > @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device
> > > > > *dev)
> > > > > 
> > > > >   DRM_ERROR("Can not allocate hardware status page\n");
> > > > >   return -ENOMEM;
> > > > >   
> > > > >   }
> > > > > 
> > > > > - ring->status_page.page_addr =
> > > > > - (void __force __iomem 
> > > > > *)dev_priv->status_page_dmah->vaddr;
> > > > > 
> > > > > - memset_io(ring->status_page.page_addr, 0, PAGE_SIZE);
> > > > > +

[Bug 25052] kernel modesetting still does not work

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=25052





--- Comment #23 from Alex Deucher   2011-08-09 
18:20:09 ---
Does a newer kernel/ddx/mesa help?  KMS works fine for the vast majority of
radeon users.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Vasily Khoruzhick]

On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote:
> On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote:
> > On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> > > On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > > > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > > > Keith,
> > > > > 
> > > > > first of all thanks for your prompt reply. Then...
> > > > > 
> > > > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > > > > > 
> > 
> > wrote:
> > > > > > > And now after v3.0 is out, I've tested it again, and yes, like
> > > > > > > it was broken on v3.0-rc5, it is (now even more) broken on
> > > > > > > v3.0 -- after first
> > > > > > 
> > > > > > > bad io access the system freezes completely:
> > > > > > I looked at this when I first saw it (a couple of weeks ago), and
> > > > > > I couldn't see any obvious reason this patch would cause this
> > > > > > particular problem. I didn't want to revert the patch at that
> > > > > > point as I feared it would cause other subtle problems. Given
> > > > > > that you've got a work-around, it seemed best to just push this
> > > > > > off past 3.0.
> > > > > 
> > > > > What kind of a workaround are you talking about? Sorry, to me it
> > > > > all looked like "UMS is being ignored forever". Anyway, let's move
> > > > > on to try to solve the issue.
> > > > > 
> > > > > > Given the failing address passed to ioread32, this seems like
> > > > > > it's probably the call to READ_BREADCRUMB --
> > > > > > I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit
> > > > > > units within the hardware status page. If the
> > > > > > status_page.page_addr value was zero, then the computed address
> > > > > > would end up being 0x84.
> > > > > > 
> > > > > > And, it looks like status_page.page_addr *will* end up being zero
> > > > > > as a result of the patch in question. The patch resets the
> > > > > > entire ring structure contents back to the initial values, which
> > > > > > includes smashing the status_page structure to zero, clearing
> > > > > > the value of status_page.page_addr set in i915_init_phys_hws.
> > > > > > 
> > > > > > Here's an untested patch which moves the initialization of
> > > > > > status_page.page_addr into intel_render_ring_init_dri. I note
> > > > > > that intel_init_render_ring_buffer *already* has the setting of
> > > > > > the status_page.page_addr value, and so I've removed the setting
> > > > > > of status_page.page_addr from i915_init_phys_hws.
> > > > > > 
> > > > > > I suspect we could remove the memset from
> > > > > > intel_init_render_ring_buffer; it seems entirely superfluous
> > > > > > given the memset in i915_init_phys_hws.
> > > > > > 
> > > > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
> > > > > > 2001 From: Keith Packard 
> > > > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page
> > > > > > address in
> > > > > > 
> > > > > >  intel_render_ring_init_dri
> > > > > > 
> > > > > > Physically-addressed hardware status pages are initialized early
> > > > > > in the driver load process by i915_init_phys_hws. For UMS
> > > > > > environments, the ring structure is not initialized until the X
> > > > > > server starts. At that point, the entire ring structure is
> > > > > > re-initialized with all new values. Any values set in the ring
> > > > > > structure (including
> > > > > > ring->status_page.page_addr) will be lost when the ring is
> > > > > > re-initialized.
> > > > > > 
> > > > > > This patch moves the initialization of the status_page.page_addr
> > > > > > value to intel_render_ring_init_dri.
> > > > > > 
> > > > > > Signed-off-by: Keith Packard 
> > > > > > ---
> > > > > > 
> > > > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct
> > > > > > drm_device *dev)
> > > > > > 
> > > > > >  static int i915_init_phys_hws(struct drm_device *dev)
> > > > > >  {
> > > > > >  
> > > > > > drm_i915_private_t *dev_priv = dev->dev_private;
> > > > > > 
> > > > > > -   struct intel_ring_buffer *ring = LP_RING(dev_priv);
> > > > > > 
> > > > > > /* Program Hardware Status Page */
> > > > > > dev_priv->status_page_dmah =
> > > > > > 
> > > > > > @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct
> > > > > > drm_device *dev)
> > > > > > 
> > > > > > DRM_ERROR("Can not allocate hardware status page\n");
> > > > > > return -ENOMEM;
> 

[Bug 25052] kernel modesetting still does not work

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=25052





--- Comment #22 from Elmar Stellnberger   2011-08-09 
17:44:18 ---
Any work in progress on this issue? Many people have to fall back to the
proprietary drivers if KMS is not avaiable or functional.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Vasily Khoruzhick]

On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote:
> On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> > On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > > Keith,
> > > 
> > > first of all thanks for your prompt reply. Then...
> > > 
> > > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov  
wrote:
> > > > > And now after v3.0 is out, I've tested it again, and yes, like it
> > > > > was broken on v3.0-rc5, it is (now even more) broken on v3.0 --
> > > > > after first
> > > > 
> > > > > bad io access the system freezes completely:
> > > > I looked at this when I first saw it (a couple of weeks ago), and I
> > > > couldn't see any obvious reason this patch would cause this
> > > > particular problem. I didn't want to revert the patch at that point
> > > > as I feared it would cause other subtle problems. Given that you've
> > > > got a work-around, it seemed best to just push this off past 3.0.
> > > 
> > > What kind of a workaround are you talking about? Sorry, to me it all
> > > looked like "UMS is being ignored forever". Anyway, let's move on to
> > > try to solve the issue.
> > > 
> > > > Given the failing address passed to ioread32, this seems like it's
> > > > probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is
> > > > 0x21, which is an offset in 32-bit units within the hardware status
> > > > page. If the status_page.page_addr value was zero, then the computed
> > > > address would end up being 0x84.
> > > > 
> > > > And, it looks like status_page.page_addr *will* end up being zero as
> > > > a result of the patch in question. The patch resets the entire ring
> > > > structure contents back to the initial values, which includes
> > > > smashing the status_page structure to zero, clearing the value of
> > > > status_page.page_addr set in i915_init_phys_hws.
> > > > 
> > > > Here's an untested patch which moves the initialization of
> > > > status_page.page_addr into intel_render_ring_init_dri. I note that
> > > > intel_init_render_ring_buffer *already* has the setting of the
> > > > status_page.page_addr value, and so I've removed the setting of
> > > > status_page.page_addr from i915_init_phys_hws.
> > > > 
> > > > I suspect we could remove the memset from
> > > > intel_init_render_ring_buffer; it seems entirely superfluous given
> > > > the memset in i915_init_phys_hws.
> > > > 
> > > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00
> > > > 2001 From: Keith Packard 
> > > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > > Subject: [PATCH] drm/i915: Initialize RCS ring status page address in
> > > > 
> > > >  intel_render_ring_init_dri
> > > > 
> > > > Physically-addressed hardware status pages are initialized early in
> > > > the driver load process by i915_init_phys_hws. For UMS environments,
> > > > the ring structure is not initialized until the X server starts. At
> > > > that point, the entire ring structure is re-initialized with all new
> > > > values. Any values set in the ring structure (including
> > > > ring->status_page.page_addr) will be lost when the ring is
> > > > re-initialized.
> > > > 
> > > > This patch moves the initialization of the status_page.page_addr
> > > > value to intel_render_ring_init_dri.
> > > > 
> > > > Signed-off-by: Keith Packard 
> > > > ---
> > > > 
> > > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device
> > > > *dev)
> > > > 
> > > >  static int i915_init_phys_hws(struct drm_device *dev)
> > > >  {
> > > >  
> > > > drm_i915_private_t *dev_priv = dev->dev_private;
> > > > 
> > > > -   struct intel_ring_buffer *ring = LP_RING(dev_priv);
> > > > 
> > > > /* Program Hardware Status Page */
> > > > dev_priv->status_page_dmah =
> > > > 
> > > > @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device
> > > > *dev)
> > > > 
> > > > DRM_ERROR("Can not allocate hardware status page\n");
> > > > return -ENOMEM;
> > > > 
> > > > }
> > > > 
> > > > -   ring->status_page.page_addr =
> > > > -   (void __force __iomem 
> > > > *)dev_priv->status_page_dmah->vaddr;
> > > > 
> > > > -   memset_io(ring->status_page.page_addr, 0, PAGE_SIZE);
> > > > +   memset_io((void __force __iomem
> > > > *)dev_priv->status_page_dmah->vaddr, +0, PAGE_SIZE);
> > > > 
> > > > i915_write_hws_pga(dev);
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > 

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Kirill Smelkov]

On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote:
> On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> > Keith,
> > 
> > first of all thanks for your prompt reply. Then...
> > 
> > On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov  
> > > wrote:
> > > 
> > > > And now after v3.0 is out, I've tested it again, and yes, like it was
> > > > broken on v3.0-rc5, it is (now even more) broken on v3.0 -- after first
> > > > bad io access the system freezes completely:
> > > 
> > > I looked at this when I first saw it (a couple of weeks ago), and I
> > > couldn't see any obvious reason this patch would cause this particular
> > > problem. I didn't want to revert the patch at that point as I feared it
> > > would cause other subtle problems. Given that you've got a work-around,
> > > it seemed best to just push this off past 3.0.
> > 
> > What kind of a workaround are you talking about? Sorry, to me it all
> > looked like "UMS is being ignored forever". Anyway, let's move on to try
> > to solve the issue.
> > 
> > 
> > > Given the failing address passed to ioread32, this seems like it's
> > > probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is 0x21,
> > > which is an offset in 32-bit units within the hardware status page. If
> > > the status_page.page_addr value was zero, then the computed address
> > > would end up being 0x84.
> > > 
> > > And, it looks like status_page.page_addr *will* end up being zero as a
> > > result of the patch in question. The patch resets the entire ring
> > > structure contents back to the initial values, which includes smashing
> > > the status_page structure to zero, clearing the value of
> > > status_page.page_addr set in i915_init_phys_hws.
> > > 
> > > Here's an untested patch which moves the initialization of
> > > status_page.page_addr into intel_render_ring_init_dri. I note that
> > > intel_init_render_ring_buffer *already* has the setting of the
> > > status_page.page_addr value, and so I've removed the setting of
> > > status_page.page_addr from i915_init_phys_hws.
> > > 
> > > I suspect we could remove the memset from intel_init_render_ring_buffer;
> > > it seems entirely superfluous given the memset in i915_init_phys_hws.
> > > 
> > > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001
> > > From: Keith Packard 
> > > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > > Subject: [PATCH] drm/i915: Initialize RCS ring status page address in
> > >  intel_render_ring_init_dri
> > > 
> > > Physically-addressed hardware status pages are initialized early in
> > > the driver load process by i915_init_phys_hws. For UMS environments,
> > > the ring structure is not initialized until the X server starts. At
> > > that point, the entire ring structure is re-initialized with all new
> > > values. Any values set in the ring structure (including
> > > ring->status_page.page_addr) will be lost when the ring is
> > > re-initialized.
> > > 
> > > This patch moves the initialization of the status_page.page_addr value
> > > to intel_render_ring_init_dri.
> > > 
> > > Signed-off-by: Keith Packard 
> > > ---
> > >  drivers/gpu/drm/i915/i915_dma.c |6 ++
> > >  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > > b/drivers/gpu/drm/i915/i915_dma.c
> > > index 1271282..8a3942c 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device *dev)
> > >  static int i915_init_phys_hws(struct drm_device *dev)
> > >  {
> > >   drm_i915_private_t *dev_priv = dev->dev_private;
> > > - struct intel_ring_buffer *ring = LP_RING(dev_priv);
> > >  
> > >   /* Program Hardware Status Page */
> > >   dev_priv->status_page_dmah =
> > > @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device *dev)
> > >   DRM_ERROR("Can not allocate hardware status page\n");
> > >   return -ENOMEM;
> > >   }
> > > - ring->status_page.page_addr =
> > > - (void __force __iomem *)dev_priv->status_page_dmah->vaddr;
> > >  
> > > - memset_io(ring->status_page.page_addr, 0, PAGE_SIZE);
> > > + memset_io((void __force __iomem *)dev_priv->status_page_dmah->vaddr,
> > > +   0, PAGE_SIZE);
> > >  
> > >   i915_write_hws_pga(dev);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index e961568..47b9b27 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -1321,6 +1321,9 @@ int intel_render_ring_init_dri(struct drm_device 
> > > *dev, u64 start, u32 size)
> > >   ring->get_seqno = pc_render_get_seqno;
> > >   }
> > >  
> > > + if (!I915_NEED_GFX_HWS(dev))
> > > + ring->status_page.page_addr = 

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #9 from Siganderson  2011-08-09 14:31:50 PDT 
---
(In reply to comment #8)
> sorry... it's not ubuntu but kubuntu (kde 4.6.7)

uff.. XD
kde 4.7

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #8 from Siganderson  2011-08-09 14:30:56 PDT 
---
sorry... it's not ubuntu but kubuntu (kde 4.6.7)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #7 from Siganderson  2011-08-09 14:29:20 PDT 
---
(In reply to comment #6)

I tried the first option alone and together with the second option. In both
cases the previous performance was not restored.

The test this time was done under ubuntu 11.10 alpha 3 with the 3.0 kernel and
mesa 7.11-devel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: don't enable connectors that are off in the hotplug handler

[alexdeuc...@gmail.com]

From: Alex Deucher 

If we get a hotplug event on an connector that is off, don't
attempt to turn it on or off, it should already be off.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=728228

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/radeon_connectors.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..8365f75 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -54,6 +54,10 @@ void radeon_connector_hotplug(struct drm_connector 
*connector)

radeon_hpd_set_polarity(rdev, radeon_connector->hpd.hpd);

+   /* if the connector is already off, don't turn it back on */
+   if (connector->dpms != DRM_MODE_DPMS_ON)
+   return;
+
/* powering up/down the eDP panel generates hpd events which
 * can interfere with modesetting.
 */
-- 
1.7.1.1

[Bug 36934] screen corruption after running a game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #8 from almos  2011-08-09 12:39:18 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > I observed that this corruption is often accompanied by these messages on 
> > the
> > console from which I start a game:
> 
> What exactly does 'often' mean? If it's not always, it probably can't (fully)
> explain the problem...
Well, 'sometimes' might have been a better word. I don't think it explains the
problem either, just mentioned it for completeness' sake.

> A couple of random things to try would be radeon.agpmode=4 and =-1, disabling
> tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't
> hurt either.
Now I'm using kernel 3.0, compiz runs on mesa 7.10.3, and I start games with
mesa from git. The problem still exists.

The interesting thing is that palettes also seem to be changing: the border
lines of areas in Qt windows change their colors (mostly into purple or green),
the names in the chat window change colors in kopete, and the colors in
gnome-terminal become different (all text become the same color).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=22312


xpressrazor at gmail.com changed:

   What|Removed |Added

 CC||xpressrazor at gmail.com




--- Comment #1 from xpressrazor at gmail.com  2011-08-09 12:20:44 ---
[   15.931030] Linux video capture interface: v2.00
[   15.948984] [drm] radeon defaulting to kernel modesetting.
[   15.948987] [drm] radeon kernel modesetting enabled.
[   15.949030] radeon :01:00.0: enabling device ( -> 0003)
[   15.949040] radeon :01:00.0: found PCI INT A -> IRQ 11
[   15.949046] radeon :01:00.0: sharing IRQ 11 with :00:02.0
[   15.949051] radeon :01:00.0: sharing IRQ 11 with :00:16.0
[   15.949055] radeon :01:00.0: sharing IRQ 11 with :00:1a.0
[   15.949114] radeon :01:00.0: sharing IRQ 11 with :02:00.0
[   15.949126] radeon :01:00.0: setting latency timer to 64
[   15.949409] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6760).
[   15.949466] [drm] register mmio base: 0xE170
[   15.949468] [drm] register mmio size: 131072
[   15.949997] radeon :01:00.0: Invalid ROM contents
[   15.950088] radeon :01:00.0: Invalid ROM contents
[   15.950116] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[   15.950120] radeon :01:00.0: Fatal error during GPU init
[   15.950124] [drm] radeon: finishing device.
[   15.950126] [TTM] Memory type 2 has not been initialized.
[   15.951164] vga_switcheroo: disabled
[   15.951383] radeon: probe of :01:00.0 failed with error -22

I have similar problem. This problem comes in all kernels(2.6.38-8, 2.6.38-10,
3.0.0-0300 and 3.0.1). I have Intel sandy bridge i5 processor.  

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour [AMD Radeon
HD 6470M]

$ lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 04c1
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at e000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour [AMD Radeon
HD 6470M] (prog-if 00 [VGA controller])
Subsystem: Dell Device 04c1
Flags: fast devsel, IRQ 11
Memory at c000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at e170 (64-bit, non-prefetchable) [disabled] [size=128K]
I/O ports at 4000 [disabled] [size=256]
Expansion ROM at e172 [disabled] [size=128K]
Capabilities: 
Kernel modules: radeon

$ uname -r
2.6.38-8-generic

Above 3.0 kernel intel's card seems to work a lot better, but radeon error
comes anyway.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #10 from Klaus Kusche  2011-08-09 
12:17:56 PDT ---
(In reply to comment #9)
> Created an attachment (id=50076)
 View: https://bugs.freedesktop.org/attachment.cgi?id=50076
 Review: https://bugs.freedesktop.org/review?bug=39696=50076

> All other things being equal, sync to the CRTC of the  primary output.
> 
> Does this patch work for making 3D and video synchronize to the primary output
> by default?

Yes, excellent: 
At least for me, the moving tear line is always 
on the display which is *not* primary. 

Even works when switching on-the-fly, for already-running applications.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39162] 3.0.0-r5: ftrace: BUG & OOPS

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=39162


Florian Mickler  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

No subject

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39162] 3.0.0-r5: ftrace: BUG & OOPS

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=39162


Florian Mickler  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #2 from Florian Mickler   2011-08-09 
12:11:59 ---
Merged in v3.1-rc1 ...

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 39162] 3.0.0-r5: ftrace: BUG & OOPS

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=39162





--- Comment #1 from Steven Rostedt   2011-08-09 
11:50:18 ---
We just missed the main release for this fix. Please apply:

commit f7bc8b61f65726ff98f52e286b28e294499d7a08
ftrace: Fix regression where ftrace breaks when modules are loaded

It's already in mainline.

-- Steve

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Ray Lee]

On Tue, Aug 9, 2011 at 10:40 AM, Kirill Smelkov  wrote:
>> If you like, submit a patch. You may now be more up-to-date on those
>> particular code paths than most of the intel-gfx developers.
>
> Ray, I'd agree with you if the topic was about cleanups.

At this point it is about cleanups unless Keith's patch upthread does
not work for you. Does it or not?

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #9 from Michel D?nzer  2011-08-09 10:20:35 
PDT ---
Created an attachment (id=50076)
 View: https://bugs.freedesktop.org/attachment.cgi?id=50076
 Review: https://bugs.freedesktop.org/review?bug=39696=50076

All other things being equal, sync to the CRTC of the  primary output.

Does this patch work for making 3D and video synchronize to the primary output
by default?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Ray Lee]

On Tue, Aug 9, 2011 at 9:32 AM, Kirill Smelkov  wrote:
> Quite frankly, I don't understand intel-gfx developers attitude: why is
> it me, just random user who is nitpicking here? Why there is no
> interest/will to analyze now obviously buggy/duplicate code and fix it?

Because they don't have an infinite amount of manpower.?Actual bugs
hitting actual users take precedence over 'cleanups' which always have
a chance of causing regressions, as you're well aware. Code churn for
the sake of abstract prettiness is discouraged, as it has a potential
cost for little potential gain.

If you like, submit a patch. You may now be more up-to-date on those
particular code paths than most of the intel-gfx developers.

[PATCH] drm: add missing header file

[Alex Deucher]

On Mon, Aug 8, 2011 at 3:22 AM, Amerigo Wang  wrote:
> This patch fixes the following 'make headers_check' errors:
>
> linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type 
> without #include 
> linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type 
> without #include 
> linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type 
> without #include 
> linux-2.6/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type 
> without #include 
> linux-2.6/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type 
> without #include 
>

These files are shared with BSD, and they get the linux/types.h from drm.h.

Alex

> Signed-off-by: WANG Cong 
>
> ---
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index c4961ea..fe8005f 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -81,6 +81,8 @@
> ?#define DRM_MODE_DIRTY_ON ? ? ? 1
> ?#define DRM_MODE_DIRTY_ANNOTATE 2
>
> +#include 
> +
> ?struct drm_mode_modeinfo {
> ? ? ? ?__u32 clock;
> ? ? ? ?__u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index 28c0d11..d7ddd33 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -27,6 +27,7 @@
> ?#ifndef _I915_DRM_H_
> ?#define _I915_DRM_H_
>
> +#include 
> ?#include "drm.h"
>
> ?/* Please note that modifications to all structs defined here are
> diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
> index fca8170..8058ce0 100644
> --- a/include/drm/mga_drm.h
> +++ b/include/drm/mga_drm.h
> @@ -35,6 +35,7 @@
> ?#ifndef __MGA_DRM_H__
> ?#define __MGA_DRM_H__
>
> +#include 
> ?#include "drm.h"
>
> ?/* WARNING: If you change any of these defines, make sure to change the
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index b65be60..f0be4c7 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -33,6 +33,7 @@
> ?#ifndef __RADEON_DRM_H__
> ?#define __RADEON_DRM_H__
>
> +#include 
> ?#include "drm.h"
>
> ?/* WARNING: If you change any of these defines, make sure to change the
> diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
> index fd11a5b..23880b0 100644
> --- a/include/drm/via_drm.h
> +++ b/include/drm/via_drm.h
> @@ -24,6 +24,7 @@
> ?#ifndef _VIA_DRM_H_
> ?#define _VIA_DRM_H_
>
> +#include 
> ?#include "drm.h"
>
> ?/* WARNING: These defines must be the same as what the Xserver uses.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #8 from Michel D?nzer  2011-08-09 09:13:15 
PDT ---
(In reply to comment #7)
> > > Currently both Xv and GL sync to LVDS by default,
> > > no matter which output is primary,
> > > and no matter which CRTC they use: 
> > > Even if DP is primary and CRTC 0, sync is on LVDS.
> > 
> > You might try assigning primary flag to the DP output.
> > xrandr --output DisplayPort-0 --primary
> 
> That's what I tried, but both GL and Xv still sync to LVDS?

I was merely describing an idea for how we could make this work, not how it's
currently working...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #7 from Klaus Kusche  2011-08-09 
09:07:03 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > Doesn't work the way we would like it:
> > * All outputs can be connected to all CRTC's.
> > * Default is LVDS:0, DP: 1
> > * Even if the mode is exactly the same: As soon as I connect the DP to CRTC > > 0
> > using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
> > reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, 
> > but
> > running both from the same CRTC seems to be impossible.
> > 
> > However, according to xrandr -- verbose they are not clones. 
> > How do I set them to clone mode?
> 
> We disable cloning of certain encoders in the driver.  At the hardware level,
> you can source multiple encoders to the same crtc, but there are too many
> encoder specific limitations in most cases that make it hard to support 
> cloning
> from the same crtc.  DP and LVDS are not possible for example as they use
> different clocking for the encoders.  LVDS is direct clocked from the PPLL
> while DP uses fixed clock derived from the DCPLL, so you can't drive both off
> the same crtc easily, at least not the way the driver is currently structured.

That would also explain why I still have a moving tear line even when using
exactly the same modeline on both - their base clock seems to differ slightly.

> > Currently both Xv and GL sync to LVDS by default,
> > no matter which output is primary,
> > and no matter which CRTC they use: 
> > Even if DP is primary and CRTC 0, sync is on LVDS.
> 
> You might try assigning primary flag to the DP output.
> xrandr --output DisplayPort-0 --primary

That's what I tried, but both GL and Xv still sync to LVDS?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #6 from Alex Deucher  2011-08-09 08:56:34 PDT 
---
(In reply to comment #5)
> 
> Doesn't work the way we would like it:
> * All outputs can be connected to all CRTC's.
> * Default is LVDS:0, DP: 1
> * Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
> using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
> reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
> running both from the same CRTC seems to be impossible.
> 
> However, according to xrandr -- verbose they are not clones. 
> How do I set them to clone mode?

We disable cloning of certain encoders in the driver.  At the hardware level,
you can source multiple encoders to the same crtc, but there are too many
encoder specific limitations in most cases that make it hard to support cloning
from the same crtc.  DP and LVDS are not possible for example as they use
different clocking for the encoders.  LVDS is direct clocked from the PPLL
while DP uses fixed clock derived from the DCPLL, so you can't drive both off
the same crtc easily, at least not the way the driver is currently structured.

> 
> Currently both Xv and GL sync to LVDS by default,
> no matter which output is primary,
> and no matter which CRTC they use: 
> Even if DP is primary and CRTC 0, sync is on LVDS.

You might try assigning primary flag to the DP output.
xrandr --output DisplayPort-0 --primary

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #5 from Klaus Kusche  2011-08-09 
07:28:24 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > > > and with synchronized vertical retrace?
> > > 
> > > There's no mechanism for that yet in general. However, if you manage to 
> > > use the
> > > same mode for both displays, you might be able to source both of them off 
> > > the
> > > same CRTC, in which case they should be perfectly synchronized.
> > 
> > Can this be set using xrandr or something else?
> 
> Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs 
> an
> output can use.

Doesn't work the way we would like it:
* All outputs can be connected to all CRTC's.
* Default is LVDS:0, DP: 1
* Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
running both from the same CRTC seems to be impossible.

However, according to xrandr -- verbose they are not clones. 
How do I set them to clone mode?

> > > > 2.) Is there a way to switch 3D and video application sync
> > > > from the internal to the external vsync rate?
> > > 
> > > There's no such mechanism for 3D yet.
> > 
> > From the user's point of view, xvattr would be expected to set both?
> 
> Not sure how xvattr could be expected to affect anything but XVideo.

I didn't mean that I expect xvattr to do that,
I just wanted to say that the average user would expect that a single setting
controls both.

> Some random ideas: All other things being equal, the driver could synchronize
> to the CRTC of the primary output, which can be changed using xrandr 
> --primary.
> Or if that's not good enough, we could add special RandR properties for this.

Currently both Xv and GL sync to LVDS by default,
no matter which output is primary,
and no matter which CRTC they use: 
Even if DP is primary and CRTC 0, sync is on LVDS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #4 from Michel D?nzer  2011-08-09 06:39:31 
PDT ---
(In reply to comment #3)
> > > and with synchronized vertical retrace?
> > 
> > There's no mechanism for that yet in general. However, if you manage to use 
> > the
> > same mode for both displays, you might be able to source both of them off 
> > the
> > same CRTC, in which case they should be perfectly synchronized.
> 
> Can this be set using xrandr or something else?

Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs an
output can use.


> > > 2.) Is there a way to switch 3D and video application sync
> > > from the internal to the external vsync rate?
> > 
> > There's no such mechanism for 3D yet.
> 
> From the user's point of view, xvattr would be expected to set both?

Not sure how xvattr could be expected to affect anything but XVideo.

Some random ideas: All other things being equal, the driver could synchronize
to the CRTC of the primary output, which can be changed using xrandr --primary.
Or if that's not good enough, we could add special RandR properties for this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #3 from Klaus Kusche  2011-08-09 
05:47:04 PDT ---
(In reply to comment #1)
> (In reply to comment #1)
> > KMS always sets sligthly different vertical refresh frequencies: 
> > The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.
> 
> Please attach the Xorg.0.log file, but most likely the external monitor's
> timing is what it specifies as preferred in its EDID.

Attached.
Yes, EDID modes used for both outputs.

> > However, although I only look at the external monitor,
> 
> Then you could switch off the internal display?

Tried that. Works (tearing gone, obviously now syncs to ext monitor).
Could be done when I'm working at my desk,
but is impractical when using a beamer in class 
(in this case, I need the internal display).

> > 1.) Is there a way to run both displays at exactly the same vert frequency
> 
> You could try manually setting the internal display's mode on the external
> monitor (or the other way around, but internal panels are typically pickier).

To my surprise, this *doesn't* work:
I defined a new mode (tried both the external and internal modeline) in xrandr,
assigned it to both outputs, switched both outputs to the new mode
(both LVDS and ext display seem to accept both modelines),
but the tearing is still there.
The sync offset line now moves at a different speed and direction,
but is still clearly visible.

Either the actual settings are not what xrandr believes,
or the base clocks of the CRTC's are different.

By the way, is there an easy way to "take mode 1920x1200" from output X
and assign it to output Y" in xrandr? Or do I have to manually define
a new modeline by cut & paste from Xorg.log and assign it to both?

> > and with synchronized vertical retrace?
> 
> There's no mechanism for that yet in general. However, if you manage to use 
> the
> same mode for both displays, you might be able to source both of them off the
> same CRTC, in which case they should be perfectly synchronized.

Can this be set using xrandr or something else?

> > 2.) Is there a way to switch 3D and video application sync
> > from the internal to the external vsync rate?
> 
> For video, you can use the XV_CRTC attribute to choose which CRTC to sync to
> (see the radeon manpage).

Works using xvattr: The sync offset line is now moving on the internal display.

> There's no such mechanism for 3D yet.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #2 from Klaus Kusche  2011-08-09 
05:29:04 PDT ---
Created an attachment (id=50068)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=50068)
Xorg.log having the problem

Xorg.log with one of the displays having the problem
(similar problem with another display and also external beamer).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #6 from Michel D?nzer  2011-08-09 04:15:45 
PDT ---
(In reply to comment #6)
> 2.6.38 -> 60 to 120 FPS with vsync on

vsync can't actually be effective if the framerate is higher than the refresh
rate...

Does

 Option "EnablePageFlip" "off"

and possibly also

 Option "SwapbuffersWait" "off"

restore the previous performance?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #49061|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #1 from Michel D?nzer  2011-08-09 03:54:57 
PDT ---
(In reply to comment #1)
> KMS always sets sligthly different vertical refresh frequencies: 
> The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.

Please attach the Xorg.0.log file, but most likely the external monitor's
timing is what it specifies as preferred in its EDID.


> However, although I only look at the external monitor,

Then you could switch off the internal display?


> 1.) Is there a way to run both displays at exactly the same vert frequency

You could try manually setting the internal display's mode on the external
monitor (or the other way around, but internal panels are typically pickier).

> and with synchronized vertical retrace?

There's no mechanism for that yet in general. However, if you manage to use the
same mode for both displays, you might be able to source both of them off the
same CRTC, in which case they should be perfectly synchronized.

> 2.) Is there a way to switch 3D and video application sync
> from the internal to the external vsync rate?

For video, you can use the XV_CRTC attribute to choose which CRTC to sync to
(see the radeon manpage).

There's no such mechanism for 3D yet.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36934] screen corruption after running a game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #7 from Michel D?nzer  2011-08-09 03:34:33 
PDT ---
(In reply to comment #6)
> I observed that this corruption is often accompanied by these messages on the
> console from which I start a game:

What exactly does 'often' mean? If it's not always, it probably can't (fully)
explain the problem...

> radeon: mmap failed, errno: 1
> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage

Looks like this app ran out of memory. (errno: 1 means EPERM, not sure how that
can happen...)


> A possibly unrelated question: what happens if the scene to be rendered needs
> more than VRAM+GART amount of data?

It's up to the userspace drivers to split it up into smaller chunks that can
fit.


A couple of random things to try would be radeon.agpmode=4 and =-1, disabling
tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't
hurt either.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36934] screen corruption after running a game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #46677|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36934] screen corruption after running a game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #46676|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36934] screen corruption after running a game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #46675|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39953] Flicker after waking from DPMS sleep

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

--- Comment #2 from Lauri Kasanen  2011-08-09 00:08:56 
PDT ---
Now that I tried to make it happen manually (sleep 1 && xset dpms force off),
it didn't show itself; though for the last few days, it's always happened after
X's 10-minute delay DPMS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39953] Flicker after waking from DPMS sleep

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

--- Comment #1 from Lauri Kasanen  2011-08-09 00:07:30 
PDT ---
Created an attachment (id=50060)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=50060)
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39953] New: Flicker after waking from DPMS sleep

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

   Summary: Flicker after waking from DPMS sleep
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: curaga at operamail.com


Created an attachment (id=50058)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=50058)
lspci -vvnn

My E-350 laptop screen flickers for ~5 minutes every time after waking from
DPMS. The flicker persists through VT switches and changing the power profile
to high.

After the wait it stabilizes and picture is good again.

It looks similar to a CRT on 60Hz, but xrandr is confident the mode is right
for the lcd (60hz, not something lower).


Lenovo G575 laptop
AMD E-350
Linux 3.0.1

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39897] Graphical glitches in some games on Evergreen

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39897

--- Comment #14 from Alex  2011-08-08 23:30:18 
PDT ---
alex at Leon:~/Projects/Games/CrayonPhysicsDeluxe$ LIBGL_DEBUG=verbose 
./launcher

libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so:
cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib/dri-alternates/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri-alternates/r600_dri.so
libGL error: dlopen /usr/lib/dri-alternates/r600_dri.so failed
(/usr/lib/dri-alternates/r600_dri.so: cannot open shared object file: No such
file or directory)
libGL: OpenDriver: trying /usr/lib32/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so


alex at Leon:~$ find / -name "r600_dri.so" 2> /dev/null
/usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so

alex at Leon:~$ file /usr/lib32/dri/r600_dri.so
/usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so:ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib32/dri-alternates/r600_dri.so: ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), dynamically linked, stripped

alex at Leon:~$ md5sum /usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so 
a8b52ca9129e3cc2902f9a9473866972  /usr/lib32/dri-alternates/r600_dri.so
fdef193b5e49473c741f3dbfad0c4737  /usr/lib32/dri/r600_dri.so

alex at Leon:~$ dpkg -S /usr/lib32/dri/r600_dri.so
/usr/lib32/dri-alternates/r600_dri.so
ia32-libs: /usr/lib32/dri/r600_dri.so
ia32-libs: /usr/lib32/dri-alternates/r600_dri.so

alex at Leon:~$ sudo apt-cache show ia32-libs
Package: ia32-libs
Priority: optional
Section: universe/libs
Installed-Size: 193896
Maintainer: Ubuntu Developers 
Original-Maintainer: Debian ia32-libs Team

Architecture: amd64
Version: 20090808ubuntu13
Filename: pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu13_amd64.deb
Origin: Ubuntu

So that's where the issue come from : a very old ia32-libs package.

But on the xorg-edgers home page, there is the following message :
== New in the PPA - 2011/06/30 ==

Multiarch xserver/mesa is in the process of being uploaded to natty and
oneiric, this transition will take some time to work out and it's advised not
to use the PPA if you are using proprietary drivers.

Should I fill a bug anyway ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39897] Graphical glitches in some games on Evergreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39897

--- Comment #14 from Alex cerebro.alex...@gmail.com 2011-08-08 23:30:18 PDT 
---
alex@Leon:~/Projects/Games/CrayonPhysicsDeluxe$ LIBGL_DEBUG=verbose ./launcher
snip
libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so:
cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib/dri-alternates/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri-alternates/r600_dri.so
libGL error: dlopen /usr/lib/dri-alternates/r600_dri.so failed
(/usr/lib/dri-alternates/r600_dri.so: cannot open shared object file: No such
file or directory)
libGL: OpenDriver: trying /usr/lib32/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so
snip

alex@Leon:~$ find / -name r600_dri.so 2 /dev/null
/usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so

alex@Leon:~$ file /usr/lib32/dri/r600_dri.so
/usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so:ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib32/dri-alternates/r600_dri.so: ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), dynamically linked, stripped

alex@Leon:~$ md5sum /usr/lib32/dri-alternates/r600_dri.so
/usr/lib32/dri/r600_dri.so 
a8b52ca9129e3cc2902f9a9473866972  /usr/lib32/dri-alternates/r600_dri.so
fdef193b5e49473c741f3dbfad0c4737  /usr/lib32/dri/r600_dri.so

alex@Leon:~$ dpkg -S /usr/lib32/dri/r600_dri.so
/usr/lib32/dri-alternates/r600_dri.so
ia32-libs: /usr/lib32/dri/r600_dri.so
ia32-libs: /usr/lib32/dri-alternates/r600_dri.so

alex@Leon:~$ sudo apt-cache show ia32-libs
Package: ia32-libs
Priority: optional
Section: universe/libs
Installed-Size: 193896
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
Original-Maintainer: Debian ia32-libs Team
pkg-ia32-libs-maintain...@lists.alioth.debian.org
Architecture: amd64
Version: 20090808ubuntu13
Filename: pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu13_amd64.deb
Origin: Ubuntu

So that's where the issue come from : a very old ia32-libs package.

But on the xorg-edgers home page, there is the following message :
== New in the PPA - 2011/06/30 ==

Multiarch xserver/mesa is in the process of being uploaded to natty and
oneiric, this transition will take some time to work out and it's advised not
to use the PPA if you are using proprietary drivers.

Should I fill a bug anyway ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: add missing header file linuc/types.h

[Amerigo Wang]

This patch fixes the following 'make headers_check' errors:

linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without 
#include linux/types.h
linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without 
#include linux/types.h
linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without 
#include linux/types.h
linux-2.6/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type 
without #include linux/types.h
linux-2.6/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without 
#include linux/types.h

Signed-off-by: WANG Cong amw...@redhat.com

---
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index c4961ea..fe8005f 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -81,6 +81,8 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+#include linux/types.h
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 28c0d11..d7ddd33 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,6 +27,7 @@
 #ifndef _I915_DRM_H_
 #define _I915_DRM_H_
 
+#include linux/types.h
 #include drm.h
 
 /* Please note that modifications to all structs defined here are
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index fca8170..8058ce0 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -35,6 +35,7 @@
 #ifndef __MGA_DRM_H__
 #define __MGA_DRM_H__
 
+#include linux/types.h
 #include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index b65be60..f0be4c7 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -33,6 +33,7 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__
 
+#include linux/types.h
 #include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
index fd11a5b..23880b0 100644
--- a/include/drm/via_drm.h
+++ b/include/drm/via_drm.h
@@ -24,6 +24,7 @@
 #ifndef _VIA_DRM_H_
 #define _VIA_DRM_H_
 
+#include linux/types.h
 #include drm.h
 
 /* WARNING: These defines must be the same as what the Xserver uses.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39953] Flicker after waking from DPMS sleep

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

--- Comment #1 from Lauri Kasanen cur...@operamail.com 2011-08-09 00:07:30 
PDT ---
Created an attachment (id=50060)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=50060)
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39953] Flicker after waking from DPMS sleep

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

--- Comment #2 from Lauri Kasanen cur...@operamail.com 2011-08-09 00:08:56 
PDT ---
Now that I tried to make it happen manually (sleep 1  xset dpms force off),
it didn't show itself; though for the last few days, it's always happened after
X's 10-minute delay DPMS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36934] screen corruption after running a game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #46675|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36934] screen corruption after running a game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #46676|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36934] screen corruption after running a game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #46677|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36934] screen corruption after running a game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #7 from Michel Dänzer mic...@daenzer.net 2011-08-09 03:34:33 PDT 
---
(In reply to comment #6)
 I observed that this corruption is often accompanied by these messages on the
 console from which I start a game:

What exactly does 'often' mean? If it's not always, it probably can't (fully)
explain the problem...

 radeon: mmap failed, errno: 1
 Mesa: User error: GL_OUT_OF_MEMORY in glTexImage

Looks like this app ran out of memory. (errno: 1 means EPERM, not sure how that
can happen...)


 A possibly unrelated question: what happens if the scene to be rendered needs
 more than VRAM+GART amount of data?

It's up to the userspace drivers to split it up into smaller chunks that can
fit.


A couple of random things to try would be radeon.agpmode=4 and =-1, disabling
tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't
hurt either.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-08-09 03:54:57 PDT 
---
(In reply to comment #1)
 KMS always sets sligthly different vertical refresh frequencies: 
 The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.

Please attach the Xorg.0.log file, but most likely the external monitor's
timing is what it specifies as preferred in its EDID.


 However, although I only look at the external monitor,

Then you could switch off the internal display?


 1.) Is there a way to run both displays at exactly the same vert frequency

You could try manually setting the internal display's mode on the external
monitor (or the other way around, but internal panels are typically pickier).

 and with synchronized vertical retrace?

There's no mechanism for that yet in general. However, if you manage to use the
same mode for both displays, you might be able to source both of them off the
same CRTC, in which case they should be perfectly synchronized.

 2.) Is there a way to switch 3D and video application sync
 from the internal to the external vsync rate?

For video, you can use the XV_CRTC attribute to choose which CRTC to sync to
(see the radeon manpage).

There's no such mechanism for 3D yet.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #49061|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-08-09 04:15:45 PDT 
---
(In reply to comment #6)
 2.6.38 - 60 to 120 FPS with vsync on

vsync can't actually be effective if the framerate is higher than the refresh
rate...

Does

 Option EnablePageFlip off

and possibly also

 Option SwapbuffersWait off

restore the previous performance?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39162] 3.0.0-r5: ftrace: BUG OOPS

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=39162





--- Comment #1 from Steven Rostedt rost...@goodmis.org  2011-08-09 11:50:18 
---
We just missed the main release for this fix. Please apply:

commit f7bc8b61f65726ff98f52e286b28e294499d7a08
ftrace: Fix regression where ftrace breaks when modules are loaded

It's already in mainline.

-- Steve

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39162] 3.0.0-r5: ftrace: BUG OOPS

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=39162


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #2 from Florian Mickler flor...@mickler.org  2011-08-09 12:11:59 
---
Merged in v3.1-rc1 ...

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39162] 3.0.0-r5: ftrace: BUG OOPS

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=39162


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=22312


xpressra...@gmail.com changed:

   What|Removed |Added

 CC||xpressra...@gmail.com




--- Comment #1 from xpressra...@gmail.com  2011-08-09 12:20:44 ---
[   15.931030] Linux video capture interface: v2.00
[   15.948984] [drm] radeon defaulting to kernel modesetting.
[   15.948987] [drm] radeon kernel modesetting enabled.
[   15.949030] radeon :01:00.0: enabling device ( - 0003)
[   15.949040] radeon :01:00.0: found PCI INT A - IRQ 11
[   15.949046] radeon :01:00.0: sharing IRQ 11 with :00:02.0
[   15.949051] radeon :01:00.0: sharing IRQ 11 with :00:16.0
[   15.949055] radeon :01:00.0: sharing IRQ 11 with :00:1a.0
[   15.949114] radeon :01:00.0: sharing IRQ 11 with :02:00.0
[   15.949126] radeon :01:00.0: setting latency timer to 64
[   15.949409] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6760).
[   15.949466] [drm] register mmio base: 0xE170
[   15.949468] [drm] register mmio size: 131072
[   15.949997] radeon :01:00.0: Invalid ROM contents
[   15.950088] radeon :01:00.0: Invalid ROM contents
[   15.950116] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[   15.950120] radeon :01:00.0: Fatal error during GPU init
[   15.950124] [drm] radeon: finishing device.
[   15.950126] [TTM] Memory type 2 has not been initialized.
[   15.951164] vga_switcheroo: disabled
[   15.951383] radeon: probe of :01:00.0 failed with error -22

I have similar problem. This problem comes in all kernels(2.6.38-8, 2.6.38-10,
3.0.0-0300 and 3.0.1). I have Intel sandy bridge i5 processor.  

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour [AMD Radeon
HD 6470M]

$ lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 04c1
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at e000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915
Kernel modules: i915

$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour [AMD Radeon
HD 6470M] (prog-if 00 [VGA controller])
Subsystem: Dell Device 04c1
Flags: fast devsel, IRQ 11
Memory at c000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at e170 (64-bit, non-prefetchable) [disabled] [size=128K]
I/O ports at 4000 [disabled] [size=256]
Expansion ROM at e172 [disabled] [size=128K]
Capabilities: access denied
Kernel modules: radeon

$ uname -r
2.6.38-8-generic

Above 3.0 kernel intel's card seems to work a lot better, but radeon error
comes anyway.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #2 from Klaus Kusche klaus.kus...@computerix.info 2011-08-09 
05:29:04 PDT ---
Created an attachment (id=50068)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=50068)
Xorg.log having the problem

Xorg.log with one of the displays having the problem
(similar problem with another display and also external beamer).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #3 from Klaus Kusche klaus.kus...@computerix.info 2011-08-09 
05:47:04 PDT ---
(In reply to comment #1)
 (In reply to comment #1)
  KMS always sets sligthly different vertical refresh frequencies: 
  The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.
 
 Please attach the Xorg.0.log file, but most likely the external monitor's
 timing is what it specifies as preferred in its EDID.

Attached.
Yes, EDID modes used for both outputs.

  However, although I only look at the external monitor,
 
 Then you could switch off the internal display?

Tried that. Works (tearing gone, obviously now syncs to ext monitor).
Could be done when I'm working at my desk,
but is impractical when using a beamer in class 
(in this case, I need the internal display).

  1.) Is there a way to run both displays at exactly the same vert frequency
 
 You could try manually setting the internal display's mode on the external
 monitor (or the other way around, but internal panels are typically pickier).

To my surprise, this *doesn't* work:
I defined a new mode (tried both the external and internal modeline) in xrandr,
assigned it to both outputs, switched both outputs to the new mode
(both LVDS and ext display seem to accept both modelines),
but the tearing is still there.
The sync offset line now moves at a different speed and direction,
but is still clearly visible.

Either the actual settings are not what xrandr believes,
or the base clocks of the CRTC's are different.

By the way, is there an easy way to take mode 1920x1200 from output X
and assign it to output Y in xrandr? Or do I have to manually define
a new modeline by cut  paste from Xorg.log and assign it to both?

  and with synchronized vertical retrace?
 
 There's no mechanism for that yet in general. However, if you manage to use 
 the
 same mode for both displays, you might be able to source both of them off the
 same CRTC, in which case they should be perfectly synchronized.

Can this be set using xrandr or something else?

  2.) Is there a way to switch 3D and video application sync
  from the internal to the external vsync rate?
 
 For video, you can use the XV_CRTC attribute to choose which CRTC to sync to
 (see the radeon manpage).

Works using xvattr: The sync offset line is now moving on the internal display.

 There's no such mechanism for 3D yet.

From the user's point of view, xvattr would be expected to set both?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: add missing header file linuc/types.h

[Alex Deucher]

On Mon, Aug 8, 2011 at 3:22 AM, Amerigo Wang amw...@redhat.com wrote:
 This patch fixes the following 'make headers_check' errors:

 linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type 
 without #include linux/types.h
 linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type 
 without #include linux/types.h
 linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type 
 without #include linux/types.h
 linux-2.6/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type 
 without #include linux/types.h
 linux-2.6/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type 
 without #include linux/types.h


These files are shared with BSD, and they get the linux/types.h from drm.h.

Alex

 Signed-off-by: WANG Cong amw...@redhat.com

 ---
 diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
 index c4961ea..fe8005f 100644
 --- a/include/drm/drm_mode.h
 +++ b/include/drm/drm_mode.h
 @@ -81,6 +81,8 @@
  #define DRM_MODE_DIRTY_ON       1
  #define DRM_MODE_DIRTY_ANNOTATE 2

 +#include linux/types.h
 +
  struct drm_mode_modeinfo {
        __u32 clock;
        __u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index 28c0d11..d7ddd33 100644
 --- a/include/drm/i915_drm.h
 +++ b/include/drm/i915_drm.h
 @@ -27,6 +27,7 @@
  #ifndef _I915_DRM_H_
  #define _I915_DRM_H_

 +#include linux/types.h
  #include drm.h

  /* Please note that modifications to all structs defined here are
 diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
 index fca8170..8058ce0 100644
 --- a/include/drm/mga_drm.h
 +++ b/include/drm/mga_drm.h
 @@ -35,6 +35,7 @@
  #ifndef __MGA_DRM_H__
  #define __MGA_DRM_H__

 +#include linux/types.h
  #include drm.h

  /* WARNING: If you change any of these defines, make sure to change the
 diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
 index b65be60..f0be4c7 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -33,6 +33,7 @@
  #ifndef __RADEON_DRM_H__
  #define __RADEON_DRM_H__

 +#include linux/types.h
  #include drm.h

  /* WARNING: If you change any of these defines, make sure to change the
 diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
 index fd11a5b..23880b0 100644
 --- a/include/drm/via_drm.h
 +++ b/include/drm/via_drm.h
 @@ -24,6 +24,7 @@
  #ifndef _VIA_DRM_H_
  #define _VIA_DRM_H_

 +#include linux/types.h
  #include drm.h

  /* WARNING: These defines must be the same as what the Xserver uses.
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #4 from Michel Dänzer mic...@daenzer.net 2011-08-09 06:39:31 PDT 
---
(In reply to comment #3)
   and with synchronized vertical retrace?
  
  There's no mechanism for that yet in general. However, if you manage to use 
  the
  same mode for both displays, you might be able to source both of them off 
  the
  same CRTC, in which case they should be perfectly synchronized.
 
 Can this be set using xrandr or something else?

Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs an
output can use.


   2.) Is there a way to switch 3D and video application sync
   from the internal to the external vsync rate?
  
  There's no such mechanism for 3D yet.
 
 From the user's point of view, xvattr would be expected to set both?

Not sure how xvattr could be expected to affect anything but XVideo.

Some random ideas: All other things being equal, the driver could synchronize
to the CRTC of the primary output, which can be changed using xrandr --primary.
Or if that's not good enough, we could add special RandR properties for this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #5 from Klaus Kusche klaus.kus...@computerix.info 2011-08-09 
07:28:24 PDT ---
(In reply to comment #4)
 (In reply to comment #3)
and with synchronized vertical retrace?
   
   There's no mechanism for that yet in general. However, if you manage to 
   use the
   same mode for both displays, you might be able to source both of them off 
   the
   same CRTC, in which case they should be perfectly synchronized.
  
  Can this be set using xrandr or something else?
 
 Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs 
 an
 output can use.

Doesn't work the way we would like it:
* All outputs can be connected to all CRTC's.
* Default is LVDS:0, DP: 1
* Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
running both from the same CRTC seems to be impossible.

However, according to xrandr -- verbose they are not clones. 
How do I set them to clone mode?

2.) Is there a way to switch 3D and video application sync
from the internal to the external vsync rate?
   
   There's no such mechanism for 3D yet.
  
  From the user's point of view, xvattr would be expected to set both?
 
 Not sure how xvattr could be expected to affect anything but XVideo.

I didn't mean that I expect xvattr to do that,
I just wanted to say that the average user would expect that a single setting
controls both.

 Some random ideas: All other things being equal, the driver could synchronize
 to the CRTC of the primary output, which can be changed using xrandr 
 --primary.
 Or if that's not good enough, we could add special RandR properties for this.

Currently both Xv and GL sync to LVDS by default,
no matter which output is primary,
and no matter which CRTC they use: 
Even if DP is primary and CRTC 0, sync is on LVDS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #6 from Alex Deucher ag...@yahoo.com 2011-08-09 08:56:34 PDT ---
(In reply to comment #5)
 
 Doesn't work the way we would like it:
 * All outputs can be connected to all CRTC's.
 * Default is LVDS:0, DP: 1
 * Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
 using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
 reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
 running both from the same CRTC seems to be impossible.
 
 However, according to xrandr -- verbose they are not clones. 
 How do I set them to clone mode?

We disable cloning of certain encoders in the driver.  At the hardware level,
you can source multiple encoders to the same crtc, but there are too many
encoder specific limitations in most cases that make it hard to support cloning
from the same crtc.  DP and LVDS are not possible for example as they use
different clocking for the encoders.  LVDS is direct clocked from the PPLL
while DP uses fixed clock derived from the DCPLL, so you can't drive both off
the same crtc easily, at least not the way the driver is currently structured.

 
 Currently both Xv and GL sync to LVDS by default,
 no matter which output is primary,
 and no matter which CRTC they use: 
 Even if DP is primary and CRTC 0, sync is on LVDS.

You might try assigning primary flag to the DP output.
xrandr --output DisplayPort-0 --primary

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #7 from Klaus Kusche klaus.kus...@computerix.info 2011-08-09 
09:07:03 PDT ---
(In reply to comment #6)
 (In reply to comment #5)
  
  Doesn't work the way we would like it:
  * All outputs can be connected to all CRTC's.
  * Default is LVDS:0, DP: 1
  * Even if the mode is exactly the same: As soon as I connect the DP to CRTC   0
  using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
  reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, 
  but
  running both from the same CRTC seems to be impossible.
  
  However, according to xrandr -- verbose they are not clones. 
  How do I set them to clone mode?
 
 We disable cloning of certain encoders in the driver.  At the hardware level,
 you can source multiple encoders to the same crtc, but there are too many
 encoder specific limitations in most cases that make it hard to support 
 cloning
 from the same crtc.  DP and LVDS are not possible for example as they use
 different clocking for the encoders.  LVDS is direct clocked from the PPLL
 while DP uses fixed clock derived from the DCPLL, so you can't drive both off
 the same crtc easily, at least not the way the driver is currently structured.

That would also explain why I still have a moving tear line even when using
exactly the same modeline on both - their base clock seems to differ slightly.

  Currently both Xv and GL sync to LVDS by default,
  no matter which output is primary,
  and no matter which CRTC they use: 
  Even if DP is primary and CRTC 0, sync is on LVDS.
 
 You might try assigning primary flag to the DP output.
 xrandr --output DisplayPort-0 --primary

That's what I tried, but both GL and Xv still sync to LVDS?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #8 from Michel Dänzer mic...@daenzer.net 2011-08-09 09:13:15 PDT 
---
(In reply to comment #7)
   Currently both Xv and GL sync to LVDS by default,
   no matter which output is primary,
   and no matter which CRTC they use: 
   Even if DP is primary and CRTC 0, sync is on LVDS.
  
  You might try assigning primary flag to the DP output.
  xrandr --output DisplayPort-0 --primary
 
 That's what I tried, but both GL and Xv still sync to LVDS?

I was merely describing an idea for how we could make this work, not how it's
currently working...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #9 from Michel Dänzer mic...@daenzer.net 2011-08-09 10:20:35 PDT 
---
Created an attachment (id=50076)
 View: https://bugs.freedesktop.org/attachment.cgi?id=50076
 Review: https://bugs.freedesktop.org/review?bug=39696attachment=50076

All other things being equal, sync to the CRTC of the  primary output.

Does this patch work for making 3D and video synchronize to the primary output
by default?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25052] kernel modesetting still does not work

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=25052





--- Comment #22 from Elmar Stellnberger estel...@gmail.com  2011-08-09 
17:44:18 ---
Any work in progress on this issue? Many people have to fall back to the
proprietary drivers if KMS is not avaiable or functional.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25052] kernel modesetting still does not work

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=25052





--- Comment #23 from Alex Deucher alexdeuc...@gmail.com  2011-08-09 18:20:09 
---
Does a newer kernel/ddx/mesa help?  KMS works fine for the vast majority of
radeon users.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39696

--- Comment #10 from Klaus Kusche klaus.kus...@computerix.info 2011-08-09 
12:17:56 PDT ---
(In reply to comment #9)
 Created an attachment (id=50076)
 View: https://bugs.freedesktop.org/attachment.cgi?id=50076
 Review: https://bugs.freedesktop.org/review?bug=39696attachment=50076

 All other things being equal, sync to the CRTC of the  primary output.
 
 Does this patch work for making 3D and video synchronize to the primary output
 by default?

Yes, excellent: 
At least for me, the moving tear line is always 
on the display which is *not* primary. 

Even works when switching on-the-fly, for already-running applications.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36934] screen corruption after running a game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #8 from almos aaalmo...@gmail.com 2011-08-09 12:39:18 PDT ---
(In reply to comment #7)
 (In reply to comment #6)
  I observed that this corruption is often accompanied by these messages on 
  the
  console from which I start a game:
 
 What exactly does 'often' mean? If it's not always, it probably can't (fully)
 explain the problem...
Well, 'sometimes' might have been a better word. I don't think it explains the
problem either, just mentioned it for completeness' sake.

 A couple of random things to try would be radeon.agpmode=4 and =-1, disabling
 tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't
 hurt either.
Now I'm using kernel 3.0, compiz runs on mesa 7.10.3, and I start games with
mesa from git. The problem still exists.

The interesting thing is that palettes also seem to be changing: the border
lines of areas in Qt windows change their colors (mostly into purple or green),
the names in the chat window change colors in kopete, and the colors in
gnome-terminal become different (all text become the same color).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #7 from Siganderson dj_...@webmail.it 2011-08-09 14:29:20 PDT ---
(In reply to comment #6)

I tried the first option alone and together with the second option. In both
cases the previous performance was not restored.

The test this time was done under ubuntu 11.10 alpha 3 with the 3.0 kernel and
mesa 7.11-devel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #8 from Siganderson dj_...@webmail.it 2011-08-09 14:30:56 PDT ---
sorry... it's not ubuntu but kubuntu (kde 4.6.7)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #9 from Siganderson dj_...@webmail.it 2011-08-09 14:31:50 PDT ---
(In reply to comment #8)
 sorry... it's not ubuntu but kubuntu (kde 4.6.7)

uff.. XD
kde 4.7

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39902] R600g Evergreen: GPU lockup after launch of StarCraft II

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

--- Comment #2 from runetmem...@gmail.com 2011-08-09 21:12:11 PDT ---
You was right, there are probably problem with packaging of x86_64 of the
driver.
https://bugs.freedesktop.org/show_bug.cgi?id=39897#c12
I can not reproduce StarCraft II GPU lockup on pure x86 setup. Works fine on
low settings by the way.

But now I have another lockup-problem when I try to launch Bioshock or Metro
2033. 
How to reproduce:
1. Install Bioshock demo: http://www.gamefront.com/files/8363410
2. Launch Bioshock. Wait few seconds.
3. Switch to any other text console, and after that switch back to graphics
console.
So now you should able to get GPU lockup. Log attached.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

runetmem...@gmail.com changed:

   What|Removed |Added

Summary|R600g Evergreen: GPU lockup |R600g Evergreen: GPU lockup
   |after launch of StarCraft   |after launch of Bioshock
   |II  |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39902

--- Comment #3 from runetmem...@gmail.com 2011-08-09 21:13:02 PDT ---
Created an attachment (id=50086)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=50086)
Example of error message

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel