Bug 26874

Summary: With dual-monitor setup on G965, first monitor doesn't resume from DPMS unless ForceEnablePipeA is set
Product: DRI Reporter: Norman Yarvin <yarvin>
Component: DRM/IntelAssignee: Jesse Barnes <jbarnes>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium Keywords: NEEDINFO
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
FW_BLC_SELF doesn't exist on 965G none

Description Norman Yarvin 2010-03-03 16:29:34 UTC
The setup: G965 motherboard with ADD2 card driving two monitors via DVI.  Everything works until I step away from the computer for a few minutes and the monitors go into DPMS shutdown mode.  Then, resuming only re-activates one of the monitors (the second one), not the first.  When this happens, Xrandr shows nothing wrong (it still lists the first monitor as 'connected').  Nothing gets me the first monitor back: switching consoles and restarting X have no effect on it.  Only rebooting fixes it.

This behavior started when I updated the kernel from 2.6.32 to 2.6.33.

If I add the line
        Option          "ForceEnablePipeA" "yes"
to xorg.conf, the problem disappears.  But the manual for the Intel driver tells me to complain here if I need that option.

This is under 64-bit Gentoo: xf86-video-intel-2.9.1 and xorg-server-1.7.5.
Comment 1 Norman Yarvin 2010-03-04 14:11:26 UTC
Hmm... this bug seems to occasionally happen even with ForceEnablePipeA set.
Comment 2 Norman Yarvin 2010-03-11 15:42:21 UTC
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.
Comment 3 Norman Yarvin 2010-03-22 22:14:54 UTC
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.
Comment 4 Norman Yarvin 2010-03-25 21:13:52 UTC
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.)
Comment 5 Jesse Barnes 2010-06-01 12:21:01 UTC
What about more recent kernels, e.g. 2.6.34?  The self-refresh code has been reworked a bit since that commit...
Comment 6 Norman Yarvin 2010-06-16 18:22:22 UTC
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.
Comment 7 Norman Yarvin 2010-06-16 18:51:04 UTC
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.
Comment 8 Norman Yarvin 2010-06-30 12:55:41 UTC
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.)
Comment 9 Jesse Barnes 2010-06-30 13:03:27 UTC
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?
Comment 10 Jesse Barnes 2010-06-30 13:06:37 UTC
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).
Comment 11 Norman Yarvin 2010-06-30 13:15:52 UTC
Yes, this is a desktop machine that I've been testing this on.  (Intel DG965WH motherboard with ADD2 card with two DVI outputs.)
Comment 12 Jesse Barnes 2010-06-30 13:16:04 UTC
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?
Comment 13 Norman Yarvin 2010-06-30 13:46:15 UTC
Yes, the patch works for me.  (Tested by applying to an unaltered 2.6.34.)
Comment 14 Jesse Barnes 2010-06-30 13:50:26 UTC
Excellent, thanks for testing.  I'll send it upstream now.

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.