Bug 41976

This bug only occur with the 3-pipe kernel.

I can reproduce this partly. Sometimes 1 pipe goes black, sometimes both. After some attempts they return.

I believe Jesse was able to reproduce it with dpms on and off as well.

Works for me with current ivb-3-pipe, can you confirm?

(In reply to comment #3)
> Works for me with current ivb-3-pipe, can you confirm?

I have try the current ivb-3-pipe branch ,and can't reproduce this issue.

Should be fixed in drm-intel-next now.

(In reply to comment #5)
> Should be fixed in drm-intel-next now.
I have try with the latest drm-intel-next,the issue can reproduce partly,I have test with VGA+2 HDMI, while switching ,sometimes one HDMI turns to be black,sometimes all HDMIs get black,but the VGA can work well all the time.

Created attachment 58018 [details]
dmesg of switching

I have try with the Kernel:
(drm-intel-testing)9c5a1897768918a941aebbeaefd9f698358c7cf9
the issue still occurs.

3 pipes... Does this help?

drm-intel-next-queued:
commit b98e5240b362e702355ffedba05aeb589dfbcbe2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 13 18:24:38 2012 +0100

    drm/i915: manage PCH PLLs separately from pipes
    
    PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
    treat them as part of the pipe.
    
    So split the code out and manage PCH PLLs separately, allocating them
    when needed or trying to re-use existing PCH PLL setups when the timings
    match.
    
    v2: add num_pch_pll field to dev_priv (Daniel)
        don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
        put register offsets in pll struct (Chris)
    
    v3: Decouple enable/disable of PLLs from get/put.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2)
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)

commit 9fdae1b484757e2b2e705cd6710ce8aef6e05b4b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 20 17:11:53 2012 +0100

    drm/i915: manage PCH PLLs separately from pipes
    
    PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
    treat them as part of the pipe.
    
    So split the code out and manage PCH PLLs separately, allocating them
    when needed or trying to re-use existing PCH PLL setups when the timings
    match.
    
    v2: add num_pch_pll field to dev_priv (Daniel)
        don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
        put register offsets in pll struct (Chris)
    
    v3: Decouple enable/disable of PLLs from get/put.
    v4: Track temporary PLL disabling during modeset
    v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni)
    v6: Avoid mishandling allocation failure by embedding the small array of
        PLLs into the device struct

(In reply to comment #9)
> commit 9fdae1b484757e2b2e705cd6710ce8aef6e05b4b
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Fri Apr 20 17:11:53 2012 +0100
>     drm/i915: manage PCH PLLs separately from pipes
>     PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
>     treat them as part of the pipe.
>     So split the code out and manage PCH PLLs separately, allocating them
>     when needed or trying to re-use existing PCH PLL setups when the timings
>     match.
>     v2: add num_pch_pll field to dev_priv (Daniel)
>         don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
>         put register offsets in pll struct (Chris)
>     v3: Decouple enable/disable of PLLs from get/put.
>     v4: Track temporary PLL disabling during modeset
>     v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni)
>     v6: Avoid mishandling allocation failure by embedding the small array of
>         PLLs into the device struct

  Hi,Chris,I try the kernel:
Kernel: (drm-intel-next-queued)eea7d92bdb47727dfaf5f148f6ea72e9a1cffaf1
Some additional commit info:
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 20 17:11:53 2012 +0100
  the issue still occurs.

Can you try again with the latest CPU and PCH steppings?  The production hardware is stable for me, but the early stuff would occasionally lose sync when doing mode sets with 3 pipe.

