xf86-video-intel 2.20.9-1 seg faults on an original Core i5-460M Intel GMA HD.
I tried to get the output, but "2>&1 > log" didn't work.
I will try to get more information. This only started with this update.
Please let me know what logs/information I can provide to help.
A backtrace from gdb would be best, but first please attach the Xorg.0.log and any xdm.log (or gdm.log or kdm.log etc).
Created attachment 68095 [details]
Created attachment 68096 [details]
Here you are good sir. I'm happy to assist in any way I can. I have not used gdb in 15 years, so I can't do that part for you yet.
I'll search/create another bug report for another bug I found concerning HDMI output. It turns the external monitor on, but it stays black. It also causes the monitor display to corrupt and display garbage. I'm installing sshd now so I don't have to hard boot to get the system back.
Do you have a rotation set upon your display? It looks like it should be fixed by
Author: Chris Wilson <firstname.lastname@example.org>
Date: Tue Oct 2 11:31:40 2012 +0100
sna: Remember to call ValidatePicture() before using newly created Pictures
Reported-by: Marco De Michele <email@example.com>
Signed-off-by: Chris Wilson <firstname.lastname@example.org>
Hi! I have what I think to be the same issue. More information here:
The crash happens when I make an xrandr call. You can find a backtrace in the post.
Sorry for the added noise. I see this has already been resolved.
I'm pretty sure this was the aforementioned issue...
*** This bug has been marked as a duplicate of bug 55527 ***
I actually think that these are two issues. I can confirm the original bug submitted by joseph yarbrough. I am running Arch Linux on a very recent Thinkpad X230 with i7 cpu but do not make use of any display rotations or external displays. My Xorg.log looks exactly as the one of joseph, i.e.
[ 8787.362] Backtrace:
[ 8787.362] 0: /usr/bin/X (xorg_backtrace+0x36) [0x560366]
[ 8787.362] 1: /usr/bin/X (0x400000+0x1640c9) [0x5640c9]
[ 8787.362] 2: /usr/lib/libpthread.so.0 (0x7ff9f7d76000+0xf170) [0x7ff9f7d85170]
[ 8787.362] 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff9f4d4d000+0x6482e) [0x7ff9f4db182e]
[ 8787.362] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff9f4d4d000+0x6340a) [0x7ff9f4db040a]
[ 8787.362] 5: /usr/bin/X (0x400000+0xf2119) [0x4f2119]
[ 8787.362] 6: /usr/bin/X (0x400000+0xeb084) [0x4eb084]
[ 8787.362] 7: /usr/bin/X (0x400000+0x34531) [0x434531]
[ 8787.362] 8: /usr/bin/X (0x400000+0x23615) [0x423615]
[ 8787.362] 9: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff9f6c22725]
[ 8787.362] 10: /usr/bin/X (0x400000+0x238ed) [0x4238ed]
[ 8787.362] Segmentation fault at address (nil)
Fatal server error:
[ 8787.362] Caught signal 11 (Segmentation fault). Server aborting
X starts properly but the server gets killed after some time. This happens rather regularly. X was running properly without any issue before a recent update to xf86-video-intel 2.20.9-1.
Any help on this would be very welcome.
So you didn't try the fix proposed, nor decode the stacktrace into something I can use?
I have not downgraded the driver, though I will probably as a workaround. The xrandr command provided in the mentioned bug report does not cause any problem on my system. Moreover I do not have any action available that allows me to reproduce the error, it just happens from time to time (4 times already today). Anyway I am running gdb now to debug the process. I will post a backtrace once the error reappears.
Downgraded? You do not have a version of the drivers with the latest fixes.
All you need to do for the time being is 'addr2line -e usr/lib/xorg/modules/drivers/intel_drv.so 0x6482e 0x6340a', using gdb to get a better stacktrace is preferable though.
I am unable to give more information because I was forced to install windows because I could not get other devices on my laptop to work and I need the system stable for school.
I should note that I had scripts that were suppose to run on startup that did xrandr for screen adjustment, and xinput for the touchscreen matrix.
I'm not sure at what point xfce4 runs those commands, but I wasn't getting any screen output before X would crash.
I wish I could offer more assistance. :(
Thank you for pointing this out but 'addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so 0x6482e 0x6340a' only returns ??:0 (addresses of course adjusted to the Xorg.log output). Since I did not compile from source I figured that by default the debug symbols are not available.
It actually seems that this is an Arch Linux issue, at least in my case:
Going back to 2.20.8-1 solves the problem and X keeps running stable.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.