Created attachment 93433 [details] Xorg.0.log after crash Hello. After upgrading xf86-video-intel from 2.99.908 to 2.99.909 my Xorg server crashes almost every time I am enabling external monitor connected via VGA. I use KDE's systemsettings to control external monitor setup and I had no problems with 2.99.908. My OS is Gentoo amd64, kernel is 3.13, mesa is 9.2.5, xf86-video-intel is 2.99.909. If you need any other info, I am ready to provide it. Please fix.
Install debug symbols for xf86-video-intel, attach gdb, grab a backtrace.
The other thing to check is using xf86-video-intel.git - one patch that rings a bell is commit 699b4fd3139d1d6d02911d6c8f193ead3445f613 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Feb 1 20:13:53 2014 +0000 sna: Undo region translation before returning Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Until I have a better idea what broke (and a ./configure --enable-debug=full log in conjunction with the bt would be ideal), all I can do is guess.
(In reply to comment #2) > The other thing to check is using xf86-video-intel.git - one patch that > rings a bell is > > commit 699b4fd3139d1d6d02911d6c8f193ead3445f613 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Sat Feb 1 20:13:53 2014 +0000 > > sna: Undo region translation before returning > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Until I have a better idea what broke (and a ./configure --enable-debug=full > log in conjunction with the bt would be ideal), all I can do is guess. After some struggle I failed to obtain X backtrace using the same machine I am running Xorg at. I'll try ssh method later today when I get to my other machine. I will try the suggested patch now and give you feedback.
(In reply to comment #3) > I will try the suggested patch now and give you feedback. Unfortunately, this patch does not help.
If you are struggling to attach gdb (and using ssh is the easiest way indeed), then recompile with ./configure --enable-debug=full and attach the resulting Xorg.0.log. I should be able to work out where it crashed and why from that log file.
Created attachment 93450 [details] Xorg.0.log.gz Here's gzipped Xorg log with xf86-video-intel's fully enabled debug output.
Hmm. That is odd. It triggered an assert whilst painting into the new frontbuffer. The assert was checking for incorrect clipping of geometry. commit 79d2f96bdfa0d7ae1567bf4b57b4f86aae424f50 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Feb 5 15:30:30 2014 +0000 sna: Add some DBG around tiled blts References: https://bugs.freedesktop.org/show_bug.cgi?id=74550 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Adds some more debug and asserts slightly earlier in that path. Please could you update and send me the new Xorg.0.log. Thanks.
Created attachment 93494 [details] Xorg.0.log.gz Here's gzipped output of Xorg log with enabled debug and applied patch above. The monitor is different though, but the problem persists.
I woke up this morning thinking I knew what the problem was. Alas according to that fresh debug log, I was on the right track, but not the right cause. :|
Actually on a second read, I think I did fix the right bug! commit 4d1a2ef9553c663bb97b56adde6f6b41241ff528 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 6 08:29:20 2014 +0000 sna: Reset composite offsets when reusing freed pixmaps Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74550 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 93516 [details] Xorg.0.log with 4d1a2ef9553c663bb97b56adde6f6b41241ff528 (In reply to comment #10) > Actually on a second read, I think I did fix the right bug! > > commit 4d1a2ef9553c663bb97b56adde6f6b41241ff528 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Feb 6 08:29:20 2014 +0000 > > sna: Reset composite offsets when reusing freed pixmaps > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74550 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> This patch breaks X completely, i.e. X fails to start and backlight just periodically turns on/off showing absolutely black screen. Here's Xorg log of this.
(In reply to comment #11) > Created attachment 93516 [details] > Xorg.0.log with 4d1a2ef9553c663bb97b56adde6f6b41241ff528 > > (In reply to comment #10) > > Actually on a second read, I think I did fix the right bug! > > > > commit 4d1a2ef9553c663bb97b56adde6f6b41241ff528 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Thu Feb 6 08:29:20 2014 +0000 > > > > sna: Reset composite offsets when reusing freed pixmaps > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74550 > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > This patch breaks X completely, i.e. X fails to start and backlight just > periodically turns on/off showing absolutely black screen. > > Here's Xorg log of this. This happens without plugging external monitor!
Exciting. Do you have the stderr to see which assertion was triggered?
Triggered one of the new assertions locally: commit 823382d28944a319c207f20ecef25ce1707a8021 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 6 10:13:41 2014 +0000 sna: And clear drawable->id on reused pixmaps References: https://bugs.freedesktop.org/show_bug.cgi?id=74550 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #13) > Exciting. Do you have the stderr to see which assertion was triggered? No. After the said backlight flickering starts the only thing possible is Alt+SysRq+REISUB. I am unable to kill X via Ctrl-C, nor switch to VT via Ctrl+Alt+Fn.
(In reply to comment #14) > Triggered one of the new assertions locally: > > commit 823382d28944a319c207f20ecef25ce1707a8021 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Feb 6 10:13:41 2014 +0000 > > sna: And clear drawable->id on reused pixmaps > > References: https://bugs.freedesktop.org/show_bug.cgi?id=74550 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> This patch should be applied alone on top of 2.99.909 or together with 4d1a2ef9553c663bb97b56adde6f6b41241ff528 ?
In addtion to the prior patch. At this moment in time though, it is imperative that you are testing with xf86-video-intel.git, there are a few other bug fixes that you are likely to stumble over otherwise.
(In reply to comment #17) > In addtion to the prior patch. At this moment in time though, it is > imperative that you are testing with xf86-video-intel.git, there are a few > other bug fixes that you are likely to stumble over otherwise. I confirm that git (HEAD is 823382d28944a319c207f20ecef25ce1707a8021) build does not trigger this issue, i.e. I can plug in external monitor and switch it on/off, change resolutions, etc in KDE's systemsettings utility without X server crash. There is a small issue though, but I am not sure if it has anything to do with intel driver: after switching my external monitor on/off in systemsettings my panel tries to stretch across both screens (laptop screen and external monitor) resulting in only half of the panel is being visible. If I enable external monitor again, then the panel is placed on my laptop screen and properly stretched to its size, but it doesn't stay this way after monitor switch off.
(In reply to comment #18) > (In reply to comment #17) > > In addtion to the prior patch. At this moment in time though, it is > > imperative that you are testing with xf86-video-intel.git, there are a few > > other bug fixes that you are likely to stumble over otherwise. > > I confirm that git (HEAD is 823382d28944a319c207f20ecef25ce1707a8021) build > does not trigger this issue, i.e. I can plug in external monitor and switch > it on/off, change resolutions, etc in KDE's systemsettings utility without X > server crash. Thank you very much for testing, and reporting the bug. > There is a small issue though, but I am not sure if it has anything to do > with intel driver: after switching my external monitor on/off in > systemsettings my panel tries to stretch across both screens (laptop screen > and external monitor) resulting in only half of the panel is being visible. > If I enable external monitor again, then the panel is placed on my laptop > screen and properly stretched to its size, but it doesn't stay this way > after monitor switch off. What does xrandr say at each stage (before monitor off, after monitor off, after monitor on)?
Created attachment 93544 [details] xrandr --verbose without external monitor plugged in xrandr --verbose without external monitor plugged in. Panel is at the laptop screen and stretched to 100% of its width.
Created attachment 93545 [details] xrandr --verbose with external monitor plugged in and enabled xrandr --verbose with external monitor plugged in and enabled. Panel is on the laptop screen and stretched to 100% of its size.
Created attachment 93546 [details] xrandr --verbose with external monitor plugged in and disabled xrandr --verbose with external monitor plugged in and disabled. Panel is at the laptop screen and stretched to 100% of combined width of laptop screen and external monitor. Only half of the panel is visible.
(In reply to comment #19) > Thank you very much for testing, and reporting the bug. Thank you for your work on this bug. > What does xrandr say at each stage (before monitor off, after monitor off, > after monitor on)? I've attached several xrandr outputs. Thank you for your extra help with this issue.
(In reply to comment #23) > > What does xrandr say at each stage (before monitor off, after monitor off, > > after monitor on)? > > I've attached several xrandr outputs. Thank you for your extra help with > this issue. Ah, from that we can see the sequence quite clearly. It's just the final step that goes wrong, as it appears that userspace is not resizing the framebuffer to match the active outputs. The desktop remains 2806 pixels, but only the first 1366 pixels that fit onto the laptop panel are visible. It could be a driver bug (or RandR bug), but it is more likely to be a bug in the desktop's display manager. "xrandr --output LVDS1 --preferred --output HDMI1 --off" should reset the display. Closing as fixed for the crash. Please open a new bug report if you feel this is a driver issue. (I think a full debug log for the resize sequence, along with an xtrace of the commands the display manager is using, would be required to piece together the cause of the error.)
(In reply to comment #24) > It could be a driver bug (or RandR bug), but it is more likely to be a bug > in the desktop's display manager. "xrandr --output LVDS1 --preferred > --output HDMI1 --off" should reset the display. Yes, it appears not to be a driver bug as I cannot reproduce it in another DE. Your xrandr command is super useful though, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.