GNOME Bugzilla – Bug 689519
gnome-shell-3.4.2 stops requesting DAMAGE notifications with recent intel drivers
Last modified: 2013-06-17 10:22:01 UTC
Since the release and upgrade to x11-drivers/xf86-video-intel-2.20.10 (or more recent driver versions), I have regular X11 freezes. The symptoms are that the screen stays as is, I can move the mouse pointer, but I can't select a window, type anything, nor switch to a console using Ctrl-Alt-Fx. So far, freezes only occured when I had a second monitor attached to my notebook. Initially, I've thought it was a problem with the most recent intel drivers and created a bug report there: https://bugs.freedesktop.org/show_bug.cgi?id=57118 Chris Wilson helped me debug the issue, and the problem seems to be that gnome-shell suddenly stops requesting DAMAGE notifications. There are backtraces of X and gnome-shell + x11trace files attached to the above bug report. I'm going to attach them here, too. I'm happy to provide any further information you might need.
Created attachment 230512 [details] Backtraces of X and gnome-shell + x11trace information The contained file x11trace.txt.1 was gathered by the command DISPLAY=:0 x11trace -o ~/x11trace.txt -- /usr/bin/gnome-shell The last DAMAGE request is in line 6660. Shortly thereafter, the freeze occured. In the remaining 16000 lines, there are no DAMAGE requests anymore. When the freeze happened, I've made several gnome-shell and X backtraces (attach with GDB, write a backtrace to a file, detach and let the process continue), every minute or so. All these backtraces were identical, so it seems both X and gnome-shell were waiting for something.
Created attachment 230529 [details] Another gnome-shell backtrace after a freeze When I have such a freeze, the X backtrace is always the same, i.e., X is always locked in WaitForSomething. However, the gnome-shell backtrace is usually different. Most of the time, it is similar to this one. But sometimes it is locked somewhere else like in the backtrace contained in the first attachment.
There's a current bug in the X server where if a monitor goes away at the wrong moment the shell will get ignored by the X server indefinitely. Is your monitor cable firmly attached?
(In reply to comment #3) > There's a current bug in the X server where if a monitor goes away at the wrong > moment the shell will get ignored by the X server indefinitely. Is your > monitor cable firmly attached? I use a docking station that is connected to the second monitor with a DVI cable. This cable has never been unplugged, so it's unlikely that there's a loose contact. And it wouldn't really explain why I get the freezes only with the intel drivers >=2.20.10 but not with older versions.
I'm using Gnome 3.6 now, but the hangs still occur. Because until now the hangs only occured with my dual-displays setup, I've disabled one display for the time being. Now it seems I don't get any hangs anymore (but of course that's just a workaround). I'll report back if I get a freeze also with just one display.
Can you enter the overview during the hang/freeze? That is unrelated to damage.
(In reply to comment #6) > Can you enter the overview during the hang/freeze? That is unrelated to damage. No, I can't. I can still move the mouse pointer and it still changes it's shape over window decorations, but everything else doesn't work anymore including switching to the overview using the windows key or changing to a console with Ctrl-Alt-Fx. All I can do is shutting down the system using Magic SysRQ keys. I can also ssh into the machine, but even killing gnome-shell and X doesn't bring me to a console again. When I kill these processes, one of the two screen blanks, the other still shows my desktop.
I've confirmed with Chris that his analysis was incorrect, and that gnome-shell's damage behavior is correct. Punting back to Intel.
Thanks Jasper, I've reopened the intel bug accordingly.
Closing as of comment #8 and comment #9.