Bug 110308

Created attachment 143846 [details]
EDID info

Created attachment 143847 [details]
dmesg log

We could get config error from the dmesg:

[ 5657.209872] [drm:pipe_config_err [i915]] mismatch in dp_m_n (expected tu 64 gmch 5190451/8388608 link 288358/524288, or tu 0 gmch 0/0 link 0/0, found tu 64, gmch 4325376/8388608 link 120149/262144)
[ 5657.209898] [drm:pipe_config_err [i915]] mismatch in base.adjusted_mode.crtc_clock (expected 148500, found 74250)
[ 5657.209920] [drm:pipe_config_err [i915]] mismatch in port_clock (expected 270000, found 162000)

Please send full dmesg from beginning.

Is this a duplicate of Bug 109593?

(In reply to Jani Saarinen from comment #4)
> Please send full dmesg from beginning.

Please refer to the attachment dmesg_from_booting.txt

Created attachment 143936 [details]
DMESG LOG FROM booting

(In reply to Lakshmi from comment #5)
> Is this a duplicate of Bug 109593?

Hi Lakshmi, thanks a lot for the sharing, this issue is reproduced on APL and KBL, we will try https://patchwork.freedesktop.org/series/59184/ and share the results here.

(In reply to Ren Chenglei from comment #8)
> (In reply to Lakshmi from comment #5)
> > Is this a duplicate of Bug 109593?
> 
> Hi Lakshmi, thanks a lot for the sharing, this issue is reproduced on APL
> and KBL, we will try https://patchwork.freedesktop.org/series/59184/ and
> share the results here.

Hmmm... 59184 seems for ICL, we can't apply it to 4.9 kernel.

(In reply to Ren Chenglei from comment #0)
> Hardware: KBL NUC7i5BNH and display ViewSonic TD2230 
> System: Ubuntu 18.04.2 LTS
> Kernel: Linux 5.1.0-rc3+ x86_64
> Description: When switch to some specific refresh rate, screen black and
> show with "out of frequency scope", wait for some time it will return to
> last working mode.
> Steps to reproduce: Setting -> Devices -> Displays -> Refresh Rate ->
> 30.00Hz -> Apply.
> Expect results: UI is normal and refresh rate change to 30Hz
> Actual results: Screen black and show with "out of frequency scope", wait
> for some time, it will return to last working mode.

How is the display connected? e.g HDMI?

@Clint, any comments from you?

(In reply to Lakshmi from comment #10)
> (In reply to Ren Chenglei from comment #0)
> > Hardware: KBL NUC7i5BNH and display ViewSonic TD2230 
> > System: Ubuntu 18.04.2 LTS
> > Kernel: Linux 5.1.0-rc3+ x86_64
> > Description: When switch to some specific refresh rate, screen black and
> > show with "out of frequency scope", wait for some time it will return to
> > last working mode.
> > Steps to reproduce: Setting -> Devices -> Displays -> Refresh Rate ->
> > 30.00Hz -> Apply.
> > Expect results: UI is normal and refresh rate change to 30Hz
> > Actual results: Screen black and show with "out of frequency scope", wait
> > for some time, it will return to last working mode.
> 
> How is the display connected? e.g HDMI?
> 
> @Clint, any comments from you?

Yes, we connect the display with HDMI port.

(In reply to Lakshmi from comment #10)
> (In reply to Ren Chenglei from comment #0)
> > Hardware: KBL NUC7i5BNH and display ViewSonic TD2230 
> > System: Ubuntu 18.04.2 LTS
> > Kernel: Linux 5.1.0-rc3+ x86_64
> > Description: When switch to some specific refresh rate, screen black and
> > show with "out of frequency scope", wait for some time it will return to
> > last working mode.
> > Steps to reproduce: Setting -> Devices -> Displays -> Refresh Rate ->
> > 30.00Hz -> Apply.
> > Expect results: UI is normal and refresh rate change to 30Hz
> > Actual results: Screen black and show with "out of frequency scope", wait
> > for some time, it will return to last working mode.
> 
> How is the display connected? e.g HDMI?
> 
> @Clint, any comments from you?

I don't see anything in the dmesg log that would show a failure. The HDMI output on the NUC is using LS/PCON and everything looks normal during the set mode. Did this work prior to Kernel 5.1?

-Clint

I updated my KBL NUC with Kernel 5.1.0-rc4 and have not been able to reproduce this issue.

(In reply to Clinton Taylor from comment #13)
> I updated my KBL NUC with Kernel 5.1.0-rc4 and have not been able to
> reproduce this issue.

Hi Clint, we tried with 5.1.0-rc3, and could reproduce this issue. Maybe this is related with specific display(ViewSonic TD2230)?
When the issue is reproduced, we could get the following log:

[ 5657.209872] [drm:pipe_config_err [i915]] mismatch in dp_m_n (expected tu 64 gmch 5190451/8388608 link 288358/524288, or tu 0 gmch 0/0 link 0/0, found tu 64, gmch 4325376/8388608 link 120149/262144)
[ 5657.209898] [drm:pipe_config_err [i915]] mismatch in base.adjusted_mode.crtc_clock (expected 148500, found 74250)
[ 5657.209920] [drm:pipe_config_err [i915]] mismatch in port_clock (expected 270000, found 162000)

Created attachment 144121 [details]
attachment-18073-0.html

Thanks for your mail. Chenglei will take AL and International Labor Day from Apr 30 to May 8. Email will not be access.
He Yue will be my backup contact on Apr 30 and May 5 - May 8.
For others, you could get to my manager Huang Yuanjun.
For emergency , pls call my mobile: +86 15021037121.

Thanks
Chenglei

@Swati, any help here?

I will look into it and get back.

(In reply to Ren Chenglei from comment #14)
> (In reply to Clinton Taylor from comment #13)
> > I updated my KBL NUC with Kernel 5.1.0-rc4 and have not been able to
> > reproduce this issue.
> 
> Hi Clint, we tried with 5.1.0-rc3, and could reproduce this issue. Maybe
> this is related with specific display(ViewSonic TD2230)?
> When the issue is reproduced, we could get the following log:
> 
> [ 5657.209872] [drm:pipe_config_err [i915]] mismatch in dp_m_n (expected tu
> 64 gmch 5190451/8388608 link 288358/524288, or tu 0 gmch 0/0 link 0/0, found
> tu 64, gmch 4325376/8388608 link 120149/262144)
> [ 5657.209898] [drm:pipe_config_err [i915]] mismatch in
> base.adjusted_mode.crtc_clock (expected 148500, found 74250)
> [ 5657.209920] [drm:pipe_config_err [i915]] mismatch in port_clock (expected
> 270000, found 162000)

Hi Ren, 

Can you please attach display_info aswell?

@Lakshmi and @Swati, thanks a lot for the help. We have tried this on Windowns, and this issue is also reproduced. So this may be one hardware defect from display side. If possible, could we close this issue?

So sorry for this noise.

(In reply to Ren Chenglei from comment #19)
> @Lakshmi and @Swati, thanks a lot for the help. We have tried this on
> Windowns, and this issue is also reproduced. So this may be one hardware
> defect from display side. If possible, could we close this issue?
> 
> So sorry for this noise.

Thanks for the feedback. Closing this as not a Kernel bug.