Bugzilla – Bug 282256
"intel" xserver crashes randomly after adding / removing the external monitor.
Last modified: 2007-09-21 10:04:46 UTC
The intel xserver crashes randomly after resume from suspend to RAM. This problem is an old one, but it got worse over the last few days. Former versions seemed to only crash on mplayer initializing the Xv output, but recent ones are also crashing on "mplayer -vo gl" or when trying to run qemu. This is on recent stable: xorg-x11-fonts-devel-7.2-30 xorg-x11-libXpm-7.2-39 xorg-x11-libXext-devel-7.2-40 xorg-x11-libXpm-devel-7.2-39 xorg-x11-server-sdk-7.2-92 xorg-x11-libX11-7.2-48 xorg-x11-libXext-7.2-40 xorg-x11-libSM-devel-7.2-35 xorg-x11-libxkbfile-devel-7.2-39 xorg-x11-libs-7.2-67 xorg-x11-libX11-ccache-7.2-50 xorg-x11-libSM-7.2-35 xorg-x11-util-devel-7.2-31 xorg-x11-libXdmcp-devel-7.2-30 xorg-x11-libXmu-7.2-40 xorg-x11-7.2-80 xorg-x11-devel-7.2-67 xorg-x11-libXt-7.2-41 xorg-x11-libxcb-devel-7.2-26 xorg-x11-libX11-devel-7.2-48 xorg-x11-server-extra-7.2-92 xorg-x11-libXmu-devel-7.2-40 xorg-x11-driver-video-7.2-112 xorg-x11-libfontenc-7.2-36 xorg-x11-proto-devel-7.2-39 xorg-x11-libXau-devel-7.2-31 xorg-x11-libXrender-7.2-39 xorg-x11-driver-input-7.2-67 xorg-x11-libXau-7.2-31 xorg-x11-libxkbfile-7.2-39 xorg-x11-libICE-devel-7.2-37 xorg-x11-libXv-7.2-36 xorg-x11-libXprintUtil-7.2-35 xorg-x11-libXrender-devel-7.2-39 xorg-x11-Xvnc-7.1-63 xorg-x11-libXp-devel-7.2-35 xorg-x11-libXdmcp-7.2-30 xorg-x11-libXfixes-7.2-40 xorg-x11-fonts-core-7.2-48 xorg-x11-fonts-7.2-48 xorg-x11-libXt-devel-7.2-41 xorg-x11-libICE-7.2-37 xorg-x11-libxcb-7.2-26 xorg-x11-xtrans-devel-7.2-32 xorg-x11-libfontenc-devel-7.2-36 xorg-x11-libXp-7.2-35 xorg-x11-libXfixes-devel-7.2-40 xorg-x11-server-7.2-92 xorg-x11-libXv-devel-7.2-36 xorg-x11-libXprintUtil-devel-7.2-35
Created attachment 145013 [details] /var/log/Xorg.0.log.old after the latest crash (qemu in this case)
Created attachment 145014 [details] another log, this time from mplayer start (IIRC)
Created attachment 145015 [details] xorg.conf
first crash (resume) seems to be vidmode related.
I can see, that you enabled 3D support. Does this also happen with 3D disabled? Ok, it probably doesn't make much sense to use the mplayer GL backend in this case, I know.
Created attachment 148066 [details] logfile, crash with "mplayer -vo x11" This time it crashed with plain "mplayer -vo x11" i disabled 3d acceleration (commented out "load dri") and will try if it happens again.
Did you already try intel driver release 2.1.0? Currently in /work/src/done/STABLE/xorg-x11-driver-video.
(In reply to comment #7 from Stefan Dirsch) > Did you already try intel driver release 2.1.0? Currently in > /work/src/done/STABLE/xorg-x11-driver-video. Yes, does not help at all. It still crashed with "mplayer -vo x11". It did, however, not crash for quite some time when i had dri disabled (i enabled it again yesterday when i switched to the new 2.1.0 driver). This might be a hint that it has something to do with 3d.
It is not about suspend, and not about 3d. How to reproduce: 2 scripts: #!/bin/sh # internaldisplay.sh xrandr -s 1024x768 xrandr --dpi 85 xrandr --auto #!/bin/sh # widescreen.sh xrandr --auto xrandr -s 1680x1050 xrandr --dpi 100 The following scenario: - boot the laptop without external display. The default(?) configuration enables clone mode. - mplayer -vo x11 foo.avi => works - plug in the external monitor - widescreen.sh # external display works with 1680x1050 - mplayer -vo x11 foo.avi => works - internaldisplay.sh => internal display works with 1024x768 - mplayer -vo x11 foo.avi => works - unplug external monitor - internaldisplay.sh # or plain "xrandr --auto" - mplayer -vo x11 foo.avi => BOOM This is 100% reproducible. Famous last words: Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80d5481] 1: [0xffffe420] 2: /usr/lib/xorg/modules//extensions/libextmod.so [0xb7c64a12] 3: /usr/bin/Xorg [0x81548ce] 4: /usr/bin/Xorg(Dispatch+0x1af) [0x808ef5f] 5: /usr/bin/Xorg(main+0x47e) [0x8076a4e] 6: /lib/libc.so.6(__libc_start_main+0xe0) [0xb7d25fe0] 7: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e1) [0x8075dd1] Fatal server error: Caught signal 11. Server aborting
If i change internaldisplay.sh to #!/bin/sh # internaldisplay.sh xrandr --auto xrandr -s 1024x768 xrandr --dpi 85 (put the xrandr --auto to the top instead of putting it at the bottom), then it works (does not crash). I need to unplug the external monitor before doing this because the xrandr -s xxx always disables the internal monitor if there is anything attached to the external VGA output
Thanks! This will make investigations much more easier. :-) BTW, I suggest to no longer use the RandR 1.1 options and switch completely to the new 1.2 options. #!/bin/sh # internaldisplay.sh xrandr --output <internal_output> --mode 1024x768 xrandr --output <external_output> --off xrandr --dpi 85 #!/bin/sh # widescreen.sh xrandr --output <external_output> --mode 1680x1050 xrandr --dpi 100 Check the names for internal_output/external_output by running xrandr without any arguments. It might even be easier by using simply --auto for each output after connecting/disconnecting the external monitor.
Seife, could you please install the -debuginfo packages, and try getting a good backtrace? Run X inside gdb for that, or attach gdb to a running X. X itself will never produce a good backtrace with line numbers.
To be honest: i have changed my scripts to not trigger the bug anymore. I think i have provided the info that you need to reproduce the bug, and you are much better at creating a backtrace than i am. I even supplied exactly the same machine as mine to make reproducing this bug easier. So i think you can get this information easily by yourself, and much faster than i am capable of providing it.
Ok.
Note to myself: I had several Xserver crashes on SigGraph with my 915 - even when I didn't use mplayer at all. So this will hopefully help me to reproduce this issue.
comment #9 is a plain easy "how to reproduce". If you did not use mplayer or anything that does xvidmode querying on SIGGRAPH, then you probably hit another bug. (Just wild, uneducated guesses from my side, as always ;-)
When I run KDE, krandrtray is always running. I could imagine, that this has something to do with it ;-) But the other bug option is always possible :-(
it does not have to do anything to do with krandrtray though, it happens without as well
I was able to reproduce this with xorg-x11-server 7.2-101 and with the 2.0.0 intel driver. I am no longer able to reproduce this with xorg-x11-server 7.2-138 and the 2.1.1 intel driver. Closing...
still reproduceable with RC1
This bug has been fixed. Dirk, please open a seperate bugreport for the VT switch crashes on your Samsung X20. Thanks.