| Summary: | x11-drivers/xf86-video-intel-2.20.14: hard system freezes | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tassilo Horn <tsdh> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | nikoli |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=57118 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
The Xorg.0.log file after the system locked up
dmesg output after the lockup "bt full" in GDB attached to the frozen X process |
||
|
Description
Tassilo Horn
2012-10-23 08:36:54 UTC
Graphics card information from lshw:
*-pci
description: Host bridge
product: Mobile PM965/GM965/GL960 Memory Controller Hub
vendor: Intel Corporation
physical id: 100
bus info: pci@0000:00:00.0
version: 0c
width: 32 bits
clock: 33MHz
configuration: driver=agpgart-intel
resources: irq:0
*-display:0
description: VGA compatible controller
product: Mobile GM965/GL960 Integrated Graphics Controller (primary)
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 0c
width: 64 bits
clock: 33MHz
capabilities: msi pm vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
resources: irq:45 memory:f8100000-f81fffff memory:e0000000-efffffff ioport:1800(size=8)
*-display:1 UNCLAIMED
description: Display controller
product: Mobile GM965/GL960 Integrated Graphics Controller (secondary)
vendor: Intel Corporation
physical id: 2.1
bus info: pci@0000:00:02.1
version: 0c
width: 64 bits
clock: 33MHz
capabilities: pm bus_master cap_list
configuration: latency=0
resources: memory:f8200000-f82fffff
> All I can do is powering off the system using Magic SysRQ keys.
Then the system is not completely frozen (probably only X server or kernel drm) and it may still be possible to get dmesg/Xorg.0.log or other debug information.
> Then the system is not completely frozen (probably only X server or kernel drm) > and it may still be possible to get dmesg/Xorg.0.log or other debug information.
Hm, right. Unfortunately, after the freeze I restarted the system, emerged the older driver, and restarted again, thus the relevant Xorg.0.log is gone now. Is there an option for specifying how many log files X should keep?
Anyway, I'll try to upgrade again and provoke the freezes later today. Which other debug information besides Xorg.0.log would be helpful?
* dmesg * Xorg.0.log * attach gdb to X server when it hangs and provide a stack trace (may need to build xorg-server and xf86-video-intel with CFLAGS="-ggdb" and FEATURES="splitdebug" to get meaningful output) * what happens when you run "chvt 1" > * dmesg > * Xorg.0.log > * what happens when you run "chvt 1" Ok, that shouldn't be hard to provide. > * attach gdb to X server when it hangs and provide a stack trace > (may need to build xorg-server and xf86-video-intel with CFLAGS="-ggdb" > and FEATURES="splitdebug" to get meaningful output) Ok, that's "gdb /usr/bin/X `pgrep X`", right? I hope that's no Heisenbug that disappears once you try to debug it. You need to attach gdb to the X server only after it has hung (via ssh or so). (In reply to comment #6) > You need to attach gdb to the X server only after it has hung (via ssh or > so). Sure. I've meant that many bugs disappear once you compile with "-O0 -ggdb" to get helpful backtraces. Or should I stick with my usual CFLAGS "-march=native -O2 -pipe -fomit-frame-pointer" and just add -ggdb? (I think, at least I need to remove the fomit-frame-pointer to get somewhat meaningful backtraces.) -fomit-frame-pointer is not very useful on amd64 anyway, you may want to consider dropping it. Otherwise, just adding -ggdb and setting FEATURES="splitdebug" should result in the exact same code being built. -O2 can stay for now. (In reply to comment #8) > -fomit-frame-pointer is not very useful on amd64 anyway, you may want to > consider dropping it. Ok, dropped it. > Otherwise, just adding -ggdb and setting FEATURES="splitdebug" should result > in the exact same code being built. -O2 can stay for now. Ok, so I created a /etc/portage/env/debug.conf with the following content: -------------------------------------------- USE="debug" CFLAGS="-march=native -pipe -g -ggdb" CXXFLAGS="${CFLAGS}" FEATURES="splitdebug" -------------------------------------------- and added these entries to /etc/portage/package.env -------------------------------------------- x11-drivers/xf86-video-intel debug.conf x11-base/xorg-server debug.conf -------------------------------------------- and recompiled these packages (intel driver 2.20.12, Xorg 1.13.0). Then I provoked another freeze. A reliable method seems to be to simply open a terminal window and press and hold F11 (in GNOME) which toggles fullscreen over and over again. The first time, I couldn't ssh into the machine when the lockup occured. But the second time I could. I'll attach the dmesg output, the Xorg.0.log, and the GDB backtrace as attachments in a minute. When the system locked up, the command "chvt 1" simply hangs. Created attachment 327240 [details]
The Xorg.0.log file after the system locked up
Created attachment 327242 [details]
dmesg output after the lockup
Created attachment 327244 [details]
"bt full" in GDB attached to the frozen X process
As root:
$ gdb /usr/bin/X `pgrep X`
(gdb) bt full
It seems to wait for some kind of input event. If possible, please report a bug at https://bugs.freedesktop.org/ and add the URL to this bug. (In reply to comment #13) > It seems to wait for some kind of input event. If possible, please report a > bug at https://bugs.freedesktop.org/ and add the URL to this bug. There are already some server bugs that look related. But I'm not sure if the backtrace actually shows the problem this report is all about. I had some more lockups in the meantime (also with x11-drivers/xf86-video-intel-2.20.13), but except for the one time above, I wasn't able to log into the machine using SSH anymore, so I couldn't generate a backtrace. So maybe the backtrace actually shows another problem which doesn't happen that frequently. At least, it doesn't seem to be related to the intel driver... I'll try out the suggestions at the X.org wiki ServerDebugging page. Maybe that will let me collect more information. I had another lockup and was able to gather another backtrace. It was the same as attached here. So I went ahead and wrote a bug report at freedesktop.org. https://bugs.freedesktop.org/show_bug.cgi?id=57118 Upstream says the bug is now fixed. Could you try the latest ~arch ebuild and let us know if it works ok for you? Thanks (In reply to comment #16) > Upstream says the bug is now fixed. Could you try the latest ~arch ebuild > and let us know if it works ok for you? I'm already running it. If the bug is still there, it should at least trigger tomorrow @work with my dual screen setup. I'll report back. > I'm already running it. If the bug is still there, it should at least
> trigger tomorrow @work with my dual screen setup. I'll report back.
I had another freeze with 2.20.14, so the bug doesn't seem to be fixed. I've reopened the upstream issue.
Closing as issue is being handled upstream. Thanks |
