Periodic Fedora 9 system hangs with jumpy mouse

Steve Dowe steve.dowe at onecool.com
Tue Jul 1 21:32:24 UTC 2008


I think I have the answer (below).

Deron Meranda wrote:
> On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <steve.dowe at onecool.com> wrote:
>   
>> http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
>>     
>
> Good link, but I think it is entirely unrelated to this.  <snip>
>   

Sorry, I misunderstood the reason that you mentioned FF originally.
> I wonder if disabling SMP at boot has any affect? Use
> the "nosmp" boot-time kernel option.  Note though that if
> you're running with only one cpu and Xorg goes wild, you
> may not be able to ssh or do anything else, depending
> where at in the kernel this problem is occurring.
>   
Actually, I don't think it's kernel based.    But your original 
suggestion about 2D acceleration was right on the mark, at least as far 
as my testing goes.

>>> My card is a Diamond Stealth ATI X1050; which is really a
>>> vendor repackaging of an ATI RV350 AS [Radeon 9550],
>>> an AGP version.  It also supposedly has this as its chipset:
>>> "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153)
>>>       
>
> and yours is a:
>
>   
>> 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
>> Series]
>> (--) RADEON(0): Chipset: "ATI Radeon X1200" (ChipID = 0x791f)
>>     
>
> It looks like we have quite different ATI cards; but I don't know
> my Radeon product line very well.
>   

Indeed, and the only similarity between our systems is the driver, 
despite being 32 vs 64 bit.

>> # grep -i cursor /var/log/Xorg.0.log
>> (II) RADEON(0): Using hardware cursor 0 (scanline 1602)
>> (II) RADEON(0): Using hardware cursor 1 (scanline 1604)
>>
>> Presumably this is influenced by the display dimensions and refresh rate?
>>     
>
> You're using hardware-assisted cursor/pointer; which is the
> default.  I think the scanline numbers indicate at which point
> in the screen refresh cycle that the interrupt will be generated
> (but I'm kind of guessing here).  It's not too important.
>
> If you disable hardware cursors in your xorg.conf, those
> lines should not appear in the log file.
>   
I didn't check this, but I did enable these options in my "Device" 
section in xorg.conf:

    Option "SWcursor" "on"
    Option "NoAccel" "on"

.. and then restarted X.  Boy, imagine life without hardware 
acceleration (no, don't!!).  I had complete success with this config - 
no hanging issue despite really, /really/ trying to upset X with my 
mouse pointer.  It just wouldn't hang, but I knew I was working it hard 
as my cpu fan speed increased :)

> It will be interesting if NoAccel works.  Of course that's quite a
> drastic workaround and may make your system seem very
> sluggish.  But it could give a clue if the system behaves differently.
>   

Given the above, I then re-enabled hardware acceleration but retained my 
software cursor and restarted X.  The result?  I managed to hang X 
within a few minutes of (frantically) drag-resizing a firefox window.  
And my mouse pointer completely disappeared this time, which confirms 
that it was running in sw mode.
> Unfortunately the system hanging on me is one of my primary
> workstations and I don't have the luxury of being able to
> tweak and play with different options as much; especially
> since having to do a hard reboot is so disruptive.
>   
That's ok - my work laptop doesn't mind  ;-)

> (I will say that I haven't had a lockup in about 3 days now;
> previously I'd see lockups 3 or 4 times a day.  I do stay up
> to date on patches, but the only things recently which seem
> even remotely plausible are a HAL and libsysfs update and
> some SELinux policies.  I may just be lucky, we'll see how
> long my system stays up).
>   
In case it hangs again, try:

    Option "AccelMethod" "EXA"

.. in xorg.conf (in the Device section).  This is a new acceleration 
architecture which, while apparently not as mature (i.e. field-tested) 
as XAA (the default acceleration architecture), seems to at least hold 
up to my slipshod X testing method in this case.

I've had an interesting evening researching this, which I wouldn't have 
had were it not for your suggestions. 

For more info on the changes in the radeon driver, check the Change Log 
of the xorg-x11-drv-ati-6.8.0-14.fc9 package (via Yum/Yumex), together 
with these links:
- 
http://linux.softpedia.com/get/System/Hardware/ATI-Open-Source-Video-Driver-35337.shtml
- http://zerias.blogspot.com/2008/02/amd-more-open-licensed-goodies.html
- http://www.botchco.com/agd5f/ (http://www.botchco.com/agd5f/?p=6)
- http://lists.freedesktop.org/archives/xorg/2008-February/032992.html

 From those, you should be able to establish a good idea of the recent 
(5 month) history of this driver development and the issues faced by 
those involved.

Thanks again for your help and suggestions.

Steve




More information about the users mailing list