On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <steve.dowe@xxxxxxxxxxx> 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: http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ 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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
