Comment 15 for bug 500999

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.