[R300] on lockups
I just wanted to contribute the following piece of information that might help with R300 lockups. I do not know whether it applies or not in this case, but just something to be aware about. Radeon has a memory controller which translates internal address space of the chip into accesses of different memory - framebuffer, agp, system ram. So from the point of view of Radeon chip there is a single flat 32 bit address space which contains everything. This is nice because you can simply set texture offset to a particular number and the chip will pull it from appropriate memory - be it video memory, agp or system ram. (albeit system ram access is done via PCI, not AGP commands and thus is much slower). It used to be that Radeon DRM driver had two modes for usage of scratch registers - a mode when it polled Radeon chip directly and a mode when the contents of the registers were mirrored in the system RAM. The driver would try mirroring during startup and if it fails uses polling method. The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. 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. 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.. 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. On the other hand, all of this might not be relevant at all.. best Vladimir Dergachev --- 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
Re: [R300] on lockups
On Saturday 04 June 2005 15:01, Vladimir Dergachev wrote: I just wanted to contribute the following piece of information that might help with R300 lockups. I do not know whether it applies or not in this case, but just something to be aware about. Radeon has a memory controller which translates internal address space of the chip into accesses of different memory - framebuffer, agp, system ram. So from the point of view of Radeon chip there is a single flat 32 bit address space which contains everything. This is nice because you can simply set texture offset to a particular number and the chip will pull it from appropriate memory - be it video memory, agp or system ram. (albeit system ram access is done via PCI, not AGP commands and thus is much slower). It used to be that Radeon DRM driver had two modes for usage of scratch registers - a mode when it polled Radeon chip directly and a mode when the contents of the registers were mirrored in the system RAM. The driver would try mirroring during startup and if it fails uses polling method. The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. 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). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev-agp-base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. 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. 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. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? cu, Nicolai pgpNmZIBoEWgy.pgp Description: PGP signature
Re: [R300] on lockups
Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. Ok, then that leads to another issue ... some AGP bridges simply don't support writes to AGP memory (or seem to support it but screw up). Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. Yup. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? I don't know for sure, probably harmless though. What I know however is that we don't program it properly since we use CONFIG_APER_SIZE, which is the aperture size on PCI and has nothing to do with the actual amount of video memory on r100/200. I don't remember what we do on r300 except that we put it down to 0 which is wrong too. This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? Well, the recommended practice is to set MC_FB_LOCATION such that the framebuffer is at the same address in card's space as it's bus address from CPU viw, that is to whatever is in the BAR. (CONFIG_APER_BASE I suppose). Then to put AGP just after that (or before that if that doesn't fit). I think we do some of that for r100/r200 (though with the issue I describe above of using the wrong information for the size) and we just put the FB down at 0 for r300. 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
Re: [R300] on lockups
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
[Bug 2754] ATI Technologies Inc Radeon Mobility M6 LY in DRM/DRI mode locks up if CPU frequency changes on battery power
http://bugzilla.kernel.org/show_bug.cgi?id=2754 --- Additional Comments From [EMAIL PROTECTED] 2005-06-04 21:18 --- I've no ideas on this either, there should be nothing cpufreq should affect in the dri/drm driver, I'm thinking the X server may be doing something bad and XFree86 4.3 in Debian is pretty old... I might see if I can reproduce this on my laptop when I get a DRM working on my pciexpress graphics card... --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
[Bug 2554] DRM fails to compile on i386
http://bugzilla.kernel.org/show_bug.cgi?id=2554 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
[Bug 3294] i830 bug when loaded without intel-agp
http://bugzilla.kernel.org/show_bug.cgi?id=3294 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
