On Wednesday 20 March 2002 14:07, you wrote: > hi again, > tried changing the S3V_UDELAY when i first got > the lockup, but that made no difference.
Ok, so we keep 1. > how much is logged differs everytime i try even with the udelay in the > debug macro, i've attached a log where it gets a bit further than the > '!s3v_dma_is_ready: -BAD-'. So i guess it hangs at a different time every > try. Do you know if Virge DX supported 64K DMA buffers? - I know: I am the one who should know -but- I have just docs for VirgeMX and no more DX ; ( Could you try recompiling drm module and XFree driver defining S3V_BUF_4K? Another point: try commenting out -all- the S3V_WRITE to 0x850C. I am not sure if that is MX specific and it was not in Utah code (did you ever try? Did it use to work for you?). If this is still failing, try setting #if 0 in s3v_dma.c, line 57 [it is the hw reset code - is is been called from my libGL too]. Then delete the comment to reactivate S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1); at line 270 of s3v_dma.c. (It was in the Utah approach but I found it useless in my driver) > seems it never gets to where it prints out the "*** buf completed after > %i..."(in your solution b), atleast its never in the log, and it still > hangs. You did comment out "s3v_do_reset(dev);" after if (times>40), didn't you? mmm... could you add a s3v_do_status(dev); in void s3v_dma_check(void* _dev), immediately after static u16 times=0; Now, look at the logs: is s3v_do_status being called? If not, it is a kernel issue with enqueing to the timer queue (could you try a 2.4.18 kernel?). If yes it is a dma issue and I will try to work it out. From the new log tell me if s3v_do_status is showing progress: is rp getting nearer to wp? > do you know if anyone else has gotten it to work for them yet? Me ; ) I got it on the VirgeGX box of a friend of mine, when it was in earlier stage of development (January). The point is that DMA structure ain't changed from my first snapshots in November (of course I changed the way kernel handle it to gain a 40% speed boost), but DMA regs handling did not change so much. And 2 people at that time reported it worked: you were one of them... ... do you still have this old code? Does it still run on your box? Could you send me the old drm version (I am not sure I have it any longer here), so that I will check if something went wrong? Good luck! Vale, - max P.S: how could there be a "[drm:s3v_dma_dispatch] done dispatch" in the log? I have no such printk! Did you add it? : ) In which point of the code is it? Could you add a s3v_do_status(dev); at the end of s3v_dma_dispatch, before the up(&s3v_buf_sem); It should log something like rp=0x0 and wp=0xyz. Can you confirm me this? _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
