On Tuesday 19 March 2002 10:31, you wrote:
> yes, i compiled and installed it yesterday,
> no problems compiling or anything, but am still having some problems.
> all the gl demos i try only shows the first
> frame(except one, Mesaimage which works ok, but it doesn't really do
> anyhing except show a pixmap i think), then it locks up hard and i have to
> reset the computer. The first frame looks great though =)
Yep. I feared that, I just had chance to test the code on my notebook, so I
hardcoded some timeout value. Everything we need to dig out the problem is in
s3v_dma.c, so try things in this order (just one at a time...)
* solution a) increase S3V_UDELAY to 1000 (1 is safe on Virge/MX, not so sure
on DX, VX, etc.). Recompile and try.
* solution b) we have a task queud in the timer task queue [s3v_dma_task],
which function is s3v_dma_check. In this function we issue a reset after we
have checked DMA buffer reading completion for 40 times. To see how many
times is (in average) taking on your machine, comment out the s3v_do_reset
after the line "if (times>40) {". Then uncomment printk(KERN_ERR "*** buf
completed after %i... ... ...
Now run a program (it should not lock this time [it it does try in
conjunction with solution a]) and check the values printed: look for the
highest of the values (especially when running games like tuxracer or
quake2), and substitute it to the '40' I have hardcoded. The lower the value
the better the feeling.
*** The point is that sometimes Virge DMA engine stalls and you would have to
*** wait for ever for buffer completion, it will stop somewhere in the middle
*** of a buffer and won't go on until you reset. Maybe there is a better ***
*** solution for that. Any suggestion is welcome ; )
pseudo-soultion c) turn on S3V_DEBUG and send be the debug, so I will try to
find a best solution.
Note: if your machine is locking hard, it could be necessary to add an
udelay(1000) after printk in S3v_DEBUG, so we have some chance debug is being
written before lock happens. Good luck.
> only thing in the log is 'and !s3v_dma_is_ready: -BAD-'
> but that doesn't seem to affect anything, as it is also shown when i run
> glxinfo.
That is normal. It just says that your DMA engine has been reset, when
s3v_dma was not ready. This will always happen the first time (at least on my
Virge/MX) since the write pointer of DMA is already a bit further of read
pointer (or viceversa?) [even if nothing has been written to card!], so when
you reset the pointer for the first time the code will just warn you, that
you issued a reset cmd when card was not ready (wp != rp).
> i attached some logs if that helps
Logs seem ok. Could you tell me give more infos on your machine? (2mb virge
dx, + ...)
>> Linux 2.4.9-13smp
Are you running it on a SMP!? I am not sure my code is SMP-proof ; (
Could you try a more recent kernel? I am not a bleeding-edge geek, but I had
some problem with my code too with linux-2.4.x (x>11). It runs fine with
2.4.18.
>> Option "texbuffer_size" "16384"
If you are running demos with many texs, reserve a bit more memory to them.
If you are able to keep your so alive when running a gl app, could you please
send me a copy of "cat /proc/dri/0/*" >& dri.log (while gl app is executing)
Vale,
- max
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
