Bug 95392 - Trying to set mode 3840x2160 at 60 Hz results in a crash
Summary: Trying to set mode 3840x2160 at 60 Hz results in a crash
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ville Syrjala
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-13 20:38 UTC by Oli
Modified: 2017-06-30 23:41 UTC (History)
3 users (show)

See Also:
i915 platform: SKL
i915 features: display/DP


Attachments
dmesg.log (67.98 KB, text/plain)
2016-05-13 20:38 UTC, Oli
no flags Details
dmesg with drm.debug=14 (141.29 KB, text/plain)
2016-05-17 06:34 UTC, Oli
no flags Details
dmesg of the kernel from the alternative branch (163.49 KB, text/plain)
2016-05-17 22:24 UTC, Oli
no flags Details

Description Oli 2016-05-13 20:38:23 UTC
Created attachment 123732 [details]
dmesg.log

If I try to go from 30 to 60 Hz refresh rate at a 4k resolution of 3840x2160 results in a 'no input' at my external display with a corresponding OOPs in my dmesg log:

[   83.446091] ------------[ cut here ]------------
[   83.446194] WARNING: CPU: 2 PID: 452 at drivers/gpu/drm/i915/intel_display.c:13917 skl_max_scale.part.90+0x6d/0x80 [i915]
[   83.446203] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[   83.446209] Modules linked in:
[   83.446216]  snd_hda_codec_hdmi dell_led snd_hda_codec_realtek snd_hda_codec_generic arc4 snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus snd_hda_intel dell_laptop snd_hda_codec dell_wmi i2c_designware_platform dell_smbios nls_iso8859_1 i2c_designware_core nls_cp437 dcdbas iwlmvm vfat intel_rapl fat rtsx_pci_ms i915 mac80211 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_core uvcvideo snd_hwdep iwlwifi snd_pcm videobuf2_vmalloc snd_timer videobuf2_memops kvm_intel videobuf2_v4l2 drm_kms_helper videobuf2_core kvm cfg80211 pcspkr psmouse snd irqbypass memstick idma64 serio_raw mei_me videodev virt_dma i2c_i801 soundcore mei shpchp media drm intel_pch_thermal intel_lpss_pci mousedev intel_gtt
[   83.446380]  evdev joydev input_leds btusb syscopyarea led_class btrtl sysfillrect processor_thermal_device sysimgblt mac_hid fb_sys_fops intel_soc_dts_iosf i2c_algo_bit fan thermal wmi battery i2c_hid hci_uart btbcm btqca video btintel pinctrl_sunrisepoint pinctrl_intel bluetooth rfkill crc16 intel_lpss_acpi intel_lpss int3400_thermal acpi_thermal_rel intel_hid int3403_thermal sparse_keymap int340x_thermal_zone ac button acpi_pad acpi_als fjes kfifo_buf industrialio tpm_tis tpm sch_fq_codel ip_tables x_tables algif_skcipher af_alg hid_multitouch hid_generic usbhid hid dm_crypt dm_mod rtsx_pci_sdmmc mmc_core atkbd libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci nvme nvme_core libata xhci_pci rtsx_pci xhci_hcd
[   83.446560]  scsi_mod usbcore usb_common i8042 serio xfs crc32c_generic crc32c_intel libcrc32c
[   83.446589] CPU: 2 PID: 452 Comm: Xorg Tainted: G     U          4.6.0-rc7-g44549e8 #1
[   83.446597] Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.3.3 03/01/2016
[   83.446604]  0000000000000286 000000002af38527 ffff88046a2cba20 ffffffff812e34a1
[   83.446618]  ffff88046a2cba70 0000000000000000 ffff88046a2cba60 ffffffff8107a5bb
[   83.446630]  0000365d000008ae ffff88046bf773c0 ffff88046b16ac00 ffff88046a187000
[   83.446643] Call Trace:
[   83.446667]  [<ffffffff812e34a1>] dump_stack+0x63/0x82
[   83.446677]  [<ffffffff8107a5bb>] __warn+0xcb/0xf0
[   83.446689]  [<ffffffff8107a63f>] warn_slowpath_fmt+0x5f/0x80
[   83.446752]  [<ffffffffa0a22cc0>] ? intel_dp_compute_config+0x2c0/0x6a0 [i915]
[   83.446818]  [<ffffffffa09ee3ed>] skl_max_scale.part.90+0x6d/0x80 [i915]
[   83.446873]  [<ffffffffa09ee4c0>] intel_check_primary_plane+0xc0/0xe0 [i915]
[   83.446936]  [<ffffffffa09de9ee>] intel_plane_atomic_check+0x12e/0x1f0 [i915]
[   83.446957]  [<ffffffffa083b488>] drm_atomic_helper_check_planes+0x48/0x1d0 [drm_kms_helper]
[   83.447026]  [<ffffffffa09f9753>] intel_atomic_check+0x2a3/0x1140 [i915]
[   83.447055]  [<ffffffffa05384d8>] drm_atomic_check_only+0x188/0x610 [drm]
[   83.447080]  [<ffffffffa0537f8c>] ? drm_atomic_set_crtc_for_connector+0x6c/0x110 [drm]
[   83.447105]  [<ffffffffa0538977>] drm_atomic_commit+0x17/0x60 [drm]
[   83.447123]  [<ffffffffa083bf81>] drm_atomic_helper_set_config+0x81/0xc0 [drm_kms_helper]
[   83.447160]  [<ffffffffa0526e55>] drm_mode_set_config_internal+0x65/0x110 [drm]
[   83.447195]  [<ffffffffa052bff8>] drm_mode_setcrtc+0x448/0x560 [drm]
[   83.447222]  [<ffffffffa051da12>] drm_ioctl+0x152/0x540 [drm]
[   83.447252]  [<ffffffffa052bbb0>] ? drm_mode_setplane+0x1c0/0x1c0 [drm]
[   83.447269]  [<ffffffff811f4c0c>] ? __vfs_write+0xcc/0x100
[   83.447282]  [<ffffffff81207fa1>] do_vfs_ioctl+0xa1/0x5b0
[   83.447292]  [<ffffffff81087631>] ? __set_task_blocked+0x41/0xa0
[   83.447301]  [<ffffffff812123f7>] ? __fget+0x77/0xb0
[   83.447313]  [<ffffffff81208529>] SyS_ioctl+0x79/0x90
[   83.447323]  [<ffffffff8108a17e>] ? SyS_rt_sigprocmask+0x8e/0xc0
[   83.447334]  [<ffffffff815c6e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[   83.447377] ---[ end trace 25edcc9116054f9e ]---
[   83.505895] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

My setup is as follows:
- Dell XPS 13 9350
- Intel Iris 540
- Display LG 27UD68P-W
- DP 1.2 cable

See the attached `dmesg` and `lspci -vvnn` output for more information:
- dmesg: http://ix.io/DEH
- lspci: http://ix.io/DEG

My ultimate goal is to drive my external display at 4k with 60 Hz. I figured this should be possible given the listed hardware.
Comment 1 Jani Nikula 2016-05-16 08:01:55 UTC
Please add drm.debug=14 module parameter, reproduce the problem, and attach the dmesg to bugzilla.
Comment 2 Oli 2016-05-17 06:34:19 UTC
Created attachment 123819 [details]
dmesg with drm.debug=14

The bug reproduced with kernel option 'drm.debug=14'
Comment 3 Ville Syrjala 2016-05-17 07:51:09 UTC
[   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
[   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9

Your cdclk is too low for that mode. I have a branch which has the required bits to adjust cdclk dynamically on SKL:
git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2

Can you test with that branch?
Comment 4 Jani Nikula 2016-05-17 11:53:56 UTC
(In reply to Ville Syrjala from comment #3)
> [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> 
> Your cdclk is too low for that mode.

Why didn't we reject the mode?
Comment 5 Ville Syrjala 2016-05-17 11:59:55 UTC
(In reply to Jani Nikula from comment #4)
> (In reply to Ville Syrjala from comment #3)
> > [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> > [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> > 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> > 
> > Your cdclk is too low for that mode.
> 
> Why didn't we reject the mode?

The current upstream SKL cdclk code is bad. It sets the max cdclk to something != current cdclk even though we don't actually support changing the frequency.
Comment 6 Oli 2016-05-17 22:24:51 UTC
Created attachment 123848 [details]
dmesg of the kernel from the alternative branch
Comment 7 Oli 2016-05-17 22:26:27 UTC
(In reply to Ville Syrjala from comment #3)
> [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> 
> Your cdclk is too low for that mode. I have a branch which has the required
> bits to adjust cdclk dynamically on SKL:
> git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2
> 
> Can you test with that branch?

I did and it seems to works, at least the display didn't blank and xrandr reports 60 Hz. Though, I have no way to tell if this is really the case, because my display won't show this information.

See the attached dmesg output for more information. I used the same drm.debug settings as before.

PS: Is this fix going upstream some time?
Comment 8 Ville Syrjala 2016-05-18 06:47:52 UTC
(In reply to Oli from comment #7)
> (In reply to Ville Syrjala from comment #3)
> > [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> > [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> > 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> > 
> > Your cdclk is too low for that mode. I have a branch which has the required
> > bits to adjust cdclk dynamically on SKL:
> > git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2
> > 
> > Can you test with that branch?
> 
> I did and it seems to works, at least the display didn't blank and xrandr
> reports 60 Hz. Though, I have no way to tell if this is really the case,
> because my display won't show this information.
> 
> See the attached dmesg output for more information. I used the same
> drm.debug settings as before.


[    9.195675] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz, VCO: 8100000 kHz, ref: 24000 kHz
[    9.195677] [drm:intel_update_max_cdclk] Max CD clock rate: 675000 kHz
[    9.195678] [drm:intel_update_max_cdclk] Max dotclock rate: 675000 kHz
[   70.790172] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
[   70.790188] [drm:intel_modeset_checks] New cdclk calculated to be atomic 540000, actual 540000
[   71.866294] [drm:skl_set_cdclk] Changing CDCLK to 540000 kHz (VCO 8100000 kHz)
[   71.872408] [drm:intel_update_cdclk] Current CD clock rate: 540000 kHz, VCO: 8100000 kHz, ref: 24000 kHz

So everything is looking good.

> 
> PS: Is this fix going upstream some time?

It's being reviewed now, so should land soonish, I hope.
Comment 9 Oli 2016-05-18 17:39:14 UTC
(In reply to Ville Syrjala from comment #8)
> (In reply to Oli from comment #7)
> > (In reply to Ville Syrjala from comment #3)
> > > [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> > > [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> > > 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> > > 
> > > Your cdclk is too low for that mode. I have a branch which has the required
> > > bits to adjust cdclk dynamically on SKL:
> > > git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2
> > > 
> > > Can you test with that branch?
> > 
> > I did and it seems to works, at least the display didn't blank and xrandr
> > reports 60 Hz. Though, I have no way to tell if this is really the case,
> > because my display won't show this information.
> > 
> > See the attached dmesg output for more information. I used the same
> > drm.debug settings as before.
> 
> 
> [    9.195675] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz,
> VCO: 8100000 kHz, ref: 24000 kHz
> [    9.195677] [drm:intel_update_max_cdclk] Max CD clock rate: 675000 kHz
> [    9.195678] [drm:intel_update_max_cdclk] Max dotclock rate: 675000 kHz
> [   70.790172] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> [   70.790188] [drm:intel_modeset_checks] New cdclk calculated to be atomic
> 540000, actual 540000
> [   71.866294] [drm:skl_set_cdclk] Changing CDCLK to 540000 kHz (VCO 8100000
> kHz)
> [   71.872408] [drm:intel_update_cdclk] Current CD clock rate: 540000 kHz,
> VCO: 8100000 kHz, ref: 24000 kHz
> 
> So everything is looking good.
> 
> > 
> > PS: Is this fix going upstream some time?
> 
> It's being reviewed now, so should land soonish, I hope.

This has not really something to do with the bug, but how are these numbers to interpret? I mean, shouldn't there be something like a '60' somewhere?
Comment 10 Ville Syrjala 2016-05-18 19:01:43 UTC
(In reply to Oli from comment #9)
> (In reply to Ville Syrjala from comment #8)
> > (In reply to Oli from comment #7)
> > > (In reply to Ville Syrjala from comment #3)
> > > > [   12.914535] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz
> > > > [   91.861529] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> > > > 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> > > > 
> > > > Your cdclk is too low for that mode. I have a branch which has the required
> > > > bits to adjust cdclk dynamically on SKL:
> > > > git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2
> > > > 
> > > > Can you test with that branch?
> > > 
> > > I did and it seems to works, at least the display didn't blank and xrandr
> > > reports 60 Hz. Though, I have no way to tell if this is really the case,
> > > because my display won't show this information.
> > > 
> > > See the attached dmesg output for more information. I used the same
> > > drm.debug settings as before.
> > 
> > 
> > [    9.195675] [drm:intel_update_cdclk] Current CD clock rate: 450000 kHz,
> > VCO: 8100000 kHz, ref: 24000 kHz
> > [    9.195677] [drm:intel_update_max_cdclk] Max CD clock rate: 675000 kHz
> > [    9.195678] [drm:intel_update_max_cdclk] Max dotclock rate: 675000 kHz
> > [   70.790172] [drm:intel_dump_crtc_timings] crtc timings: 533280 3840 3848
> > 3992 4000 2160 2214 2219 2222, type: 0x0 flags: 0x9
> > [   70.790188] [drm:intel_modeset_checks] New cdclk calculated to be atomic
> > 540000, actual 540000
> > [   71.866294] [drm:skl_set_cdclk] Changing CDCLK to 540000 kHz (VCO 8100000
> > kHz)
> > [   71.872408] [drm:intel_update_cdclk] Current CD clock rate: 540000 kHz,
> > VCO: 8100000 kHz, ref: 24000 kHz
> > 
> > So everything is looking good.
> > 
> > > 
> > > PS: Is this fix going upstream some time?
> > 
> > It's being reviewed now, so should land soonish, I hope.
> 
> This has not really something to do with the bug, but how are these numbers
> to interpret? I mean, shouldn't there be something like a '60' somewhere?

For the refresh rate? That'd be 'dotclock/htotal/vtotal' so in this case
533280*1000/4000/2222 = 60.
Comment 11 Oli 2016-06-28 23:55:04 UTC
Any progress on this one? An ETA when it will be merged into upstream?
Comment 12 Jani Nikula 2016-06-29 08:31:38 UTC
(In reply to Oli from comment #11)
> Any progress on this one? An ETA when it will be merged into upstream?

We seem to have pushed this a while back http://mid.gmane.org/20160523182136.GY4329@intel.com

So it's all in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel, headed to v4.8. Thanks for the report, closing. Please reopen if the problem persists with those.


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.