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

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

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?

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

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.

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)

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.

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.

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

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.

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

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.

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.

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

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!

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...

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 ?

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

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.

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

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

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

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.

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!