[i965gme] Freezes when attempting to switch to projector (or just detect them)

Bug #500999 reported by Bryan Quigley
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Surbhi Palande
Lucid
Fix Released
Medium
Surbhi Palande
xserver-xorg-video-intel (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: xorg

Using up-to-date lucid as of 28th december, GME965/960 graphics.

Attempting to plug-in external projector makes the computer freeze, even just opening the display dialog with a projector connected makes it freeze (no mouse movement).

Booting up with projector plugged in results in many out of memory errors until eventually the kernel panics due to out of memory.

The problem is fixed in linux 2.6.33-rc1. The commit that fixed it has been identified as:

commit 9cf00977da092096c7a983276dad8b3002d23a99
Author: Adam Jackson <email address hidden>
Date: Thu Dec 3 17:44:36 2009 -0500

    drm/edid: Unify detailed block parsing between base and extension blocks

    Also fix an embarassing bug in standard timing subblock parsing that
    would result in an infinite loop.

    Signed-off-by: Adam Jackson <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

ProblemType: Bug
Architecture: amd64
Date: Mon Dec 28 17:51:47 2009
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20091222.1)
MachineType: Hewlett-Packard Compaq 510
Package: xorg 1:7.5~3ubuntu4
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-9-generic root=UUID=8be2e4e2-547f-4a57-8f98-4f3169fbea42 ro quiet splash
ProcEnviron:
 LANG=en_IN
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-9.13-generic
RelatedPackageVersions:
 xserver-xorg 1:7.5~3ubuntu4
 libgl1-mesa-glx 7.6.1~rc3-1ubuntu1
 libdrm2 2.4.14-1ubuntu2
 xserver-xorg-video-intel 2:2.9.1-1ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20091125.0061c4db-0ubuntu1
SourcePackage: xorg
Symptom: display
Tags: freeze lucid
Title: Xorg freeze
Uname: Linux 2.6.32-9-generic x86_64
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 09/24/2009
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68PVU Ver. F.08
dmi.board.name: 308A
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 26.08
dmi.chassis.asset.tag: CNU9457YHN
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68PVUVer.F.08:bd09/24/2009:svnHewlett-Packard:pnCompaq510:pvrF.08:rvnHewlett-Packard:rn308A:rvrKBCVersion26.08:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: Compaq 510
dmi.product.version: F.08
dmi.sys.vendor: Hewlett-Packard
fglrx: Not loaded
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.32-9-generic

Revision history for this message
Bryan Quigley (bryanquigley) wrote :
description: updated
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

It crashes during bootup just if the projecter has power going to it (in standby mode). Very odd.

Bryce Harrington (bryce)
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Revision history for this message
Bryan Quigley (bryanquigley) wrote :
Revision history for this message
Bryan Quigley (bryanquigley) wrote :
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Both of the above pictures are from me booting in recovery mode, where it still crashes. That likely means it can't be an xorg bug?

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Bug was introduced with 2.6.31-rc7 (just finished going through a bunch of kernels)
Also, Karmic is also affected.

affects: xserver-xorg-video-intel (Ubuntu) → linux (Ubuntu)
Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

It is not an xorg bug, but from the pictures it looks like it could be a problem with the i915 kernel module and those bugs are handled upstream by the same people who handle bug for xserver-xorg-video-intel, so I leave that task open for now.

Thanks for tracing it down to 2.6.31-rc7. Perhaps you can bisect if further down? It is somewhat time consuming, but usually finding the bad commit is more than halfway to resolve a bug. There is a relatively straightforward guide for how to build ubuntu packages from git at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild . You can check out 2.6.31-rc7 and with `git checkout v2.6.31-rc7` before running `make oldconfig`. Then the git-bisect manpage should explain how to proceed pretty much by example. You would need to build roughly 7 kernels in order to identify a bad commit between rc6 and rc7. It may be a good idea to build and test rc6 and rc7 in order to verify your findings with a self-built kernel.

Could you try to add the kernel parameter 'nomodeset' and see if it changes anything? You can add this by pressing 'e' on the grub boot menu and adding it after 'quiet splash'.Alternatively, you may add it in /etc/default/grub and run update-grub.

tags: added: 965gme
summary: - Freezes when attempting to switch to projector (or just detect them)
+ [i965gme] Freezes when attempting to switch to projector (or just detect
+ them)
tags: added: dual-head
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

It works with nomodeset. I also "tried" bisecting the bug and got the result:
[616b8434688aa08bd6f019cc60c8dfe121e9e5ae] drm/radeon/kms: Add specific rs690 authorized register table

Which doesn't make sense to me, so perhaps I did something wrong. Also of note, it is fixed in 2.6.33-rc1 (2.6.33-rc2 doesn't boot on my hardware which I think is unrelated - http://lkml.org/lkml/2009/12/25/35)

Revision history for this message
Geir Ove Myhr (gomyhr) wrote : Re: [Bug 500999] Re: [i965gme] Freezes when attempting to switch to projector (or just detect them)

