dri-devel January 2014

dri-devel@lists.freedesktop.org

145 participants
957 discussions

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #92 from d4ddi0 <stillcompiling(a)gmail.com> --- Looks like maybe * bug 35998 <https://bugs.freedesktop.org/show_bug.cgi?id=35998> ?* *Your observation about it only happening when Exapixmaps is off might be really helpful* On Sun, Jan 5, 2014 at 10:29 AM, <bugzilla-daemon(a)freedesktop.org> wrote: > *Comment # 91 <https://bugs.freedesktop.org/show_bug.cgi?id=35457#c91> > on bug 35457 <https://bugs.freedesktop.org/show_bug.cgi?id=35457> from > Programmist11180 <programmer11180(a)programist.ru> * > > Symptoms same as on screenshots in attachments. > > I found out that graphics corruption appears with this /etc/X11/xorg.conf > > Section "Device" > Identifier "Radeon" > Driver "radeon" > Option "EXAPixmaps" "off" > EndSection > > When "EXAPixmaps" is "on", no graphic corruption. > It is fair for ALL kernels that I tested (3.2 , 3.12 , 3.13rc6). > Appears only in applications that used opengl (glxgears for example). > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #91 from Programmist11180 <programmer11180(a)programist.ru> --- Symptoms same as on screenshots in attachments. I found out that graphics corruption appears with this /etc/X11/xorg.conf Section "Device" Identifier "Radeon" Driver "radeon" Option "EXAPixmaps" "off" EndSection When "EXAPixmaps" is "on", no graphic corruption. It is fair for ALL kernels that I tested (3.2 , 3.12 , 3.13rc6). Appears only in applications that used opengl (glxgears for example). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 66967] New: Dota 2 crashes with r600g when starting the tutorial
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=66967 Priority: medium Bug ID: 66967 Assignee: dri-devel(a)lists.freedesktop.org Summary: Dota 2 crashes with r600g when starting the tutorial Severity: normal Classification: Unclassified OS: All Reporter: tilman(a)code-monkey.de Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 82486 --> https://bugs.freedesktop.org/attachment.cgi?id=82486&action=edit Log When trying to start the tutorial in today's version of Dota 2, there's a segfault in check_begin_texture_render(): Program received signal SIGSEGV, Segmentation fault. 0xf5397c5a in check_begin_texture_render (ctx=0x8bb4000, fb=0x17e90700) at ../../src/mesa/main/fbobject.c:1871 1871 if (att->Texture && att->Renderbuffer->TexImage) { (gdb) p *att $3 = {Type = 5890, Complete = 0 '\000', Renderbuffer = 0x0, Texture = 0x17e88500, TextureLevel = 0, CubeMapFace = 0, Zoffset = 0, Layered = 0 '\000'} att->Renderbuffer is dereferenced even though it's null. I can reproduce this segfault reliably with Mesa git-e4fdf1b on my rv730. The log I'm attaching shows a bunch of messages like > ##### CMaterialReference::Init got error material for dev\white in tex group Other textures that might be related. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #90 from d4ddi0 <stillcompiling(a)gmail.com> --- *Programmist11180 <programmer11180(a)programist.ru>,* your dmesg looks like the patch is working as intended. what are your symptoms? This bug is not the only one affecting these cards (just the longest running) Perhaps you could post a screen capture. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #89 from Programmist11180 <programmer11180(a)programist.ru> --- Created attachment 91520 --> https://bugs.freedesktop.org/attachment.cgi?id=91520&action=edit kernel 3.13 rc6 (without rs690m patch) dmesg, Gateway LT3103u -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 35457] [rs690m] Graphics corruption with ati x1200
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #88 from Programmist11180 <programmer11180(a)programist.ru> --- Created attachment 91519 --> https://bugs.freedesktop.org/attachment.cgi?id=91519&action=edit kernel 3.13 rc6 dmesg, Gateway LT3103u -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 70706] Regression in fbconfig
by bugzilla-daemon＠freedesktop.org 05 Jan '14

