[Bug 23894] [bisected i915] 9 piglit tests segmentation fault
http://bugs.freedesktop.org/show_bug.cgi?id=23894 Shuang He changed: What|Removed |Added AssignedTo|dri-|e...@anholt.net |de...@lists.sourceforge.net | Summary|[bisected i915] some piglit |[bisected i915] 9 piglit |tests failed|tests segmentation fault -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23894] New: [bisected i915] some piglit tests failed
http://bugs.freedesktop.org/show_bug.cgi?id=23894 Summary: [bisected i915] some piglit tests failed Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: major Priority: high Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: shuang...@intel.com System Environment: -- Platform: 945GM Libdrm: (master)67e4172394a88d4922fb8d9c7c3d96ce7e02c5a6 Mesa: (master)57d16c4cc37689710f951cb13981e2efc160cd23 Xserver:(master)8fb3fa28a5a1b36cdaad38055a607400828b9e1c Xf86_video_intel: (master)efbcf29dd1a1ca058b7a2a93f0685102c06c9369 Kernel: (drm-intel-next)7e61615857c6fb3afbcb43f5c4e97511a923f5a8 Bug detailed description: - This issue happens on 945GM and 945G, but seems not happening with mesa_7_6_branch on another 945GME. Some piglit tests (general/read-front, general/texgen, shaders/fp-kil, shaders/fp-lit-mask, shaders/trinity-fp1, shaders/fp-incomplete-tex, shaders/fp-fragment-position, mesa/crossbar, texturing/texrect-many) will segement falut due to following commit: Author: Eric Anholt Date: Thu Sep 10 09:26:38 2009 -0700 intel: Don't forget to map the depth read buffer in spans. This broke BlitFramebufferEXT(GL_DEPTH_BUFFER_BIT). ./read-front (gdb) bt #0 0x in ?? () #1 0xb7bb60ff in _swrast_read_rgba_span (ctx=0x90838a0, rb=0x93c0b78, n=1, x=0, y=0, dstType=5126, rgba=0xb77fe008) at swrast/s_span.c:1583 #2 0xb7bb4c28 in _swrast_ReadPixels (ctx=0x90838a0, x=0, y=0, width=1, height=1, format=6407, type=5126, packing=0x90907c4, pixels=0xbfcf3254) at swrast/s_readpix.c:422 #3 0xb7a907ce in intelReadPixels (ctx=0x90838a0, x=0, y=0, width=1, height=1, format=6407, type=5126, pack=0x90907c4, pixels=0xbfcf3254) at intel_pixel_read.c:314 #4 0xb7b30dd3 in _mesa_ReadPixels (x=0, y=0, width=1, height=1, format=6407, type=5126, pixels=0xbfcf3254) at main/readpix.c:208 #5 0x08049c2d in piglit_probe_pixel_rgb () #6 0x080497c4 in display () #7 0xb7eb54e2 in processWindowWorkList (window=0x9070d60) at glut_event.c:1306 #8 0xb7eb6138 in glutMainLoop () at glut_event.c:1356 #9 0x080499a7 in main () -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 --- Comment #7 from Krzysztof A. Sobiecki 2009-09-12 18:03:31 PST --- Created an attachment (id=29460) --> (http://bugs.freedesktop.org/attachment.cgi?id=29460) Small patch based on http://bugs.freedesktop.org/show_bug.cgi?id=22271#c5 Apply patch and recompile radeon.ko(make drivers/gpu/drm/radeon/radeon.ko) to replace old one. You should start the test again after that. If test works(both ret's are 0) after applying patch, #23816 is a duplicate of #22271 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816
--- Comment #6 from Kevin DeKorte 2009-09-12 16:05:34 PST
---
output from make test
sudo make test
[sudo] password for kdekorte:
./test_ioctl
ret 0
val 38296
./ia32-test_ioctl
ret -22
val 0
output from dmesg
ioctl32(ia32-test_ioctl:9436): Unknown cmd fd(3) cmd(c0106467){t:'d';sz:16}
arg(ffd710c4) on /dev/dri/card0
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 Krzysztof A. Sobiecki changed: What|Removed |Added CC||sob...@gmail.com --- Comment #5 from Krzysztof A. Sobiecki 2009-09-12 13:30:04 PST --- By the way, I think It's really a duplicate of #22271, I could set it that way, but Michel may disagree with my opinion, so I will wait for his action. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 --- Comment #4 from Krzysztof A. Sobiecki 2009-09-12 13:25:29 PST --- Created an attachment (id=29459) --> (http://bugs.freedesktop.org/attachment.cgi?id=29459) Small ioctl test I meant dristat -v. It actually works. That what I get for mindlessly copying test cases from other bugs. You can also try my small ioctl test I have attached. just run "make" and then "make test" to run test. It should work on KMS, since only on it I had ioctl32 problems. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
Luc Verhaegen wrote: > On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote: > >>> What should the canonical source of such versioning information be? >>> >>> * This header file defines the interface, and this versioning included >>> in the same headerfile should then niquely identify this interface. >>> * driver builds against this header and should then require this version >>> of the interface from the drm as well. It might choose to have some >>> build time or run time workarounds if the developer decides to spend >>> time on this, but it doesn't need to. >>> >> No thats where you got it wrong, a driver should never *require* version >> of interface at runtime == version of interface at build time. We >> rarely make incompatible major number changes in the kernel drivers, >> (radeon kms being the first in my memory). DRM drivers ship in the >> kernel, not separately so dealing with inequality of version isn't >> optional. >> > > It is exactly such a major change that made this version numbering > necessary in the header file. > > >> So from what I can see this solves a compile time problem, not a run time. >> Generally this has been solved in other ways, either requiring when >> the driver needs a newer version of the header it requires a new libdrm >> or when the driver needs a newer version of the header it ships it within >> itself. >> > > No it is not, the interfaces are not compatible. This patch will not > be put in everywhere immediately. How does a graphics driver give the > user a reason for why the whole thing came crashing down, while things > worked just fine before the kernel update that joe user most likely > will not immediately see as the reason for this breakage? > > I really do not see what the problem is with having the driver version > carried around in the interface headerfile. X driver, mesa and drm > driver build with that. drm claims this version. If this version is not > compatible, both X driver and mesa can then try to handle this > gracefully. If you choose to have the driver fail hard with an error > message, then fine, it at least is better than having half the userbase > complain that their drm wasn't initialised fully, for no visible > reason. > > >> Its just not been required before and I'd like to understand why no-one >> else has had the requirement over the other 8 or so drm/dri drivers >> produced. Generally I think we avoid it because it links the build and >> runtime versioning, which isn't something that a driver should ever do. >> > > Isn't versioning a common scheme to be able to handle both run and > build time compatibility in a halfdecent manner? What use is > runtime-only or buildtime-only versioning? > > Are you against this because carrying a versioning information makes it > possible to do major changes gracefully and therefor encourages major > changes and therefor is totally unacceptable? > > That almost sounds like saying that people shouldn't use electricity at > all because it could mean that a whole team of people in a nuclear > power plant will end up doing the wrong thing, every few weeks. > > >> But if *chrome all agrees its a good plan, then I'll take a patch, >> it would be nice if TH signs off on it. >> > > We discussed it out fully 3.5 years ago, and TH committed it 3.5ys > ago, and he has nicely kept up the version bumping since from his side. > > What is it that you still require here? > Yes, IIRC we moved that over to via_drm.h because Luc wanted a full check at compile time for the unichrome driver, whereas openchrome knows what DRM versions it works with and judges the compile-time compatibility from other defines. While I don't think it's necessary, I have nothing against having versioning in via_drm.h. /Thomas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 2/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI - C file
Bruce, others. This patch series raises a number of questions. 1) It seems to do a lot more than just fixing a hang issue. See below. 2) There are code cleanups mixed with other stuff, which makes the patches difficult to read. Can you supply the code cleanups as separate patches? As for the additional functionality: a) You define AGP headers 3) and 4). I can't find a description of them in any documentation I have. Are they described somewhere in your open-source code? What do they do? b) You define a separate command submission mechanism for video. Why is that needed? c) You define a double-buffered AGP operation mode instead of the ring-buffer mode? Why is that needed? d) You define a via authmagic IOCTL that seems to do nothing? What is the purpose of this ioctl? e) Why is the INIT_JUDGE ioctl needed? The init ioctl should only be called by the DRM master and surely it must be able to keep track of that itself? f) From what I can see, the AGP buffers submitted though the video command submission mechanism are never checked by the command verifier? g) The GET_INFO ioctl should probably be replaced with a GETPARAM ioctl, (see how other drivers have done this). h) The suspend / resume functionality seems to duplicate a lot of stuff done in the X server driver. For example the 3D engine initialization is done there IIRC. More seriously, it seems like most of these additions are there to support a mode where an (unauthorized) drm client prepare double command buffers for submission directly in AGP memory, without any command checking and has access to the register map, and given the insecure nature of the unichrome, that should never be allowed unless perhaps in an "embedded" mode which should never be turned on by default. Currently, unichrome security is enforced in the following way: 1) No user-space processes except the DRM master may access the register maps. 2) All other user-space processes including 3d clients and video players *MUST* write to registers through DRM. 3) All AGP command buffers must be checked by the command verifier. If you want to add functionality, please use one patch per functionality item if possible. If there is a fix for a hang, plase supply that fix in a single patch. Thanks, Thomas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816
--- Comment #3 from Kevin DeKorte 2009-09-12 10:09:10 PST
---
Both drmstat 32bit and 64 bit give errors when run, they look like this..
64bit
./drmstat -v -O /dev/dri/card0
No driver available
/home/kdekorte/git/drm/tests/.libs/lt-drmstat: error 1 (Operation not
permitted)
32bit
./drmstat -v -O /dev/dri/card0
No driver available
/home/kdekorte/git/drm-32/tests/.libs/lt-drmstat: error 1 (Operation not
permitted)
Running under root does not make a difference. Do I need to have X shutdown
when I do this?
however when I run the 32bit app I get this message from dmesg
ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0246400){t:'d';sz:36}
arg(08058008) on /dev/dri/card0
ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0106407){t:'d';sz:16}
arg(ffc5cc10) on /dev/dri/card0
ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0086401){t:'d';sz:8}
arg(ffc5cc08) on /dev/dri/card0
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 --- Comment #2 from Krzysztof A. Sobiecki 2009-09-12 09:19:41 PST --- Can you try running 32bit "drmstat -v -O /dev/dri/card0" on problematic kernel? Comparing its output with 64bit version should show what is wrong. If drmstat fails, dmesg will be also valuable. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add async event synchronization for drmWaitVblank
On Sat, 12 Sep 2009 16:02:10 +0200 Thomas Hellstrom wrote: > Jesse Barnes wrote: > > On Fri, 11 Sep 2009 14:33:34 -0400 > > "Kristian Høgsberg" wrote: > > > > > >> This patch adds a new flag to the drmWaitVblank ioctl, which asks > >> the drm to return immediately and notify userspace when the > >> specified vblank sequence happens by sending an event back on the > >> drm fd. > >> > >> The event mechanism works with the other flags supported by the > >> ioctls, specifically, the vblank sequence can be specified > >> relatively or absolutely, and works for primary and seconday crtc. > >> > >> The signal field of the vblank request is used to provide user > >> data, which will be sent back to user space in the vblank event. > >> > >> Signed-off-by: Kristian Høgsberg > >> --- > >> > > > > Looks nice, we should get this into 2.6.32. The last page flip > > patch should be approximately ready too right? IIRC the only thing > > left on the kernel side was to add some padding to the request > > struct; the rest was userland and driver specific stuff (though > > I'll have to go through the discussion to be sure). > > > Kristian, Jesse, > > This patch looks good. In particular I like the way a new spinlock is > used instead of dev->struct_mutex. > > For the vblank stuff I think we agreed that the driver cs mechanism > should do the blocking and not dri2, which means that the cs > mechanism of the supported drivers will need modification. Right, we don't want to unnecessarily block clients. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23474] xrandr doesn't pick up on 1600x1200 modeline
http://bugs.freedesktop.org/show_bug.cgi?id=23474 --- Comment #11 from Michael de Lang 2009-09-12 08:38:45 PST --- Created an attachment (id=29457) --> (http://bugs.freedesktop.org/attachment.cgi?id=29457) non-KMS Xorg log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23474] xrandr doesn't pick up on 1600x1200 modeline
http://bugs.freedesktop.org/show_bug.cgi?id=23474 --- Comment #10 from Michael de Lang 2009-09-12 08:38:19 PST --- Sorry for the delay, I managed to get ill. Here's the non-KMS log without the modeline added to the xorg.conf. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] PCI/VGA: fix header commentary
Signed-off-by: Tiago Vignatti --- Amend this somewhere, Jesse. Thanks. include/linux/vgaarb.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index e81c64a..290409c 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -1,5 +1,5 @@ /* - * vgaarb.c + * vgaarb.h * * (C) Copyright 2005 Benjamin Herrenschmidt * (C) Copyright 2007 Paulo R. Zanoni -- 1.5.6.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] mesa/st: Create front renderbuffer on the fly when supplied
>From f08d6efbc85609d1384006b773ea0a3276eb1e67 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Nicolai=20H=C3=A4hnle?=
Date: Sat, 12 Sep 2009 16:49:31 +0200
Subject: [PATCH] mesa/st: Create front renderbuffer on the fly when supplied
with a surface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Normally, the mesa/st would create a fake front buffer out of a
client-allocated surface.
In the DRI setting, however, st/dri provides a front buffer surface which is
created and maintained by the X server. Prefer to use this surface instead,
so that front buffer rendering and reading works correctly.
Signed-off-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_framebuffer.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_framebuffer.c
b/src/mesa/state_tracker/st_framebuffer.c
index ca32b2e..5c0d335 100644
--- a/src/mesa/state_tracker/st_framebuffer.c
+++ b/src/mesa/state_tracker/st_framebuffer.c
@@ -66,7 +66,7 @@ st_create_framebuffer( const __GLcontextModes *visual,
else {
/* Only allocate front buffer right now if we're single buffered.
* If double-buffered, allocate front buffer on demand later.
- * See check_create_front_buffers().
+ * See check_create_front_buffers() and
st_set_framebuffer_surface().
*/
struct gl_renderbuffer *rb
= st_new_renderbuffer_fb(colorFormat, samples, FALSE);
@@ -170,8 +170,20 @@ st_set_framebuffer_surface(struct st_framebuffer *stfb,
strb = st_renderbuffer(stfb->Base.Attachment[surfIndex].Renderbuffer);
- /* fail */
- if (!strb) return;
+ if (!strb) {
+ if (surfIndex == ST_SURFACE_FRONT_LEFT) {
+ /* Delayed creation when the window system supplies a fake front
buffer */
+ struct st_renderbuffer *strb_back
+= st_renderbuffer(stfb-
>Base.Attachment[ST_SURFACE_BACK_LEFT].Renderbuffer);
+ struct gl_renderbuffer *rb
+= st_new_renderbuffer_fb(surf->format, strb_back-
>Base.NumSamples, FALSE);
+ _mesa_add_renderbuffer(&stfb->Base, BUFFER_FRONT_LEFT, rb);
+ strb = st_renderbuffer(rb);
+ } else {
+ /* fail */
+ return;
+ }
+ }
/* replace the renderbuffer's surface/texture pointers */
pipe_surface_reference( &strb->surface, surf );
--
1.6.0.4
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers
>From 471cf346d0e9bf0bd97f2e652fd3052ba8f7a0c7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Nicolai=20H=C3=A4hnle?=
Date: Sat, 12 Sep 2009 12:13:35 +0200
Subject: [PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_cb_fbo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index a966028..aad8493 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -258,8 +258,9 @@ st_new_renderbuffer_fb(enum pipe_format format, int
samples, boolean sw)
strb->Base.ClassID = 0x4242; /* just a unique value */
strb->Base.NumSamples = samples;
strb->format = format;
+ init_renderbuffer_bits(strb, format);
strb->software = sw;
switch (format) {
case PIPE_FORMAT_A8R8G8B8_UNORM:
case PIPE_FORMAT_B8G8R8A8_UNORM:
--
1.6.0.4
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23781] Wine + Civ4 BTS crashes after a short time
http://bugs.freedesktop.org/show_bug.cgi?id=23781 --- Comment #2 from Frej Soya Rasmussen 2009-09-12 07:54:56 PST --- Created an attachment (id=29456) --> (http://bugs.freedesktop.org/attachment.cgi?id=29456) radeon_debug=all trace (last 10k lines) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23781] Wine + Civ4 BTS crashes after a short time
http://bugs.freedesktop.org/show_bug.cgi?id=23781 --- Comment #1 from Frej Soya Rasmussen 2009-09-12 07:47:30 PST --- Too big (22mb) to be attached. http://omploader.org/vMmMzZA/debug.7z RADEOEN_DEBUG=all trace of crash. Sadly it takes quite a bit longer to reproduce so (likely because of slowness in rending when debugging is on) the file is ~2.9GB extracted. Before the assertion i always get one or more of: bo(0xa10920a8, 65536) is mapped (-1) can't valide it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23883] no mouse-pointer on secound screen with kms enabled
http://bugs.freedesktop.org/show_bug.cgi?id=23883 --- Comment #1 from Michael Mair-Keimberger 2009-09-12 07:02:17 PST --- Created an attachment (id=29453) --> (http://bugs.freedesktop.org/attachment.cgi?id=29453) Xorg Log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add async event synchronization for drmWaitVblank
Jesse Barnes wrote: > On Fri, 11 Sep 2009 14:33:34 -0400 > "Kristian Høgsberg" wrote: > > >> This patch adds a new flag to the drmWaitVblank ioctl, which asks the >> drm to return immediately and notify userspace when the specified >> vblank sequence happens by sending an event back on the drm fd. >> >> The event mechanism works with the other flags supported by the >> ioctls, specifically, the vblank sequence can be specified relatively >> or absolutely, and works for primary and seconday crtc. >> >> The signal field of the vblank request is used to provide user data, >> which will be sent back to user space in the vblank event. >> >> Signed-off-by: Kristian Høgsberg >> --- >> > > Looks nice, we should get this into 2.6.32. The last page flip patch > should be approximately ready too right? IIRC the only thing left on > the kernel side was to add some padding to the request struct; the rest > was userland and driver specific stuff (though I'll have to go through > the discussion to be sure). > Kristian, Jesse, This patch looks good. In particular I like the way a new spinlock is used instead of dev->struct_mutex. For the vblank stuff I think we agreed that the driver cs mechanism should do the blocking and not dri2, which means that the cs mechanism of the supported drivers will need modification. /Thomas > Reviewed-by: Jesse Barnes > > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23883] New: no mouse-pointer on secound screen with kms enabled
http://bugs.freedesktop.org/show_bug.cgi?id=23883 Summary: no mouse-pointer on secound screen with kms enabled Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: bu9zi...@gmail.com Created an attachment (id=29452) --> (http://bugs.freedesktop.org/attachment.cgi?id=29452) Xorg configuration File If updated my system to the latest git version of mesa, xf86-video-ati and libdrm in order to get kms and dri working. Latest git-clone was today. Kernel Version is 2.6.31 (gentoo-sources). xorg-server Version is the latest RC (1.6.3.901, from the gentoo-portage tree) So far everything works quite fine. But i have dual-head System and on my right screen i have no mouse pointer (xrandr says its the first screen = DVI-0) Clicking and doing stuff works well on the right screen. The only Problem is, that i don't see where my mouse-pointer is. Without kms enabled at boot, i have a mouse-pointer on both screens. As attachment if added the Xorg.0.log, xorg.conf and an emerge --info. Hopefully it can you. If you need more info, please let me know. Actually i'am not sure if its correct to post the bug here, because if its only kms related i don't know on which component i should open this bug. Or should i open an bug report on bugs.kernel.org? Michael PS: kms is awesome :D emerge --info: Portage 2.1.6.13 (default/linux/amd64/10.0/no-multilib, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.31-gentoo x86_64) = System uname: linux-2.6.31-gentoo-x86_64-intel-r-_core-tm-2_cpu_66...@_2.40ghz-with-gentoo-2.0.1 Timestamp of tree: Sat, 12 Sep 2009 08:15:02 + ccache version 2.4 [enabled] app-shells/bash: 4.0_p28 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.6.2-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=nocona -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=nocona -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="candy ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"; LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1,--hash-style=gnu,--as-needed" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/kde-testing /usr/local/portage/layman/x11 /media/overlays/local" SYNC="rsync://192.168.2.60/gentoo-portage" USE="X acl alsa amd64 berkdb bzip2 cdr cli consolekit cracklib crypt cups dbus dri dvd dvdr dvdread exif fortran gdbm gif gnutls gpm hal iconv ipv6 isdnlog jpeg kde kipi lm_sensors mad mmx mmxext mng mp3 mudflap ncurses nls nptl nptlonly opengl openmp pam pcre perl phonon png policykit pppd python readline reflection sasl sdl semantic-desktop session spell spl sse sse2 ssl ssse3 sysfs tcpd tiff truetype unicode v4l2 vorbis xcomposite xinerama xml xorg xv xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ex
Re: Radeon r6xx with KMS not working
2009/9/11 Mike Lothian : > 2009/9/9 Alex Deucher : >> On Tue, Sep 8, 2009 at 8:20 PM, Mike Lothian wrote: >>> 2009/9/9 Alex Deucher : On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothian wrote: > 2009/9/8 Mike Lothian : >> 2009/9/8 Alex Deucher : >>> On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothian wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) >>> >>> [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). >>> [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). >>> >>> Pull the latest from the drm-next branch. >>> >>> Alex >>> >> >> Just noticed that after Perry pointed out the fix on Phoronix >> >> Thanks >> >> Will let you know how I get on >> > > The good news is that KMS now works, the bad news is KDM still wont > start with compositing. Plain X works and glxgears work as does KDM > with compositing off > > Glxgears says: > IRQ's not enabled, falling back to busy waits: 2 1 > do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working > correctly. > > My dmesg says: > > Unpin not necessary for 88007c9a1600 ! > Unpin not necessary for 88006eda6400 ! > Unpin not necessary for 88006b14d400 ! > > I couldn't see anything in my Xorg.0.log file that would explain why > KDM keeps rebooting > > Is there anything else that might be useful? > kde GL compositing doesn't work that well at the moment even without KMS. Alex >>> >>> I'm reporting a regression from the r6xx-r7xx-3d tree, the new code >>> causes X to restart >>> >> >> It's not a regression as KMS did not work until recently; lots of >> stuff has problems in dri2 mode with the current r600 3d driver. Or >> are you saying that the drm-next code with KMS disabled is causing a >> problem? >> >> Alex >> > > Might I just add that this is repeated constantly in my /var/log/messages > > Sep 11 03:43:03 quark kernel: [drm:radeon_ib_get] *ERROR* radeon: > IB(0:0x40101000:673) > Sep 11 03:43:03 quark kernel: [drm:radeon_ib_get] *ERROR* radeon: GPU > lockup detected, fail to get a IB > Sep 11 03:43:03 quark kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! > With the latest kernel update I know get this in my dmesg repetitively running glxgears [drm:radeon_ring_write] *ERROR* radeon: writting more dword to ring than expected ! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
