Periodic Fedora 9 system hangs with jumpy mouse

[Deron Meranda]

Steve, your observed Xorg behavior certainly sounds very much like mine.
It is quite frustrating.

I've been trying to minimize my use of Firefox (painful) and shutting
the app down when I'm not using it; and so far that seems to have
greatly reduced (but not eliminated) the frequency of my hanging.
But still, this almost has to be an interaction between the kernel and
Xorg.  I really wish I knew how to go about debugging the kernel
when it gets in this mode....even if it's just to identify "what" it is
doing.


First, to compare systems..  It looks like you're running with a 64-bit
kernel; I'm using a 32-bit 2-core processor.  Are you also running
with SMP (multiple CPU cores?).  Do a:   cat /proc/cpuinfo

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)

My card also has dual-head output capability (one DVI and
one VGA); but I'm only using the DVI output only.  I'm also
not using any of the 3-D stuff.

What does your card identify itself as?  Try doing:
  lspci
Also look in the Xorg.0.log file:
  grep -i chipset /var/log/Xorg.0.log


On Tue, Jul 1, 2008 at 9:26 AM, Steve Dowe <steve.dowe at onecool.com> wrote:
>> The cause of this problem on my system seems to be when dragging
>> (resizing) a window.  X then seems to hang, the pointer gets jumpy

Although mine happens (usually) when I'm doing vertical scrolling,
they may be related.  In both cases there is usually a lot of bitmap
moving occurring, which may be a bitblit operation of some sort,
possibly involving 2D acceleration.

> I should also have added that the  mouse cursor image "sticks" to the
> diagonal arrow - it doesn't become the normal arrow/pointer again.

This is probably to be expected.  I believe that the cursor/pointer
movement is "hardware" assisted; which means that it runs within
interrupt code and not in the main Xorg event loop.  Changing the
pointer graphic though must be done outside interrupts; and the Xorg
process appears to be stuck.

See if you see what I do:

$ grep -i cursor /var/log/Xorg.0.log
(II) RADEON(0): Using hardware cursor 0 (scanline 1202)
(II) RADEON(0): Using hardware cursor 1 (scanline 1204)


> I have just booted up in the debug kernel and managed to re-hang X in no
> time at all, using the method described above... :-/

Hmmm. I should try that too.


> The only error message I can find, both in dmesg and messages, is this:
>
>  kernel: ACPI Error (tbfadt-0453): 32/64X address mismatch in
> "Pm2ControlBlock": [00008800] [0000000000008100], using 64X [20070126]

I don't know for sure, but this seems like a problem that would
only occur on a 64-bit system.  I only have a 32-bit system.

I don't know if this would be related to your Xorg hanging, but I
would have to guess that such an error would cause a process
(or the kernel) to be completely aborted/panic'd....not get
stuck in a 100% cpu loop.


One thing we could try, is to pass options to the ATI driver
to disable certain features (perhaps like certain forms of
acceleration??).  You can do a "man radeon" to see the
options available.  Those would supposedly go into your
/etc/X11/xorg.conf file.   I don't have any good suggestions
on what to try though; and it's tedious to do the trial and
error thing.

Any kernel-savy people have any ideas of how to collect
more information about this?
-- 
Deron Meranda