[Bug 9252] complete lockups with radeon 9600 XT
http://bugs.freedesktop.org/show_bug.cgi?id=9252 --- Comment #27 from [EMAIL PROTECTED] 2007-03-02 03:19 PST --- (In reply to comment #26) Created an attachment (id=8913) -- (http://bugs.freedesktop.org/attachment.cgi?id=8913action=view) [details] DO_USLEEP if it is supported What exactly is the problem addressed by this patch? While it may make sense to drop the lock while sleeping (but it's not obvious why not doing so could cause lockups, except by changing the timing maybe), I don't think making the sleep conditional on the do_usleeps configuration makes sense because it's not directly related to this situation. Its purpose is to allow sleeps when the CPU gets too far ahead of the GPU, but here it would instead greatly change the time out waiting for the GPU to go idle. Still lockups the second time I run beryl. So apparently, that's not related to your patches at all? What are the symptoms? E.g., is the X server still running? If not, any hints in its log file or stderr output? ... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10156] New: Reversed cube mapping on Radeon 9000 with DRI enabled
http://bugs.freedesktop.org/show_bug.cgi?id=10156 Summary: Reversed cube mapping on Radeon 9000 with DRI enabled Product: Mesa Version: 6.5 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Overview Description: When doing cube mapping with DRI enabled, reflections are on the opposite side of where they should be. You can see this in the following images: This is with DRI on: http://img488.imageshack.us/my.php?image=cubemapdrinv4.png This is with DRI off: http://img90.imageshack.us/my.php?image=cubemapnodricr4.png The second image is the correct result. It can be obtained also in the same computer on Windows with ATI official drivers and on other computers on Linux with NVIDIA official drivers. Steps to Reproduce: 0) Have DRI enabled. 1) Execute any application performing cube mapping. (You can find the application from which I took the screenshots at http://xivis.viladelpingui.net/cubemap.zip . It's not mine, but I don't remember where I got it from.) Actual Results: An image like the first one above. Expected Results: An image like the second one above. Build Date Platform: OpenGL renderer string: Mesa DRI R200 20060602 AGP 1x x86/MMX/SSE2 TCL OpenGL version string: 1.3 Mesa 6.5.1 Package by Fedora: mesa-libGL.i386.6.5.1-9.fc6 Build Time : Wed Jan 24 22:24:02 2007 On Fedora Core 6, with a Radeon 9000 graphics card. Additional Builds and Platforms: Any previous release for Fedora Core 6, on the same system. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] replace instance of SA_SHIRQ with IRQF_SHARED
The use of SA_* is slowly being removed, at least that's my impression. I use a realtime kernel and it was gone, it seems a similar thing might happen for other kernels in the near future (-mm for 2.6.21). Maarten. fix.patch Description: Binary data - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] replace instance of SA_SHIRQ with IRQF_SHARED
This is for the drm in case that's not obvious from the patch, forget to mention that. On 3/2/07, Maarten Maathuis [EMAIL PROTECTED] wrote: The use of SA_* is slowly being removed, at least that's my impression. I use a realtime kernel and it was gone, it seems a similar thing might happen for other kernels in the near future (-mm for 2.6.21). Maarten. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10156] Reversed cube mapping on Radeon 9000 with DRI enabled
http://bugs.freedesktop.org/show_bug.cgi?id=10156 --- Comment #1 from [EMAIL PROTECTED] 2007-03-02 05:44 PST --- The mesa/progs/demos/cubemap test works correctly from mesa 6.5.2 upto current git with R200 and rv250 chips. I'd suggest you upgrade to xorg 7.2 with mesa 6.5.2 and retest. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
On Mon, 2007-02-26 at 07:09 +0200, Panagiotis Papadakos wrote: Well I think I have the correct patch for this. I'm afraid not; the test modification is incorrect. The test is an optimization to avoid doing unnecessary work when the context is already up to date wrt the drawables passed in and doesn't have anything to do with the stamps. We should call radeonSetCliprects inside radeonMakeCurrent to update to the new pClipRects whenever lastStamps change. I think that makes sense though. Maybe the updates of radeon-lastStamp could also be moved into radeonSetCliprects and/or the common parts of radeonMakeCurrent and r300RegainedLock moved into a separate function called by both. BTW, the patch also has superfluous whitespace-only changes, which should be avoided. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10156] Reversed cube mapping on Radeon 9000 with DRI enabled
http://bugs.freedesktop.org/show_bug.cgi?id=10156 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-03-02 08:29 PST --- This looks like fixed by cb08dcbbf29dfa82128c8302f7aa69e90478a5ea, since this demo exactly hits that case (GL_REFLECTION_MAP_ARB texgen and lighting disabled). It works for me (though due to texsubimage it's slower than software rendering...). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7767] No hardware rendering for SuperSavage/IXC 64 and Xorg 7.2 RC3
http://bugzilla.kernel.org/show_bug.cgi?id=7767 --- Additional Comments From [EMAIL PROTECTED] 2007-03-02 11:08 --- Created an attachment (id=10584) -- (http://bugzilla.kernel.org/attachment.cgi?id=10584action=view) Output of dmesg for 2.6.20-1.2953.fc7 [2.6.21rc1] git kernel tree DRM modules with modprobe drm debug=1 I have merged the DRM source from: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git as of 2007-03-02 with the 2.6.20-1.2953.fc7 [2.6.21rc1] kernel package from the FC development tree. Unfortunately still no success: after building and loading modules drm.ko and savage.ko via insmod after booting into text mode and launching the X server afterwards, I still obtain the familiar error message: libGL error: drmMap of framebuffer failed (Invalid argument) .. when I execute glxinfo. In Xorg.0.log appears the error message: (EE) AIGLX error: drmMap of framebuffer failed (Invalid argument) (EE) AIGLX: reverting to software rendering --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10090] Google Earth rendering trouble with Unichrome IGP
http://bugs.freedesktop.org/show_bug.cgi?id=10090 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #7 from [EMAIL PROTECTED] 2007-03-02 15:06 PST --- In bzflag the patch in comment #5 makes the world continue outside of the radar box. This is not correct, as far as i know. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10090] Google Earth rendering trouble with Unichrome IGP
http://bugs.freedesktop.org/show_bug.cgi?id=10090 --- Comment #8 from [EMAIL PROTECTED] 2007-03-02 17:50 PST --- There is a patch in the other bug that should fix that. The problem was that drawXoff was still affecting the backbuffer. http://bugs.freedesktop.org/show_bug.cgi?id=9965 that should fix that problem and the problem Xavier reported about the preview of opengl screensaver in xscreensaver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3493] r128: Entire X-windowing system hangs during normal 3D gaming
http://bugs.freedesktop.org/show_bug.cgi?id=3493 --- Comment #7 from [EMAIL PROTECTED] 2007-03-02 18:22 PST --- This is extremely easy to reproduce with SPECviewperf 9.0.3. (I have it installed to test my i965 hardware in the same machine.) Although unlike last time, I didn't get any (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 49 messages in my Xorg.0.log. X unfroze when I killed the viewperf process that caused the [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock message. Terminal output from a full SPECviewperf run: [EMAIL PROTECTED]:/usr/local/src/opengl/SPEC/SPECViewperf9.0$ ./Run_All.csh Running: 3dsmax-04.csh Terminated Running: catia.csh Writing PNG file '../results/catia/01.png'...done. Terminated Running: Ensight-03.sh Terminated Running: light-08.csh Terminated Running: maya-02.csh Writing PNG file '../results/maya/01.png'...done. Terminated Running: proe-04.csh Writing PNG file '../results/proe/proe01.png'...done. Terminated Running: suzuki-engine Writing PNG file '../results/sw/sw01.png'...done. Writing PNG file '../results/sw/sw01Full.png'...done. Writing PNG file '../results/sw/sw02.png'...done. Writing PNG file '../results/sw/sw02Full.png'...done. Illegal instruction Running: ugnx-01.csh Segmentation fault Segmentation fault Terminated Terminated Terminated Terminated Terminated Segmentation fault Terminated Terminated Terminated Running: tcvis-01.csh Terminated Run All Summary 3dsmax-04 Weighted Geometric Mean = 0.0 catia-02 Weighted Geometric Mean = 0.0 ensight-03 Weighted Geometric Mean = 0.0 light-08 Weighted Geometric Mean = 0.0 maya-02 Weighted Geometric Mean = 0.0 proe-04 Weighted Geometric Mean = 0.0 sw-01 Weighted Geometric Mean = 0.0 ugnx-01 Weighted Geometric Mean = 0.0 tcvis-01 Weighted Geometric Mean = 0.0 kernel log: Mar 2 21:25:46 tesla kernel: [65315.110796] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:28:21 tesla kernel: [65470.003625] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:28:32 tesla kernel: [65481.086515] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:28:42 tesla kernel: [65491.348416] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:29:07 tesla kernel: [65515.740211] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:29:48 tesla kernel: [65557.313944] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:31:07 tesla kernel: [65636.105453] viewperf[16959] trap invalid opcode rip:2b2deb5fea1b rsp:7fffc0bc8ed8 error:0 Mar 2 21:31:40 tesla kernel: [65669.276782] viewperf[16970]: segfault at 07048f70 rip 07048f70 rsp 7fffa4036dc8 error 15 Mar 2 21:32:42 tesla kernel: [65731.491660] viewperf[16972]: segfault at cd242f70 rip cd242f70 rsp 7fffdde3fbe8 error 14 Mar 2 21:35:38 tesla kernel: [65907.385109] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:44:39 tesla kernel: [66448.322471] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:49:10 tesla kernel: [66719.224818] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:51:42 tesla kernel: [66870.685200] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 21:56:50 tesla kernel: [67178.608402] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 22:01:33 tesla kernel: [67461.398885] viewperf[17042]: segfault at e9c1df70 rip e9c1df70 rsp 7fffc14641e8 error 14 Mar 2 22:01:42 tesla kernel: [67470.173738] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 22:07:58 tesla kernel: [67846.09] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 22:09:18 tesla kernel: [67926.606019] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock Mar 2 22:09:40 tesla kernel: [67948.741423] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock ugnx locked up the most. Maybe it just has a test script that invokes viewperf many times, instead of the batch mode the others use. Every Terminated line in that output is from me doing killall viewperf after a new kernel log message, and lack of CPU load, indicates that it got stuck again. I have no idea why it would run an illegal instruction, or segfault. Maybe the SIGILL was just from a jump to an address in an executable memory region that wasn't meant to be amd64 instructions. BTW, I compiled SPECviewperf 9.0.3 from the source in the src directory. ./Configure, and choose Linux64, IIRC. Mesa, r128_dri, and libdrm are all built from git sources. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief
[Bug 10090] Google Earth rendering trouble with Unichrome IGP
http://bugs.freedesktop.org/show_bug.cgi?id=10090 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #8867 is|1 |0 patch|| Attachment #8867 is|0 |1 obsolete|| --- Comment #9 from [EMAIL PROTECTED] 2007-03-02 21:58 PST --- (From update of attachment 8867) yup wrong fix. Looking at the code again the way it was was fine. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
