[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

https://bugzilla.kernel.org/show_bug.cgi?id=48941 Igor Murzov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers

2012. 11. 3. ?? 9:21 Rahul Sharma ??: > This patch fixes the problem of mapping contigous dma buffers. Currently page > struct is calculated from the buf->dma_addr which is not the physical address. > It is replaced by buf->pages which points to the page struct of the first page > of

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

https://bugzilla.kernel.org/show_bug.cgi?id=48941 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/7015d7ee/attachment.html>

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/39e5eb6a/attachment.html>

[Bug 56788] New: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/15747cc0/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

s mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/b3edd9fd/attachment.html>

[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)

dri-devel/attachments/20121105/48a9a737/attachment.html>

[bisected] drm i915 hangs on heavy io load

On Sunday 04 November 2012 16:08:47 Dave Airlie wrote: > On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining > wrote: > > On Di, 30 Okt 2012, Dave Airlie wrote: > >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 > >> final to 3.7-rc1 or maybe -rc2. > > > > Sorry for my

[PATCH] drm: exynos: fix for mapping of dma buffers

This patch fixes the problem of mapping contigous and non contigous dma buffers. Currently page struct is calculated from the buf->dma_addr which is not the physical address. It is replaced by buf->pages which points to the page struct of the first page of contigous memory chunk. This gives the

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/a08cad9d/attachment.html>

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/3a4df1cb/attachment-0001.html>

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

nel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/23436beb/attachment.html>

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

Alex Deucher wrote: > On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote: >> Alex Deucher wrote: >>> >>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, 5 Nov 2012 08:40:38 + Dave Airlie wrote: > On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite > wrote: > > On Mon, 29 Oct 2012 23:16:24 +0100 > > Antonio Ospite wrote: > > > >> Hi, > >> > >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > >> my video adapter

merging printk and WARN

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote: > It looks like these patches were not a good idea, because in each case the > printk provides an error level, and WARN then provides another one. I think this is not a problem within btrfs at the place where this has changed. david

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/ce8d9998/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

on DCE6 chips. On DCE6, the the memory controller request bit is now tied in with the crtc blanking bit. When the crtc is blanked, memory requests are also disabled. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f62d09d7/attachment.html>

[PATCH 4/4] drm/ttm: Optimize reservation slightly

On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: > Hey, > > Op 05-11-12 14:31, Thomas Hellstrom schreef: >> Reservation locking currently always takes place under the LRU spinlock. >> Hence, strictly there is no need for an atomic_cmpxchg call; we can use >> atomic_read followed by atomic_write

[PATCH 4/4] drm/ttm: Optimize reservation slightly

Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: > Reservation locking currently always takes place under the LRU spinlock. > Hence, strictly there is no need for an atomic_cmpxchg call; we can use > atomic_read followed by atomic_write since nobody else will ever reserve > without the lru

[PATCH 4/4] drm/ttm: Optimize reservation slightly

Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2

The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu synchronization is needed at module unload time. v2:

[PATCH 2/4] kref: Implement kref_get_unless_zero v2

This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock

[PATCH 1/4] drm: Make hashtab rcu-safe

TTM base objects will be the first consumer. Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/drm_hashtab.c | 18 +++--- 1 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c index c3745c4..5729e39 100644

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2

A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

hen I'll get home tonight. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/c151856a/attachment.html>

[PATCH] drm/exynos: add userptr feature for g2d module

This patch adds userptr feautre for G2D module. The userptr means user space address allocated by malloc(). And the purpose of this feature is to make G2D's dma able to access the user space region. To user this feature, user should flag G2D_BUF_USRPTR to offset variable of struct

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

On 11/05/2012 02:31 PM, Thomas Hellstrom wrote: > The mostly used lookup+get put+potential_destroy path of TTM objects > is converted to use RCU locks. This will substantially decrease the amount > of locked bus cycles during normal operation. > Since we use kfree_rcu to free the objects, no rcu

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

This patch adds iommu support for hdmi driver with device tree based search. It searches for sysmmu property in hdmi dt node to get tv iommu device pointer which will be used to configure iommu hw interface. This patch is based on "exynos-drm-next-iommu" branch at

[PATCH 4/4] drm/ttm: Optimize reservation slightly

Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu synchronization is needed at module unload time.

[PATCH 2/4] kref: Implement kref_get_unless_zero

This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock

[PATCH 1/4] drm: Make hashtab rcu-safe

TTM base objects will be the first consumer. Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/drm_hashtab.c | 18 +++--- 1 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c index c3745c4..5729e39 100644

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops

A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/42dbed96/attachment.html>

[Bug 17511] Display no longer works with KMS enabled

https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.

https://bugzilla.kernel.org/show_bug.cgi?id=16065 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk --- Comment #2

[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

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

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

oved vram, we can re-enable the clients (mc_resume()) so that they point to the new vram location. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f777c29e/attachment.html>

[PATCH v4] drm/exynos: add iommu support for exynos drm framework

Changelog v4: - fix condition to drm_iommu_detach_device funtion. Changelog v3: - add dma_parms->max_segment_size setting of drm_device->dev. - use devm_kzalloc instead of kzalloc. Changelog v2: - fix iommu attach condition. . check archdata.dma_ops of drm device instead of subdrv device's

[PATCH] drm/radeon: fix typo in evergreen_mc_resume()

From: Alex Deucher Add missing index that may have led us to enabling more crtcs than necessary. May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/evergreen.c |2

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

-a-helper-f.patch 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch 0003-drm-radeon-disable-the-pll-before-a-modeset.patch Can you see if the second set helps? If not, please try the first patch. Alex -- next part -- A non-text attachment was scrubbed... Name:

[PATCH v7 8/8] drm_modes: add of_videomode helpers

. Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/41cb8434/attachment.pgp>

drm i915 hangs on heavy io load

On So, 04 Nov 2012, Dave Airlie wrote: > Yeah thats fine, bisecting works by going to where commits were > originally committed, so drm-intel-next was 3.6.0-rc2 at some point > was only merged into Linus later. Ok, thanks, didn't know that. Have started the bisect game now, coming back in about 1

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite wrote: > Hi, > > I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > my video adapter is the one integrated on the MSI M3N78-VM motherboard > (hence x86_64): > [...] > [ 1943.858601] BUG: unable to handle kernel paging

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite wrote: > On Mon, 29 Oct 2012 23:16:24 +0100 > Antonio Ospite wrote: > >> Hi, >> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), >> my video adapter is the one integrated on the MSI M3N78-VM motherboard >> (hence x86_64):

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: >>> But even then, choosing the manager is not easy, as whoever chooses the >>> >>manager needs to observe all the possible displays used at the same >>> >>time... >> > >> >Right. I was wondering if omapfb/omapdrm could understand the 'all >> >possible

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

.org/archives/dri-devel/attachments/20121105/ab1a6c11/attachment-0001.html>

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), my video adapter is the one integrated on the MSI M3N78-VM motherboard (hence x86_64): [...] [ 1943.858601] BUG: unable to handle

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), my video adapter is the one integrated on the MSI

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops

