Re: [Dri-devel] Radeon lockups
On Sun, 3 Mar 2002, Keith Whitwell wrote: > Adam K Kirchhoff wrote: > > > > Can anyone offer an explanation why my Radeon 7500 will constantly lockup > > on Tribes2 after loading the mission data, but an original DDR 64 Meg > > Radeon doesn't lockup on the exact same machine with the exact same verion > > of X (namely, the main DRI branch)? > > > > I don't have any answers on this one. I also don't have access to a radeon > 7500... We seem to be seeing a few differences in behaviour with the 7500. > > Keith Well, for what it's worth, Q3A also locks up on the Radeon 7500 but plays just fine on the same original DDR 64 Meg Radeon. These are the only two applications where I've noticed this difference/problem. What would be the best way to go about diagnosing this problem? Adam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon lockups
Adam K Kirchhoff wrote: > > Can anyone offer an explanation why my Radeon 7500 will constantly lockup > on Tribes2 after loading the mission data, but an original DDR 64 Meg > Radeon doesn't lockup on the exact same machine with the exact same verion > of X (namely, the main DRI branch)? > I don't have any answers on this one. I also don't have access to a radeon 7500... We seem to be seeing a few differences in behaviour with the 7500. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon lockups
Can anyone offer an explanation why my Radeon 7500 will constantly lockup on Tribes2 after loading the mission data, but an original DDR 64 Meg Radeon doesn't lockup on the exact same machine with the exact same verion of X (namely, the main DRI branch)? I find this kind of peculiar :-) Adam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon lockups with Quake3
On Fri, Apr 13, 2001 at 02:07:05PM -0700, Simon Kirby wrote: > On Fri, Apr 13, 2001 at 01:32:39PM -0700, Simon Kirby wrote: > > > I'm trying to compile the glx client but I'm not having much luck. > > Debian unstable. How are you compiling it over there? > > Okay, finally got qf-client-glx to compile (library conflicts with DRI > tree). > > It starts up and runs, but I'm not able to find any multiplayer servers > and it doesn't let me play single player. I'll search for some in xqf or > something. > > However, in the mean time, there are some strange things happening. As > soon as the client starts, my analog flatpanel starts to get all jittery > -- pixels are all vibrating left and right. I can _sometimes_ see a > single row of pixels jittering normally if the sync is misaligned, but > quakeforge isn't even changing the resoution (1024x768) and it just > suddenly starts going all funky. Each scanline is different, as if the > horizontal sync is changing phase slightly. > > As soon as I quit, everything returns to normal. > > I just obscured the window trying to find a multiplayer server, and got a > lock up. Sysrq worked, but my mouse was frozen. I hadn't even started > playing yet. > > Trying again... Well, I compiled "nuq" instead (the single player version), and I just finished three levels without any problems (other than the weird pixel thing which doesn't happen in q3). I tried obscuring the window, changing virtual desktops, dragging everything over it, etc., and couldn't get it to lock up at all. Before, when I had my G200, I could cause a lockup with any GL program by dragging partially or fully obscuring the GL window. It seems that this isn't causing it, though, or something in the multiplayer client is. Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon lockups with Quake3
On Fri, Apr 13, 2001 at 01:32:39PM -0700, Simon Kirby wrote: > I'm trying to compile the glx client but I'm not having much luck. > Debian unstable. How are you compiling it over there? Okay, finally got qf-client-glx to compile (library conflicts with DRI tree). It starts up and runs, but I'm not able to find any multiplayer servers and it doesn't let me play single player. I'll search for some in xqf or something. However, in the mean time, there are some strange things happening. As soon as the client starts, my analog flatpanel starts to get all jittery -- pixels are all vibrating left and right. I can _sometimes_ see a single row of pixels jittering normally if the sync is misaligned, but quakeforge isn't even changing the resoution (1024x768) and it just suddenly starts going all funky. Each scanline is different, as if the horizontal sync is changing phase slightly. As soon as I quit, everything returns to normal. I just obscured the window trying to find a multiplayer server, and got a lock up. Sysrq worked, but my mouse was frozen. I hadn't even started playing yet. Trying again... Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon lockups with Quake3
On Thu, Apr 12, 2001 at 08:56:12PM -0700, Simon Kirby wrote: > I decided to upgrade to the newest (as of earlier today) DRI tree, along > with 2.4.3-ac5. I was playing Quake3 again, and got a lockup which has > never happened before: the monitor on my Radeon went blank, but Quake3 > kept going (I could hear the sounds and still "t"alk and hear the > transmission). Usually the sound will loop over and over and sysrq will > either work or not work. This time everything worked except for the > monitor, but it locked up as soon as I quit the game (blindly). The looping sound, blanked screen, and sysrq working case is exactly the one which I can reproduce faithfully with QuakeForge. I have not tried Q3A recently as I have no way of knowing exactly what it's doing whereas I obviously know QF pretty well.. I have been experiencing this combination of problems since 2.4.2. I currently use a slightly patched version of 2.4.3-ac4 (I've added lm-sensors and an updated bttv driver..) I've been temporarily out of commission for the past day or two, so I haven't tried -ac5 yet. Just so you know that the error is probably not a freak bug which only you have happen. Of course, it dies for me in seconds, not minutes. I'll see if I can produce your results under -ac5 in Q3A. If you have a Quake CD laying around (or don't mind tracking down the shareware pak file), could you give QuakeForge a shot? Perhaps something it does is killing it faster? I'm using the "quakeforge" CVS tree, usually the nq-glx target. It also happens with the qw-client-glx target. If I am real lucky, we are experiencing the same bug. -- Joseph Carter <[EMAIL PROTECTED]>Free software developer RFC 882 put the dot in .com, not Sun Microsystems -- Seen on Slashdot PGP signature
[Dri-devel] Radeon lockups with Quake3
On Thu, Apr 12, 2001 at 01:16:06AM -0700, Simon Kirby wrote: > I'm also seeing lockups with Quake3 on my ASUS P2B-DS dual Celeron board > with my Radeon VE 32MB DDR. > > Sometimes it will play fine for a few CTF games, but it will usually die > somewhere in the game. It seems to die either one of two ways -- either > the screen will go blank or become corrupted (for example, scanning the > first scan line for the entire screen while my second head on a PCI > card remains fine), or the screen will just freeze. > > In the latter case, the machine will not respond to sysrq. In the > former case, it will, and I can unmount and reboot cleanly. I decided to upgrade to the newest (as of earlier today) DRI tree, along with 2.4.3-ac5. I was playing Quake3 again, and got a lockup which has never happened before: the monitor on my Radeon went blank, but Quake3 kept going (I could hear the sounds and still "t"alk and hear the transmission). Usually the sound will loop over and over and sysrq will either work or not work. This time everything worked except for the monitor, but it locked up as soon as I quit the game (blindly). I set up a serial console on another box and ssh'd in to a screen'd minicom process on my second head while playing Q3 on the first. During play, no messages occurred. After about 20 minutes, the older style lockup occurred (monitor went blank, sound looped, sysrq works), and as this happened, no messages appeared on the second head. Upon reboot, minicom had captured this looping output: [drm:radeon_freelist_get] *ERROR* returning NULL! ... [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! SysRq: Emergency Remount R/O [drm:radeon_freelist_get] *ERROR* returning NULL! Remounting device 03:02 ... OK Remounting device 03:01 ... OK Remounting device 03:04 ... OK Remounting device 03:43 ... OK Done. [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! SysRq: Emergency Sync [drm:radeon_freelist_get] *ERROR* returning NULL! Syncing device 03:02 ... OK Syncing device 03:01 ... OK Syncing device 03:04 ... OK Syncing device 03:43 ... OK Done. [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! [drm:radeon_freelist_get] *ERROR* returning NULL! SysRq: Resetting So, there now seem to be three different kind of lockups. Totally dead, somewhat dead (sysrq works), and only partially dead (only the Radeon head goes blank). Fun fun. :) Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
