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

Sorry, I just went digging through my Junk folder, and found this e-mail.

On Mon, 30 Oct 2006 15:15:10 -0500, Roland Scheidegger  
<[email protected]> wrote:

> 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.

ACPI resume? What's that? Is that in the logs? I have been using VT a ton,  
but how does that affect me?

>
>> 	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.

It does seem to elimate the screen-goes-blank-minutes-after-login crash.

>>          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?

No, sometimes it is more unstable this way... I tihink... thing is, it is  
so hard to tell what caused the crash.

>>          Option          "EnableDepthMoves" "false" # MUST BE FALSE!!!
> In general, depth moves are very very slow, but does it affect stability?

Don't know. Again, it is hard to tell, but this seemed to cause crashing,

>>          Option          "ColorTiling" "false" # More stable this way.
> That's interesting. Never heard that it would cause stability problems.

Well, again... not sure...

>>          Option          "DynamicClocks" "true"
> You could try disabling that, there were some problems with it in the  
> past.

Now that I've got latest git drivers installed, this doesn't seem to make  
any affect.

>>          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

Well, I don't _need_ it, but I really want it.

> , 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.

So is there a way to test or fix this? Some patch? Configuration? I've got  
latest drm, mesa, and xf86-driver-ati stuff compiled into my system, so we  
can use that if we need. Anything to get this stupid crashing fixed! I've  
been working on this for about 6 months. That's way too long for me. :(

Oh, by the way, since I last posted here, the crashing's changed. I no  
longer get the fade-into-whitish-negative crash or the TV-squigglies, but  
I get everything else plus screen-turns-black crash. I also get a new one  
where the screen seems to be stretched vertically, and zoomed in, and then  
added a bunch of fuzzies. Cursor still moved (hardware cursor) until I  
pushed Ctrl+Alt+F1 to get to a console so I could reboot my system safely.  
Then the cursor froze up, but the squigglies kept moving. I've taken a  
picture of this new one. I'll upload it later today.

-------------------------------------------------------------------------
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
--