Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 01:37:01AM +0200, Michel D?nzer wrote: On Wed, 2002-07-17 at 01:19, Steven Walter wrote: I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running DRI cvs trunk as of a few days ago. Something interesting that I have found is a correlation to the xvidmode extension. With it enabled, the first switch-away/switch-back will cause a hard lock. The screen mostly restores, but even the mouse and keyboard are solidly wedged. With xvidmode disabled, X will lock in the same way after exactly TWO switch-away/switch-backs. Just a curious data point. Interesting though - how do you disable it? Could be the AdjustFrame() call in EnterVT() interfering or something... I disable it by commenting the EnableXVidModeExtension line in XFree86, and optionally adding an explicit DisableXVidModeExtension. The latter doesn't seem to make any difference. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of wuv confuses and infuriates us! -- Lur of Omicron Persei VIII --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Segmentation fault with Radeon 7500 QW
I recently bought a Radeon 7500 64MB DDR (lovingly called a QW), and have had no luck with the DRI cvs trunk. 3D acceleration /does/ work, however, with xfree86 4.2 The problem is, whenever I run a 3d app, I get a segmentation fault. Running strace on said apps reveals that the segfault right after: old_mmap(NULL, 499712, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x44dcf000 Neither RADEON_NO_VTXFMT nor RADEON_NO_TCL fix the problem. Running with LIBGL_ALWAYS_INDIRECT, however, does. This is kernel 2.4.19-rc1, using the DRI cvs drm. I'm using the ATI framebuffer for console. Any ideas what the problem might be? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of wuv confuses and infuriates us! -- Lur of Omicron Persei VIII --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Backtrace from hung GL app (tdfx)
On Mon, Jun 10, 2002 at 05:59:50PM +0100, Michael wrote: On Sun, Jun 09, 2002 at 02:37:23PM -0500, Steven Walter wrote: It's hanging in glide, trying to read from the status register. Or, equally likely, it's repeatedly calling that function, waiting for the engine to become idle (or some such, I don't really know what I'm talking about). The next line looks like garbage. Then we're in good ole Mesa code. The only interesting thing I see here is that _tnl_render_quad_strip_verts was called with a NULL ctx. Should that ever happen? Is it the cause of the problem? Where might that occur? I'll have a look later. Which app did you run to get that backtrace? I can't yet reproducably cause the hang. It was moebius, at the time, a GL hack. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of wuv confuses and infuriates us! -- Lur of Omicron Persei VIII ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Backtrace from hung GL app (tdfx)
Occasionally, I'll get an OpenGL app (almost always a screensaver) that will freeze up, leaving the console unusable. Numlock doesn't toggle, etc. If I log in via serial console and kill the app, then all is well. This seems to happen once every day or two. Recently, I got a debuggable build of the DRI cvs running, and was happily able to obtain a backtrace from the (apparently) frozen app. Some of it looks a little weird, but I hope it's more useful to you gurus than to me. Here it is: #0 0x4072fd51 in _grSstStatus () from /usr/lib/libglide3.so.3 #1 0x1000 in ?? () #2 0x401f06c2 in _tnl_render_quad_strip_verts (ctx=0x0, start=4096, count=216, flags=2312) at tnl/t_vb_rendertmp.h:391 #3 0x401f134c in run_render (ctx=0x8076df8, stage=0x44aa6000) at t_vb_render.c:335 #4 0x401d8e83 in _tnl_run_pipeline (ctx=0x8076df8) at t_pipeline.c:154 #5 0x401d715b in _tnl_run_cassette (ctx=0x4401, IM=0x1a7) at t_imm_exec.c:375 #6 0x401d0da8 in execute_compiled_cassette (ctx=0x4401, data=0x1a7) at t_imm_dlist.c:379 #7 0x40112863 in execute_list (ctx=0x8076df8, list=134704632) at dlist.c:3999 #8 0x40112f4d in _mesa_CallList (list=2) at dlist.c:4837 #9 0x0804a7b1 in strcpy () #10 0x0804b694 in strcpy () #11 0x0804c1ab in strcpy () #12 0x0804e569 in strcpy () #13 0x0804a4cd in strcpy () #14 0x0804d340 in strcpy () #15 0x404446cf in __libc_start_main () from /lib/libc.so.6 It's hanging in glide, trying to read from the status register. Or, equally likely, it's repeatedly calling that function, waiting for the engine to become idle (or some such, I don't really know what I'm talking about). The next line looks like garbage. Then we're in good ole Mesa code. The only interesting thing I see here is that _tnl_render_quad_strip_verts was called with a NULL ctx. Should that ever happen? Is it the cause of the problem? Where might that occur? Hope someone can help shed some insight on this, and get this bug fixed. (This is a with a Voodoo4 4000 AGP, don't think I mentioned that). -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell He's alive. He's alive! Oh, that fellow at RadioShack said I was mad! Well, who's mad now? -- Montgomery C. Burns ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] The Weather Channel Funding Radeon 8500 Support
On Sat, Jun 08, 2002 at 05:47:28PM -0600, Jens Owen wrote: Good news for Radeon 8500 owners. We have posted this announcement on our TG web site: The Weather Channel is funding TG to develop an open source 3D DRI driver for the ATI Radeon 8500 graphics card. The driver will be released to the XFree86 Project around Q4 of 2002, to be distributed to the public in future versions of the XFree86 X Server. We'll be starting this project right away and using the DRI repository for our open development. YAY! -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell He's alive. He's alive! Oh, that fellow at RadioShack said I was mad! Well, who's mad now? -- Montgomery C. Burns ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] glxgears framerate for Voodoo4/5
On Wed, Jan 02, 2002 at 09:48:24PM -0500, Aciel wrote: Okay, found one of the many problems. It didn't want libglide.so.3 to be real--it wanted a static link. So now instead of that odd error about glXChooseVisual, I get something much more familiar: # LIBGL_DEBUG=1 glxinfo name of display: :0.0 Segmentation fault (core dumped) # LIBGL_DEBUG=1 glxgears Segmentation fault (core dumped) No fun. :( From where did you obtain your copy of libglide.so? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell He's alive. He's alive! Oh, that fellow at RadioShack said I was mad! Well, who's mad now? -- Montgomery C. Burns ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Repeatable lockups with Voodoo4
I'm having a problem with playing Return to Castle Wolfenstein, both with single-player under winex and the multiplayer native binary. With single-player under winex, I'm running version 1.0-2, debian package. I can start the game, and then exit immediately, with no problem. I can even go into menus and back. However, if I start a new game, or load a saved game, any attempt to quit the program after that will cause a lock. The symptoms of all the locks are the same. The screen is frozen as it last appeared before the lock, i.e., still in the game. The mouse cursor is frozen, and the keyboard accepts no input. Numlock, capslock, etc., do not toggle. I can, however, log in via the serial console, and run a killall wine. This unlocks the system, and the following message is left on the terminal where wine was started: wait4: No child processes Terminated Additionally, if I attempt to switch to multiplayer mode in winex, I get he lockup on a solid grey screen. Or, if I start WolfMP manually, any attempt to exit /period/ causes the lockup. Attempting to switch from WolfMP to single player mode causes erradic behavior, ranging from locking wine (requiring a killall wine), locking X (requiring a killall -9 X), or succeeding. The situation is similar with the multiplayer binary. The version is 1.0b2; I can start the game and then immediately exit with no problem. However, if I load the multiplayer menu, and then try to exit after that, I get a freeze identical to the one under wine. When killing it, I get the following error message: - CL_Shutdown - RE_Shutdown( 1 ) Received signal 11, exiting... DOUBLE SIGNAL FAULT: Received signal 15, exiting... Shutdown tty console /usr/local/bin/wolf: line 4: 29499 Killed ./wolf.x86 $* Additionally, I've long been getting lockups in exactly the same way with q3demo. This leads me to suspect that it's a problem with DRI. However, since the problem shows itself so readily in winex, it's a problem that they should be alerted to as well. As such, this message is CC'ed to them. Any help that anyone can offer on any aspect of this is greatly appreciated; this problem is something of a major annoyance. My system is an AMD Thunderbird 900MHz, 128MB RAM, with a 3dfx Voodoo4 video card. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell He's alive. He's alive! Oh, that fellow at RadioShack said I was mad! Well, who's mad now? -- Montgomery C. Burns ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [PATCH] 3dnow transform bugs
On Mon, Oct 15, 2001 at 09:44:15PM +0200, Dieter N?tzel wrote: Hello Andrew, very nice work! But can you please redo your patch against the real Mesa-3.5 CVS tree and not yours? src/X86/3dnow_xform3.S src/X86/3dnow_xform4.S fail. As I see that you are very good x86 asm hacker and I am not (I learned asm on 6502 and 68k) what do you think about working together on the outstanding Glide3 3DNow! bugs? I, too, am interested in getting this working. If you need a guinea pig, than I'm more than willing to help. If you're lucky, I may even be able to produce/repair some code. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell Those that would give up a necessary freedom for temporary safety deserver neither freedom nor safety. -- Ben Franklin ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] VSA-100 chip specs
Can someone send a copy of the white papers/references for the 3dfx VSA-100/Napalm my way? Were they even ever released openly? I know that the said document for Avenger (Voodoo3) were, and they used to be availible on 3dfx's website. Unfortunately, though, this website is no longer up, so I can't easily check if the VSA-100 documents were there. Thanks! -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Recurring lockup in q3demo with tdfx
Occasinally, when exiting q3demo or changing video modes, X will hang I haven't seen any particular pattern to when this happens, but when it does happen, the mouse cursor is shown in the far upper left corner, and both the pointer and crosshair are present. X doesn't respond, but SysRq does. Therefore, I have the attached output from SysRq+S. This problem happened with XFree86 4.1.0 and kernel 2.4.5-ac2, however it has happened under several different combinations of X and kernels. I can't recall a recent combination that worked. Some that haven't worked have been tdfx-0.7 and a recent DRI CVS version. In fact, I have output from kdb when a lockup occurred with tdfx-0.7. This is the only other debugging info I have. It is also attached. If there's any other information I can provide, or help debug in some way, let me know. I read dri-devel in digest. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell btp 264 EBP EIP Function(args) 0xc73b1f18 0xc0111f20 schedule+0x25c kernel .text 0xc010 0xc0111cc4 0xc0112050 0xc8926027 [tdfx]tdfx_lock+0x157 (0xc5ed90e0, 0xc747cc60, 0x4008642a, 0xb4fc) tdfx .text 0xc8924060 0xc8925ed0 0xc8926140 0xc8925ec2 [tdfx]tdfx_ioctl+0xd2 (0xc5ed90e0, 0xc747cc60, 0x4008642a, 0xb4fc) tdfx .text 0xc8924060 0xc8925df0 0xc8925ed0 0xc013b0b6 sys_ioctl+0x16a (0x8, 0x4008642a, 0xb4fc, 0x8, 0x40015000) kernel .text 0xc010 0xc013af4c 0xc013b0d0 0xc0106a93 system_call+0x33 kernel .text 0xc010 0xc0106a60 0xc0106aa0 SysRq : Show State freesibling task PCstack pid father child younger older X S C891F640 5012 264255 279 (NOTLB) Call Trace: [c891f640] [c891f7a8] [c8919e97] [c891f640] [c891f7ac] [c891f7ac] [c8919d40] [c0137aa6] [c0106aa3] c891f640: [tdfx]__module_kernel_version+0/0 c891f7a8: [tdfx]__module_parm_drm_opts+e6/5ae c8919e97: [tdfx]tdfx_lock+14b/258 c891f640: [tdfx]__module_kernel_version+0/0 c891f7ac: [tdfx]__module_parm_drm_opts+ea/5ae c891f7ac: [tdfx]__module_parm_drm_opts+ea/5ae c8919d40: [tdfx]tdfx_ioctl+c8/d4 c0137aa6: sys_ioctl+1ea/204 c0106aa3: system_call+33/40 q3demoS 48 18894 18882 18895 (NOTLB) Call Trace: [c01156ae] [c0106aa3] c01156ae: sys_wait4+362/394 c0106aa3: system_call+33/40 q3demo.x86S C17A7FB0 2672 18895 18894 (NOTLB) Call Trace: [c0110979] [c0105c77] [c0106aa3] c0110979: schedule+225/334 c0105c77: sys_rt_sigsuspend+e3/100 c0106aa3: system_call+33/40 EIP: 0010:[c0105143] CPU: 0 EFLAGS: 00200246 EAX: EBX: c021 ECX: c1e44260 EDX: c1e44260 ESI: c0105120 EDI: e000 EBP: 0008e000 DS: 0018 ES: 0018 CR0: 8005003b CR2: 4009e012 CR3: 04b6f000 CR4: 0090 Call Trace: [c01051a7] [c0105000] [c0100197] EIP; c0105143 default_idle+23/28 c01051a7: cpu_idle+3f/54 c0105000: prepare_namespace+0/8 c0100197: L6+0/2
