Arch Linux

Please attach Xorg.0.log(.old) after this crash happens. I can't debug anything without that information.

I can confirm this is happening also to me:

xorg-server 1.6.3-2
xf86-video-ati 6.12.2-2

My gfx card is a ATI 4850.

I attached the log: when the crash happened I has Firefox 3.5, transmission and Audacious2 (playing music) running.

I don't see any weird things in this logfile. Are you sure it's from when X crashed?

It's the right file: it crashed some minutes ago. I forgot to backup ~/.xsession-errors, sorry.

But I found interesting messages in these other logs:

This is from demon.log:

Aug 10 12:47:37 accipigna gdm-binary[4626]: WARNING: gdm_slave_xioerror_handler: errore fatale di X. Riavvio di :0 in corso
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-WARNING: instance with invalid (NULL) class pointer
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-CRITICAL: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-CRITICAL: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Aug 10 12:47:38 accipigna acpid: client 4629[0:0] has disconnected

This is from everything.log:
Aug 10 12:47:37 accipigna gdm-binary[4626]: WARNING: gdm_slave_xioerror_handler: errore fatale di X. Riavvio di :0 in corso
Aug 10 12:47:37 accipigna kernel: [drm] Resetting GPU
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-WARNING: instance with invalid (NULL) class pointer
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-CRITICAL: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Aug 10 12:47:37 accipigna console-kit-daemon[4228]: GLib-GObject-CRITICAL: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Aug 10 12:47:38 accipigna acpid: client 4629[0:0] has disconnected
Aug 10 12:47:38 accipigna acpid: client connected from 6513[0:0]
Aug 10 12:47:38 accipigna acpid: 1 client rule loaded
Aug 10 12:47:38 accipigna kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Aug 10 12:47:38 accipigna kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Aug 10 12:47:39 accipigna kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Aug 10 12:47:39 accipigna kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Aug 10 12:47:39 accipigna kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Aug 10 12:47:39 accipigna kernel: [drm] Setting GART location based on new memory map
Aug 10 12:47:39 accipigna kernel: [drm] Loading RV770 PFP Microcode
Aug 10 12:47:39 accipigna kernel: [drm] Loading RV770 CP Microcode
Aug 10 12:47:39 accipigna kernel: [drm] Resetting GPU
Aug 10 12:47:39 accipigna kernel: [drm] writeback test succeeded in 1 usecs

Did you want me to attach Xorg.0.log.old immediately after a crash? I've attached the file here, but the crash happened a few hours ago.

I have the same bug, using the radeon opn-source driver on a RV3xx video card. And it is exactly the same behavior, randomly disconnected but seems related to keyboard. I have the same traces in my logs.

I suspect it's something in the -ati driver then. Does radeonhd have this problem also?

I have the same problem with the Intel driver. I'll attach the log after the next crash.

I just had one a few minutes ago, here is my log.. if it helps.

Here's my log.

Hmm there seems to be nothing interesting in my xorg log, sorry. But in everython.log, at the time of the crash :

Aug 11 10:41:47 xglurb-laptop gnome-session[2159]: WARNING: Detected that screensaver has left the bus
Aug 11 10:41:47 xglurb-laptop gdm-binary[2051]: WARNING: gdm_slave_xioerror_handler : erreur X fatale - Redémarrage de :0

I do have some strange behavior of the screensaver also : sometimes, the screen goes black, while I am working - mouse and/or keyboard is active (not idle). I just have to move the mouse or type something and I get my screen back. Maybe this is related ? It seems so when looking at the everything.log.
Does anyone has the same probleme here with the screen ?

Yes, i have the same problem with the screen.

The screen going black is what I also have here, I think it's related to gnome-power-manager not doing the right thing. I think it's fixed in 2.26.4, but we haven't updated yet.

As for the backtrace in Philipp B's comment:
https://bugzilla.redhat.com/show_bug.cgi?id=502252

I have the same problem. Seems like before some package update, behaviour was "the screen goes black, while I am working - mouse and/or keyboard is active (not idle). I just have to move the mouse or type something and I get my screen back" like Etienne said. New behaviour is X crashing.

I have the same problem(s), using nvidia drivers... just for totally discard a driver-specific problem

I can confirm also the screen going blank. I'm not 100% sure but this behavoir happens only when I use GNOME. The crash happens in GNOME and KDE indifferently.

I've been running these packages for more than a week now without crashing, so I can't reproduce it. I don't use any way of compositing, so that could make a difference.

I don't use compositing and the crashes occure any way.

there should be a test case that raises the bug. To me I can tell only that Firefox was running as main app. Then Transmission and Claws Mail minimized in background.
Note that in my .xsession-error there are a lot of:

(firefox:4770): Gdk-WARNING **: XID collision, trouble ahead

Could this be the trigger?

I don't have any compositing enabled. It tends to happen around once or twice a day at random and I am quite sure the keyboard is always involved.

Indeed it seems to happen when I'm using keyboard shortcuts in eclipse or gnome-terminal.

Today I also had the "screen goes black and then get back" behavior. So my previous assumption saying new behavior is Xorg crash was false.

