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@xxxxxxxxxxx> 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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
