My notebook is thinkpad 220i notebook with i3-2310M cpu. I have been gnome-shell for my desktop. X has hung 5 times in the pass two days. keyboard & mouse unresponsable, cannot switch to command line console, but ssh login are still functional. And if I kill X server from ssh console, the whole system will crash. There was no relative kernel log or syslog, but xorg log has "EQ overflowing. The server is probably stuck in an infinite loop." Reproducible: Sometimes
Created attachment 307855 [details] xorg.0.log there was backtrace at the end of the log, and it's the same every time it hangs.
kernel: gentoo-sources-3.2.12 x11-base/xorg-server-1.11.2-r2 (kdrive nptl udev xorg xvfb) x11-drivers/xf86-video-intel-2.17.0-r3 (dri -sna) x11-apps/mesa-7.11.2 (classic egl gallium gles llvm nptl openvg shared-dricore shared-glapi video_cards_intel -bindist -debug -gbm -kernel_FreeBSD -motif -osmesa -pax_kernel -pic -selinux -video_cards_mach64 -video_cards_mga -video_cards_nouveau -video_cards_r128 -video_cards_radeon -video_cards_savage -video_cards_sis -video_cards_tdfx -video_cards_via -video_cards_vmware) x11-libs/libdrm-2.4.27 (video_cards_intel -libkms -static-libs -video_cards_nouveau -video_cards_radeon -video_cards_vmware) gnome-base/gnome-shell-3.2.2.1 (bluetooth -networkmanager) media-libs/clutter-1.8.4 (introspection -debug -doc) x11-libs/cairo-1.10.2-r1 (X glib opengl svg xcb -aqua -debug -directfb -doc -drm -gallium -openvg -qt4 -static-libs) x11-libs/gtk+-2.24.8-r1 (cups introspection xinerama -aqua -debug -doc -examples -test -vim-syntax) x11-libs/gtk+-3.2.3 (colord cups introspection xinerama -aqua -debug -doc -examples -packagekit -test -vim-syntax)
Created attachment 307857 [details] emerge --info
Can you get dmesg via ssh when it hangs? You could check whether removing this kernel parameter makes any difference: > [ 17.294] Kernel command line: root=/dev/sda5 pcie_aspm=force Other things to try: Enable/disable USE="sna" when building xf86-video-intel Upgrade to kernel 3.3.0 xorg-server-1.12.0 xf86-video-intel-2.18.0
dmesg don't have anything output before or after x hung up, just some wifi log. yesterday I've installed x11-drivers/xf86-video-intel-2.18.0 and x11-libs/libdrm-2.4.33, nothing goes wrong so far. I'll report back in a couple of days.
(In reply to comment #4) > Can you get dmesg via ssh when it hangs? > > You could check whether removing this kernel parameter makes any difference: > > [ 17.294] Kernel command line: root=/dev/sda5 pcie_aspm=force > > Other things to try: > Enable/disable USE="sna" when building xf86-video-intel > Upgrade to kernel 3.3.0 > xorg-server-1.12.0 > xf86-video-intel-2.18.0 update: I've tried x11-libs/libdrm-2.4.33 x11-drivers/xf86-video-intel-2.17.0-r3 (dri sna) system hung up after 3 hour of usage. there's no useful info in Xorg.0.log this time, and nothing in /var/log/message other than "rsyslogd: -- MARK --" . And I did not check via ssh this time due to not knowing my IP in the first place. now I've switched to x11-drivers/xf86-video-intel-2.18.0 and see if things will improve.
Created attachment 307971 [details] xorg.log_2 xorg.log when using xf86-video-intel-2.18.0 (dri sna) x11-libs/libdrm-2.4.33
Created attachment 307973 [details] dmesg dmesg output when using xf86-video-intel-2.18.0 (dri sna) x11-libs/libdrm-2.4.33
reviewing all the hang up cases, it seams they all happened when my system is under load, some happens when I was emerging package, some happens when I was using firefox and kvm(winXP 512m). I've just saw kernel 3.2.14 and 3.3.1 has a i915 bugfix (Only clear the GPU domains upon a successful finish, commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604 upstream), i'll go check it out.
Tried kernel 3.2.14, and Tested for serveral days. I can confirm that my system can runs stable (3 days without rebooting) when not using KVM。But as soon as I start KVM, it has a high risk making the i915 driver hang (same xorg.log & kernel error message as previous kernel) app-emulation/qemu-kvm-1.0-r3 aio alsa bluetooth curl opengl pulseaudio qemu-ifup qemu_softmmu_targets_i386 qemu_softmmu_targets_x86_64 qemu_user_targets_i386 qemu_user_targets_x86_64 sdl threads vhost-net -brltty -debug -fdt -ncurses -qemu_softmmu_targets_arm -qemu_softmmu_targets_cris -qemu_softmmu_targets_m68k -qemu_softmmu_targets_microblaze -qemu_softmmu_targets_mips -qemu_softmmu_targets_mips64 -qemu_softmmu_targets_mips64el -qemu_softmmu_targets_mipsel -qemu_softmmu_targets_ppc -qemu_softmmu_targets_ppc64 -qemu_softmmu_targets_ppcemb -qemu_softmmu_targets_sh4 -qemu_softmmu_targets_sh4eb -qemu_softmmu_targets_sparc -qemu_softmmu_targets_sparc64 -qemu_user_targets_alpha -qemu_user_targets_arm -qemu_user_targets_armeb -qemu_user_targets_cris -qemu_user_targets_m68k -qemu_user_targets_microblaze -qemu_user_targets_mips -qemu_user_targets_mipsel -qemu_user_targets_ppc -qemu_user_targets_ppc64 -qemu_user_targets_ppc64abi32 -qemu_user_targets_sh4 -qemu_user_targets_sh4eb -qemu_user_targets_sparc -qemu_user_targets_sparc32plus -qemu_user_targets_sparc64 -rbd -sasl -smartcard -spice -static -test -tls -usbredir -vde -xattr -xen ps: my kvm guest os is Windows XP sp3.
now it's stable on xf86-video-intel-2.20.x and kernel 3.4.x/3.5.x
Closing as per comment #11. Thanks for the update.