That commit doesn't make sense to me either. Could you attach the
output of `git bisect log` here?

Since it is fixed in 2.6.33-rc1, guess we can't count on help from
upstream either. Maybe you can isolate the commit that fixes this?
Then we can try if that commit can be applied to a Karmic kernel. I'm
not sure if git-bisect is fine looking for the first "good" commit, or
if we have to reverse meaning of the two.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Already working on it (bisecting from 2.6.32 to 2.6.33-rc1), but it will be a while. You do have to reverse good/bad (which means I could easily make another mistake).

I'm guessing one of these commits makes more sense (2.6.31-rc7):
drm/edid: fixup detailed timings like the X server.
drm/kms: teardown crtc correctly when fb is destroyed.

Seeing as how their seem to be a lot of edid fixes in 2.6.33-rc1 it might make sense.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

This is the git bisect log for between 2.6.32 and 2.6.33-rc1. Unfortunately I can't get the kernel to compile any more.. (I also started bisecting this before I realized the older log would be useful)

git bisect start
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
# bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
# bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
# good: [701791cc3c8fc6dd83f6ec8af7e2541b4a316606] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
git bisect good 701791cc3c8fc6dd83f6ec8af7e2541b4a316606
# bad: [6eb7365db6f3a4a9d8d9922bb0b800f9cbaad641] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
git bisect bad 6eb7365db6f3a4a9d8d9922bb0b800f9cbaad641
# good: [6884bb09244498bfa67a99737f33b638d8eae450] Staging: vme: remove unused #include <linux/version.h>
git bisect good 6884bb09244498bfa67a99737f33b638d8eae450

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Yea, it turns out I was only off by one: I'm now 99% sure the bug was introduced in

# bad: [ebb177d2afb8532a8a316489aed545ed0c170802] drm/edid: fixup detailed timings like the X server.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

For the reverse bisection I came up with:
103a196f4224dc6872081305cf7f82ebf67aa7bd is the first bad commit
commit 103a196f4224dc6872081305cf7f82ebf67aa7bd
Author: Zhenyu Wang <email address hidden>
Date: Fri Nov 27 11:44:36 2009 +0800

    drm/i915: PineView only has LVDS and CRT ports

    PineView only has 2 ports for LVDS and CRT. Don't enable other
    ports for it.

    Cc: Shaohua Li <email address hidden>
    Signed-off-by: Zhenyu Wang <email address hidden>
    Signed-off-by: Eric Anholt <email address hidden>

:040000 040000 fda2d9aa7d834ae69304aa47665ae7cc01c10f33 877c16a4377782385f58f81333eeac3f705843c4 M drivers

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Oops.. I reversed the meaning, so actually the first good commit might instead be:
 good: [c35614380d5c956bfda20eab2755b2f5a7d6f1e7] drm/i915: Don't set up the TV port if it isn't in the BIOS table.

In the reverse log good means bad, and bad means good.

Geir Ove Myhr (gomyhr)
description: updated
Changed in linux (Ubuntu):
status: New → Triaged
tags: added: xorg-needs-kernel-fix
Geir Ove Myhr (gomyhr)
Changed in linux (Ubuntu):
milestone: none → ubuntu-10.04
milestone: ubuntu-10.04 → none
tags: added: karmic
Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

Bryan, I looked at your git-bisect log in comment #13 again. Since the meaning of good and bad is reverse, the first good (i.e "bad" in the log) commit seems to be
[103a196f4224dc6872081305cf7f82ebf67aa7bd] drm/i915: PineView only has LVDS and CRT ports
The one in comment #14
[c35614380d5c956bfda20eab2755b2f5a7d6f1e7] drm/i915: Don't set up the TV port if it isn't in the BIOS table.
is marked as "good" in the log and therefore is really bad.
The strange thing is that between these two commits there shouldn't be any changes to you chipset at all.

Could you build and save the last bad and first good with different --append-to-version parameters, so that you can install both and make sure that when you boot the bad one, it is really bad and when you boot the good one it is really good.

PS: It is suspicious when there are too many bad or good after each other in the log. You have 6 "good" in a row. Assuming a probability of 1/2 for good or bad in each step of the binary search, the probability of this happening is 1/(2^5) = 1/32. It may be that you marked 103a196f4224dc6872081305cf7f82ebf67aa7bd as "bad" when it was if fact bad and therefore should have been marked good. That would lead the search to find only "good" (i.e. bad) commits afterwards. So I suggest you test this kernel again first to find out if it is really the first commit that doesn't have the problem.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

You are indeed correct!... This looks much more fruitful:
9cf00977da092096c7a983276dad8b3002d23a99 is the first bad commit
commit 9cf00977da092096c7a983276dad8b3002d23a99
Author: Adam Jackson <email address hidden>
Date: Thu Dec 3 17:44:36 2009 -0500

    drm/edid: Unify detailed block parsing between base and extension blocks

    Also fix an embarassing bug in standard timing subblock parsing that
    would result in an infinite loop.

    Signed-off-by: Adam Jackson <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

