Created attachment 128265 [details] dmesg No visible issues, but on the latest -nightly I keep hitting the following: [ 6.136214] WARNING: CPU: 0 PID: 396 at drivers/gpu/drm/i915/intel_pm.c:2089 ilk_compute_pipe_wm+0x4b0/0x4c0 [i915] [ 6.136215] WARN_ON(intel_state->cdclk == 0) [ 6.136216] Modules linked in: [ 6.136217] i915(+) rtsx_pci_sdmmc mmc_core intel_gtt i2c_algo_bit drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel drm serio_raw ghash_clmulni_intel e1000e rtsx_pci ptp pps_core fjes video [ 6.136229] CPU: 0 PID: 396 Comm: systemd-udevd Not tainted 4.9.0-rc7-drm-intel+ #183 [ 6.136230] Hardware name: LENOVO 20BW000FUK/20BW000FUK, BIOS JBET54WW (1.19 ) 11/06/2015 [ 6.136231] ffffb686014c36d8 ffffffff85527243 ffffb686014c3728 0000000000000000 [ 6.136234] ffffb686014c3718 ffffffff850ae7eb 00000829e912cd00 0000000000000000 [ 6.136237] ffff95dfe6498000 ffff95dfe86b1000 0000000000000004 ffff95dfe3477800 [ 6.136240] Call Trace: [ 6.136244] [<ffffffff85527243>] dump_stack+0x86/0xc3 [ 6.136245] [<ffffffff850ae7eb>] __warn+0xcb/0xf0 [ 6.136247] [<ffffffff850ae86f>] warn_slowpath_fmt+0x5f/0x80 [ 6.136270] [<ffffffffc028a8e0>] ilk_compute_pipe_wm+0x4b0/0x4c0 [i915] [ 6.136278] [<ffffffffc01c1f9b>] ? __drm_mode_object_find+0x6b/0xd0 [drm] [ 6.136306] [<ffffffffc02fac54>] intel_crtc_atomic_check+0x64/0x250 [i915] [ 6.136311] [<ffffffffc0235d3f>] drm_atomic_helper_check_planes+0x13f/0x1e0 [drm_kms_helper] [ 6.136339] [<ffffffffc02fde88>] intel_atomic_check+0xa28/0x11e0 [i915] [ 6.136366] [<ffffffffc02fe6da>] sanitize_watermarks+0x9a/0x1c0 [i915] [ 6.136394] [<ffffffffc03065ba>] intel_modeset_init+0xf8a/0x1660 [i915] [ 6.136417] [<ffffffffc02755b2>] i915_driver_load+0xa12/0x14b0 [i915] [ 6.136440] [<ffffffffc02801cd>] i915_pci_probe+0x2d/0x50 [i915] [ 6.136443] [<ffffffff85581825>] local_pci_probe+0x45/0xa0 [ 6.136445] [<ffffffff8558288a>] ? pci_match_device+0xca/0x110 [ 6.136448] [<ffffffff85582ca3>] pci_device_probe+0x103/0x150 [ 6.136450] [<ffffffff8567f853>] driver_probe_device+0x223/0x430 [ 6.136452] [<ffffffff8567fb43>] __driver_attach+0xe3/0xf0 [ 6.136453] [<ffffffff8567fa60>] ? driver_probe_device+0x430/0x430 [ 6.136455] [<ffffffff8567d173>] bus_for_each_dev+0x73/0xc0 [ 6.136456] [<ffffffff8567ef8e>] driver_attach+0x1e/0x20 [ 6.136457] [<ffffffff8567e9c3>] bus_add_driver+0x173/0x270 [ 6.136459] [<ffffffffc03f0000>] ? 0xffffffffc03f0000 [ 6.136460] [<ffffffff85680790>] driver_register+0x60/0xe0 [ 6.136462] [<ffffffffc03f0000>] ? 0xffffffffc03f0000 [ 6.136464] [<ffffffff85581140>] __pci_register_driver+0x60/0x70 [ 6.136488] [<ffffffffc03f0057>] i915_init+0x57/0x5a [i915] [ 6.136491] [<ffffffff85002190>] do_one_initcall+0x50/0x180 [ 6.136493] [<ffffffff8512c365>] ? rcu_read_lock_sched_held+0x45/0x80 [ 6.136494] [<ffffffff8526b9d0>] ? kmem_cache_alloc_trace+0x220/0x280 [ 6.136496] [<ffffffff851f2ed3>] ? do_init_module+0x27/0x1f1 [ 6.136497] [<ffffffff851f2f0b>] do_init_module+0x5f/0x1f1 [ 6.136499] [<ffffffff85158244>] load_module+0x2604/0x2a80 [ 6.136501] [<ffffffff851548d0>] ? __symbol_put+0x70/0x70 [ 6.136503] [<ffffffff8529a3db>] ? vfs_read+0x11b/0x130 [ 6.136505] [<ffffffff8515893f>] SYSC_finit_module+0xdf/0x110 [ 6.136507] [<ffffffff8515898e>] SyS_finit_module+0xe/0x10 [ 6.136508] [<ffffffff85003eec>] do_syscall_64+0x6c/0x1f0 [ 6.136511] [<ffffffff8599fa09>] entry_SYSCALL64_slow_path+0x25/0x25
Reference to Ville's patch for initializing dev_priv->atomic_cdclk_freq at init time: https://patchwork.freedesktop.org/series/16100/
Fix has now been merged, so marking as resolved: commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Nov 29 16:13:57 2016 +0200 drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time Looks like we're only initializing dev_priv->atomic_cdclk_freq at resume and commit times, not at init time. Let's do that as well. We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in hsw_compute_linetime_wm() on account of populating intel_state->cdclk from dev_priv->atomic_cdclk_freq. Previously we were mispopulating intel_state->cdclk with dev_priv->cdclk_freq which always had a proper value at init time and hence the WARN_ON() didn't trigger.
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.