> This, of course, would not work if the memory controller is misprogrammed > - which was the cause of failures.
Goood old discussion :) > Which way can memory controller be misprogrammed ? The part that concerns > us are positions of Video RAM, AGP and System Ram in Radeon address space. > (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). > > The memory controller *always* assumes that system RAM (accessible via > PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 > then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. > However, the size of video > RAM is usually much smaller than the size of system RAM. So if the scratch > registers image in system memory had small physical address you might get > a lockup and if it was high you don't. You also would be more likely to get > a lockup when load on system memory increased. > > This problem has been fixed for plain Radeon drivers, but it could be > that something similar is manifesting again on R300.. Yup, look at X.org side, it's still getting wrong. > Note that old driver was able to test whether mirroring works, so it > would correspond to behaviour of RV350 cards. It could be that R300 cards > are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. Ben. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
