Periodic Fedora 9 system hangs with jumpy mouse
Steve Dowe
steve.dowe at onecool.com
Tue Jul 1 19:59:56 UTC 2008
Deron Meranda wrote:
> Steve, your observed Xorg behavior certainly sounds very much like mine.
> It is quite frustrating.
>
It certainly is - I normally have to hard reset my machine once or twice
a day, on average. Sounds like you do at least this?
> 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.
>
>
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:
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
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).
> 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
>
>
I'm running on an AMD Turion TL-60. Sounds like you have an intel?
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 72
model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping : 2
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy
svm extapic cr8_legacy
bogomips : 1599.46
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 72
model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping : 2
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy
svm extapic cr8_legacy
bogomips : 1599.46
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
> 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
>
>
I'm using the Fedora open source Radeon driver. No 3D desktop effects,
etc.. which I couldn't get working on this card without fglrx and
downgrading X anyway. Hmm, that now sounds like a nice option. ;-)
# lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge
(Internal gfx)
00:04.0 PCI bridge: ATI Technologies Inc Unknown device 7914
00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI
Express Port 1)
00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI
Express Port 2)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon
X1200 Series]
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(rev 02)
10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M
Gigabit Ethernet PCI Express (rev 02)
30:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g
(rev 02)
# grep -i chipset /var/log/Xorg.0.log
(II) RADEON: Driver for ATI Radeon chipsets:
(--) RADEON(0): Chipset: "ATI Radeon X1200" (ChipID = 0x791f)
> 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.
>
>
This is interesting. It seems, on my system, somewhat related to the
speed at which I drag my mouse. If I drag nice and slowly when resizing
a window, I (usually, I think) get away with it. If I drag hastily, it
hangs. I was going to suggest some kind of timing issue, so it seems we
might be homing in on something here.
>> 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 get this:
# 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?
>> 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.
>
>
Didn't help much when I did it.. :-D
I wonder if there are kernel flags set by the bootloader which can
influence debugging level?
>
>> 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.
>
>
Fair enough. I suppose also that as this error was detected and
presumably correctly identified, it probably has a workaround in place.
Let's consider that item eliminated for now, then.
> 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.
>
>
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.
Will get back to you.
> Any kernel-savy people have any ideas of how to collect
> more information about this?
>
More information about the fedora-list
mailing list