05 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #14 from Michael Mair-Keimberger <bu9zilla(a)gmail.com> --- I can confirm this problem with kwin too. X.Org X Server 1.15.0 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[PATCH 00/18] dri3+gallium patch series
by Keith Packard 03 Jan '14

03 Jan '14

This series has a bunch of DRI3 cleanups and fixes followed by a few patches that finish up DRI3 support in gallium. The first two patches have nothing to do with DRI3, just some warning fixes: [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from [PATCH 02/18] dri/swrast: Passing dri_context * instead of DRI3 cleanups [PATCH 03/18] Don't use libudev for glx/dri3 [PATCH 04/18] dri3: Switch to libxshmfence version 1.1 [PATCH 05/18] dri3: Free resources when drawable is destroyed. [PATCH 06/18] dri3: Clean up struct dri3_drawable [PATCH 07/18] dri3: Track full 64-bit SBC numbers, instead of just [PATCH 08/18] dri3: Fix dri3_wait_for_sbc to wait for completion of [PATCH 09/18] dri3: Enable GLX_INTEL_swap_event [PATCH 10/18] i965: Correct check for re-bound buffer in [PATCH 11/18] i965: Set fast color clear mcs_state on newly allocated [PATCH 12/18] dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACK [PATCH 13/18] dri3: Flush XCB before blocking for special events [PATCH 14/18] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888 And the gallium patches: The middle two are from Ben Skeggs, but haven't been reviewed and not in an area of the code I feel comfortable reviewing. [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to [PATCH 16/18] gallium/dri: fix unsetting of format when encountering [PATCH 17/18] nvc0: fix segfault if nv50_miptree_from_handle() fails [PATCH 18/18] gallium: Use base.stamp for all drawable invalidation

4 26

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
by Ilia Mirkin 03 Jan '14

03 Jan '14

The code expects non-VRAM mem nodes to have a pages list. If that's not set, it will do a null deref down the line. Warn on that condition and return an error. See https://bugs.freedesktop.org/show_bug.cgi?id=64774 Reported-by: Pasi Kärkkäinen <pasik(a)iki.fi> Tested-by: Pasi Kärkkäinen <pasik(a)iki.fi> Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> Cc: <stable(a)vger.kernel.org> # 3.8+ --- I don't exactly understand what's going on, but this is just a straightforward way to avoid a null deref that you see happens in the bug. I haven't figured out the root cause of this, but it's getting well into the "I have no idea how TTM works" space. However this seems like a bit of defensive programming -- nouveau_vm_map_sg will pass node->pages as a list down, which will be dereferenced by nvc0_vm_map_sg. Perhaps the other arguments should make that dereferencing not happen, but it definitely was happening here, as you can see in the bug. Ben/Maarten, I'll let you judge whether this check is appropriate, since like I hope I was able to convey above, I'm just not really sure :) drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index cdc3282..191145d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, struct nouveau_bo *nvbo, struct nouveau_mem *node = mem->mm_node; int ret; + /* If we ever get here for a non-vram mem node that doesn't + * have pages, we will end up doing a null deref in + * nouveau_vm_map_sg. */ + if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages)) + return -EINVAL; + ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages << PAGE_SHIFT, node->page_shift, NV_MEM_ACCESS_RW, vma); -- 1.8.1.5

4 21

[Bug 67961] New: radeon drm: atombios pptable.h headers not portable
by bugzilla-daemon＠bugzilla.kernel.org 03 Jan '14

03 Jan '14

https://bugzilla.kernel.org/show_bug.cgi?id=67961 Bug ID: 67961 Summary: radeon drm: atombios pptable.h headers not portable Product: Drivers Version: 2.5 Kernel Version: mainline Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: kallisti5(a)unixzen.com Regression: No The new pptable.h atombios headers aren't portable to older gcc versions (gcc2) pptable.h moved to using: (which isn't portable to gcc2) #pragma pack(push, 1) . . . #pragma pack(pop) while atombios.h uses: (which is portable) #pragma pack(1) . . . #pragma pack() This bug is mostly to track the request to agd5f -- You are receiving this mail because: You are watching the assignee of the bug.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2014