FS#13642 - Xorg crashes / freezes system
Attached to Project:
Arch Linux
Opened by Georg Grabler (STiAT) - Tuesday, 03 March 2009, 09:29 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 28 April 2009, 18:23 GMT
Opened by Georg Grabler (STiAT) - Tuesday, 03 March 2009, 09:29 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 28 April 2009, 18:23 GMT
|
Details
Description:
xorg-server freezes the whole system with intel drivers. Additional info: * xorg-server 1.6.0-1 (testing) * intel drivers 2.6.2-1 (testing) * Intel Corporation 82865GG graphics controller Steps to reproduce: Install, boot X (startx). Attached file * Xorg.0.log from a crashing startx Please let me know if you need additional information. I think it's an upstream bug though, but to keep track on it. |
This task depends upon
I don't know if you're using an xorg.conf, but if you do, could you supply it as attachment? Further, you might want to try the different AccelMethods, XAA, EXA or UXA. Default is EXA.
1.) Starting up and freeze (mouse working, not able to click anywhere, keyboard not working, not even ctrl+alt+backspace, windows not reacting on mouseover anymore as they use to do on a clean startx)
2.) Starting up and everything is working. Locks up some seconds later
3.) Starting up and everything is working. Locks up as soon as I exit X.
The 3rd case is very uncommon, and I just had it two times trying about an hour with dozen of reboots. Most likely, it's #1 or #2, at a chance of 50/50, what's probably just about how long X needs to start up.
Starting kdm/gdm always locks up, most likely since starting kdm takes a little bit longer than a startx.
Strange is, that I most likely can move my mouse, but nothing happens hovering or clicking (means that X locked up).
Even though, a normal startx also doesn't get rid of the problem - and this shouldn't use compositing at all.
Not even the windows (the 3 xterms which are usually opened by startx) were loaded.
Also, I just managed to start up X using startx, getting a full X display with all 3 xterms, where I even managed to type something in a console window. The lockup followed short later (without executnig any command).
Looks like "random lockups", or probably an upstream issue. Any way to get more information out of xorg what's going wrong? verbose?
I'm working on a pciaccess port of the old i810 driver. I hope I can get this thing working, because it's a solution for all i8xx users who are left behind by recent development in the intel driver. I know a lot of users are still using the i810 driver with the old and non-supported xorg-server-1.4 version.
I'll check if it also occurs on the 945 this eve' (which is a bit newer) on my notebook.
I've been fighting all day with this problem, and I tried tons of different configuration, I'll try to summarize the most relevant things.
* I use slim as a login manager. When it started today I had no mouse cursor and the keyboard didn't work. The machine was well alive, though, as a quick ssh could confirm. I checked my xorg.conf just to make sure I didn't have any input devices specified, since I use evdev, but everything was ok. No AutoAddDevices option, so it should default to true.
* Every possible combination of AutoAddDevices and AllowEmptyInput didn't change anything.
* I tried setting AutoAddDevices to false and specifying mouse and keyboard the old way, but I only got the mouse to work, with both 'mouse' and 'evdev' drivers.
* USB and PS/2 keyboards behave the same way.
* A point that seems very interesting to me is lots of "expected keysym, got XF86..." warnings when running startx: this never changes, nevermind what I do.
* Being desperate I tried removing the whole xorg.conf, and this produced a change: most keystrokes changed the screen resolution and color depth. This reminded me of an old problem which required to export the XKEYSYMDB variable to make X work (http://bbs.archlinux.org/viewtopic.php?id=50221, http://bbs.archlinux.org/viewtopic.php?id=19200 and more). It made the keyboard work. Well, somewhat. Sometimes X froze after a few seconds, that's why I think it is related to this bug. We both had this problem without xorg.conf, so it's probably overridden somewhere.
* Looking at the log I noticed that X configured itself to work with fglrx, ati or vesa, not radeonhd, so I created a xorg.conf that only contained the Device section and specified the driver. That's the one I'm using now. The situation got better, and X lockups seemed to stop. Maybe this is only one of two problems I'm experiencing.
* I exported XKEYSYMDB in /etc/rc.d/slim, but when I got to the login screen I had to press some keys twice to actually get them on the screen. Moreover, entering my X session resumed the resolution switching behavior, so I thought that the XKEYSYMDB value isn't inherited when logging in, and I returned to startx.
* Most things now work, the only crazy effect is with the keyboard: some keys work, others look more like that (or some other) key with some modifiers applied. Reinstalling/rebuilding kbd, libx11 (the package that contains the XKeysymDB file) and xkeyboard-config doesn't help.
I can produce logs for any of these situations, but I don't want to pollute this thread too much if it is unrelated (haha... like if I didn't already do it...). In case, just ask.
My head hurts.
1.) The driver works with a 945G chipset
2.) Xorg works with xf86-video-intel 2.4.3 installed
3.) Xorg works perfectly with nvidia
I filed an upstream bug report, let's see what the intel guys say to this situation. If it proves wrong to be a xorg / intel related problem, i'll report back.
http://bugs.freedesktop.org/show_bug.cgi?id=20453
I've tried a lot to get it working already with 1.6.2, even tried the master branch (1.6.3), a dozen configurations and more.
This needs to be fixed upstream - not a arch problem I'd say. For arch, the case is solved by adding the legacy driver.