(In reply to comment #11)
> Can you try again with the latest CPU and PCH steppings?  The production
> hardware is stable for me, but the early stuff would occasionally lose sync
> when doing mode sets with 3 pipe.

Till now, we don't have any latter CPU and PCH steppings.

Created attachment 64255 [details]
dmesg info with 3pipe still happens

The issue occurs with VGA+2 DP monitor on kernel:
Kernel: (drm-intel-next-queued)1edc2c89df6cc1730cb2329fbecfe041b8dcc2e0
I can reproduce this partly. Sometimes 1  DP pipe goes black, sometimes both DP. After some attempts they return. It always happen while switching from x-window to console,and this time we try with a product machine.

Lack of error reporting ftl....

Not that it would have fixed the underlying issue. :|

(In reply to comment #14)
> Lack of error reporting ftl....
> Not that it would have fixed the underlying issue. :|

Chris, what's "ftl"? Is there any more info you need?

A few things two check:
- If you do a few manual modeset (e.g. disabling a pipe, then reenabling a pipe again with xrandr), does the kernel recover and display again something on the screen? It might take a few trials ...
- To which crtcs (xrandr --verbose) are the screens connected to go black? The important information information here is whether it's only crtc 1&2 that can go black, or whether crtc 0 can go black, too.
- Please attach xrandr --verbose of a failing configuration.

My suspicion is that this is another case of the FDI B/C link train fail that Keith and Damien have been hunting. Adding Damien to the bug cc.

Created attachment 66001 [details]
xrandr -verbose info

(In reply to comment #16)
> A few things two check:
> - If you do a few manual modeset (e.g. disabling a pipe, then reenabling a pipe
> again with xrandr), does the kernel recover and display again something on the
> screen? It might take a few trials ...
I try with VGA+2HDMI monitor.
When I run the xrandr to disable and reenable the pipe.
xrandr --output HDMI1 --off
xrandr --output HDMI1 --auto
The HDMI1 can't linght up and shows:
xrandr: Configure crtc 1 failed

> - To which crtcs (xrandr --verbose) are the screens connected to go black? The
> important information information here is whether it's only crtc 1&2 that can
> go black, or whether crtc 0 can go black, too.
> - Please attach xrandr --verbose of a failing configuration.
> 
I try with VGA+2HDMI monitor, the 2 HDMI monitors (crtc 1&2) always turn to be black after switching , I attach the dmesg and xrandr --verbose.

> My suspicion is that this is another case of the FDI B/C link train fail that
> Keith and Damien have been hunting. Adding Damien to the bug cc.

Created attachment 66002 [details]
dmesg info

attach the dmesg info

(In reply to comment #17)
> Created attachment 66001 [details]
> xrandr -verbose info

You've attached dmesg here, too ;-)

(In reply to comment #18)
> Created attachment 66002 [details]
> dmesg info
> 
> attach the dmesg info

dmesg is incomplete. If this happens, you need to increase the dmesg buffer with log_buf_len=1M (or maybe even bigger). Iirc this is part of the dmesg bkm even.

Created attachment 66014 [details]
right xrandr -verbose info

(In reply to comment #19)
> (In reply to comment #17)
> > Created attachment 66001 [details]
> > xrandr -verbose info
> 
> You've attached dmesg here, too ;-)
:), I save the info as a same name.Here is the right xrandr info.

Created attachment 66041 [details]
full dmesg info

(In reply to comment #20)
> (In reply to comment #18)
> > Created attachment 66002 [details]
> > dmesg info
> > 
> > attach the dmesg info
> 
> dmesg is incomplete. If this happens, you need to increase the dmesg buffer
> with log_buf_len=1M (or maybe even bigger). Iirc this is part of the dmesg bkm
> even.
Ok, I attach the full info.

Created attachment 66901 [details]
full dmesg with 3-pipe info

The issue still occurs with :
Kernel: (drm-intel-testing)c3c3d4e9c2daeca01c42040cda0e5e0579c5c80b
and I attach the full dmesg

This issue all exist. Test with:
Kernel: (drm-intel-testing)6760818aad5622d7f20d7f1c45d75a8165aeaf24

I think we still have issues with FDI training failing silently, but Daniel has pushed some fixes that may help.  Does this still occur with the latest dinq branch?  If so, maybe we can at least add some more mode set sanity checks and re-try the mode set if it fails.

Created attachment 70145 [details]
dmesg info with latest dinq branch

(In reply to comment #25)
> I think we still have issues with FDI training failing silently, but Daniel
> has pushed some fixes that may help.  Does this still occur with the latest
> dinq branch?  If so, maybe we can at least add some more mode set sanity
> checks and re-try the mode set if it fails.
I try with the newest dinq branch:
Kernel: (drm-intel-next-queued)af8b2942b3e8f50d532dbc71cfb170861be52f54
the issue still occurs, and I attach the dmesg info.

Daniel just pushed some fixes for this, can you confirm they work?

(In reply to comment #27)
> Daniel just pushed some fixes for this, can you confirm they work?
I have try with the latest -testing, the issue still occurs unstable,The switching can work well  after booing sometimes, but fail to turn on all the 3 screens  after booting sometimes.

You need to test on -nightly, the important fix has not made it into this week's manual testing cycle unfortunately. Patch is

commit 539526b4137bc0e7a8806c38c8522f226814a0e6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Dec 8 12:58:33 2012 +0100

    drm/i915: disable cpt phase pointer fdi rx workaround

(In reply to comment #29)
> You need to test on -nightly, the important fix has not made it into this
> week's manual testing cycle unfortunately. Patch is
> 
> commit 539526b4137bc0e7a8806c38c8522f226814a0e6
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Sat Dec 8 12:58:33 2012 +0100
> 
>     drm/i915: disable cpt phase pointer fdi rx workaround

I try with that commit, the issue is gone.

Thanks for retesting, closing this bug report here.

Closing old verified.