A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and

[PATCH 2/4] kref: Implement kref_get_unless_zero

This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu synchronization is needed at module unload time.

[PATCH 4/4] drm/ttm: Optimize reservation slightly

Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

Re: [PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

On 11/05/2012 02:31 PM, Thomas Hellstrom wrote: The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2

A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and

[PATCH 1/4] drm: Make hashtab rcu-safe

TTM base objects will be the first consumer. Signed-off-by: Thomas Hellstrom thellst...@vmware.com --- drivers/gpu/drm/drm_hashtab.c | 18 +++--- 1 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c index

[PATCH 2/4] kref: Implement kref_get_unless_zero v2

This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2

The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu synchronization is needed at module unload time. v2:

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #12 from Alex Deucher ag...@yahoo.com --- (In reply to comment #11) Found what is wrong with the help of a few printk and by comparing to the code being replaced. All the logic is good (going through crtc, disabling them, waiting

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

This patch adds iommu support for hdmi driver with device tree based search. It searches for sysmmu property in hdmi dt node to get tv iommu device pointer which will be used to configure iommu hw interface. This patch is based on exynos-drm-next-iommu branch at

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody

[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

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

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

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

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.

https://bugzilla.kernel.org/show_bug.cgi?id=16065 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers

2012. 11. 3. 오후 9:21 Rahul Sharma rahul.sha...@samsung.com 작성: This patch fixes the problem of mapping contigous dma buffers. Currently page struct is calculated from the buf-dma_addr which is not the physical address. It is replaced by buf-pages which points to the page struct of the

[Bug 17511] Display no longer works with KMS enabled

https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #13 from Alex Deucher ag...@yahoo.com --- Created attachment 69564 -- https://bugs.freedesktop.org/attachment.cgi?id=69564action=edit possible fix Slightly adjusted wait for vblank function. Maybe this will help? -- You are

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #14 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #12) (In reply to comment #11) Found what is wrong with the help of a few printk and by comparing to the code being replaced. All the logic is good

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

This patch adds iommu support for hdmi driver with device tree based search. It searches for sysmmu property in hdmi dt node to get tv iommu device pointer which will be used to configure iommu hw interface. This patch is based on exynos-drm-next-iommu branch at

[PATCH] drm: exynos: fix for mapping of dma buffers

This patch fixes the problem of mapping contigous and non contigous dma buffers. Currently page struct is calculated from the buf-dma_addr which is not the physical address. It is replaced by buf-pages which points to the page struct of the first page of contigous memory chunk. This gives the

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote: Alex Deucher wrote: On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

On Mon, 5 Nov 2012 08:40:38 + Dave Airlie airl...@gmail.com wrote: On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I am experiencing a bug with nouveau with

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #15 from Alex Deucher ag...@yahoo.com --- (In reply to comment #14) (In reply to comment #12) (In reply to comment #11) Found what is wrong with the help of a few printk and by comparing to the code being replaced. All the

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #16 from Alex Deucher ag...@yahoo.com --- Created attachment 69573 -- https://bugs.freedesktop.org/attachment.cgi?id=69573action=edit possible fix Actually, I think I found the problem. Missing index in mc_resume(). -- You are

[PATCH] drm/radeon: fix typo in evergreen_mc_resume()

From: Alex Deucher alexander.deuc...@amd.com Add missing index that may have led us to enabling more crtcs than necessary. May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 Signed-off-by: Alex Deucher alexander.deuc...@amd.com Cc: sta...@vger.kernel.org ---

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

Alex Deucher wrote: On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote: Alex Deucher wrote: On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

https://bugs.freedesktop.org/show_bug.cgi?id=56081 Tony Thomas autonym...@gmail.com changed: What|Removed |Added Attachment #68684|0 |1 is obsolete|

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

https://bugs.freedesktop.org/show_bug.cgi?id=56081 --- Comment #10 from Tony Thomas autonym...@gmail.com --- Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux), failures and corruption DO NOT prevent VT-switching as the 9.0 branch does. -- You are receiving this mail

[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)

https://bugs.freedesktop.org/show_bug.cgi?id=53130 --- Comment #3 from Darren Salt bugs...@moreofthesa.me.uk --- I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I suspect that DISCARD_RANGE being re-enabled is the problem, although I've also built and installed an

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #17 from Alexandre Demers alexandre.f.dem...@gmail.com --- I'm about to test patches. But before, as promised, here are the values retrieved read and written to the registers. By the way, I have only a single monitor. tmp =

[Bug 56788] New: [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

https://bugs.freedesktop.org/show_bug.cgi?id=56788 Priority: medium Bug ID: 56788 Assignee: dri-devel@lists.freedesktop.org Summary: [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

https://bugs.freedesktop.org/show_bug.cgi?id=56788 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- Created attachment 69590 -- https://bugs.freedesktop.org/attachment.cgi?id=69590action=edit Wine backtrace -- You are receiving this mail because: You are the assignee for the bug.

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

https://bugs.freedesktop.org/show_bug.cgi?id=56788 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

https://bugzilla.kernel.org/show_bug.cgi?id=48941 Florian Mickler flor...@mickler.org changed: What|Removed |Added CC||flor...@mickler.org

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

https://bugzilla.kernel.org/show_bug.cgi?id=48941 Igor Murzov e-m...@date.by changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #18 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #16) Created attachment 69573 [details] [review] possible fix Actually, I think I found the problem. Missing index in mc_resume(). This seems to

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #19 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #15) (In reply to comment #14) (In reply to comment #12) (In reply to comment #11) Found what is wrong with the help of a few printk and by

[ANNOUNCE] libdrm 2.4.40

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, libdrm 2.4.40 has been released. The reason is we need to use the radeon stencil mipmap allocator for combined depth-stencil buffers in Mesa. Alex Deucher (1): radeon: add some new SI pci ids Andreas Boll (1): radeon: fix

Re: [PATCH] drm: exynos: fix for mapping of dma buffers

Applied. Thanks, Inki Dae 2012/11/6 Rahul Sharma rahul.sha...@samsung.com This patch fixes the problem of mapping contigous and non contigous dma buffers. Currently page struct is calculated from the buf-dma_addr which is not the physical address. It is replaced by buf-pages which points

[drm-intel:drm-intel-next-queued 255/259] drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef expression

Hi Ben, FYI, there are new sparse warnings show up in tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued head: afef67fbc09aec8508c88aac1931661a36e91958 commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using AGP layer for GEN6+ +

Re: merging printk and WARN

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote: It looks like these patches were not a good idea, because in each case the printk provides an error level, and WARN then provides another one. I think this is not a problem within btrfs at the place where this has changed. david

[bisected] drm i915 hangs on heavy io load

On Sunday 04 November 2012 16:08:47 Dave Airlie wrote: On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining prein...@logic.at wrote: On Di, 30 Okt 2012, Dave Airlie wrote: I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 final to 3.7-rc1 or maybe -rc2. Sorry for my

Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the manager needs to observe all the possible displays used at the same time... Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information'

Re: [PATCH] drm/radeon: fix typo in evergreen_mc_resume()

On Mon, 2012-11-05 at 11:34 -0500, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com Add missing index that may have led us to enabling more crtcs than necessary. May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 Signed-off-by: Alex Deucher