Bug 41976 - [IVB] screen turn to be black while switching between console and x-window with 3-pipe active
Summary: [IVB] screen turn to be black while switching between console and x-window wi...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: high major
Assignee: Jesse Barnes
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 44622
  Show dependency tree / graph
 
Reported: 2011-10-18 19:51 UTC by Guang Yang
Modified: 2017-10-06 14:51 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:

Attachments
dmesg of switching (122.67 KB, text/plain)
2012-03-05 00:47 UTC, Guang Yang 		no flags Details
dmesg info with 3pipe still happens (123.68 KB, text/plain)
2012-07-16 06:34 UTC, Guang Yang 		no flags Details
xrandr -verbose info (124.00 KB, text/plain)
2012-08-23 07:32 UTC, Guang Yang 		no flags Details
dmesg info (124.00 KB, text/plain)
2012-08-23 07:33 UTC, Guang Yang 		no flags Details
right xrandr -verbose info (31.73 KB, text/plain)
2012-08-23 08:37 UTC, Guang Yang 		no flags Details
full dmesg info (171.41 KB, text/plain)
2012-08-24 02:32 UTC, Guang Yang 		no flags Details
full dmesg with 3-pipe info (100.13 KB, text/plain)
2012-09-10 07:40 UTC, Guang Yang 		no flags Details
dmesg info with latest dinq branch (317.87 KB, text/plain)
2012-11-16 06:43 UTC, Guang Yang 		no flags Details
View All

Description Guang Yang 2011-10-18 19:51:18 UTC 
System Environment:
--------------------------
Platform:        IvyBridge
Kernel: (ivb-3-pipe)344f5205ecf58b0c56f7d6439621fa5467e9881e

Bug detailed description:
-------------------------
First we start the x-window with 3 displays active, then we do "chvt 7, chvt 1,chvt 7,chvt 1" twice,two screens will turn to be black.
Comment 1 Guang Yang 2011-10-19 02:54:03 UTC 
This bug only occur with the 3-pipe kernel.
Comment 2 Eugeni Dodonov 2011-10-19 13:39:15 UTC 
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.
Comment 3 Jesse Barnes 2011-11-15 10:46:00 UTC 
Works for me with current ivb-3-pipe, can you confirm?
Comment 4 Guang Yang 2011-11-15 20:22:01 UTC 
(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.
Comment 5 Jesse Barnes 2012-01-11 10:55:00 UTC 
Should be fixed in drm-intel-next now.
Comment 6 Guang Yang 2012-01-11 18:58:34 UTC 
(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.
Comment 7 Guang Yang 2012-03-05 00:47:22 UTC 
Created attachment 58018 [details]
dmesg of switching

I have try with the Kernel:
(drm-intel-testing)9c5a1897768918a941aebbeaefd9f698358c7cf9
the issue still occurs.
Comment 8 Chris Wilson 2012-04-19 15:32:11 UTC 
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)
Comment 9 Chris Wilson 2012-04-24 09:48:18 UTC 
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
Comment 10 Guang Yang 2012-04-24 20:21:01 UTC 
(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.
Comment 11 Jesse Barnes 2012-04-25 09:21:18 UTC 
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.
Comment 12 Yi Sun 2012-04-25 20:26:05 UTC 
(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.
Comment 13 Guang Yang 2012-07-16 06:34:46 UTC 
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.
Comment 14 Chris Wilson 2012-07-16 06:58:31 UTC 
Lack of error reporting ftl....

Not that it would have fixed the underlying issue. :|
Comment 15 Gordon Jin 2012-08-17 03:12:41 UTC 
(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?
Comment 16 Daniel Vetter 2012-08-22 09:03:44 UTC 
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.
Comment 17 Guang Yang 2012-08-23 07:32:45 UTC 
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.
Comment 18 Guang Yang 2012-08-23 07:33:19 UTC 
Created attachment 66002 [details]
dmesg info

attach the dmesg info
Comment 19 Daniel Vetter 2012-08-23 08:30:52 UTC 
(In reply to comment #17)
> Created attachment 66001 [details]
> xrandr -verbose info

You've attached dmesg here, too ;-)
Comment 20 Daniel Vetter 2012-08-23 08:32:44 UTC 
(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.
Comment 21 Guang Yang 2012-08-23 08:37:13 UTC 
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.
Comment 22 Guang Yang 2012-08-24 02:32:11 UTC 
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.
Comment 23 Guang Yang 2012-09-10 07:40:03 UTC 
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
Comment 24 shui yangwei 2012-10-18 08:28:24 UTC 
This issue all exist. Test with:
Kernel: (drm-intel-testing)6760818aad5622d7f20d7f1c45d75a8165aeaf24
Comment 25 Jesse Barnes 2012-11-14 17:43:02 UTC 
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.
Comment 26 Guang Yang 2012-11-16 06:43:52 UTC 
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.
Comment 27 Jesse Barnes 2012-12-11 19:17:21 UTC 
Daniel just pushed some fixes for this, can you confirm they work?
Comment 28 Guang Yang 2012-12-12 02:11:08 UTC 
(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.
Comment 29 Daniel Vetter 2012-12-12 08:45:10 UTC 
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
Comment 30 Guang Yang 2012-12-12 09:22:30 UTC 
(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.
Comment 31 Daniel Vetter 2012-12-12 09:24:36 UTC 
Thanks for retesting, closing this bug report here.
Comment 32 Elizabeth 2017-10-06 14:51:44 UTC 
Closing old verified.

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.