[MMTests] IO metadata on XFS

Adding dri-devel and a few others because an i915 patch contributed to the regression. On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote: > On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote: > > > It increases the CPU overhead (dirty_inode can be called up to 4 > > >

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #29 from Daniel Vetter 2012-07-02 13:29:18 PDT --- (In reply to comment #28) > are there any news on this issue? > The 3.4 and 3.5-rc series seem stable wrt this issue, > but unfortunately something broke resume from s2ram badly, >

[Bug 28622] radeon video lockup

https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #11 from Alex Deucher 2012-07-02 20:21:02 --- Is this still an issue with a more recent kernel (3.x)? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because:

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #28 from stefan 2012-07-02 13:13:59 PDT --- Hi, are there any news on this issue? The 3.4 and 3.5-rc series seem stable wrt this issue, but unfortunately something broke resume from s2ram badly, the backlight stays off and the

[PATCH] drm/radeon: add an exclusive lock for GPU reset

On 02.07.2012 18:41, Jerome Glisse wrote: > On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig > wrote: >> On 02.07.2012 17:39, j.glisse at gmail.com wrote: >>> From: Jerome Glisse >>> >>> GPU reset need to be exclusive, one happening at a time. For this >>> add a rw semaphore so that any path

[PATCH] drm/radeon: add an exclusive lock for GPU reset

On 02.07.2012 17:39, j.glisse at gmail.com wrote: > From: Jerome Glisse > > GPU reset need to be exclusive, one happening at a time. For this > add a rw semaphore so that any path that trigger GPU activities > have to take the semaphore as a reader thus allowing concurency. > > The GPU reset path

[RFC v2] implicit drm synchronization wip with dma-buf

Well, V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain some nice code. My goal was to extend dma-buf in a generic way now, some elements from v1 are remaining, most notably a dma-buf used for syncing. However it is expected now that dma-buf syncing will work in a

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #8 from Eugene St Leger 2012-07-02 11:04:54 PDT --- A summary of all of the patches follows. r200 essential patches (1st 3 patches) for gnome shell: "Essential patch to disable texture formats that are reported unrenderable

[PATCH 1/3] drm/radeon: move ring locking out of reset path

On 02.07.2012 17:41, Jerome Glisse wrote: > On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer wrote: >> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote: >>> On 29.06.2012 17:09, Michel D?nzer wrote: On Fre, 2012-06-29 at 16:45 +0200, Christian K?nig wrote: > Hold the ring lock the

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #7 from Eugene St Leger 2012-07-02 10:51:10 PDT --- Created attachment 63718 --> https://bugs.freedesktop.org/attachment.cgi?id=63718 Optional untested patch to warn (once) when a blit with 2048 pixel dimension occurs on r100. If

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #6 from Eugene St Leger 2012-07-02 10:49:07 PDT --- Created attachment 63717 --> https://bugs.freedesktop.org/attachment.cgi?id=63717 Untested but probably essential patch to allow 2048 pixel blits on r100. Without this patch,

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #4 from Eugene St Leger 2012-07-02 10:40:51 PDT --- Created attachment 63715 --> https://bugs.freedesktop.org/attachment.cgi?id=63715 Proposed blit register dirtying patch. It appears bliting dirties some registers without

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #3 from Eugene St Leger 2012-07-02 10:37:47 PDT --- Created attachment 63714 --> https://bugs.freedesktop.org/attachment.cgi?id=63714 Unessential fixes/enhancements patch. Minor spelling fixes & enhancements. -- Configure

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #2 from Eugene St Leger 2012-07-02 10:34:41 PDT --- Created attachment 63713 --> https://bugs.freedesktop.org/attachment.cgi?id=63713 Essential patch to reapply dirtied texenv registers. Without this patch, colour corruption

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #1 from Eugene St Leger 2012-07-02 10:29:44 PDT --- Created attachment 63712 --> https://bugs.freedesktop.org/attachment.cgi?id=63712 Essential patch to allow 2048 pixel blits. Without this patch, gnome shell crashes. 2048 pixel

[Bug 51658] New: r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 Bug #: 51658 Summary: r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3 Classification: Unclassified Product: Mesa Version: 8.0 Platform: All

[PATCH] staging: drm/omap: add rotation properties

On Fri, Jun 29, 2012 at 07:17:23AM -0500, Rob Clark wrote: > On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen > wrote: > > On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: > >> From: Rob Clark > >> > >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane > >> properties as

[PATCH v3] DRM: Add DRM kms/fb cma helper

This patchset introduces a set of helper function for implementing the KMS framebuffer layer for drivers which use the drm gem CMA helper function. Signed-off-by: Lars-Peter Clausen --- Note: This patch depends on Sascha's "DRM: add drm gem CMA helper" patch Changes since v2: * Adapt

[PATCH] drm/radeon: fix rare segfault

On Mon, Jul 2, 2012 at 12:40 PM, wrote: > From: Jerome Glisse > > In gem idle/busy ioctl the radeon object was derefenced after > drm_gem_object_unreference_unlocked which in case the object > have been destroyed lead to use of a possibly free pointer with > possibly wrong data. > >

Bogus video resolution in Linux 3.5-rc4

On 6/26/12 3:21 AM, Takashi Iwai wrote: > From: Takashi Iwai > Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution > > When a monitor EDID doesn't give the preferred bit, driver assumes > that the mode with the higest resolution and rate is the preferred > mode.

[PATCH libdrm] intel: Fix build failure in test_decode.c

On Sat, 30 Jun 2012 13:12:45 +0300 Lauri Kasanen wrote: > Hi list > > The recently released libdrm 2.4.37 does not compile the Intel part: > > test_decode.c: In function 'compare_batch': > test_decode.c:107: error: implicit declaration of function 'open_memstream' > > PS: Please CC me. > >

[PATCH 1/3] pci_regs: define LNKSTA2 pcie cap + bits.

On Thu, Jun 28, 2012 at 3:45 AM, Dave Airlie wrote: > On Wed, Jun 27, 2012 at 8:35 AM, Dave Airlie wrote: >> From: Dave Airlie >> >> We need these for detecting the max link speed for drm drivers. > > Hi Bjorn, > > Can you ack this patch so I can carry it in the drm-next tree? we need > these

[Bug 28622] radeon video lockup

https://bugzilla.kernel.org/show_bug.cgi?id=28622 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Kernel

[PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 1:05 PM, Christian K?nig wrote: > On 02.07.2012 18:41, Jerome Glisse wrote: >> >> On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig >> wrote: >>> >>> On 02.07.2012 17:39, j.glisse at gmail.com wrote: From: Jerome Glisse GPU reset need to be exclusive,

[PATCH, RFC] i.MX DRM support

On 02.07.2012 12:05, Sascha Hauer wrote: > On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: >> Hi All, >> >> The following is the state-of-the-art i.MX IPU (Image Processing Unit) >> DRM support. >> >> This code is around for quite some time now and has been posted several >> times

[Bug 51652] New: [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups

https://bugs.freedesktop.org/show_bug.cgi?id=51652 Bug #: 51652 Summary: [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups Classification: Unclassified Product: DRI Version: XOrg CVS Platform:

[PATCH] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[PATCH 01/10] drm/radeon: document radeon_device.c (v2)

On 29.06.2012 18:50, alexdeucher at gmail.com wrote: > From: Alex Deucher > > Adds documentation to most of the functions in > radeon_device.c > > v2: split out general descriptions as per Christian's > comments. > > Signed-off-by: Alex Deucher For the whole series: Reviewed-by: Christian K?nig

[PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig wrote: > On 02.07.2012 17:39, j.glisse at gmail.com wrote: >> >> From: Jerome Glisse >> >> GPU reset need to be exclusive, one happening at a time. For this >> add a rw semaphore so that any path that trigger GPU activities >> have to take the

[PATCH] drm/radeon: fix rare segfault

From: Jerome Glisse In gem idle/busy ioctl the radeon object was derefenced after drm_gem_object_unreference_unlocked which in case the object have been destroyed lead to use of a possibly free pointer with possibly wrong data. Signed-off-by: Jerome Glisse ---

[PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 11:39 AM, wrote: > From: Jerome Glisse > > GPU reset need to be exclusive, one happening at a time. For this > add a rw semaphore so that any path that trigger GPU activities > have to take the semaphore as a reader thus allowing concurency. > > The GPU reset path take

[PATCH 1/3] drm/radeon: move ring locking out of reset path

On Mon, Jul 2, 2012 at 11:58 AM, Christian K?nig wrote: > On 02.07.2012 17:41, Jerome Glisse wrote: >> >> On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer >> wrote: >>> >>> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote: On 29.06.2012 17:09, Michel D?nzer wrote: > > On

[PATCH, RFC] i.MX DRM support

On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: > Hi All, > > The following is the state-of-the-art i.MX IPU (Image Processing Unit) > DRM support. > > This code is around for quite some time now and has been posted several > times with different APIs, first with plain old

[PATCH 1/3] drm/radeon: move ring locking out of reset path

On Mon, Jul 2, 2012 at 11:58 AM, Christian K?nig wrote: > On 02.07.2012 17:41, Jerome Glisse wrote: >> >> On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer >> wrote: >>> >>> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote: On 29.06.2012 17:09, Michel D?nzer wrote: > > On

gma500 suspend to ram fails (3.4)

On Mon, 2 Jul 2012 07:06:59 +0900 Mattia Dongili wrote: > On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote: > > On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote: > > > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote: > > > > On Sun, Jun 17, 2012 at

[PATCH 1/3] drm/radeon: move ring locking out of reset path

On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer wrote: > On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote: >> On 29.06.2012 17:09, Michel D?nzer wrote: >> > On Fre, 2012-06-29 at 16:45 +0200, Christian K?nig wrote: >> >> Hold the ring lock the whole time the reset is in progress, >> >>

[PATCH] drm/radeon: add an exclusive lock for GPU reset

From: Jerome Glisse GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #5 from Eugene St Leger 2012-07-02 10:45:01 UTC --- Created attachment 63716 --> https://bugs.freedesktop.org/attachment.cgi?id=63716 Optional patch to warn (once) when a blit with 2048 pixel dimension occurs on r200. If 2048

gma500 suspend to ram fails (3.4)

On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote: > On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote: > > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote: > > > On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili > > > wrote: > ... > > > If possible, add

Re: [PATCH, RFC] i.MX DRM support

On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: Hi All, The following is the state-of-the-art i.MX IPU (Image Processing Unit) DRM support. This code is around for quite some time now and has been posted several times with different APIs, first with plain old framebuffer

Re: gma500 suspend to ram fails (3.4)

On Mon, 2 Jul 2012 07:06:59 +0900 Mattia Dongili malat...@linux.it wrote: On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote: On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote: On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote: On Sun, Jun 17,

Re: [PATCH 01/10] drm/radeon: document radeon_device.c (v2)

On 29.06.2012 18:50, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com Adds documentation to most of the functions in radeon_device.c v2: split out general descriptions as per Christian's comments. Signed-off-by: Alex Deucher alexander.deuc...@amd.com For the whole

[Bug 51652] New: [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups

https://bugs.freedesktop.org/show_bug.cgi?id=51652 Bug #: 51652 Summary: [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups Classification: Unclassified Product: DRI Version: XOrg CVS Platform:

[Bug 28622] radeon video lockup

https://bugzilla.kernel.org/show_bug.cgi?id=28622 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk

Re: [PATCH] staging: drm/omap: add rotation properties

On Fri, Jun 29, 2012 at 07:17:23AM -0500, Rob Clark wrote: On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Use tiled buffers for rotated/reflected scanout, with CRTC and plane

[PATCH v3] DRM: Add DRM kms/fb cma helper

This patchset introduces a set of helper function for implementing the KMS framebuffer layer for drivers which use the drm gem CMA helper function. Signed-off-by: Lars-Peter Clausen l...@metafoo.de --- Note: This patch depends on Sascha's DRM: add drm gem CMA helper patch Changes since v2:

Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path

On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: On 29.06.2012 17:09, Michel Dänzer wrote: On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: Hold the ring lock the whole time the reset is in progress,

[PATCH] drm/radeon: add an exclusive lock for GPU reset

From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

Re: gma500 suspend to ram fails (3.4)

On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote: On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote: On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote: On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili malat...@linux.it wrote: ... If possible,

Re: [PATCH, RFC] i.MX DRM support

On 02.07.2012 12:05, Sascha Hauer wrote: On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: Hi All, The following is the state-of-the-art i.MX IPU (Image Processing Unit) DRM support. This code is around for quite some time now and has been posted several times with different APIs,

Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path

On 02.07.2012 17:41, Jerome Glisse wrote: On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: On 29.06.2012 17:09, Michel Dänzer wrote: On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: Hold the ring lock

Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path

On Mon, Jul 2, 2012 at 11:58 AM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 17:41, Jerome Glisse wrote: On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: On 29.06.2012 17:09, Michel Dänzer

[RFC v2] implicit drm synchronization wip with dma-buf

Well, V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain some nice code. My goal was to extend dma-buf in a generic way now, some elements from v1 are remaining, most notably a dma-buf used for syncing. However it is expected now that dma-buf syncing will work in a

Re: [PATCH 1/3] drm/radeon: move ring locking out of reset path

On Mon, Jul 2, 2012 at 11:58 AM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 17:41, Jerome Glisse wrote: On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: On 29.06.2012 17:09, Michel Dänzer

Re: [PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 11:39 AM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency.

Re: [PATCH] drm/radeon: add an exclusive lock for GPU reset

On 02.07.2012 17:39, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset

Re: [PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 12:26 PM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 17:39, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU

[PATCH] drm/radeon: fix rare segfault

From: Jerome Glisse jgli...@redhat.com In gem idle/busy ioctl the radeon object was derefenced after drm_gem_object_unreference_unlocked which in case the object have been destroyed lead to use of a possibly free pointer with possibly wrong data. Signed-off-by: Jerome Glisse jgli...@redhat.com

[PATCH] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

Re: [PATCH] drm/radeon: add an exclusive lock for GPU reset

On 02.07.2012 18:41, Jerome Glisse wrote: On Mon, Jul 2, 2012 at 12:26 PM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 17:39, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore

Re: [PATCH] drm/radeon: add an exclusive lock for GPU reset

On Mon, Jul 2, 2012 at 1:05 PM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 18:41, Jerome Glisse wrote: On Mon, Jul 2, 2012 at 12:26 PM, Christian König deathsim...@vodafone.de wrote: On 02.07.2012 17:39, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #1 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:29:44 PDT --- Created attachment 63712 -- https://bugs.freedesktop.org/attachment.cgi?id=63712 Essential patch to allow 2048 pixel blits. Without this patch, gnome shell

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #2 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:34:41 PDT --- Created attachment 63713 -- https://bugs.freedesktop.org/attachment.cgi?id=63713 Essential patch to reapply dirtied texenv registers. Without this patch, colour

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #3 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:37:47 PDT --- Created attachment 63714 -- https://bugs.freedesktop.org/attachment.cgi?id=63714 Unessential fixes/enhancements patch. Minor spelling fixes enhancements. --

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #4 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:40:51 PDT --- Created attachment 63715 -- https://bugs.freedesktop.org/attachment.cgi?id=63715 Proposed blit register dirtying patch. It appears bliting dirties some registers

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #5 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:45:01 UTC --- Created attachment 63716 -- https://bugs.freedesktop.org/attachment.cgi?id=63716 Optional patch to warn (once) when a blit with 2048 pixel dimension occurs on

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #6 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:49:07 PDT --- Created attachment 63717 -- https://bugs.freedesktop.org/attachment.cgi?id=63717 Untested but probably essential patch to allow 2048 pixel blits on r100. Without

[Bug 51658] r200 ( possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3

https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #7 from Eugene St Leger gri...@yahoo.com 2012-07-02 10:51:10 PDT --- Created attachment 63718 -- https://bugs.freedesktop.org/attachment.cgi?id=63718 Optional untested patch to warn (once) when a blit with 2048 pixel dimension

Re: Bogus video resolution in Linux 3.5-rc4

On 6/26/12 3:21 AM, Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution When a monitor EDID doesn't give the preferred bit, driver assumes that the mode with the higest resolution and rate is the preferred mode.

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #28 from stefan fdo.12.ben...@xoxy.net 2012-07-02 13:13:59 PDT --- Hi, are there any news on this issue? The 3.4 and 3.5-rc series seem stable wrt this issue, but unfortunately something broke resume from s2ram badly, the backlight

[Bug 28622] radeon video lockup

https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #11 from Alex Deucher alexdeuc...@gmail.com 2012-07-02 20:21:02 --- Is this still an issue with a more recent kernel (3.x)? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving

Re: [PATCH] drm/radeon: fix rare segfault

On Mon, Jul 2, 2012 at 12:40 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com In gem idle/busy ioctl the radeon object was derefenced after drm_gem_object_unreference_unlocked which in case the object have been destroyed lead to use of a possibly free pointer with

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #29 from Daniel Vetter dan...@ffwll.ch 2012-07-02 13:29:18 PDT --- (In reply to comment #28) are there any news on this issue? The 3.4 and 3.5-rc series seem stable wrt this issue, but unfortunately something broke resume from

Re: [PATCH libdrm] intel: Fix build failure in test_decode.c

On Sat, 30 Jun 2012 13:12:45 +0300 Lauri Kasanen c...@gmx.com wrote: Hi list The recently released libdrm 2.4.37 does not compile the Intel part: test_decode.c: In function 'compare_batch': test_decode.c:107: error: implicit declaration of function 'open_memstream' PS: Please CC me.