Michel Dänzer wrote: >On Thu, 2002-07-18 at 09:47, Henry Worth wrote: > >>Henry Worth wrote: >> >>>Digging thru the X logs, I see that agp is failing to map the ring >>>buffer with >>>this drm module. It does with kernel module built from BenH's linuxppc >>>dev >>>tree, but I haven't tried the dri CVS before, so I don't know yet if >>>it even works >>>without the COMMIT_RING changes. [...] >>> >>Decided to do a quick compile and check before calling it a night. >>Without the >>patch, agp also fails to map the ring buffer. I'll take a look at merging >>in whatever fixes are in BenH's src tree tomorrow. >> > >Like http://www.penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff ? :) >
Exactly like that... AGP is mapping the ring now. So to the results -- again this is with dual 450 G4's with SMP linux 2.4.19-rc1-ben0, DRI CVS from Monday on top of XFre86 2.4.0 with the Michel's XV dma patch, indirect buffering patch, ioremap patch, the r128 endiness patches and the COMMIT_RING changes. While it is still possible to hang X in any combination of PCI/AGP mode and XV dma enabled/disabled by mixing various pairs of XV, DRI, and concurrent X activity, like x11perf, in general it takes more effort. When it does hang I've yet to see a hard hang of the X server or of the system, as was common before. In all hang cases the offending processes could be killed and X would continue, if I was lucky enough to kill the right process, other processes would restart. Previously enabling XV dma, xine starting play would almost always hang in a very short time with SMP kernels. On occasions it did play for a while, trying to move another window was extremely jerky and slow, dispite a very low CPU load (10-15%), and would always result in an eventual hang. Hangs almost always required a reboot to recover. Now, xine with XV dma will play as long as there isn't much other X activity. X remains responsive with windows moving fairly smoothly. I was even able to run X11perf for a couple of minutes before problems occured. But, I've yet to see a literal hang, except when starting a GLX program, and killing the GLX program allowed xine to continue. The problem I now see repeatedly with XV dma is that eventually X11perf or moving a window will cause video sync to go haywire. Xine is playing audio and the keyboard is responsive, and I can ctl-alt-del. But video sync does not recover when X exits or is restarted, a reboot is required to reset the video card. Previously I had somethimes seen a problem like this, but never had keyb responsiveness and attempts to recover from a telnet session often resulted in a system hang when trying to kill X or perform a shutdown. Overall, pci mode and XV dma disabled is still the most stable mode, but agp mode with XV dma disabled is more usable. I was able to run the Mesa terrain demo with texture, two gears demos and x11perf in agp mode for 20minutes, with frequent moving and raising of windows, before a deadlock that was cleared by killing the glx processes. BTW, I do see quite a few "128(0): Idle timed out, resetting engine..." being logged by r128_accel.c's R128WaitForIdle() routine when running x11perf with both the old and new drivers. Henry > ------------------------------------------------------- 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
