Hmm... this bug seems to occasionally happen even with ForceEnablePipeA set.

I went back to 2.6.32, leaving everything else on the system the same, and have been using it for a few days now.  I haven't encountered the bug once; and at the rate it was occurring, I'd expect it to have happened five or six times by now if it were present.  So this does seem to be a kernel bug.

I decided that this bug was repeatable enough that I could bisect it.  Here's the result:

-------

33c5fd121eabbccc9103daf6cda36941eb3c349f is the first bad commit
commit 33c5fd121eabbccc9103daf6cda36941eb3c349f
Author: David John <davidjon@xenontk.org>
Date:   Wed Jan 27 15:19:08 2010 +0530

    drm/i915: Disable SR when more than one pipe is enabled
    
    Self Refresh should be disabled on dual plane configs.  Otherwise, as
    the SR watermark is not calculated for such configs, switching to non
    VGA mode causes FIFO underrun and display flicker.
    
    This fixes Korg Bug #14897.
    
    Signed-off-by: David John <davidjon@xenontk.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: stable@kernel.org
    Signed-off-by: Eric Anholt <eric@anholt.net>

:040000 040000 1eb51014927a018b8cd172e2032198bc87b3a786 62fd80ebe7c6aa94e432791bb78507ca5547888c Mdrivers

------

That sure looks like it could be the cause.  And looking at the relevant discussion, at:

http://lkml.org/lkml/2010/1/27/60

it says "I've updated the patch to fix i965 and i9xx as I assume the same problem will occur on those chipsets as well, but this has _not_been tested as I
don't have the relevant platforms."

Well, it seems to have a problem on i965.

Starting from 2.6.33, and reverting that one commit that the bisection pointed to, does indeed get me a kernel without the bug.  (If it's really a bug; this hardware has been cantankerous before, as per bug 16631.  That's cantankerous by design, since other people with the same type of ADD2 card had the same problem, not cantankerous by malfunction.)

What about more recent kernels, e.g. 2.6.34?  The self-refresh code has been reworked a bit since that commit...

I just tried 2.6.34, and it still has the problem.  (Sorry for the delay; I was away from the computer that exhibits the problem.)  This time, when I tried to revert that one bad commit (the one whose reversion made 2.6.33 work), git gave me the message "Automatic revert failed.", so I didn't proceed further.

I'm just now trying 2.6.35-rc3.  It's even worse: the second monitor boots up showing a clone of the first display (as usual), but then turns off when I start up X.  Again, Xrandr shows nothing wrong: DVI2 is still listed as "connected".  Shutting down X doesn't revive the monitor; restarting X makes it turn on momentarily, but then it immediately turns off again.

Poking into this a bit more, 2.6.34 works fine for me once I comment out the two lines

              I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
                                      & ~FW_BLC_SELF_EN);

in i965_update_wm().  (Those are the same lines which were added by the patch whose reversion made 2.6.33 work for me; the conflict in reverting the patch was in another function, which appears to be for other GPUs.)

Oh interesting.  What is the value of that register on your machine?  I wonder if self-refresh is enabled by default and disabling it causes trouble.  If it's already disabled then maybe a second write of some existing bits is causing trouble?

No wait, if you have a real 965G as opposed to a 965GM then that register is totally different on your platform.

So any writes to FW_BLC_SELF need to be protected by an if (IS_I965GM(dev)) test (or maybe an IS_MOBILE(dev) instead).

Yes, this is a desktop machine that I've been testing this on.  (Intel DG965WH motherboard with ADD2 card with two DVI outputs.)

Created attachment 36645 [details] [review]
FW_BLC_SELF doesn't exist on 965G

Can you try this patch and see if it works for you?

Yes, the patch works for me.  (Tested by applying to an unaltered 2.6.34.)

Excellent, thanks for testing.  I'll send it upstream now.