It is not related to firefox or any application : it happens for me when using lyx, or tomboy, or a terminal, ... I really think too that the keyboard is involved, it seems to be our only track.

As someone said, it happens on gnome and KDE... I did not test any other DE.

I'm having a very similar problem and I can't find any relevant log information on that problem. I'd also like to know if any of you notice a problem switching tty sessions after relogging in gnome. In my case the tty7 (graphical) is always staying on screen but there's some graphics glitch in it and the screen is frozen.

same issue here with intel driver on a eeepc. composite disabled

Can people who experience this problem attach configuration files? I'm running this version of xorg-server since the day it was updated now, and it hasn't crashed once here. Please also report the kernel version and driver versions installed on the system. This includes evdev, your display driver, libgl and any associated DRI driver.

xorg-server 1.6.3-2
kernel-headers 2.6.30.1-1
kernel26 2.6.30.4-1
kernel26-firmware 2.6.30-1
xf86-input-evdev 2.2.3-1
ati-dri 7.5-2
xf86-video-ati 6.12.2-2
libgl 7.5-2


$ uname -a
Linux accipigna 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 07:30:28 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux

$ uname -a
Linux lappy 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 07:30:28 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz GenuineIntel GNU/Linux

xorg-server 1.6.3-2
kernel-headers 2.6.30.1-1
kernel26 2.6.30.4-1
kernel26-firmware 2.6.30-1
xf86-input-evdev 2.2.3-1
xf86-input-synaptics 1.1.2-2
xf86-video-intel 2.7.99.902-1
libgl 7.5-2

The xorg.conf was automatically generated in my debian times.

$ uname -a
Linux dell1526 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 18:10:38 UTC 2009 i686 AMD Turion(tm) 64 X2 Mobile Technology TL-62 AuthenticAMD GNU/Linux

xorg-server 1.6.3-2
kernel-headers 2.6.30.1-1
kernel26 2.6.30.4-1
kernel26-firmware 2.6.30-1
xf86-input-evdev 2.2.3-1
ati-dri 7.5-2
xf86-video-ati 6.12.2-2
libgl 7.5-2

I can't seem to find an xorg.conf file so I'm not sure which configuration file I should attach. I have previously attached the Xorg.0.log.old file.

I uploaded 1.6.3-3 to testing an hour ago, it contains the fix for screen turning black, and contains a more official fix for the hal initialization problem. Please test this release and report if it fixes the issue.
I still can't find anything suspicious in the logfiles, configuration files or driver versions though, except for that backtrace generated by the intel driver, which could be a different bug. Is there any consistency in the window manager used? Everyone using GNOME, everyone using KDE, everyone using something else?

I think the bugs are fixed. But it needs more testing.

I think this bug is not really so much X related:

If I am correct a few people investigated (and worked around) this bug on the forums. It's due to XServer starting on TTY2, same as a getty (somehow related to the initscripts upgrade - maybe deleting the vc consoles made x-server think that the previous ttys are free, hence taking tty2, and the getty started after X).

I tried the workaround on the forums and I don't experience the error anymore.

Here's the workaround:
http://bbs.archlinux.org/viewtopic.php?id=77351
Here are more bug reports:
http://bbs.archlinux.org/viewtopic.php?id=77590

Indeed force XServer to start on TTY7 via GDM custom.conf fixed the bug for me

This should be fixed with gdm 2.20.10-2. I removed the sed line that changes /dev/tty* to /dev/vc/*. Now that we don't have /dev/vc/* anymore, this causes problems.

newest GDM spawns on TTY2 again. Experiencing crashes again.
Same symptoms.
Bug reports here:
http://bbs.archlinux.org/viewtopic.php?id=82308

I have this issue with the 28.1 edition as well.

I consider this as a critical priority bug, not just high priority.
When you press the '2' key on the keyboard regardless what keyboard layout you use, you are logged out.
Scandalous, isn't it?

For people having problems:
How is gdm started? From inittab, or DAEMONS in rc.conf?

on my pc via DAEMONS in rc.conf

When launching from DAEMONs, I would advise to launch it as last daemon. Starting it somewhere in between triggers the race condition where gdm will take a tty not yet taken by getty.

gdm shouldn't behave this way. I actually *need* to launch it before the last daemons in rc.conf. After gdm i start ppp that connects to the internet. If ppp fails to connect it will retry a few times, meanwhile leaving me without a working console.

gdm just takes the first console available, which is tty1 at the moment getty hasn't already launched everything. For your ppp issue, there's also a feature that backgrounds daemons, you might want to background the ppp daemon instead.

Starting gdm as a last daemon is not practical since it makes the boot time appear to be longer.
Isn't there a way how to make sure that "now it is safe to start GDM"? Or can't this issue be somehow addressed in the /etc/rc.d/gdm script?

Starting gdm as last daemon is what is done when you start it from inittab. If you're concerned about boottime, background the ones that aren't important for gdm and place gdm as last daemon. By the time gdm is initialized, getty will have taken the consoles and gdm will launch on tty7.
There should be a smarter way to do this though, but I have no idea yet about forcing gdm to a certain console yet.