Periodic Fedora 9 system hangs with jumpy mouse

Deron Meranda deron.meranda at
Tue Jul 1 20:46:53 UTC 2008

On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <steve.dowe at> wrote:
> I became aware of the firefox buffer memory flushing issue when running FF
> 3.0b5.  However, it seems to behave itself very well now on my box, using
> FF3.0.  Here is a link which I found useful in understanding that issue
> further:

Good link, but I think it is entirely unrelated to this.  I'm running FF 3.0
final.  Besides I never see any I/O contention; and many times when
it hangs there is not disk I/O at all.  And the hang never clears up,
even after sitting for hours, as an fsync delay would cause.  And the
wchan for FF (or Xorg) never indicates that its blocking on an fsync.
Also I can and have done filesystem writes *after* such an Xorg
hang with no problems.

> I suspected something was wrong by seeing a high CPU count for kcryptd,
> which is used to encrypt a hard disk if configured that way (incidentally,
> high kcryptd CPU was, in that case, a red herring).

I'm also using an encrypted logical volume (dmcrypt/LUKS) for my
home directory; but I've not seen anything suspicious about it.
Only Xorg hangs, anything else I try to do (from a command line)
works fine.

> I'm running on an AMD Turion TL-60.  Sounds like you have an intel?

So you have a SMP 64-bit, and I have an SMP 32-bit.
Yes, I'm have an Intel Pentium 4 (300MHz) with
hyperthreading (pseudo 2-core).

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.

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

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

> man radeon - excellent intro doc to the driver.  The first two options are
> of primary interest to me:
>     Option "SWcursor" "boolean"
>             Selects software cursor.  The default is off.
>      Option "NoAccel" "boolean"
>             Enables or disables all hardware acceleration.
>             The default is to enable hardware acceleration.
> I'm going to try with both of these options enabled in xorg.conf and see if
> I can hang the machine again.  If so, perhaps we should look at the kernel.

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.

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.

(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).
Deron Meranda

More information about the fedora-list mailing list