Bug 1519

Created attachment 999 [details]
Test Case

Created attachment 1020 [details] [review]
patch which changes tam emit order

Are you sure it does not lockup if you simply omit the aniso tex parameter
call? I can't see any reason why setting it to 1 would be any different than
not calling it at all.
I've tried the test case and as expected it did not lock up (rv250) (for 5
minutes).
You could try the attached patch (emit the tam after the tex state atoms - this
is just a shot in the dark). You could also enable the debug printf at the
bottom of r200_texstate.c to see if the hang workaround code really gets
triggered (as far as I can see, it should if you use aniso > 1).

(In reply to comment #2)
> You could also enable the debug printf at the
> bottom of r200_texstate.c to see if the hang workaround code really gets
> triggered (as far as I can see, it should if you use aniso > 1).
Scrap that. The LRU hang workaround will only get triggered if you don't use
mipmaps at all.

> Are you sure it does not lockup if you simply omit the aniso tex parameter 
> call? I can't see any reason why setting it to 1 would be any different than 
> not calling it at all. 
> I've tried the test case and as expected it did not lock up (rv250) (for 5 
> minutes). 
 
Yes, I'm quite sure. I ran it with anisotropy not set at all, and it ran for 
over a half hour with no lock ups, but testing it with 1 caused it to lock up 
within 5 minutes, and setting it above one (the highest setting, 16, in this 
case) causes it to lock up. 
 
Could it be a hardware bug that was fixed in rv250/280 series cards? Because I 
have a true R200. 
 
Additional notes: I originally came across this bug when playing with 
DarkPlaces, a very popular Quake engine fork. It locked up every once in 
awhile, and I couldn't understand why. So, one day, I decided to figure what 
did it. I turned off all the GL extensions using command line flags, and slowly 
turned each GL extension on until I found which one was crashing. The last on 
the long list was the anisotropy extention, which would cause it to lock up.  
 
Then, I built this little test to make sure it was that, and as you can see, 
that is in fact whats doing it. 
 
Even More Info: I'm currently on a Pentium 3 system, which uses a 82443BX/ZX/DX 
(rev 03) AGP controller. My card identifies itself as a Radeon R200 QM. I'm 
using Felix Kuehling's 20041002 cvs snapshot on 2.6.8.1. 
 

(In reply to comment #4)
> > Are you sure it does not lockup if you simply omit the aniso tex parameter 
> > call? I can't see any reason why setting it to 1 would be any different than 
> > not calling it at all. 
> > I've tried the test case and as expected it did not lock up (rv250) (for 5 
> > minutes). 
>  
> Yes, I'm quite sure. I ran it with anisotropy not set at all, and it ran for 
> over a half hour with no lock ups, but testing it with 1 caused it to lock up 
> within 5 minutes, and setting it above one (the highest setting, 16, in this 
> case) causes it to lock up. 
I don't doubt that aniso could cause lockups. But setting it to 1 will do
absolutely nothing (as it's the default value), and in fact the code for setting
aniso and the filter parameters is the same in the r200 driver - I just can't
see a reason why it would make a difference if you call it (it will execute
exactly the same code again as it did when you changed the filter parameter).
 
> Could it be a hardware bug that was fixed in rv250/280 series cards? Because I 
> have a true R200. 
Possible, yes. You could try experimenting what combinations make it lockup (MIN
filter might make a difference, especially if it uses mip maps or not).

I think I made a mistake with my original testing. It seems to only trigger 
when it wants too. Heavily loading the card will always make it trigger if I 
set anisotropy, but heavily loading the card without setting anisotropy OR not 
heavily loading the card and setting it won't trigger it. I'm really confused, 
and I'm wondering if it might me some hardware issue (ie, the radeon is 
overheating a little and anisotropy is causing it to crash).  
 
So, unless I go play a game for awhile (with anisotropy not set) and then try 
the test, it won't trigger. What gives? 
 

(In reply to comment #6)
> I'm really confused, 
> and I'm wondering if it might me some hardware issue (ie, the radeon is 
> overheating a little and anisotropy is causing it to crash).  
I doubt it's a hardware issue (could be of course). I'd suggest you try a newer
snapshot, some state emit changes were commited after the snapshot you're using,
which could potentially fix occasional lockups.

Currently, snapshots are being built for xorg, and I'm waiting for xfree86 
snapshots to be built again. I can't test until then. 

(In reply to comment #8)
> Currently, snapshots are being built for xorg, and I'm waiting for xfree86 
> snapshots to be built again. I can't test until then. 

OT for this bug, but since you brought it up ...

There will be no more xfree86 snapshots because the 2D drivers (which are part
of the snapshots) are developed upstream in X.org CVS. I just uploaded an Xorg
server binary to http://freedesktop.org/~dri/snapshots/extras/Xorg and updated
the snapshot download instructions. This should get binary snapshots going in an
XFree86 installation (I hope).

Created attachment 1083 [details] [review]
dbg = 0x6 setting

Off of clean CVS I could get a lockup in under 30 seconds.  Changing dbg = 0x0
to 0x6 cleared it up.

Do we know what exactly dbg = 0x6 does?  Are there significant downsides?

dbg = 0x6 fixes this on my box as well. It doesn't seem to effect any games 
I've tried (including darkplaces and quake3) so can this be committed to cvs? 
 

Workaround committed, please report any further problems.