| Summary: | [845G] [bisected] Freeze a few minutes after log in | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Geir Ove Myhr <gomyhr> | ||||||||||||||||
| Component: | Driver/intel | Assignee: | Carl Worth <cworth> | ||||||||||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | medium | CC: | adamjlincoln, bernardgagnon, brian, gregbair, laurent.joye, markellse, moikkis, tgrundlesr, victor.grischenko | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||
| URL: | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/456902 | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Geir Ove Myhr
2009-10-30 16:38:47 UTC
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.