:040000 040000 aba8219f0f4da70650bda741f317f89dfb7611a3 3c9fe967e4e78df11f10b8c9a2b8ed9bba9f44e8 M drivers

Geir Ove Myhr (gomyhr)
description: updated
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

That looks like a much more likely commit to fix this. Did you double-check by testing the last freezing (i.e. "good") and first non-freezing (i.e. "bad") kernel again?

It seems that the commit is not as atomic as it maybe should have been, since it fixes a bug and changes the behaviour. I will leave it up to the Ubuntu developers to assess whether the commit can be appled as a whole or needs to be rewritten. Anyway, they should now have all the information they need in order to fix this. Thank you for excellent troubleshooting!

tags: added: cherry-pick
Geir Ove Myhr (gomyhr)
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Invalid
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

I didn't double check, but can do that today. The patch does not seem to work on karmic's kernel from what I've tried, so I guess it would need to be modified...

Surbhi Palande (csurbhi)
Changed in linux (Ubuntu):
importance: Undecided → Medium
Surbhi Palande (csurbhi)
Changed in linux (Ubuntu):
assignee: nobody → Surbhi Palande (csurbhi)
status: Triaged → In Progress
Revision history for this message
Surbhi Palande (csurbhi) wrote :

Hi Bryan Quigley, Thanks for bisecting the kernel and finding out the appropriate patch :)
Can you confirm whether the PPA at https://edge.launchpad.net/~csurbhi/+archive/lucid/ works for you ?

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

It does indeed work. Thanks! Any chance of that patch (or similar) making it back to Karmic?

Revision history for this message
Surbhi Palande (csurbhi) wrote :

Bryan Quigley, Karmic has now reached its stable version and we shall only backport patches which fix a regression, data loss or are security fixes. You can find more information on this at https://wiki.ubuntu.com/StableReleaseUpdates.
Since, backporting this patch to karmic needs large changes, this change will not be seen in karmic.

Surbhi Palande (csurbhi)
Changed in linux (Ubuntu Lucid):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.32-14.19

---------------
linux (2.6.32-14.19) lucid; urgency=low

  [ Andy Whitcroft ]

  * ensure we build the source package contents when enabled
    - LP: #522308
  * [Config] enable CONFIG_X86_MCE_XEON75XX
  * SAUCE: AppArmor -- add linux/kref.h for struct kref
  * [Config] enable CONFIG_HID_ORTEK
  * enable udeb generation for arm versatile flavour
    - LP: #522515

  [ John Johansen ]

  * ubuntu: AppArmor -- update to mainline 2010-02-18
    - LP: #439560, #496110, #507069

  [ Johnathon Harris ]

  * SAUCE: HID: add support for Ortek WKB-2000
    - LP: #405390

  [ Upstream Kernel Changes ]

  * tpm_tis: TPM_STS_DATA_EXPECT workaround
    - LP: #490487
  * x86, mce: Xeon75xx specific interface to get corrected memory error
    information
  * x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll
  * x86, mce: Make xeon75xx memory driver dependent on PCI
  * drm/edid: Unify detailed block parsing between base and extension
    blocks
    - LP: #500999
  * (pre-stable) eCryptfs: Add getattr function
    - LP: #390833
 -- Andy Whitcroft <email address hidden> Thu, 18 Feb 2010 19:22:02 +0000

Changed in linux (Ubuntu Lucid):
status: Fix Committed → Fix Released
Revision history for this message
djinn (supreet-sethi) wrote :

This bug occurs with Karmic release on my pineview based netbook. What are my options?

Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

On Fri, May 28, 2010 at 11:18 AM, djinn wrote:
> This bug occurs with Karmic release on my pineview based netbook. What
> are my options?

1. Don't use the projector (bad option)
2. Pretend that the freeze is a feature, not a bug (really bad option)
3. Try Lucid (good option)
4. Install the Lucid kernel (the linux-image deb-package from [1]) or
the latest 2.6.33.x or 2.6.34.y mainline kernel ([2], see [3]) on your
Karmic system (it does not replace the Karmic kernel, you can choose
to boot either). (intermediate option)

The Pineview chipset is so new that the Karmic graphics drivers for it
is at best immature. There may still be some issues with Pineview on
Lucid that will only be resolved in future releases, but for now Lucid
is your best option. You may try a LiveCD to check that it works well
on your system before you install/upgrade.

[1]: https://launchpad.net/ubuntu/+source/linux
[2]: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
[3]: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

For me anyway (from comment #8) turning off kernel modesetting does the trick.

Modify the line in /etc/default/grub from something like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

to something like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

Then do sudo update-grub. But yea.. I am upgrading most of my machines to lucid.

Revision history for this message
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-lucid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.