From: Leif D. <lde...@re...> - 2003-03-05 19:32:04
|
On 5 Mar 2003, Dave D. wrote: > On Wed, 2003-03-05 at 02:19, Leif Delgass wrote: > > On 4 Mar 2003, Dave D. wrote: > > > > > Hi folks, > > > > > > I'm using Leif's mach64 dri branch, mach64-0-0-6-branch. > > > > I just want to point out that the mach64 driver is the combined work of > > Gareth Hughes, Jose Fonseca, and myself. If you're talking about the code > > in DRI cvs, you can just call it the DRI mach64 driver. ;) > > My apologies to all, credit where credit is due! > > > > I'm running the branch on top of 4.2.0 right now, so I don't think that's > > a problem. > > Okay, that's good to know. I would like to understand more about > the meanings of version numbers in X though. When you build from the DRI tree, you end up with the X server binary and driver modules matching the version of XFree86 that the DRI tree is based on (in this case 4.2.99.2). Other libraries and modules not directly related to DRI will come from your original X install. So for example, you won't be able to use the RandR extension unless the libXrandr library from your X install is recent enough. Having the X server binary and driver modules match eliminates most of the potential incompatibilities, but there's still the potential for problems if the original X install is significantly older then the version of X in the DRI tree. I'm not sure if there's any hard and fast rule regarding differing version numbers that would gaurantee compatibility. The mach64 branch will be updated to 4.3.0 once the merge to the DRI trunk happens. > > Could you post your XF86Config? It sounds like a syntax problem in the > > config. It should look something like: > > > > Section "Device" > > [...] > > Driver "ati" > > Option "DMAMode" "mmio" > > [...] > > EndSection > > Ah...all I needed was some quotes, doh! Thanks for this little > snippet, it was the missing information for me I guess. > > Glxgears is running fine now, and I'm getting a pretty consistent > ~147 fps for this. Ok, good -- I figured it might be something like that. > > The recent discussion about a PCI posting problem in the Radeon driver has > > got me thinking again about the problem with DMA on ppc in the mach64 > > driver. Would you be willing to try applying a patch or two to the DRM > > in the mach64-0-0-6-branch and testing DMA? > > I would be glad to; just let me know how I can go about doing this. > > Dave OK, that would be great. First off, I should say that have to be prepared for a few lockups and reboots when testing DMA. A journalled filesystem makes this a bit less painful, but isn't a requirement. Also, if you normally use xdm/gdm/kdm, I'd recommend switching to runlevel 3 and testing with startx. If you have remote access to the test system with ssh, this can also be useful if the X server locks up, but the system is still responsive. I guess the first thing to do is to test DMA with the current DRM, to see if anything has changed since this was last tested. Try changing the DMAMode option to "async" and restart the X server. You can start off by trying some of the Mesa demos: glxgears, tunnel, etc. If/when you get a lockup, the best thing is to restart from a powered-off state, to make sure the card gets fully reset. If you have remote access and can log in after the lockup, make a copy of the system log (the drm will write some debugging info to the log on a lockup) and halt the system before powering up again. Assuming that you get a lockup on the first test (which you probably will), try applying the attached patch: 1. copy the diff file to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel in your build tree 2. Apply the patch with: "patch -p0 < dma-testing1.diff" 3. Rebuild the drm: "make -f Makefile.linux clean mach64.o" 4. Install the new drm as root: "cp mach64.o /lib/modules/`uname -r`/kernel/drivers/char/drm/ 5. Exit X and unload the mach64 module as root: "rmmod mach64" 6. Run startx (as a normal user) and test. Check the system log for messages with "[drm]" Depending on what kind of output you get in the system log, it might be useful to turn on debugging in the drm, but I can explain that later depending on how the test goes. -- Leif Delgass http://www.retinalburn.net |