Created attachment 30853 [details] Batchbuffer dump from 20091029 Forwarding a bug report from ubuntu user Adam J. Lincoln: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/456902 [Problem] On 845G X freezes a few minutes after log in, but does not freeze if left without logging in. [Original report] After a do-release-upgrade -d from jaunty to karmic beta, I am getting "lock ups". If I don't log in and just leave gdm idling, the machine doesn't freeze. If I switch to a virtual console and use that, no freeze. I can ssh in just fine and do all kinds of stuff with no lock ups. But once I log in via gdm, I can go <strike>about 5-10 minutes</strike> EDIT 22 Oct 2009: anywhere from a few minutes to 12 hours or so until the machine: EDIT 26 Oct 2009: Please see comments for update on how the freezes behave! 1) <strike>stops responding to all mouse/keyboard input</strike> EDIT 2 Oct 2009: In all freezes, the keyboard stops responding and mouse clicks do nothing. Recent freezes have left the mouse pointer movable, but some of the first freezes I saw left the mouse pointer immovable. 2) CapsLock will not toggle 3) <strike>sshing in doesn't work anymore</strike> EDIT 2 Oct 2009: This may not be the case. The freezes occurring over the last couple of days have left ssh still operating. 4) alt+sysrq+reisub will cause a reboot, and the screen usually blanks after the 'i' is put in to send SIGKILL to all processes. I have the 82845G graphics chipset, and i915 is shown in the output of lsmod. As the problem only occurs when I'm in X, and as it doesn't matter whether I'm in GNOME or a failsafe xterm session, I suspect the graphics driver. EDIT 22 Oct 2009: I'm working through the X freeze troubleshooting tips at https://wiki.ubuntu.com/X/Troubleshooting/Freeze and will provide more info as soon as possible. ProblemType: Bug Architecture: i386 CurrentDmesg: [ 18.816154] e100: eth0 NIC Link is Up 100 Mbps Full Duplex [ 18.816928] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 29.376013] eth0: no IPv6 routers present [ 59.736386] uart_close: bad serial port count; tty->count is 1, state->count is 0 Date: Tue Oct 20 23:29:42 2009 DistroRelease: Ubuntu 9.10 Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Package: xorg 1:7.4+3ubuntu7 ProcCmdLine: root=UUID=3492c127-3318-4e7e-b169-25b40fccecc8 ro quiet splash ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-14.48-generic RelatedPackageVersions: xserver-xorg 1:7.4+3ubuntu7 libgl1-mesa-glx 7.6.0-1ubuntu4 libdrm2 2.4.14-1ubuntu1 xserver-xorg-video-intel 2:2.9.0-1ubuntu2 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1 SourcePackage: xorg Uname: Linux 2.6.31-14-generic i686 XorgConf: dmi.bios.date: 11/15/2002 dmi.bios.vendor: Intel Corp. dmi.bios.version: RG84510A.86A.0022.P12.0211151511 dmi.board.name: D845GEBV2 dmi.board.vendor: Intel Corporation dmi.board.version: AAA97677-106 dmi.chassis.type: 2 dmi.modalias: dmi:bvnIntelCorp.:bvrRG84510A.86A.0022.P12.0211151511:bd11/15/2002:svn:pn:pvr:rvnIntelCorporation:rnD845GEBV2:rvrAAA97677-106:cvn:ct2:cvr: fglrx: Not loaded system: distro: Ubuntu architecture: i686kernel: 2.6.31-14-generic [lspci] 00:00.0 Host bridge [0600]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface [8086:2560] (rev 03) Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface [8086:2560] 00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 03) Subsystem: Intel Corporation Device [8086:5247]
Created attachment 30854 [details] Batchbuffer dump from 20091026
Created attachment 30855 [details] Batchbuffer dump from 20091024
Created attachment 30856 [details] BootDmesg.txt
Created attachment 30857 [details] Lspci.txt
Created attachment 30858 [details] XorgLog.txt
I'm the original reporter via launchpad. I did have one freeze at the gdm login screen, but it was after logging in to GNOME and logging out, and it occured when switching back to X from a virtual terminal. This contradicts my original report which claimed that I never got a freeze at the gdm login, so thought I should mention it here.
Created attachment 30968 [details] Xorg log
Comment on attachment 30968 [details] Xorg log I have the same problem on an old PC with the 845G chipset. Everything works at first but then it all locks up except that the mouse pointer still moves. Arch Linux, kernel 2.6.31-ARCH (apparently 2.6.31.5-1, according to Arch's package info), Xorg 1.7.1, Intel module 2.9.1. So I suppose I must have the patches mentioned in bug 23082.
Does anyone know which component can be reverted to avoid this problem (kernel, mesa, xf86-video-intel)? I'm going to be helping someone with i845 freezes, and I'll bisect if doing so turns out to be practical. But first it'd be helpful to know which component to start on.
(In reply to comment #9) > Does anyone know which component can be reverted to avoid this problem (kernel, > mesa, xf86-video-intel)? I'm going to be helping someone with i845 freezes, and > I'll bisect if doing so turns out to be practical. But first it'd be helpful to > know which component to start on. I'm not certain of components that can be reverted to avoid the problem, but here are some ideas: It's usually not too hard to avoid running any 3D software, (just don't run a 3D compositing manager like compiz (sometimes known as "desktop effects or so in the configuration), and obviously don't run any 3D games or what have you). If you still have problems that way, then you don't need to worry about mesa. That still leaves xf86-video-intel and the kernel. But just because you can revert one and see the problem go away, doesn't necessarily mean that you'll get a bisect down to a bug commit. For example, you might bisect xf86-video-intel down to a commit of "start using the kernel driver for feature <foo>". So that's something to look out for. But we definitely appreciate your willingness to investigate, and look forwar to whatever further information you can provide. -Carl
The problem is in the kernel somewhere between 2.6.30 and 2.6.31-rc3. I can reproduce the freeze with both Karmic's Xorg driver (based on 2.9.0) and Jaunty's (2.6.3) with 2.6.31-rc3 and the system won't freeze with either Xorg driver on 2.6.30. I'm using the mainline kernel builds at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and at this point I have to start building myself because it's missing i386 builds for -rc1 and -rc2. But I've got a bisect building now on my laptop.
The problem definitely appears before 2.6.31-rc1. I suspected I made a mistake at one point and started over with a bisect limited to drivers/gpu and include/drm. The following will reproduce what I have at this point: git bisect start 517d0869 v2.6.30 f2cb5d8 -- drivers/gpu/ include/drm/ Maybe 4410f3 (fbdev: add support for handoff from firmware to hw framebuffers) is the bad commit... The others don't appear to make any hardware specific changes. When I resume bisecting, I'll check that commit and its parent.
> Maybe 4410f3 (fbdev: add support for handoff from firmware to hw framebuffers) > is the bad commit... The others don't appear to make any hardware specific > changes. When I resume bisecting, I'll check that commit and its parent. Brian, thank you for bisecting this far. Did you get any chance to identify the bad commit?
I have it narrowed down a bit farther now, to the range 03347e2..02200d0. I'll have a chance to finish the job and double-check it in two or three days (it's not my own machine). But I already highly suspect commit 02200d0 will be the identified commit, because it looks a commit that would be enabling something. Maybe drm doesn't work before this commit in Karmic? The kernels that didn't hang also seemed rather slow with graphics.
Thank you for narrowing it down this far. I will see if I can build a "good" and a "bad" ubuntu kernel once it has been narrowed down, so that others with similar problems may test. I don't know exactly how to do this yet, but I'll try and find out.
I have built three ubuntu kernel packages and asked for testing downstream. So far I have two confirmations that 02200d0 is the commit that triggers this bug (and none to the contrary). The kernel packages are available at http://www.kvante.info/845Gfreeze/ and they are: * linux-image-2.6.30-freezetest1_git03347e2~gomyhr_i386.deb - last known good commit * linux-image-2.6.30-freezetest8_git6fd4693~gomyhr_i386.deb - parent of first known bad commit * linux-image-2.6.30-freezetest9_git02200d0~gomyhr_i386.deb - first known bad commit Two people have confirmed that the two first work without freezes and that the last one freezes (but not yet the original reporter from whom the batchbuffer dumps attached here come). I also asked some people with 855GM freezes (fdo bug 24789) to test the kernels to check if the same applied to them, but they had different result, so the 845G and 855GM problems are not the same.
Looks like it's not the kernel. In the downstream bug, we found that the Jaunty versions of libdrm and the userspace Intel driver don't freeze, even under kernel 2.6.31. That means the bad commit is in one of the following: - in libdrm, between 2.4.5 and 2.4.14 - in xserver-xorg-video-intel, between 2.6.3 and 2.9.0 I don't think the freezing requires 3D, either, so it's probably the Intel driver (I guess DDX is the correct term here). I've got a PPA set up, where I'm going to try to bisect my way toward the first bad commit, or at least the first bad release.
I have the same bug on OpenSUSE 11.2. Randomly desktop freezes, keyboard doesn't work and only mouse cursor is moved. So I had to press Reset to reboot desktop. After upgrading to 2.6.33 kernel the freezes doesn't disappear but keyboard doesn't lock any more. So I can switch to terminal (Ctrl+Alt+F1) login as root and soft reboot with reboot command.
I think this is just the general incoherency issue. Some people were just able to hit the problem sooner than others. Duping. *** This bug has been marked as a duplicate of bug 26345 ***
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.