[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #6 from Tom Stellard 2010-07-08 23:24:11 PDT --- Can you post the output with RADEON_DEBUG=fp from the most recent git version. -- 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 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #6 from Tom Stellard 2010-07-08 23:24:11 PDT --- Can you post the output with RADEON_DEBUG=fp from the most recent git version. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28624] [r300g] too many texture indirections (was: fails to compile some fragment programs of Enemy Territory: Quake Wars)
https://bugs.freedesktop.org/show_bug.cgi?id=28624 --- Comment #3 from Tom Stellard 2010-07-08 22:05:13 PDT --- This should be fixed by commit 8a8e311d8c3c60982d101826a4aa013672730e6c. Can you try again with the latest git code? -- 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 28624] [r300g] too many texture indirections (was: fails to compile some fragment programs of Enemy Territory: Quake Wars)
https://bugs.freedesktop.org/show_bug.cgi?id=28624 --- Comment #3 from Tom Stellard 2010-07-08 22:05:13 PDT --- This should be fixed by commit 8a8e311d8c3c60982d101826a4aa013672730e6c. Can you try again with the latest git code? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25109] [r300] failing to schedule TEX blocks (was: Wine - Civ4 Black Terrain after upgrading to mesa 7.6)
https://bugs.freedesktop.org/show_bug.cgi?id=25109 Tom Stellard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Tom Stellard 2010-07-08 21:43:05 PDT --- Fixed in git master commit: 3724a2e65f5b3aa6e123889342a3e9c4d05903f5 -- 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 25109] [r300] failing to schedule TEX blocks (was: Wine - Civ4 Black Terrain after upgrading to mesa 7.6)
https://bugs.freedesktop.org/show_bug.cgi?id=25109 Tom Stellard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Tom Stellard 2010-07-08 21:43:05 PDT --- Fixed in git master commit: 3724a2e65f5b3aa6e123889342a3e9c4d05903f5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Tom Stellard 2010-07-08 21:39:09 PDT --- Fix in mesa git master commit: 8a8e311d8c3c60982d101826a4aa013672730e6c -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Tom Stellard 2010-07-08 21:39:09 PDT --- Fix in mesa git master commit: 8a8e311d8c3c60982d101826a4aa013672730e6c -- 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/gem: Add new flink_to ioctl
> > My argument was based around that the current system is designed as a > > directory of opaque objects and so the extended attributes should be > > kept opaque to the kernel as well and left open to interpretation by > > userland. What I am most unclear about is under which circumstances is > > this backchannel communication preferable to passing the extra information > > over the IPC that needs to be performed anyway in order to open a surface. > > That's the part I had trouble with as well. Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... Passing the blob through the kernel does give you a basis for more complex security since you can agree a blob format with the kernel security layer and add security hooks to the interface in future.
[PATCH] drm/gem: Add new flink_to ioctl
2010/7/8 Kristian H?gsberg : ... > In the work on the EGL extension, the other Khronos members have > indicated that sharing buffers by passing an integer could work for > their implementations too, and that's what the draft standard > currently requires. ?I could try to get that changed to a > size+bytearray couple, but then the "pass the blob" API makes it all > the way into user APIs. ?We could implement the integer ID in > userspace by creating a file in a shared directory by the name of the > integer handle and serialize meta data into that. ?I'm not fond of > either approach, but they're possible. Chris was asking for details about this extensions, and I thought I'd post it here too to give a better idea of what it might look like. We're looking at two new entry points: EGLDisplayNameKHR eglGetDisplayNameKHR(EGLDisplay dpy); EGLBoolean eglExportImageKHR(EGLDisplay dpy, EGLImageKHRimage, EGLDisplayNameKHR target_dpy EGLImageNameKHR *handle); with typedef khronos_uint32_t EGLDisplayNameKHR; typedef khronos_uint32_t EGLImageNameKHR; The process that wants to receive a shared EGLImage must call eglGetDisplayNameKHR() to get a global name for the EGLDisplay handle it wants to import the EGLImage into and send that to the process sharing the image. The process sharing the EGLImage then calls eglExportImageKHR() and gets an integer handle for the EGLImage it can send back to the receiving process, which will pass it as the EGLClientBuffer argument to eglCreateImage(). At that point, the receiving process can use the EGLImage as usual. As I said above, nothing here requires using integer names, but it makes an application level API easier to use and does fit in rather nicely with how GL otherwise uses integer names for various objects. Kristian
[PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 12:14:28 -0400, Kristian H??gsberg wrote: > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > > On Thu, ??8 Jul 2010 11:23:25 -0400, Kristian H??gsberg > bitplanet.net> wrote: > > > >> ??- a mechanism to attach a binary blob to an flink_to buffer name. > >> ?? ??open_with_data returns the data. ??Userspace (typically libdrm) > >> ?? ??decides the layout and versioning of the blob and the contents > >> ?? ??will be chipset specific. ??it's an opaque blob to the kernel, > >> ?? ??which doesn't need to know about stride and formats etc. > > > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > > need to know all of this data, having it in an explicit (versioned) > > format will protect applications from randomly mis-interpreting the data. > > I talked with ickle about that and whether or not to include a > version+format u32 for the data in the ioctl args. He convinced me > that the kernel didn't need to know about the layout of the blob and > that requiring by convention that the first u32 of the blob is the > version+format u32 would suffice. I can go either way on this, but I > guess I have a small preference for making it part of the ioctl args > as you suggest. I am not going to argue with someone who has been tackling the issue of protocol extensions for 25 years... ;-) My argument was based around that the current system is designed as a directory of opaque objects and so the extended attributes should be kept opaque to the kernel as well and left open to interpretation by userland. What I am most unclear about is under which circumstances is this backchannel communication preferable to passing the extra information over the IPC that needs to be performed anyway in order to open a surface. -ickle -- Chris Wilson, Intel Open Source Technology Centre
Re: 2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.
Graphics hardware is NV250 type card.
Some quick testing last night showed this patch fixed both the boot
messages and graphics performance.
[tip:x86/urgent] rbtree: Undo augmented trees performance damage and regression
http://marc.info/?l=linux-kernel&m=127833440902862&w=2
On Fri, Jul 9, 2010 at 8:26 AM, Andrew Morton wrote:
> (Rafael, Maciej: two probably-separate post-2.6.34 regressions here)
>
> On Tue, 06 Jul 2010 22:22:17 +1000
> Andrew Hendry wrote:
>
>>
>> Some extra messages when booting with -rc4. Didn't get them in -rc3.
>> [ 1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
>> [ 1.387409] swapper:1 freeing invalid memtype bf789000-bf78a000
>> [ 5.999675] modprobe:548 freeing invalid memtype d000-d004
>> [ 6.068347] modprobe:548 freeing invalid memtype d014-d015
>> [ 6.068647] modprobe:548 freeing invalid memtype d015-d016
>> [ 6.069661] modprobe:548 freeing invalid memtype d017-d01f
>> [ 6.085969] modprobe:548 freeing invalid memtype d01f-d020
>> [ 6.087673] modprobe:548 freeing invalid memtype d021-d022
>> [ 6.087900] modprobe:548 freeing invalid memtype d022-d023
>> [ 6.088092] modprobe:548 freeing invalid memtype d023-d024
>> [ 6.088317] modprobe:548 freeing invalid memtype d024-d025
>
> hrmpf, one of those wonderful messages where neither it nor its source
> code give you any clue regarding what caused it nor how to fix it.
>
> please, apply this:
>
> --- a/arch/x86/mm/pat.c~a
> +++ a/arch/x86/mm/pat.c
> @@ -359,7 +359,7 @@ int free_memtype(u64 start, u64 end)
> entry = rbt_memtype_erase(start, end);
> spin_unlock(&memtype_lock);
>
> - if (!entry) {
> + if (WARN_ON(!entry)) {
> printk(KERN_INFO "%s:%d freeing invalid memtype %Lx-%Lx\n",
> current->comm, current->pid, start, end);
> return -EINVAL;
>
>
> and let's at least see where it's coming from.
>
>> Not sure if its related, but also have a noticeable performance issue with
>> graphics under rc4.
>> Dragging and resizing windows, screen updates, and jumpy cursor are all slow.
>> Playing a full screen video under vlc gets only 1-2 frames per second, but
>> plays fine under rc3.
>> Tested a kernel compile, it was roughly the same.
>> Userspace is ubunutu 10.04 64bit.
>>
>> Any hints? Otherwise will start a bisect tomorrow night.
>>
>> Config attached, lspci, rc3 and rc4 boot messages below:
>
> What graphics hardware are you using?
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28847] [r300c, r300g] Regnum Online only works in safe mode
https://bugs.freedesktop.org/show_bug.cgi?id=28847 Marek Olšák changed: What|Removed |Added Summary|Regnum Online only works in |[r300c, r300g] Regnum |safe mode |Online only works in safe ||mode -- 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 28847] [r300c, r300g] Regnum Online only works in safe mode
https://bugs.freedesktop.org/show_bug.cgi?id=28847 Marek Ol??k changed: What|Removed |Added Summary|Regnum Online only works in |[r300c, r300g] Regnum |safe mode |Online only works in safe ||mode -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28437] [r300g] wrong texture colors with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28437 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Marek Olšák 2010-07-08 15:54:33 PDT --- Fixed with commit 392a2515c0967c395be098cac6a37f325dd66b90. Closing.. -- 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 28437] [r300g] wrong texture colors with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28437 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Marek Ol??k 2010-07-08 15:54:33 PDT --- Fixed with commit 392a2515c0967c395be098cac6a37f325dd66b90. Closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28625] [r300g] all surfaces in unreal tournament 2004 are GL_NEAREST
https://bugs.freedesktop.org/show_bug.cgi?id=28625 --- Comment #3 from Marek Olšák 2010-07-08 15:53:00 PDT --- The commit 392a2515c0967c395be098cac6a37f325dd66b90 in master should fix this issue, can you confirm? -- 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 28625] [r300g] all surfaces in unreal tournament 2004 are GL_NEAREST
https://bugs.freedesktop.org/show_bug.cgi?id=28625 --- Comment #3 from Marek Ol??k 2010-07-08 15:53:00 PDT --- The commit 392a2515c0967c395be098cac6a37f325dd66b90 in master should fix this issue, can you confirm? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: 2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.
(Rafael, Maciej: two probably-separate post-2.6.34 regressions here)
On Tue, 06 Jul 2010 22:22:17 +1000
Andrew Hendry wrote:
>
> Some extra messages when booting with -rc4. Didn't get them in -rc3.
> [1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
> [1.387409] swapper:1 freeing invalid memtype bf789000-bf78a000
> [5.999675] modprobe:548 freeing invalid memtype d000-d004
> [6.068347] modprobe:548 freeing invalid memtype d014-d015
> [6.068647] modprobe:548 freeing invalid memtype d015-d016
> [6.069661] modprobe:548 freeing invalid memtype d017-d01f
> [6.085969] modprobe:548 freeing invalid memtype d01f-d020
> [6.087673] modprobe:548 freeing invalid memtype d021-d022
> [6.087900] modprobe:548 freeing invalid memtype d022-d023
> [6.088092] modprobe:548 freeing invalid memtype d023-d024
> [6.088317] modprobe:548 freeing invalid memtype d024-d025
hrmpf, one of those wonderful messages where neither it nor its source
code give you any clue regarding what caused it nor how to fix it.
please, apply this:
--- a/arch/x86/mm/pat.c~a
+++ a/arch/x86/mm/pat.c
@@ -359,7 +359,7 @@ int free_memtype(u64 start, u64 end)
entry = rbt_memtype_erase(start, end);
spin_unlock(&memtype_lock);
- if (!entry) {
+ if (WARN_ON(!entry)) {
printk(KERN_INFO "%s:%d freeing invalid memtype %Lx-%Lx\n",
current->comm, current->pid, start, end);
return -EINVAL;
and let's at least see where it's coming from.
> Not sure if its related, but also have a noticeable performance issue with
> graphics under rc4.
> Dragging and resizing windows, screen updates, and jumpy cursor are all slow.
> Playing a full screen video under vlc gets only 1-2 frames per second, but
> plays fine under rc3.
> Tested a kernel compile, it was roughly the same.
> Userspace is ubunutu 10.04 64bit.
>
> Any hints? Otherwise will start a bisect tomorrow night.
>
> Config attached, lspci, rc3 and rc4 boot messages below:
What graphics hardware are you using?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.
(Rafael, Maciej: two probably-separate post-2.6.34 regressions here)
On Tue, 06 Jul 2010 22:22:17 +1000
Andrew Hendry wrote:
>
> Some extra messages when booting with -rc4. Didn't get them in -rc3.
> [1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
> [1.387409] swapper:1 freeing invalid memtype bf789000-bf78a000
> [5.999675] modprobe:548 freeing invalid memtype d000-d004
> [6.068347] modprobe:548 freeing invalid memtype d014-d015
> [6.068647] modprobe:548 freeing invalid memtype d015-d016
> [6.069661] modprobe:548 freeing invalid memtype d017-d01f
> [6.085969] modprobe:548 freeing invalid memtype d01f-d020
> [6.087673] modprobe:548 freeing invalid memtype d021-d022
> [6.087900] modprobe:548 freeing invalid memtype d022-d023
> [6.088092] modprobe:548 freeing invalid memtype d023-d024
> [6.088317] modprobe:548 freeing invalid memtype d024-d025
hrmpf, one of those wonderful messages where neither it nor its source
code give you any clue regarding what caused it nor how to fix it.
please, apply this:
--- a/arch/x86/mm/pat.c~a
+++ a/arch/x86/mm/pat.c
@@ -359,7 +359,7 @@ int free_memtype(u64 start, u64 end)
entry = rbt_memtype_erase(start, end);
spin_unlock(&memtype_lock);
- if (!entry) {
+ if (WARN_ON(!entry)) {
printk(KERN_INFO "%s:%d freeing invalid memtype %Lx-%Lx\n",
current->comm, current->pid, start, end);
return -EINVAL;
and let's at least see where it's coming from.
> Not sure if its related, but also have a noticeable performance issue with
> graphics under rc4.
> Dragging and resizing windows, screen updates, and jumpy cursor are all slow.
> Playing a full screen video under vlc gets only 1-2 frames per second, but
> plays fine under rc3.
> Tested a kernel compile, it was roughly the same.
> Userspace is ubunutu 10.04 64bit.
>
> Any hints? Otherwise will start a bisect tomorrow night.
>
> Config attached, lspci, rc3 and rc4 boot messages below:
What graphics hardware are you using?
Re: [PATCH] drm/gem: Add new flink_to ioctl
2010/7/8 Kristian Høgsberg : ... > In the work on the EGL extension, the other Khronos members have > indicated that sharing buffers by passing an integer could work for > their implementations too, and that's what the draft standard > currently requires. I could try to get that changed to a > size+bytearray couple, but then the "pass the blob" API makes it all > the way into user APIs. We could implement the integer ID in > userspace by creating a file in a shared directory by the name of the > integer handle and serialize meta data into that. I'm not fond of > either approach, but they're possible. Chris was asking for details about this extensions, and I thought I'd post it here too to give a better idea of what it might look like. We're looking at two new entry points: EGLDisplayNameKHR eglGetDisplayNameKHR(EGLDisplay dpy); EGLBoolean eglExportImageKHR(EGLDisplay dpy, EGLImageKHRimage, EGLDisplayNameKHR target_dpy EGLImageNameKHR *handle); with typedef khronos_uint32_t EGLDisplayNameKHR; typedef khronos_uint32_t EGLImageNameKHR; The process that wants to receive a shared EGLImage must call eglGetDisplayNameKHR() to get a global name for the EGLDisplay handle it wants to import the EGLImage into and send that to the process sharing the image. The process sharing the EGLImage then calls eglExportImageKHR() and gets an integer handle for the EGLImage it can send back to the receiving process, which will pass it as the EGLClientBuffer argument to eglCreateImage(). At that point, the receiving process can use the EGLImage as usual. As I said above, nothing here requires using integer names, but it makes an application level API easier to use and does fit in rather nicely with how GL otherwise uses integer names for various objects. Kristian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28966] New: [r300g] Dynamic branching 3 demo does not run
https://bugs.freedesktop.org/show_bug.cgi?id=28966 Summary: [r300g] Dynamic branching 3 demo does not run Product: Mesa Version: git Platform: Other URL: http://www.humus.name/index.php?page=3D&ID=67 OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se I'm filing this just in case it's of interest for those hacking shaders on r300. Humus DynamicBranching3 demo does not run: Note: 'for (i ... )' body is too large/complex to unroll Fragment program using varying vars not written by vertex shader For reference, this demo does work with the i965 driver. http://www.humus.name/index.php?page=3D&ID=67 System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30 -- xserver: 1.8.1.901 -- mesa: 61a26cdfdc9c75a83c0d362c973d5436fe077be4 -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc3 -- 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 28966] New: [r300g] Dynamic branching 3 demo does not run
https://bugs.freedesktop.org/show_bug.cgi?id=28966 Summary: [r300g] Dynamic branching 3 demo does not run Product: Mesa Version: git Platform: Other URL: http://www.humus.name/index.php?page=3D&ID=67 OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se I'm filing this just in case it's of interest for those hacking shaders on r300. Humus DynamicBranching3 demo does not run: Note: 'for (i ... )' body is too large/complex to unroll Fragment program using varying vars not written by vertex shader For reference, this demo does work with the i965 driver. http://www.humus.name/index.php?page=3D&ID=67 System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30 -- xserver: 1.8.1.901 -- mesa: 61a26cdfdc9c75a83c0d362c973d5436fe077be4 -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28869] [r300g] Tiny and Big doesn't run
https://bugs.freedesktop.org/show_bug.cgi?id=28869 --- Comment #1 from Sven Arvidsson 2010-07-08 14:57:11 PDT --- Clicking on "Options" results in: [linuxplatform] Error: OpenGL error: out of memory (thrown from createImpl (../../../scape/opengl/openglpixelbuffer.cpp, line 275)) -- 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 28869] [r300g] Tiny and Big doesn't run
https://bugs.freedesktop.org/show_bug.cgi?id=28869 --- Comment #1 from Sven Arvidsson 2010-07-08 14:57:11 PDT --- Clicking on "Options" results in: [linuxplatform] Error: OpenGL error: out of memory (thrown from createImpl (../../../scape/opengl/openglpixelbuffer.cpp, line 275)) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson changed: What|Removed |Added Summary|[r300g] Yo Frankie crash: |[r300g] Yo Frankie - |assertion failure / Too |shaders not working: Too |many hardware temporaries |many instructions |used| -- 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 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson changed: What|Removed |Added Summary|[r300g] Yo Frankie crash: |[r300g] Yo Frankie - |assertion failure / Too |shaders not working: Too |many hardware temporaries |many instructions |used| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28860] [r300g] Yo Frankie crash: assertion failure / Too many hardware temporaries used
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson changed: What|Removed |Added Attachment #36701|0 |1 is obsolete|| --- Comment #5 from Sven Arvidsson 2010-07-08 14:50:51 PDT --- Created an attachment (id=36892) --> (https://bugs.freedesktop.org/attachment.cgi?id=36892) Yo Frankie screenshot Now using git master 61a26cdfdc9c75a83c0d362c973d5436fe077be4 it no longer crashes, but the game does look kinda trippy ;-) -- 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 28860] [r300g] Yo Frankie crash: assertion failure / Too many hardware temporaries used
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson changed: What|Removed |Added Attachment #36701|0 |1 is obsolete|| --- Comment #5 from Sven Arvidsson 2010-07-08 14:50:51 PDT --- Created an attachment (id=36892) --> (https://bugs.freedesktop.org/attachment.cgi?id=36892) Yo Frankie screenshot Now using git master 61a26cdfdc9c75a83c0d362c973d5436fe077be4 it no longer crashes, but the game does look kinda trippy ;-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: linux-next: Tree for July 8 (nouveau)
On Thu, 2010-07-08 at 09:48 -0700, Randy Dunlap wrote: > On Thu, 8 Jul 2010 15:10:22 +1000 Stephen Rothwell wrote: > > > Hi all, > > > > Changes since 20100707: > > > > The i.MX tree mismerge has been fixed. > > > > The omap tree gained a conflict (involving serveral files) against the > > arm tree. > > > > > > > Should nouveau depend on PCI? > It has build errors when PCI is disabled: Should be fixed in todays drm-next tree, when we moved the PCI depend from the toplevel it didn't make it into all the sublevel drivers. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #12 from Tom Stellard 2010-07-08 14:49:19 PDT --- Created an attachment (id=36891) View: https://bugs.freedesktop.org/attachment.cgi?id=36891 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36891 Final patch I cleaned up the old patch a little bit, can you confirm that this one still works. -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #12 from Tom Stellard 2010-07-08 14:49:19 PDT --- Created an attachment (id=36891) View: https://bugs.freedesktop.org/attachment.cgi?id=36891 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36891 Final patch I cleaned up the old patch a little bit, can you confirm that this one still works. -- 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/gem: Add new flink_to ioctl
On Thu, Jul 8, 2010 at 12:49 PM, Jesse Barnes wrote: > On Thu, 08 Jul 2010 17:37:20 +0100 > Chris Wilson wrote: > >> On Thu, 8 Jul 2010 12:14:28 -0400, Kristian H?gsberg >> wrote: >> > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard >> > wrote: >> > > On Thu, ?8 Jul 2010 11:23:25 -0400, Kristian H?gsberg > > > bitplanet.net> wrote: >> > > >> > >> ?- a mechanism to attach a binary blob to an flink_to buffer name. >> > >> ? ?open_with_data returns the data. ?Userspace (typically libdrm) >> > >> ? ?decides the layout and versioning of the blob and the contents >> > >> ? ?will be chipset specific. ?it's an opaque blob to the kernel, >> > >> ? ?which doesn't need to know about stride and formats etc. >> > > >> > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't >> > > need to know all of this data, having it in an explicit (versioned) >> > > format will protect applications from randomly mis-interpreting the data. >> > >> > I talked with ickle about that and whether or not to include a >> > version+format u32 for the data in the ioctl args. ?He convinced me >> > that the kernel didn't need to know about the layout of the blob and >> > that requiring by convention that the first u32 of the blob is the >> > version+format u32 would suffice. ?I can go either way on this, but I >> > guess I have a small preference for making it part of the ioctl args >> > as you suggest. >> >> I am not going to argue with someone who has been tackling the issue of >> protocol extensions for 25 years... ;-) >> >> My argument was based around that the current system is designed as a >> directory of opaque objects and so the extended attributes should be >> kept opaque to the kernel as well and left open to interpretation by >> userland. What I am most unclear about is under which circumstances is >> this backchannel communication preferable to passing the extra information >> over the IPC that needs to be performed anyway in order to open a surface. > > That's the part I had trouble with as well. ?Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... There's nothing in the use cases I have in mind that strictly requires passing buffers around as integer IDs. We could standardize a serialization mechanism in libdrm that would give you a blob that contains the bo name and the meta data, and you would then send that over the protocol when you need to share a buffer. Attaching a blob to the name instead and passing just the uint32_t name around makes life a little easier though, in the EGL API, in the protocol code. It is IPC-ish, I guess, but in the same sense as xattr's are, for example. The other point is that we already do this to some extent, with the object size (returned by open) and the tiling and swizzle parameters (communicated through the set and get ioctls). They're are somewhat special in that the kernel also needs to know these values, but we do use the kernel to communicate these values between processes. There's no reason gem_open needs to return size in the ioctl args and the intel get_tiling ioctl is only required because we don't pass the tiling meta data over dri2 protocol (it's a chipset specific thing after all). The flink_to blob approach combines the convenience of getting the data at gem_open time and the option to pass free form chipset specific meta data. In the work on the EGL extension, the other Khronos members have indicated that sharing buffers by passing an integer could work for their implementations too, and that's what the draft standard currently requires. I could try to get that changed to a size+bytearray couple, but then the "pass the blob" API makes it all the way into user APIs. We could implement the integer ID in userspace by creating a file in a shared directory by the name of the integer handle and serialize meta data into that. I'm not fond of either approach, but they're possible. Kristian
[Bug 28612] [r300g] View isn't permanent, menus/controls are corrupted in Blender
https://bugs.freedesktop.org/show_bug.cgi?id=28612 --- Comment #7 from Marek Olšák 2010-07-08 13:07:21 PDT --- Is this still an issue with current mesa git? -- 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 28612] [r300g] View isn't permanent, menus/controls are corrupted in Blender
https://bugs.freedesktop.org/show_bug.cgi?id=28612 --- Comment #7 from Marek Ol??k 2010-07-08 13:07:21 PDT --- Is this still an issue with current mesa git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)
https://bugs.freedesktop.org/show_bug.cgi?id=28517 Marek Olšák changed: What|Removed |Added Summary|[r300g] Savage 2 : |[r300g] loop unrolling |characters are not rendered |fails (was: Savage 2 : |+ another corruptions |characters are not rendered ||+ another corruptions) -- 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 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)
https://bugs.freedesktop.org/show_bug.cgi?id=28517 Marek Ol??k changed: What|Removed |Added Summary|[r300g] Savage 2 : |[r300g] loop unrolling |characters are not rendered |fails (was: Savage 2 : |+ another corruptions |characters are not rendered ||+ another corruptions) -- 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: make sure rio_mem is valid before unmapping it
If we were not able to map the io bar in device init, don't attempt to unmap it in device fini. All radeons should have a io bar, so I doubt this would ever trigger, but just to be on the safe side... Pointed out by: Alberto Milone Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index d3e86f4..9b092b6 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -737,7 +737,8 @@ void radeon_device_fini(struct radeon_device *rdev) destroy_workqueue(rdev->wq); vga_switcheroo_unregister_client(rdev->pdev); vga_client_register(rdev->pdev, NULL, NULL, NULL); - pci_iounmap(rdev->pdev, rdev->rio_mem); + if (rdev->rio_mem) + pci_iounmap(rdev->pdev, rdev->rio_mem); rdev->rio_mem = NULL; iounmap(rdev->rmmio); rdev->rmmio = NULL; -- 1.7.0.1
[PATCH] drm/gem: Add new flink_to ioctl
On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > On Thu, ?8 Jul 2010 11:23:25 -0400, Kristian H?gsberg > wrote: > >> ?- a mechanism to attach a binary blob to an flink_to buffer name. >> ? ?open_with_data returns the data. ?Userspace (typically libdrm) >> ? ?decides the layout and versioning of the blob and the contents >> ? ?will be chipset specific. ?it's an opaque blob to the kernel, >> ? ?which doesn't need to know about stride and formats etc. > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > need to know all of this data, having it in an explicit (versioned) > format will protect applications from randomly mis-interpreting the data. I talked with ickle about that and whether or not to include a version+format u32 for the data in the ioctl args. He convinced me that the kernel didn't need to know about the layout of the blob and that requiring by convention that the first u32 of the blob is the version+format u32 would suffice. I can go either way on this, but I guess I have a small preference for making it part of the ioctl args as you suggest. Kristian
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, Jul 8, 2010 at 12:49 PM, Jesse Barnes wrote: > On Thu, 08 Jul 2010 17:37:20 +0100 > Chris Wilson wrote: > >> On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg >> wrote: >> > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: >> > > On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg >> > > wrote: >> > > >> > >> - a mechanism to attach a binary blob to an flink_to buffer name. >> > >> open_with_data returns the data. Userspace (typically libdrm) >> > >> decides the layout and versioning of the blob and the contents >> > >> will be chipset specific. it's an opaque blob to the kernel, >> > >> which doesn't need to know about stride and formats etc. >> > > >> > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't >> > > need to know all of this data, having it in an explicit (versioned) >> > > format will protect applications from randomly mis-interpreting the data. >> > >> > I talked with ickle about that and whether or not to include a >> > version+format u32 for the data in the ioctl args. He convinced me >> > that the kernel didn't need to know about the layout of the blob and >> > that requiring by convention that the first u32 of the blob is the >> > version+format u32 would suffice. I can go either way on this, but I >> > guess I have a small preference for making it part of the ioctl args >> > as you suggest. >> >> I am not going to argue with someone who has been tackling the issue of >> protocol extensions for 25 years... ;-) >> >> My argument was based around that the current system is designed as a >> directory of opaque objects and so the extended attributes should be >> kept opaque to the kernel as well and left open to interpretation by >> userland. What I am most unclear about is under which circumstances is >> this backchannel communication preferable to passing the extra information >> over the IPC that needs to be performed anyway in order to open a surface. > > That's the part I had trouble with as well. Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... There's nothing in the use cases I have in mind that strictly requires passing buffers around as integer IDs. We could standardize a serialization mechanism in libdrm that would give you a blob that contains the bo name and the meta data, and you would then send that over the protocol when you need to share a buffer. Attaching a blob to the name instead and passing just the uint32_t name around makes life a little easier though, in the EGL API, in the protocol code. It is IPC-ish, I guess, but in the same sense as xattr's are, for example. The other point is that we already do this to some extent, with the object size (returned by open) and the tiling and swizzle parameters (communicated through the set and get ioctls). They're are somewhat special in that the kernel also needs to know these values, but we do use the kernel to communicate these values between processes. There's no reason gem_open needs to return size in the ioctl args and the intel get_tiling ioctl is only required because we don't pass the tiling meta data over dri2 protocol (it's a chipset specific thing after all). The flink_to blob approach combines the convenience of getting the data at gem_open time and the option to pass free form chipset specific meta data. In the work on the EGL extension, the other Khronos members have indicated that sharing buffers by passing an integer could work for their implementations too, and that's what the draft standard currently requires. I could try to get that changed to a size+bytearray couple, but then the "pass the blob" API makes it all the way into user APIs. We could implement the integer ID in userspace by creating a file in a shared directory by the name of the integer handle and serialize meta data into that. I'm not fond of either approach, but they're possible. Kristian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/11] drm/i915: prepare for fair lru eviction
On Fri, 2 Jul 2010 15:02:17 +0100, Chris Wilson wrote: > From: Daniel Vetter > > This does two little changes: > > - Add an alignment parameter for evict_something. It's not really great to > whack a carefully sized hole into the gtt with the wrong alignment. > Especially since the fallback path is a full evict. > > - With the inactive scan stuff we need to evict more that one object, so > move the unbind call into the helper function that scans for the object > to be evicted, too. And adjust its name. Doesn't compile -- i915_gem_get_fence_alignment undefined. pgpbKQXZO0lL1.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 07/11] drm/i915: prepare for fair lru eviction
On Fri, 2 Jul 2010 15:02:17 +0100, Chris Wilson wrote: > From: Daniel Vetter > > This does two little changes: > > - Add an alignment parameter for evict_something. It's not really great to > whack a carefully sized hole into the gtt with the wrong alignment. > Especially since the fallback path is a full evict. > > - With the inactive scan stuff we need to evict more that one object, so > move the unbind call into the helper function that scans for the object > to be evicted, too. And adjust its name. Doesn't compile -- i915_gem_get_fence_alignment undefined. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100708/82beade5/attachment-0001.pgp>
[PATCH] drm/gem: Add new flink_to ioctl
flink_to is similar to flink, but the global name is only made available to one other drm fd, identified by the existing drm_magic_t cookie mechanism. flink_to names are transient. Once the receiving fd opens a name, it goes away. flink_to lets application attach a binary blob of data to the name, which is passed to the receiving fd when it uses the open_with_data ioctl. This lets us pass meta data about the buffer along with the name, which generalizes how we currently passes object size, tile and swizzle information. With the flink_to ioctl, the X server can specify exactly which clients should be able to access the window buffers, which avoids leaking buffer access to other X servers or unpriviledged X clients. Signed-off-by: Kristian H?gsberg --- We've discussed how the current drm security model is broken in different ways before. This is my proposal for fixing it: - drm auth today is a bit in the file_priv, set by the drm master when a client requests it (typically through dri2 protocol). Doesn't take multiple masters or fine-grained buffers access into account. - broken in multiple masters world; vt switch, server drops master, then anybody can become master and auth themselves. client is now authenticated and can access all buffers from the X server. - XACE, no way to restrict access to window buffers, once one client is direct rendering to the window, all authenticated drm clients can access the buffers. What is flink_to - similar to flink, but global name is only made available to one other drm fd, identified by the existing drm_magic_t cookie mechanism. - flink_to names are transient, once the receiving fd opens it, it goes away. makes user space easier, we don't have to track "did we already flink_to this buffer to that client and what was the name". - flink_to fails if the receiving fd already has an flink_to name pending (EBUSY). this prevents unlimited flink_to names from piling up if the receiving fd doesn't open them. - flink_to twice on the same bo gives different names. - flink_to lets application attach a binary blob of data to the name (see below). How does flink_to fix the security problems - for dri2, the X server will use flink_to to grant each client access to the dri2 buffers as they call dri2 getbuffers on a per buffer basis. - drm applications that aren't X clients can't talk to dri2 and can't get access. vt switching doesn't affect this in any way. - xace can reject individual clients access to the dri2 extension, preventing those applications from accessing window buffers they aren't authorized for. Suggest to drop auth requirement for gem ioctls - rely on /dev/dri/card0 file permissions to restrict access to gpu to local users. similar to how it works for most other hw. - access to buffers is in the drm-with-mm world is what needs to be controlled. - keep auth and master requirement for kms and old drm ioctls - allows gpgpu type applications - risks: you now don't need to be an X client to access the gpu, malicious applications can starve or maybe crash gpu. malicious programs submitting hand-crafted batch buffers to read from absolute addresses? X front buffer location in gtt is pretty predictable. needs cmd checker or ppgtt or such to be 100% secure. Attached data - a mechanism to attach a binary blob to an flink_to buffer name. open_with_data returns the data. Userspace (typically libdrm) decides the layout and versioning of the blob and the contents will be chipset specific. it's an opaque blob to the kernel, which doesn't need to know about stride and formats etc. - applications use this to pass metadata about the buffer along with the buffer name. this keeps chipset specific details out of ipc. We already share object size, tiling and swizzling information through the kernel and need to ioctl immediately after gem_open to get those details. this mechanism lets us pass that info along with other meta data and return it all as we open the buffer with open_with_data. - EGLImage sharing: assign a global name to an EGLImage to share with a different process. Used by wayland or potentially other non-X systems. Khronos EGL extension in the works. Backwards compat - an flink_to name can be opened by old gem open, which succeeds if it was flinked_to magic 0 or the file_priv of the opener. If the name was flinked to magic 0, the name is not transient (it's not reclaimed by opening it). The X server can then use flink_to in getbuffers, and old and new clients can still use plain gem_open to open the buffers. This requires that clients only gem_open a name once per getbuffers request. this is currently true for all dri2 drivers. - Or could just introduce new getbuffers request that returns flink_to names for all buffers and no metadata (require the ddx driver to attach t
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 09:49:26 -0700, Jesse Barnes wrote: > That's the part I had trouble with as well. Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... Yeah, if the kernel doesn't need to know it, why is the kernel storing it? What options do we have here? -- keith.pack...@intel.com pgpy12T7JKXEu.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 09:49:26 -0700, Jesse Barnes wrote: > That's the part I had trouble with as well. Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... Yeah, if the kernel doesn't need to know it, why is the kernel storing it? What options do we have here? -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100708/c35f2fbd/attachment.pgp>
Re: [PATCH] drm/gem: Add new flink_to ioctl
> > My argument was based around that the current system is designed as a > > directory of opaque objects and so the extended attributes should be > > kept opaque to the kernel as well and left open to interpretation by > > userland. What I am most unclear about is under which circumstances is > > this backchannel communication preferable to passing the extra information > > over the IPC that needs to be performed anyway in order to open a surface. > > That's the part I had trouble with as well. Passing the blob through > the kernel saves a little IPC but also seems unnecessary, and so rubs > against my kernel minimalist side... Passing the blob through the kernel does give you a basis for more complex security since you can agree a blob format with the kernel security layer and add security hooks to the interface in future. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
* Justin P. Mattock wrote: > On 07/07/2010 11:44 PM, Ingo Molnar wrote: > > > >* Justin P. Mattock wrote: > > > >>On 07/02/10 13:04, Justin P. Mattock wrote: > >>>this is new(below) has anybody reported/bisected hit this yet > >>>(if not I'll bisect it) > >>> > >>>[drm] Num pipes: 1 > >>>[ 29.742432] [drm] writeback test succeeded in 1 usecs > >>>[ 30.089717] X:2252 conflicting memory types 4000-4800 > >>>uncached-minus<->write-combining > >>>[ 30.089721] reserve_memtype failed 0x4000-0x4800, track > >>>uncached-minus, req uncached-minus > >>>[ 30.123517] [drm] Num pipes: 1 > >>>[ 30.351017] X:2252 freeing invalid memtype 4000-4800 > >>>[ 30.354255] CPU 0 > >>>[ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm > >>>sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat > >>>nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack > >>>nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci > >>>firewire_core video battery ath9k ac ath9k_common joydev sky2 > >>>ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse > >>>aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null > >>>sha256_generic cbc des_generic cast5 blowfish serpent camellia > >>>twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 > >>>uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth > >>>coretemp acpi_cpufreq processor mperf appletouch applesmc > >>>uvcvideo[ 30.354255] > >>>[ 30.354255] Pid: 2252, comm: X Not tainted > >>>2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 > >>>[ 30.354255] RIP: 0010:[] > >>>[] radeon_read_ring_rptr+0x2b/0x2f [radeon] > >>>[ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 > >>>[ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: > >>>c9cf8000 > >>>[ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: > >>>8800385e8848 > >>>[ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: > >>>0010 > >>>[ 30.354255] R10: R11: ea930af0 R12: > >>>0010 > >>>[ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: > >>>8800385e8178 > >>>[ 30.354255] FS: 7f0aaa823840() > >>>GS:880001a0() knlGS: > >>>[ 30.354255] CS: 0010 DS: ES: CR0: 80050033 > >>>[ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: > >>>06f0 > >>>[ 30.354255] DR0: DR1: DR2: > >>> > >>>[ 30.354255] DR3: DR6: 0ff0 DR7: > >>>0400 > >>>[ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, > >>>task 880033dc5c40) > >>>[ 30.354255] 8800360dfc90 a0358130 8800360dfca8 > >>>a035881c > >>>[ 30.354255]<0> 8800385e8848 8800360dfcc8 > >>>a0359ac7 > >>>[ 30.354255]<0> 8800385e8848 8800360dfce8 > >>>a035c961 8800385e8848 > >>>[ 30.354255] [] > >>>radeon_get_ring_head+0x11/0x3c [radeon] > >>>[ 30.354255] [] radeon_commit_ring+0x48/0x97 > >>>[radeon] > >>>[ 30.354255] [] radeon_do_cp_idle+0x140/0x14d > >>>[radeon] > >>>[ 30.354255] [] > >>>radeon_apply_surface_regs+0x22/0x138 [radeon] > >>>[ 30.354255] [] free_surface+0xd8/0xee [radeon] > >>>[ 30.354255] [] > >>>radeon_driver_lastclose+0x3c/0x56 [radeon] > >>>[ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] > >>>[ 30.354255] [] drm_release+0x656/0x6a3 [drm] > >>>[ 30.354255] [] put_files_struct+0x65/0xb3 > >>>[ 30.354255] [] exit_files+0x46/0x4e > >>>[ 30.354255] [] do_exit+0x214/0x69f > >>>[ 30.354255] [] ? fput+0x1e2/0x1f1 > >>>[ 30.354255] [] do_group_exit+0x72/0x9a > >>>[ 30.354255] [] sys_exit_group+0x12/0x16 > >>>[ 30.354255] [] system_call_fastpath+0x16/0x1b > >>>[ 30.354255] RSP > >>>[ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- > >>>[ 30.354255] [] fput+0x122/0x1f1 > >>>[ 30.354255] [] filp_close+0x63/0x6d > >>> > >>>Justin P. Mattock > >> > >>o.k. finished bisecting.. the results point to this: 6a4f3b523 doing > >>a git revert gets me to startx without crashing and burning. > >>the problem code is this: > >>new->subtree_max_end = new->end; > >> > >>which sends me to: (if im reading correctly) > >>if (match->type != found_type&& newtype == NULL) > >> goto failure; > >> > >>so how/what might be happening here?! > > > >Could you please check latest upstream, which has this fix: > > > > b945d6b: rbtree: Undo augmented trees performance damage and regression > > > >Does it fix your X too? > > > >Thanks, > > > > Ingo > > > > > yep.. just pulled, everything looks good... Great - thanks for checking! Ingo
Re: linux-next: Tree for July 8 (nouveau)
On Thu, 8 Jul 2010 15:10:22 +1000 Stephen Rothwell wrote: > Hi all, > > Changes since 20100707: > > The i.MX tree mismerge has been fixed. > > The omap tree gained a conflict (involving serveral files) against the > arm tree. > > Should nouveau depend on PCI? It has build errors when PCI is disabled: drivers/gpu/drm/nouveau/nouveau_bios.c: In function 'load_vbios_pci': drivers/gpu/drm/nouveau/nouveau_bios.c:167: error: implicit declaration of function 'pci_enable_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:171: error: implicit declaration of function 'pci_map_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:171: warning: assignment makes pointer from integer without a cast drivers/gpu/drm/nouveau/nouveau_bios.c:175: error: implicit declaration of function 'pci_unmap_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:178: error: implicit declaration of function 'pci_disable_rom' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, 08 Jul 2010 17:37:20 +0100 Chris Wilson wrote: > On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg > wrote: > > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > > > On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg > > > wrote: > > > > > >> - a mechanism to attach a binary blob to an flink_to buffer name. > > >> open_with_data returns the data. Userspace (typically libdrm) > > >> decides the layout and versioning of the blob and the contents > > >> will be chipset specific. it's an opaque blob to the kernel, > > >> which doesn't need to know about stride and formats etc. > > > > > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > > > need to know all of this data, having it in an explicit (versioned) > > > format will protect applications from randomly mis-interpreting the data. > > > > I talked with ickle about that and whether or not to include a > > version+format u32 for the data in the ioctl args. He convinced me > > that the kernel didn't need to know about the layout of the blob and > > that requiring by convention that the first u32 of the blob is the > > version+format u32 would suffice. I can go either way on this, but I > > guess I have a small preference for making it part of the ioctl args > > as you suggest. > > I am not going to argue with someone who has been tackling the issue of > protocol extensions for 25 years... ;-) > > My argument was based around that the current system is designed as a > directory of opaque objects and so the extended attributes should be > kept opaque to the kernel as well and left open to interpretation by > userland. What I am most unclear about is under which circumstances is > this backchannel communication preferable to passing the extra information > over the IPC that needs to be performed anyway in order to open a surface. That's the part I had trouble with as well. Passing the blob through the kernel saves a little IPC but also seems unnecessary, and so rubs against my kernel minimalist side... -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: Add new flink_to ioctl
On Thu, 08 Jul 2010 17:37:20 +0100 Chris Wilson wrote: > On Thu, 8 Jul 2010 12:14:28 -0400, Kristian H?gsberg > wrote: > > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > > > On Thu, ?8 Jul 2010 11:23:25 -0400, Kristian H?gsberg > > bitplanet.net> wrote: > > > > > >> ?- a mechanism to attach a binary blob to an flink_to buffer name. > > >> ? ?open_with_data returns the data. ?Userspace (typically libdrm) > > >> ? ?decides the layout and versioning of the blob and the contents > > >> ? ?will be chipset specific. ?it's an opaque blob to the kernel, > > >> ? ?which doesn't need to know about stride and formats etc. > > > > > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > > > need to know all of this data, having it in an explicit (versioned) > > > format will protect applications from randomly mis-interpreting the data. > > > > I talked with ickle about that and whether or not to include a > > version+format u32 for the data in the ioctl args. He convinced me > > that the kernel didn't need to know about the layout of the blob and > > that requiring by convention that the first u32 of the blob is the > > version+format u32 would suffice. I can go either way on this, but I > > guess I have a small preference for making it part of the ioctl args > > as you suggest. > > I am not going to argue with someone who has been tackling the issue of > protocol extensions for 25 years... ;-) > > My argument was based around that the current system is designed as a > directory of opaque objects and so the extended attributes should be > kept opaque to the kernel as well and left open to interpretation by > userland. What I am most unclear about is under which circumstances is > this backchannel communication preferable to passing the extra information > over the IPC that needs to be performed anyway in order to open a surface. That's the part I had trouble with as well. Passing the blob through the kernel saves a little IPC but also seems unnecessary, and so rubs against my kernel minimalist side... -- Jesse Barnes, Intel Open Source Technology Center
linux-next: Tree for July 8 (nouveau)
On Thu, 8 Jul 2010 15:10:22 +1000 Stephen Rothwell wrote: > Hi all, > > Changes since 20100707: > > The i.MX tree mismerge has been fixed. > > The omap tree gained a conflict (involving serveral files) against the > arm tree. > > Should nouveau depend on PCI? It has build errors when PCI is disabled: drivers/gpu/drm/nouveau/nouveau_bios.c: In function 'load_vbios_pci': drivers/gpu/drm/nouveau/nouveau_bios.c:167: error: implicit declaration of function 'pci_enable_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:171: error: implicit declaration of function 'pci_map_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:171: warning: assignment makes pointer from integer without a cast drivers/gpu/drm/nouveau/nouveau_bios.c:175: error: implicit declaration of function 'pci_unmap_rom' drivers/gpu/drm/nouveau/nouveau_bios.c:178: error: implicit declaration of function 'pci_disable_rom' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg wrote: > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > > On Thu,  8 Jul 2010 11:23:25 -0400, Kristian Høgsberg > > wrote: > > > >>  - a mechanism to attach a binary blob to an flink_to buffer name. > >>   open_with_data returns the data.  Userspace (typically libdrm) > >>   decides the layout and versioning of the blob and the contents > >>   will be chipset specific.  it's an opaque blob to the kernel, > >>   which doesn't need to know about stride and formats etc. > > > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > > need to know all of this data, having it in an explicit (versioned) > > format will protect applications from randomly mis-interpreting the data. > > I talked with ickle about that and whether or not to include a > version+format u32 for the data in the ioctl args. He convinced me > that the kernel didn't need to know about the layout of the blob and > that requiring by convention that the first u32 of the blob is the > version+format u32 would suffice. I can go either way on this, but I > guess I have a small preference for making it part of the ioctl args > as you suggest. I am not going to argue with someone who has been tackling the issue of protocol extensions for 25 years... ;-) My argument was based around that the current system is designed as a directory of opaque objects and so the extended attributes should be kept opaque to the kernel as well and left open to interpretation by userland. What I am most unclear about is under which circumstances is this backchannel communication preferable to passing the extra information over the IPC that needs to be performed anyway in order to open a surface. -ickle -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: make sure rio_mem is valid before unmapping it
If we were not able to map the io bar in device init, don't attempt to unmap it in device fini. All radeons should have a io bar, so I doubt this would ever trigger, but just to be on the safe side... Pointed out by: Alberto Milone Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index d3e86f4..9b092b6 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -737,7 +737,8 @@ void radeon_device_fini(struct radeon_device *rdev) destroy_workqueue(rdev->wq); vga_switcheroo_unregister_client(rdev->pdev); vga_client_register(rdev->pdev, NULL, NULL, NULL); - pci_iounmap(rdev->pdev, rdev->rio_mem); + if (rdev->rio_mem) + pci_iounmap(rdev->pdev, rdev->rio_mem); rdev->rio_mem = NULL; iounmap(rdev->rmmio); rdev->rmmio = NULL; -- 1.7.0.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg > wrote: > >> - a mechanism to attach a binary blob to an flink_to buffer name. >> open_with_data returns the data. Userspace (typically libdrm) >> decides the layout and versioning of the blob and the contents >> will be chipset specific. it's an opaque blob to the kernel, >> which doesn't need to know about stride and formats etc. > > Arbitrary binary blobs considered harmful? Even if the kernel doesn't > need to know all of this data, having it in an explicit (versioned) > format will protect applications from randomly mis-interpreting the data. I talked with ickle about that and whether or not to include a version+format u32 for the data in the ioctl args. He convinced me that the kernel didn't need to know about the layout of the blob and that requiring by convention that the first u32 of the blob is the version+format u32 would suffice. I can go either way on this, but I guess I have a small preference for making it part of the ioctl args as you suggest. Kristian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg wrote: > - a mechanism to attach a binary blob to an flink_to buffer name. >open_with_data returns the data. Userspace (typically libdrm) >decides the layout and versioning of the blob and the contents >will be chipset specific. it's an opaque blob to the kernel, >which doesn't need to know about stride and formats etc. Arbitrary binary blobs considered harmful? Even if the kernel doesn't need to know all of this data, having it in an explicit (versioned) format will protect applications from randomly mis-interpreting the data. -- keith.pack...@intel.com pgpMl4MXVzFin.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: Add new flink_to ioctl
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian H?gsberg wrote: > - a mechanism to attach a binary blob to an flink_to buffer name. >open_with_data returns the data. Userspace (typically libdrm) >decides the layout and versioning of the blob and the contents >will be chipset specific. it's an opaque blob to the kernel, >which doesn't need to know about stride and formats etc. Arbitrary binary blobs considered harmful? Even if the kernel doesn't need to know all of this data, having it in an explicit (versioned) format will protect applications from randomly mis-interpreting the data. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100708/52b76845/attachment.pgp>
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
* Justin P. Mattock wrote: > On 07/02/10 13:04, Justin P. Mattock wrote: > >this is new(below) has anybody reported/bisected hit this yet > >(if not I'll bisect it) > > > >[drm] Num pipes: 1 > >[ 29.742432] [drm] writeback test succeeded in 1 usecs > >[ 30.089717] X:2252 conflicting memory types 4000-4800 > >uncached-minus<->write-combining > >[ 30.089721] reserve_memtype failed 0x4000-0x4800, track > >uncached-minus, req uncached-minus > >[ 30.123517] [drm] Num pipes: 1 > >[ 30.351017] X:2252 freeing invalid memtype 4000-4800 > >[ 30.354255] CPU 0 > >[ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm > >sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat > >nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack > >nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci > >firewire_core video battery ath9k ac ath9k_common joydev sky2 > >ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse > >aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null > >sha256_generic cbc des_generic cast5 blowfish serpent camellia > >twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 > >uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth > >coretemp acpi_cpufreq processor mperf appletouch applesmc > >uvcvideo[ 30.354255] > >[ 30.354255] Pid: 2252, comm: X Not tainted > >2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 > >[ 30.354255] RIP: 0010:[] > >[] radeon_read_ring_rptr+0x2b/0x2f [radeon] > >[ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 > >[ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: > >c9cf8000 > >[ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: > >8800385e8848 > >[ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: > >0010 > >[ 30.354255] R10: R11: ea930af0 R12: > >0010 > >[ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: > >8800385e8178 > >[ 30.354255] FS: 7f0aaa823840() > >GS:880001a0() knlGS: > >[ 30.354255] CS: 0010 DS: ES: CR0: 80050033 > >[ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: > >06f0 > >[ 30.354255] DR0: DR1: DR2: > > > >[ 30.354255] DR3: DR6: 0ff0 DR7: > >0400 > >[ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, > >task 880033dc5c40) > >[ 30.354255] 8800360dfc90 a0358130 8800360dfca8 > >a035881c > >[ 30.354255] <0> 8800385e8848 8800360dfcc8 > >a0359ac7 > >[ 30.354255] <0> 8800385e8848 8800360dfce8 > >a035c961 8800385e8848 > >[ 30.354255] [] > >radeon_get_ring_head+0x11/0x3c [radeon] > >[ 30.354255] [] radeon_commit_ring+0x48/0x97 > >[radeon] > >[ 30.354255] [] radeon_do_cp_idle+0x140/0x14d > >[radeon] > >[ 30.354255] [] > >radeon_apply_surface_regs+0x22/0x138 [radeon] > >[ 30.354255] [] free_surface+0xd8/0xee [radeon] > >[ 30.354255] [] > >radeon_driver_lastclose+0x3c/0x56 [radeon] > >[ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] > >[ 30.354255] [] drm_release+0x656/0x6a3 [drm] > >[ 30.354255] [] put_files_struct+0x65/0xb3 > >[ 30.354255] [] exit_files+0x46/0x4e > >[ 30.354255] [] do_exit+0x214/0x69f > >[ 30.354255] [] ? fput+0x1e2/0x1f1 > >[ 30.354255] [] do_group_exit+0x72/0x9a > >[ 30.354255] [] sys_exit_group+0x12/0x16 > >[ 30.354255] [] system_call_fastpath+0x16/0x1b > >[ 30.354255] RSP > >[ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- > >[ 30.354255] [] fput+0x122/0x1f1 > >[ 30.354255] [] filp_close+0x63/0x6d > > > >Justin P. Mattock > > o.k. finished bisecting.. the results point to this: 6a4f3b523 doing > a git revert gets me to startx without crashing and burning. > the problem code is this: > new->subtree_max_end = new->end; > > which sends me to: (if im reading correctly) > if (match->type != found_type && newtype == NULL) > goto failure; > > so how/what might be happening here?! Could you please check latest upstream, which has this fix: b945d6b: rbtree: Undo augmented trees performance damage and regression Does it fix your X too? Thanks, Ingo
[PATCH] drm/gem: Add new flink_to ioctl
flink_to is similar to flink, but the global name is only made available to one other drm fd, identified by the existing drm_magic_t cookie mechanism. flink_to names are transient. Once the receiving fd opens a name, it goes away. flink_to lets application attach a binary blob of data to the name, which is passed to the receiving fd when it uses the open_with_data ioctl. This lets us pass meta data about the buffer along with the name, which generalizes how we currently passes object size, tile and swizzle information. With the flink_to ioctl, the X server can specify exactly which clients should be able to access the window buffers, which avoids leaking buffer access to other X servers or unpriviledged X clients. Signed-off-by: Kristian Høgsberg --- We've discussed how the current drm security model is broken in different ways before. This is my proposal for fixing it: - drm auth today is a bit in the file_priv, set by the drm master when a client requests it (typically through dri2 protocol). Doesn't take multiple masters or fine-grained buffers access into account. - broken in multiple masters world; vt switch, server drops master, then anybody can become master and auth themselves. client is now authenticated and can access all buffers from the X server. - XACE, no way to restrict access to window buffers, once one client is direct rendering to the window, all authenticated drm clients can access the buffers. What is flink_to - similar to flink, but global name is only made available to one other drm fd, identified by the existing drm_magic_t cookie mechanism. - flink_to names are transient, once the receiving fd opens it, it goes away. makes user space easier, we don't have to track "did we already flink_to this buffer to that client and what was the name". - flink_to fails if the receiving fd already has an flink_to name pending (EBUSY). this prevents unlimited flink_to names from piling up if the receiving fd doesn't open them. - flink_to twice on the same bo gives different names. - flink_to lets application attach a binary blob of data to the name (see below). How does flink_to fix the security problems - for dri2, the X server will use flink_to to grant each client access to the dri2 buffers as they call dri2 getbuffers on a per buffer basis. - drm applications that aren't X clients can't talk to dri2 and can't get access. vt switching doesn't affect this in any way. - xace can reject individual clients access to the dri2 extension, preventing those applications from accessing window buffers they aren't authorized for. Suggest to drop auth requirement for gem ioctls - rely on /dev/dri/card0 file permissions to restrict access to gpu to local users. similar to how it works for most other hw. - access to buffers is in the drm-with-mm world is what needs to be controlled. - keep auth and master requirement for kms and old drm ioctls - allows gpgpu type applications - risks: you now don't need to be an X client to access the gpu, malicious applications can starve or maybe crash gpu. malicious programs submitting hand-crafted batch buffers to read from absolute addresses? X front buffer location in gtt is pretty predictable. needs cmd checker or ppgtt or such to be 100% secure. Attached data - a mechanism to attach a binary blob to an flink_to buffer name. open_with_data returns the data. Userspace (typically libdrm) decides the layout and versioning of the blob and the contents will be chipset specific. it's an opaque blob to the kernel, which doesn't need to know about stride and formats etc. - applications use this to pass metadata about the buffer along with the buffer name. this keeps chipset specific details out of ipc. We already share object size, tiling and swizzling information through the kernel and need to ioctl immediately after gem_open to get those details. this mechanism lets us pass that info along with other meta data and return it all as we open the buffer with open_with_data. - EGLImage sharing: assign a global name to an EGLImage to share with a different process. Used by wayland or potentially other non-X systems. Khronos EGL extension in the works. Backwards compat - an flink_to name can be opened by old gem open, which succeeds if it was flinked_to magic 0 or the file_priv of the opener. If the name was flinked to magic 0, the name is not transient (it's not reclaimed by opening it). The X server can then use flink_to in getbuffers, and old and new clients can still use plain gem_open to open the buffers. This requires that clients only gem_open a name once per getbuffers request. this is currently true for all dri2 drivers. - Or could just introduce new getbuffers request that returns flink_to names for all buffers and no metadata (require the ddx driver to attach t
[Bug 28430] [865G] OOPS when stolen memory set to zero
https://bugs.freedesktop.org/show_bug.cgi?id=28430 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Chris Wilson 2010-07-08 03:01:26 PDT --- Eric applied the patch to his next tree, so it will be upstreamed with 2.6.36. Thanks. -- 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 28430] [865G] OOPS when stolen memory set to zero
https://bugs.freedesktop.org/show_bug.cgi?id=28430 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Chris Wilson 2010-07-08 03:01:26 PDT --- Eric applied the patch to his next tree, so it will be upstreamed with 2.6.36. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
* Justin P. Mattock wrote: > On 07/07/2010 11:44 PM, Ingo Molnar wrote: > > > >* Justin P. Mattock wrote: > > > >>On 07/02/10 13:04, Justin P. Mattock wrote: > >>>this is new(below) has anybody reported/bisected hit this yet > >>>(if not I'll bisect it) > >>> > >>>[drm] Num pipes: 1 > >>>[ 29.742432] [drm] writeback test succeeded in 1 usecs > >>>[ 30.089717] X:2252 conflicting memory types 4000-4800 > >>>uncached-minus<->write-combining > >>>[ 30.089721] reserve_memtype failed 0x4000-0x4800, track > >>>uncached-minus, req uncached-minus > >>>[ 30.123517] [drm] Num pipes: 1 > >>>[ 30.351017] X:2252 freeing invalid memtype 4000-4800 > >>>[ 30.354255] CPU 0 > >>>[ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm > >>>sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat > >>>nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack > >>>nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci > >>>firewire_core video battery ath9k ac ath9k_common joydev sky2 > >>>ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse > >>>aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null > >>>sha256_generic cbc des_generic cast5 blowfish serpent camellia > >>>twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 > >>>uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth > >>>coretemp acpi_cpufreq processor mperf appletouch applesmc > >>>uvcvideo[ 30.354255] > >>>[ 30.354255] Pid: 2252, comm: X Not tainted > >>>2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 > >>>[ 30.354255] RIP: 0010:[] > >>>[] radeon_read_ring_rptr+0x2b/0x2f [radeon] > >>>[ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 > >>>[ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: > >>>c9cf8000 > >>>[ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: > >>>8800385e8848 > >>>[ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: > >>>0010 > >>>[ 30.354255] R10: R11: ea930af0 R12: > >>>0010 > >>>[ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: > >>>8800385e8178 > >>>[ 30.354255] FS: 7f0aaa823840() > >>>GS:880001a0() knlGS: > >>>[ 30.354255] CS: 0010 DS: ES: CR0: 80050033 > >>>[ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: > >>>06f0 > >>>[ 30.354255] DR0: DR1: DR2: > >>> > >>>[ 30.354255] DR3: DR6: 0ff0 DR7: > >>>0400 > >>>[ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, > >>>task 880033dc5c40) > >>>[ 30.354255] 8800360dfc90 a0358130 8800360dfca8 > >>>a035881c > >>>[ 30.354255]<0> 8800385e8848 8800360dfcc8 > >>>a0359ac7 > >>>[ 30.354255]<0> 8800385e8848 8800360dfce8 > >>>a035c961 8800385e8848 > >>>[ 30.354255] [] > >>>radeon_get_ring_head+0x11/0x3c [radeon] > >>>[ 30.354255] [] radeon_commit_ring+0x48/0x97 > >>>[radeon] > >>>[ 30.354255] [] radeon_do_cp_idle+0x140/0x14d > >>>[radeon] > >>>[ 30.354255] [] > >>>radeon_apply_surface_regs+0x22/0x138 [radeon] > >>>[ 30.354255] [] free_surface+0xd8/0xee [radeon] > >>>[ 30.354255] [] > >>>radeon_driver_lastclose+0x3c/0x56 [radeon] > >>>[ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] > >>>[ 30.354255] [] drm_release+0x656/0x6a3 [drm] > >>>[ 30.354255] [] put_files_struct+0x65/0xb3 > >>>[ 30.354255] [] exit_files+0x46/0x4e > >>>[ 30.354255] [] do_exit+0x214/0x69f > >>>[ 30.354255] [] ? fput+0x1e2/0x1f1 > >>>[ 30.354255] [] do_group_exit+0x72/0x9a > >>>[ 30.354255] [] sys_exit_group+0x12/0x16 > >>>[ 30.354255] [] system_call_fastpath+0x16/0x1b > >>>[ 30.354255] RSP > >>>[ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- > >>>[ 30.354255] [] fput+0x122/0x1f1 > >>>[ 30.354255] [] filp_close+0x63/0x6d > >>> > >>>Justin P. Mattock > >> > >>o.k. finished bisecting.. the results point to this: 6a4f3b523 doing > >>a git revert gets me to startx without crashing and burning. > >>the problem code is this: > >>new->subtree_max_end = new->end; > >> > >>which sends me to: (if im reading correctly) > >>if (match->type != found_type&& newtype == NULL) > >> goto failure; > >> > >>so how/what might be happening here?! > > > >Could you please check latest upstream, which has this fix: > > > > b945d6b: rbtree: Undo augmented trees performance damage and regression > > > >Does it fix your X too? > > > >Thanks, > > > > Ingo > > > > > yep.. just pulled, everything looks good... Great - thanks for checking! Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
* Justin P. Mattock wrote: > On 07/02/10 13:04, Justin P. Mattock wrote: > >this is new(below) has anybody reported/bisected hit this yet > >(if not I'll bisect it) > > > >[drm] Num pipes: 1 > >[ 29.742432] [drm] writeback test succeeded in 1 usecs > >[ 30.089717] X:2252 conflicting memory types 4000-4800 > >uncached-minus<->write-combining > >[ 30.089721] reserve_memtype failed 0x4000-0x4800, track > >uncached-minus, req uncached-minus > >[ 30.123517] [drm] Num pipes: 1 > >[ 30.351017] X:2252 freeing invalid memtype 4000-4800 > >[ 30.354255] CPU 0 > >[ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm > >sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat > >nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack > >nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci > >firewire_core video battery ath9k ac ath9k_common joydev sky2 > >ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse > >aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null > >sha256_generic cbc des_generic cast5 blowfish serpent camellia > >twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 > >uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth > >coretemp acpi_cpufreq processor mperf appletouch applesmc > >uvcvideo[ 30.354255] > >[ 30.354255] Pid: 2252, comm: X Not tainted > >2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 > >[ 30.354255] RIP: 0010:[] > >[] radeon_read_ring_rptr+0x2b/0x2f [radeon] > >[ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 > >[ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: > >c9cf8000 > >[ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: > >8800385e8848 > >[ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: > >0010 > >[ 30.354255] R10: R11: ea930af0 R12: > >0010 > >[ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: > >8800385e8178 > >[ 30.354255] FS: 7f0aaa823840() > >GS:880001a0() knlGS: > >[ 30.354255] CS: 0010 DS: ES: CR0: 80050033 > >[ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: > >06f0 > >[ 30.354255] DR0: DR1: DR2: > > > >[ 30.354255] DR3: DR6: 0ff0 DR7: > >0400 > >[ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, > >task 880033dc5c40) > >[ 30.354255] 8800360dfc90 a0358130 8800360dfca8 > >a035881c > >[ 30.354255] <0> 8800385e8848 8800360dfcc8 > >a0359ac7 > >[ 30.354255] <0> 8800385e8848 8800360dfce8 > >a035c961 8800385e8848 > >[ 30.354255] [] > >radeon_get_ring_head+0x11/0x3c [radeon] > >[ 30.354255] [] radeon_commit_ring+0x48/0x97 > >[radeon] > >[ 30.354255] [] radeon_do_cp_idle+0x140/0x14d > >[radeon] > >[ 30.354255] [] > >radeon_apply_surface_regs+0x22/0x138 [radeon] > >[ 30.354255] [] free_surface+0xd8/0xee [radeon] > >[ 30.354255] [] > >radeon_driver_lastclose+0x3c/0x56 [radeon] > >[ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] > >[ 30.354255] [] drm_release+0x656/0x6a3 [drm] > >[ 30.354255] [] put_files_struct+0x65/0xb3 > >[ 30.354255] [] exit_files+0x46/0x4e > >[ 30.354255] [] do_exit+0x214/0x69f > >[ 30.354255] [] ? fput+0x1e2/0x1f1 > >[ 30.354255] [] do_group_exit+0x72/0x9a > >[ 30.354255] [] sys_exit_group+0x12/0x16 > >[ 30.354255] [] system_call_fastpath+0x16/0x1b > >[ 30.354255] RSP > >[ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- > >[ 30.354255] [] fput+0x122/0x1f1 > >[ 30.354255] [] filp_close+0x63/0x6d > > > >Justin P. Mattock > > o.k. finished bisecting.. the results point to this: 6a4f3b523 doing > a git revert gets me to startx without crashing and burning. > the problem code is this: > new->subtree_max_end = new->end; > > which sends me to: (if im reading correctly) > if (match->type != found_type && newtype == NULL) > goto failure; > > so how/what might be happening here?! Could you please check latest upstream, which has this fix: b945d6b: rbtree: Undo augmented trees performance damage and regression Does it fix your X too? Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
On 07/07/2010 11:44 PM, Ingo Molnar wrote: > > * Justin P. Mattock wrote: > >> On 07/02/10 13:04, Justin P. Mattock wrote: >>> this is new(below) has anybody reported/bisected hit this yet >>> (if not I'll bisect it) >>> >>> [drm] Num pipes: 1 >>> [ 29.742432] [drm] writeback test succeeded in 1 usecs >>> [ 30.089717] X:2252 conflicting memory types 4000-4800 >>> uncached-minus<->write-combining >>> [ 30.089721] reserve_memtype failed 0x4000-0x4800, track >>> uncached-minus, req uncached-minus >>> [ 30.123517] [drm] Num pipes: 1 >>> [ 30.351017] X:2252 freeing invalid memtype 4000-4800 >>> [ 30.354255] CPU 0 >>> [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm >>> sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat >>> nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack >>> nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci >>> firewire_core video battery ath9k ac ath9k_common joydev sky2 >>> ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse >>> aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null >>> sha256_generic cbc des_generic cast5 blowfish serpent camellia >>> twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 >>> uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth >>> coretemp acpi_cpufreq processor mperf appletouch applesmc >>> uvcvideo[ 30.354255] >>> [ 30.354255] Pid: 2252, comm: X Not tainted >>> 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 >>> [ 30.354255] RIP: 0010:[] >>> [] radeon_read_ring_rptr+0x2b/0x2f [radeon] >>> [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 >>> [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: >>> c9cf8000 >>> [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: >>> 8800385e8848 >>> [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: >>> 0010 >>> [ 30.354255] R10: R11: ea930af0 R12: >>> 0010 >>> [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: >>> 8800385e8178 >>> [ 30.354255] FS: 7f0aaa823840() >>> GS:880001a0() knlGS: >>> [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 >>> [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: >>> 06f0 >>> [ 30.354255] DR0: DR1: DR2: >>> >>> [ 30.354255] DR3: DR6: 0ff0 DR7: >>> 0400 >>> [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, >>> task 880033dc5c40) >>> [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 >>> a035881c >>> [ 30.354255]<0> 8800385e8848 8800360dfcc8 >>> a0359ac7 >>> [ 30.354255]<0> 8800385e8848 8800360dfce8 >>> a035c961 8800385e8848 >>> [ 30.354255] [] >>> radeon_get_ring_head+0x11/0x3c [radeon] >>> [ 30.354255] [] radeon_commit_ring+0x48/0x97 >>> [radeon] >>> [ 30.354255] [] radeon_do_cp_idle+0x140/0x14d >>> [radeon] >>> [ 30.354255] [] >>> radeon_apply_surface_regs+0x22/0x138 [radeon] >>> [ 30.354255] [] free_surface+0xd8/0xee [radeon] >>> [ 30.354255] [] >>> radeon_driver_lastclose+0x3c/0x56 [radeon] >>> [ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] >>> [ 30.354255] [] drm_release+0x656/0x6a3 [drm] >>> [ 30.354255] [] put_files_struct+0x65/0xb3 >>> [ 30.354255] [] exit_files+0x46/0x4e >>> [ 30.354255] [] do_exit+0x214/0x69f >>> [ 30.354255] [] ? fput+0x1e2/0x1f1 >>> [ 30.354255] [] do_group_exit+0x72/0x9a >>> [ 30.354255] [] sys_exit_group+0x12/0x16 >>> [ 30.354255] [] system_call_fastpath+0x16/0x1b >>> [ 30.354255] RSP >>> [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- >>> [ 30.354255] [] fput+0x122/0x1f1 >>> [ 30.354255] [] filp_close+0x63/0x6d >>> >>> Justin P. Mattock >> >> o.k. finished bisecting.. the results point to this: 6a4f3b523 doing >> a git revert gets me to startx without crashing and burning. >> the problem code is this: >> new->subtree_max_end = new->end; >> >> which sends me to: (if im reading correctly) >> if (match->type != found_type&& newtype == NULL) >> goto failure; >> >> so how/what might be happening here?! > > Could you please check latest upstream, which has this fix: > >b945d6b: rbtree: Undo augmented trees performance damage and regression > > Does it fix your X too? > > Thanks, > > Ingo > yep.. just pulled, everything looks good... Justin P. Mattock
Re: [bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
On 07/07/2010 11:44 PM, Ingo Molnar wrote: * Justin P. Mattock wrote: On 07/02/10 13:04, Justin P. Mattock wrote: this is new(below) has anybody reported/bisected hit this yet (if not I'll bisect it) [drm] Num pipes: 1 [ 29.742432] [drm] writeback test succeeded in 1 usecs [ 30.089717] X:2252 conflicting memory types 4000-4800 uncached-minus<->write-combining [ 30.089721] reserve_memtype failed 0x4000-0x4800, track uncached-minus, req uncached-minus [ 30.123517] [drm] Num pipes: 1 [ 30.351017] X:2252 freeing invalid memtype 4000-4800 [ 30.354255] CPU 0 [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc uvcvideo[ 30.354255] [ 30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 [ 30.354255] RIP: 0010:[] [] radeon_read_ring_rptr+0x2b/0x2f [radeon] [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: c9cf8000 [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 8800385e8848 [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 0010 [ 30.354255] R10: R11: ea930af0 R12: 0010 [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 8800385e8178 [ 30.354255] FS: 7f0aaa823840() GS:880001a0() knlGS: [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 06f0 [ 30.354255] DR0: DR1: DR2: [ 30.354255] DR3: DR6: 0ff0 DR7: 0400 [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 880033dc5c40) [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 a035881c [ 30.354255]<0> 8800385e8848 8800360dfcc8 a0359ac7 [ 30.354255]<0> 8800385e8848 8800360dfce8 a035c961 8800385e8848 [ 30.354255] [] radeon_get_ring_head+0x11/0x3c [radeon] [ 30.354255] [] radeon_commit_ring+0x48/0x97 [radeon] [ 30.354255] [] radeon_do_cp_idle+0x140/0x14d [radeon] [ 30.354255] [] radeon_apply_surface_regs+0x22/0x138 [radeon] [ 30.354255] [] free_surface+0xd8/0xee [radeon] [ 30.354255] [] radeon_driver_lastclose+0x3c/0x56 [radeon] [ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] [ 30.354255] [] drm_release+0x656/0x6a3 [drm] [ 30.354255] [] put_files_struct+0x65/0xb3 [ 30.354255] [] exit_files+0x46/0x4e [ 30.354255] [] do_exit+0x214/0x69f [ 30.354255] [] ? fput+0x1e2/0x1f1 [ 30.354255] [] do_group_exit+0x72/0x9a [ 30.354255] [] sys_exit_group+0x12/0x16 [ 30.354255] [] system_call_fastpath+0x16/0x1b [ 30.354255] RSP [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- [ 30.354255] [] fput+0x122/0x1f1 [ 30.354255] [] filp_close+0x63/0x6d Justin P. Mattock o.k. finished bisecting.. the results point to this: 6a4f3b523 doing a git revert gets me to startx without crashing and burning. the problem code is this: new->subtree_max_end = new->end; which sends me to: (if im reading correctly) if (match->type != found_type&& newtype == NULL) goto failure; so how/what might be happening here?! Could you please check latest upstream, which has this fix: b945d6b: rbtree: Undo augmented trees performance damage and regression Does it fix your X too? Thanks, Ingo yep.. just pulled, everything looks good... Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
