Re: ATI Radeon M6 LY in Edgy - does some crashing - how do I debug?

Roland Scheidegger <[email protected]>
Newsgroups gmane.comp.video.dri.user
Message-ID <[email protected]>
Jacob wrote:
> My ATI Readon M6 LY has never been stable, and it isn't any more stable  
> now with Edgy, either. Mostly crashes come with static across areas that  
> scroll, sometimes without freezing at all. Sometimes crashes come with  
> stripes across the screen, mostly vertical, with the screen fading to  
> something like negative, and then to white, sometimes "snapping out of it"  
> with the screen going back to normal. Most of the time I have to reboot,  
> however.
> 
> I've pasted complete logs and configurations for that boot below. You'll  
> notice in the xorg.conf, I commented options that I think make my system  
> more stable, but am not really sure. The crash that belongs to these logs  
> are the one ith the screen fading to something like negative, and then to  
> white. The computer had frozen, but I was able to go through the  
> Alt+SysRq+S, Alt+SysRq+U, Alt+SysRq+B procedure to reboot safely.
Typical symptoms of a gpu lockup.
Not sure, but the log seems to indicate there was a vt switch or maybe 
some acpi resume? The problems could be related to that.

> 	Option		"BusType" "PCI"
Do you really need that? On some hardware it seems to make a difference 
to stability, but I'm a bit puzzled about it.
>          Option          "AGPMode" "4"
This obviously will be ignored with bustype pci, but otherwise it should 
work fine, unless you have a chipset which is known to be problematic.
>          Option          "AGPFastWrite" "false" # MUST BE FALSE!!!
Yes, this often doesn't work at all.
>          Option          "SWcursor" "true" # MUST BE TRUE!!!
What happens otherwise? Immediate lockup?
>          Option          "EnableDepthMoves" "false" # MUST BE FALSE!!!
In general, depth moves are very very slow, but does it affect stability?
>          Option          "ColorTiling" "false" # More stable this way.
That's interesting. Never heard that it would cause stability problems.
>          Option          "DynamicClocks" "true"
You could try disabling that, there were some problems with it in the past.
>          Option          "XAANoOffscreenPixmaps" "true"

Though maybe your problems could be related to that:
 > (--) RADEON(0): Mapped VideoRAM: 8192 kByte (32 bit DDR SDRAM)
If that's really 32bit ddr sdram, the available bandwidth is a bit low 
(depends of course on the clock frequency of the ram too, but I'd guess 
it's not that high). I've speculated in the past that very low bandwidth 
situations (which undoubtly will also cause high latency) might cause 
lockups - the speculation being caused by the fact that dri (and cp 
accel) doesn't seem to work reliably at all on the es1000 (with 16bit 
ddr sdram - though probably clocked around twice as fast as yours). And, 
some experiments with placing the back buffer into main memory also was 
quite prone to lockups with a rv250. This isn't really any sort of 
proof, the lockups in both of those low-bandwidth/high latency 
situations could easily be caused by other things. Though if it is, 
maybe the programming of the memory controller would need some tweaks.
If you don't need 3d, you could try using the mmio accel code instead 
(by not loading dri, or if it's autoloaded, by making sure the agp gart 
kernel driver is not available (when using agp gart) for instance). It 
feels quite a bit slower in some cases, but this is what's used for the 
above-mentioned es1000 too.

Roland

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.