Okay, so Xorg ran away last night while the system was totally idle and not being used at all. So I guess the scrollbar theory could be suspect. There was a screensaver running (just the "cosmos" image slideshow, no moving graphics); and I left firefox up, which had a gmail window running so it would I supposed occasionally refresh itself. But otherwise it should have been a completely idle unused system. My big question at this point is how is this locking up so hard? When you can't even kill -9 the process, what is going on. This has to be more than just Xorg (a user-space program), the kernel has to be involved here too. Is it a spinlock deadlock, or something like that? So how can you figure out what all those cpu cycles are being used for? Isn't there a way to probe into the kernel to see what it's doing? Unfortunately the wchan is 0, which is how I thought you could tell this sort of thing. Is there some place under /proc or some other method to peek around? Anyway, concerning the Xorg driver module, this is a brand new install of F9 (not an upgrade). All the software is part of the base F9 repo; nothing 3rd party was added. Everything was auto-detected. The video card shows up in a system scan as: ATI Technologies Inc RV350 AS [Radeon 9550] Chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) The vendor's name on the box was: Diamond ATI Stealth X1050 (AGP 256MB) The Xorg driver chosen for this was: /usr/lib/xorg/modules/drivers//radeon_drv.so My screen is 1440 x 900 x 24, monitor is DELL E198WFP > just for fun and practice of card swapping, do you have a different > graphics card to try with different drivers? The only other card I had was a PCI card that only had VGA output, no DVI. And F9 didn't seem to know how to detect the monitor correctly and was overdriving the frequency (although it worked under F7). > do you boot level 3 or level 5. boot level 3, if cpu usage is low, then > 'startx' to see what happens. mono verses color. Yes, I can try that. So far it's just been boot to runlevel 5. > from level 3 boot, remove driver, then use 'yum install' to bring your > driver back in and reboot to load it. driver may be fried. The driver is coming from the package xorg-x11-drv-ati-6.8.0-14.fc9.i386 I did an rpm verify on it, rpm -V -v xorg-x11-drv-ati-6.8.0-14.fc9.i386 and that said all the files were intact and correct. > kde, gnome? have you tried any minimal desktops? something may, tho i > would doubt, be different in how you bring up x. Haven't tried other desktops other than Gnome, but I have disabled all the fancy effects, etc. The system runs perfectly fine; until that magic moment when the Xorg process runs away. Or is that the kernel that is running away? I wish I knew how to debug the kernel better; because it just doesn't appear to be a user-space problem. -- Deron Meranda -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
