[Bug 3386] sigsegv in r200 when glXCreateContext called by JOGL (Java for OpenGL)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3386 --- Additional Comments From [EMAIL PROTECTED] 2005-05-24 01:24 --- Created an attachment (id=2759) -- (https://bugs.freedesktop.org/attachment.cgi?id=2759action=view) java JVM-generated crash log This is the complete crash log file, as generated by the java JVM. -- Configure bugmail: https://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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3386] New: sigsegv in r200 when glXCreateContext called by JOGL (Java for OpenGL)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3386 Summary: sigsegv in r200 when glXCreateContext called by JOGL (Java for OpenGL) Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I am encountering segsegv application crashes when I run the JOGL (Java for OpenGL) demo TestContextDestruction. Software: updated (with YUM) Fedora Core 3 (kernel 2.6.11-1.14_FC3) Xorg 6.8.2 (release date 9 February 2005) radeon 4.0.1, ati 6.5.6, drm 1.0.0 20040925. Java: build 1.5.0_01-b08 (www.java.sun.com) JOGL: binary build, 1.1b11 (May 11, 2005) (https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=3336expandFolder=3336folderID=0) Hardware: DELL latitude D600 notebook with an ATI Mobility 9000 (M9) graphics card I have a 100% reproducable testcase: If I run the JOGL demo program TestContextDestruction, a sigsegv is thrown, ironically in xGLCreateContext(). The TestContextDestruction demo can be downloaded in the jogl-demos.jar download on the same page as the jogl installation, or can be individually downloaded (single java file) from the jogl project CVS. I have also submitted a bug report to the JOGL project, but their belief is that this is most likely a DRI r200 problem. Their response included: JOGL stresses the multithreading support of the driver more than most C applications. To reproduce the crash, a java VM needs to be installed (I have 1.5) and the JOGL libraries (1 java - jogl.jar, and 2 native libjogl.so, libjogl_cg.so) must be installed as well (usually in path-to-java/jre/lib/ext (for jogl.jar) and path-to-java/jre/lib/i386 (for jogl*.so)). 1a. If the demos are downloaded in binary form extract the jogl-demos.jar file using jar xvf jogl-demos.jar. 1b. If the source file was downloaded (say from CVS) then compile it using: javac -classpath .:path-to-/jogl.jar -d . TestContextDestruction.java 2. run the program: java demos.testContextDestruction.TestContextDestruction 3. click on the swap frame 1's and frame2's components button twice. The screen shows a summary of the crash, and names the log file (created in the current directory) containing further information. I am happy to provide any further information required. The initial lines of the Java JVM-generated stack trace are included here, and I will attach the entire file to this report. # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa7e7d0be, pid=2476, tid=2773232560 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode) # Problematic frame: # C [r200_dri.so+0x14d0be] # --- T H R E A D --- Current thread (0x0842d778): JavaThread AWT-EventQueue-0 [_thread_in_native, id=2487] siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x0050 Registers: EAX=0x, EBX=0x084544d8, ECX=0x084544d8, EDX=0x085f41e0 ESP=0xa54c1924, EBP=0xa54c194c, ESI=0x08451ed8, EDI=0xa54c1938 EIP=0xa7e7d0be, CR2=0x0050, EFLAGS=0x00010202 Top of Stack: (sp=0xa54c1924) 0xa54c1924: 084544d8 a54c1938 a54c193c 0xa54c1934: 005daf01 02c00011 085f41e0 08454418 0xa54c1944: 08451ed8 084889cc a54c197c a7e7dc11 0xa54c1954: 08453a50 08451ed8 08451ed8 0xa54c1964: 08451edc 1000 084889cc 0xa54c1974: 084884c0 08453650 a54c19bc 00b563a2 0xa54c1984: 081b69e8 08453a50 0xa54c1994: 084889cc a54c19bc 08453a50 8fbcc5a8 Instructions: (pc=0xa7e7d0be) 0xa7e7d0ae: e8 f2 0f ee ff 85 c0 2e 74 a3 8b 45 f0 8b 40 08 0xa7e7d0be: 8b 40 50 8b 30 8b 45 ec 89 44 24 04 89 34 24 ff Stack: [0xa5442000,0xa54c3000), sp=0xa54c1924, free space=510k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [r200_dri.so+0x14d0be] C [r200_dri.so+0x14dc11] C [libGL.so.1+0x4a3a2] C [libGL.so.1+0x4a7e7] glXCreateContext+0x3e C [libjogl.so+0xc09a2] Java_net_java_games_jogl_impl_x11_GLX_glXCreateContext0 +0x76 j net.java.games.jogl.impl.x11.GLX.glXCreateContext0(JLjava/nio/Buffer;JZ)J+0 j net.java.games.jogl.impl.x11.GLX.glXCreateContext(JLnet/java/games/jogl/impl/ x11/XVisualInfo;JZ)J+16 j net.java.games.jogl.impl.x11.X11GLContext.createContext(Lnet/java/games/jogl/ impl/x11/XVisualInfo;Z)J+46 j net.java.games.jogl.impl.x11.X11GLContext.chooseVisualAndCreateContext(Z)V+9 j net.java.games.jogl.impl.x11.X11OnscreenGLContext.create()V+2 J net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(Ljava/lang/Runnable;)Z J net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(Ljava/lang/Runn able;)Z J
Re: [R300] the_perfect_frag snapshot
On Mon, 23 May 2005, Vladimir Dergachev wrote: On Mon, 23 May 2005, Dario Laera wrote: Hi, I'm doing some test with this driver, and I read on the website that Radeon 9600 (including Radeon Mobility M10) - works well, no lockups... well, not for me :P Exactly, I can play almost every 3d game avaible for linux/PPC, but I get lockups when not in full screen mode. In window mode moving the mouse is a risk, from glxgears to neverball. I remember this problem was discussed some time ago on this list, but don't seems fixed for me. 1. Are you using merged framebuffer ? Try turning it off. 2. Try turning of SilkenMouse - it is one of the options in xorg.conf One more thing - I have DynamicClocks enabled in my xorg.conf - it would be interesting if this has any effect. best Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Vladimir Dergachev wrote: Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. I added a printk for each function in r300_cmdbuf.c... When Q3A locked up, and the last thing showing up in syslog was r300_pacify. So I added printk's after every line in r300_pacify :-) The last thing in syslog was: OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() So it seems to be making it all the way through r300_pacify, which had been called from r300_check_range, from r300_emit_unchecked_state. Here's the sequence: r300_emit_raw r300_emit_packet3 r300_emit_raw r300_emit_unchecked_state r300_check_range r300_emit_unchecked_state r300_check_range r300_pacify RING_LOCALS BEGIN_RING(6) OUT_RING( CP_PACKET0( R300_RB3D_DSTCACHE_CTLSTAT, 0 ) ) OUT_RING( 0xa ) OUT_RING( CP_PACKET0( 0x4f18, 0 ) ) OUT_RING( 0x3 ) OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() Does this tell us anything? Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. I added a printk for each function in r300_cmdbuf.c... When Q3A locked up, and the last thing showing up in syslog was r300_pacify. So I added printk's after every line in r300_pacify :-) The last thing in syslog was: OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() So it seems to be making it all the way through r300_pacify, which had been called from r300_check_range, from r300_emit_unchecked_state. Here's the sequence: r300_emit_raw r300_emit_packet3 r300_emit_raw r300_emit_unchecked_state r300_check_range r300_emit_unchecked_state r300_check_range r300_pacify RING_LOCALS BEGIN_RING(6) OUT_RING( CP_PACKET0( R300_RB3D_DSTCACHE_CTLSTAT, 0 ) ) OUT_RING( 0xa ) OUT_RING( CP_PACKET0( 0x4f18, 0 ) ) OUT_RING( 0x3 ) OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() Does this tell us anything? Adam By the way, this was consisten in all four lockups I've experienced since making these changes. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Adam K Kirchhoff wrote: Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. I added a printk for each function in r300_cmdbuf.c... When Q3A locked up, and the last thing showing up in syslog was r300_pacify. So I added printk's after every line in r300_pacify :-) The last thing in syslog was: OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() So it seems to be making it all the way through r300_pacify, which had been called from r300_check_range, from r300_emit_unchecked_state. Here's the sequence: r300_emit_raw r300_emit_packet3 r300_emit_raw r300_emit_unchecked_state r300_check_range r300_emit_unchecked_state r300_check_range r300_pacify RING_LOCALS BEGIN_RING(6) OUT_RING( CP_PACKET0( R300_RB3D_DSTCACHE_CTLSTAT, 0 ) ) OUT_RING( 0xa ) OUT_RING( CP_PACKET0( 0x4f18, 0 ) ) OUT_RING( 0x3 ) OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() Does this tell us anything? Adam By the way, this was consisten in all four lockups I've experienced since making these changes. Just because the CPU got to that point doesn't mean that the hardware didn't stall earlier. At very least you'd want to modify ADVANCE_RING() so that it 1) flushes the ring to hardware and 2) waits for hardware to idle, providing an indication that hardware was able to digest that packet and not get sick... Keith --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Tuesday 24 May 2005 18:33, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. I added a printk for each function in r300_cmdbuf.c... When Q3A locked up, and the last thing showing up in syslog was r300_pacify. So I added printk's after every line in r300_pacify :-) The last thing in syslog was: OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() So it seems to be making it all the way through r300_pacify, which had been called from r300_check_range, from r300_emit_unchecked_state. Here's the sequence: r300_emit_raw r300_emit_packet3 r300_emit_raw r300_emit_unchecked_state r300_check_range r300_emit_unchecked_state r300_check_range r300_pacify RING_LOCALS BEGIN_RING(6) OUT_RING( CP_PACKET0( R300_RB3D_DSTCACHE_CTLSTAT, 0 ) ) OUT_RING( 0xa ) OUT_RING( CP_PACKET0( 0x4f18, 0 ) ) OUT_RING( 0x3 ) OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() Does this tell us anything? Unfortunately, I don't think so. The thing is, all those OUT_RING and ADVANCE_RING commands do not really call into the hardware immediately; all they do is write stuff to the ring buffer, but the ring buffer is just some memory area without any magic of its own. Only a call to COMMIT_RING will tell the hardware that new commands are waiting in the ring buffer, and the only thing we do know is that *something* in the ring buffer before the last COMMIT_RING causes the chip to hang. So another possible way to investigate this could be: - Call radeon_do_wait_for_idle() at the end of the COMMIT_RING macro, and define RADEON_FIFO_DEBUG (this will print out additional information when wait_for_idle fails) - Increasingly add COMMIT_RING macros into r300_cmdbuf.c to pinpoint the exact location of the problem, if at all possible. It would be very helpful if you could single out one command we send using this procedure. Note that in the worst case (depending on the actual nature of the lockup in hardware), those debugging changes could actually *remove* the lockup (e.g. because they remove a race condition that caused the lockup in the first place). cu, Nicolai pgp3gtAZqqVTh.pgp Description: PGP signature
Re: r300 radeon 9800 lockup
I was doing some heavy debugging of all things that might be send (allmost every debug flag + self print) unfortunetly the overload of writting all this infos into a file cause the lock to disapear. No lock in 10min of quake3 while i get a lock in less 1 minutes without debugging. Thus as you suggest Nicolai NOP might be needed, i will try to track with commit ring. Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Jerome Glisse wrote: I was doing some heavy debugging of all things that might be send (allmost every debug flag + self print) unfortunetly the overload of writting all this infos into a file cause the lock to disapear. No lock in 10min of quake3 while i get a lock in less 1 minutes without debugging. Thus as you suggest Nicolai NOP might be needed, i will try to track with commit ring. Jerome Glisse FYI, I will say that one of my four attempts at Q3A (with the printks added to the drm driver) lasted for over 30 minutes before it locked up, which is much longer than I had previously experienced. The debugging info probably reduced the chances of a lockup in my case, too. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On 5/24/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Jerome Glisse wrote: FYI, I will say that one of my four attempts at Q3A (with the printks added to the drm driver) lasted for over 30 minutes before it locked up, which is much longer than I had previously experienced. The debugging info probably reduced the chances of a lockup in my case, too. Ooops maybe i am not patient enought but my log was around 1giga thus i prefered stop there :) But this is definitly a clue because i have lockup even without moving in quake 3. Thus i have a lockup with no debug and no lock with debug with what we may assume are same command (draw the same scene from the same point of view...). IMHO this tell us that this lock is probably related to not waiting for something, maybe there is some cmd that we better wait for completion before doing anything else... Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] overflow(?) with ut2004 demo
Hi, When experimenting with UT2004 demo I get: DRM_RADEON_TEXTURE: return = -22 offset=0x04823000 image width=32 height=1024 blit width=1024 height=128 data=0xa6246200 It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. Any ideas how to track this down? Rune Petersen --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] overflow(?) with ut2004 demo
On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote: Hi, When experimenting with UT2004 demo I get: DRM_RADEON_TEXTURE: return = -22 offset=0x04823000 image width=32 height=1024 blit width=1024 height=128 data=0xa6246200 It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. radeon_cp_dispatch_texture() also returns EINVAL in a number of other cases. Is there anything apropos in the kernel output? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On 5/24/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: Unfortunately, I don't think so. The thing is, all those OUT_RING and ADVANCE_RING commands do not really call into the hardware immediately; all they do is write stuff to the ring buffer, but the ring buffer is just some memory area without any magic of its own. Only a call to COMMIT_RING will tell the hardware that new commands are waiting in the ring buffer, and the only thing we do know is that *something* in the ring buffer before the last COMMIT_RING causes the chip to hang. So another possible way to investigate this could be: - Call radeon_do_wait_for_idle() at the end of the COMMIT_RING macro, and define RADEON_FIFO_DEBUG (this will print out additional information when wait_for_idle fails) - Increasingly add COMMIT_RING macros into r300_cmdbuf.c to pinpoint the exact location of the problem, if at all possible. It would be very helpful if you could single out one command we send using this procedure. Note that in the worst case (depending on the actual nature of the lockup in hardware), those debugging changes could actually *remove* the lockup (e.g. because they remove a race condition that caused the lockup in the first place). Below a sample of what i get when a lockup occur. There is something that seems strange to me, i saw CP_RB_RTPR change while i am in a lockup and CP_RB_WTPR increase 6 by 6, I haven't let the things live for too much time (about 2mins before reboot) but i looks like it still process ring buffer but slowly. Anyway i must misunderstood this i have to dig up more this drm code to understand it a little more. By the way why radeon_cp_flush is disactivated ? May 24 21:33:25 localhost kernel: [drm:radeon_do_wait_for_idle] *ERROR* failed! May 24 21:33:25 localhost kernel: radeon_status: May 24 21:33:25 localhost kernel: RBBM_STATUS = 0x80010140 May 24 21:33:25 localhost kernel: CP_RB_RTPR = 0x0003fdf0 May 24 21:33:25 localhost kernel: CP_RB_WTPR = 0x0d95 May 24 21:33:25 localhost kernel: AIC_CNTL = 0x May 24 21:33:25 localhost kernel: AIC_STAT = 0x0004 May 24 21:33:25 localhost kernel: AIC_PT_BASE = 0x May 24 21:33:25 localhost kernel: TLB_ADDR = 0x May 24 21:33:25 localhost kernel: TLB_DATA = 0x --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] overflow(?) with ut2004 demo
Michel Dnzer wrote: On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote: Hi, When experimenting with UT2004 demo I get: DRM_RADEON_TEXTURE: return = -22 offset=0x04823000 image width=32 height=1024 blit width=1024 height=128 data=0xa6246200 It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. radeon_cp_dispatch_texture() also returns EINVAL in a number of other cases. Is there anything apropos in the kernel output? you are right (I managed to look at the wrong log). [drm:radeon_cp_dispatch_texture] *ERROR* Invalid destination offset Rune Petersen --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
