After upgrading from xorg 1.5.3 (which ran perfectly) to xorg 1.6 (current stable), following the upgrade guide including libxcb, and considerable fiddling with kernel configuration and xorg.conf, I now can "startx" with XSESSION commented out of /etc/rc.conf, and get a clean start of FVWM, which performs properly and stays up. Using XSESSION to start KDE-3.5 (current stable), KDE works for anything from a couple of seconds to several minutes, then the machine locks up. The mouse pointer moves on the screen, but the mouse buttons, keyboard, and power button produce no response. The machine is a Dell Optiplex G270 with a single Pentium 4 processor and 512M of DRAM #uname -a Linux fuchsia 2.6.30-gentoo-r6 #9 SMP PREEMPT Wed Oct 7 15:42:00 MDT 2009 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux #cat /etc/X11/xorg.conf Section "ServerFlags" Option "AllowEmptyInput" "FALSE" Option "AutoAddDevices" "FALSE" EndSection The dmesg, Xorg.0.log, and emerge --info are attachments since they are long. NOTE that the Xorg.0.log is obtained from an FVWM session, since after an aborted KDE session not even a journalling filesystem (ext3) can resurrect this file intact - it is truncated and full of garbage.
Created attachment 206558 [details] Xorg.0.log from an FVWM session
Created attachment 206560 [details] dmesg just after system startup
Created attachment 206561 [details] emerge --info
Power button producing no response is interesting here, but that's probably a KDE quirk. You've probably misunderstood (as many did) the upgrade guide. (AFAIK, KDE starts hal, not sure about it, as I don't use it) Is your mouse/keyboard USB/wireless (it may explain the random time) ? Is that your full xorg.conf ? Do you have any real reason against hal/evdev ? (I'm not a hal-in-xorg-server enthusiast, but it doesn't bother me much)
Power button is an embarrasment - I just discovered acpid was not running. When it is, the power button gets me out of the freeze. It even shows up in Xorg.0.log, acpid connection now succeeds. Other than that, the log is not changed after an aborted KDE session compared to the one attached here. I wouldn't be a bit surprised if I had misunderstood the upgrade guide, and have had some correspondence about it with the author. He believes that the results I now get from the checking script show that the system is now OK. Nothing on this system is wireless, even the network is wired. That's all the xorg.conf I am now using, the result of a lot of experiments and advice on the forums. I'm using hal and evdev, which is a bit trickier than it was under xorg 1.5.3. The second line in xorg.conf is needed to stop all characters from the keyboard appearing in triplicate.
Please remove both ServerFlags options, AllowEmptyInput is a debugging option, and AutoAddDevices is to stop HAL from being used. Let's figure this bug out _first_, we'll tackle the KDE hang later in another bug. Thanks
This corresponds to no xorg.conf at all. Tried that, X comes up and works as before, which shows that you should not believe all you read in the forums. Regrettably, it still freezes. It seems to last a bit longer if started from root than from a user, but this may be coincidence.
A bit more information If I stick to purely text commands within an xterm window, KDE will stay running. any graphical command, such as starting a new app or resizing a window, seems to cause the crash. I never did a graphical command in FVWM, which is probably why it continued to work. I still think this is an xorg issue. It started when I updated X from 1.5.3 to 1.6, and KDE did not change in that update, though many of its files were rebuilt during the libxcb update.
(In reply to comment #7) > This corresponds to no xorg.conf at all. Tried that, X comes up and works as > before, which shows that you should not believe all you read in the forums. Yeah, there can be a lot of misinformation in the forums :) > Regrettably, it still freezes. It seems to last a bit longer if started from > root than from a user, but this may be coincidence. Indeed, probably just a coincidence. (In reply to comment #8) > A bit more information If I stick to purely text commands within an xterm > window, KDE will stay running. any graphical command, such as starting a new > app or resizing a window, seems to cause the crash. Sounds like a server/driver bug indeed. > I still think this is an xorg issue. It started when I updated X from 1.5.3 to > 1.6, and KDE did not change in that update, though many of its files were > rebuilt during the libxcb update. The X libraries are just protocol libraries which allows apps to talk to the server. The assumption here is that the server should _never_ crash (yeah... long shot). So let's just concentrate on the crash, I don't think KDE's to blame here. Could you try upgrading to the latest ~arch gentoo-sources and/or to the latest xf86-video-intel in ~arch as well? Could you also post Xorg.0.log after the crash? (Xorg rotates the log with Xorg.0.log.old in the same dir) Thanks Thanks
Created attachment 206689 [details] Xorg.0.log post KDE crash Root session, lasted about 2 minutes
Moving to latest xf86-video-intel in ~arch with the stable kernel does not help or hinder. Behaviour seems completely unchanged. I'm compiling the latest ~arch gentoo-sources now. In this, as in the old kernel, framebuffer support is off. This was a stage in getting things as far as they are now. I'll put framebuffer back when the system seems to work, unless you specifically wish it to be on.
With the latest ~arch gentoo-sources and to the latest xf86-video-intel in ~arch the system seems stable, to the extent that a very active 15-minute KDE session caused no crash. I'll try activating the framebuffer.
There seems to be no framebuffer support in the latest kernel that would apply to my video card, so it looks as if I'm finished. The KDE session has run flawlessly for 30 minutes. This looks like the solution. Thanks to all who helped.
Thanks for the follow up, Rick, I greatly appreciate it :) FTR, with newer kernels, you shouldn't use framebuffer drivers anymore (vesafb, uvesafb, intelfb, etc). Those drivers are now in direct conflict with the Intel DRM driver (i915). Instead you should enable Kernel Mode Setting (better known as KMS) which provides a framebuffer driver (inteldrmfb) on _using_ the DRM driver. To enable KMS, you have 2 choices : - just add "i915.modeset=1" to your kernel commandline in grub.conf, or - rebuild the kernel with "KMS on by default" in your kernel config. Either way, I strongly advise you to try KMS as it will become the only supported driver option soon. Please don't hesitate to file new bugs if you have any issues with or without KMS. Thanks
Reopening
And closing with the proper resolution. Thanks
With KMS built ito the kernel, everything seems to work perfectly.
