[Intel-gfx] i915: WARN_ON(val > dev_priv->rps.max_freq_softlimit)

[Daniel Vetter]

On Wed, Jan 28, 2015 at 12:43:21AM -0500, Michael Auchter wrote:
> Testing out 3.19-rc6 on my 2014 Thinkpad X1 Carbon (Haswell) resulted in
> this WARN at boot (and pretty frequently afterwards):
> 
> WARNING: CPU: 0 PID: 989 at drivers/gpu/drm/i915/intel_pm.c:4377 gen6_set_rps+0x371/0x3c0()
> WARN_ON(val > dev_priv->rps.max_freq_softlimit)
> Modules linked in:
> CPU: 0 PID: 989 Comm: kworker/0:2 Not tainted 3.19.0-rc6 #31
> Hardware name: LENOVO 20A7002WUS/20A7002WUS, BIOS GRET38WW (1.15 ) 05/29/2014
> Workqueue: events intel_gen6_powersave_work
>  0000000000000000 ffffffff81a82dd0 ffffffff817f099e ffff88021451bd28
>  ffffffff8107d107 ffff8802148e0000 0000000000000022 ffff8802148e86f0
>  ffff88021498f000 0000000000040000 ffffffff8107d185 ffffffff81a83448
> Call Trace:
>  [<ffffffff817f099e>] ? dump_stack+0x40/0x50
>  [<ffffffff8107d107>] ? warn_slowpath_common+0x77/0xb0
>  [<ffffffff8107d185>] ? warn_slowpath_fmt+0x45/0x50
>  [<ffffffff813c6ff1>] ? gen6_set_rps+0x371/0x3c0
>  [<ffffffff813caa10>] ? intel_gen6_powersave_work+0x780/0x1180
>  [<ffffffff81090c50>] ? process_one_work+0x130/0x350
>  [<ffffffff81091274>] ? worker_thread+0x114/0x450
>  [<ffffffff81091160>] ? rescuer_thread+0x2f0/0x2f0
>  [<ffffffff810954ec>] ? kthread+0xbc/0xe0
>  [<ffffffff81095430>] ? kthread_create_on_node+0x170/0x170
>  [<ffffffff817f86ac>] ? ret_from_fork+0x7c/0xb0
>  [<ffffffff81095430>] ? kthread_create_on_node+0x170/0x170
> ---[ end trace c3ac159c87b9b234 ]---
> 
> I bisected this back to:
> 
> commit 93ee29203f506582cca2bcec5f05041526d9ab0a
> Author: Tom O'Rourke <Tom.O'Rourke at intel.com>
> Date:   Wed Nov 19 14:21:52 2014 -0800
> 
>     drm/i915: Use efficient frequency for HSW/BDW
> 
>     Added gen6_init_rps_frequencies() to initialize
>     the rps frequency values.  This function replaces
>     parse_rp_state_cap().  In addition to reading RPn,
>     RP0, and RP1 from RP_STATE_CAP register, the new
>     function reads efficient frequency (aka RPe) from
>     pcode for Haswell and Broadwell and sets the turbo
>     softlimits.  The turbo minimum frequency softlimit
>     is set to RPe for Haswell and Broadwell and to RPn
>     otherwise.
> 
>     For RPe, the efficiency is based on the frequency/power
>     ratio (MHz/W); this is considering GT power and not
>     package power.  The efficent frequency is the highest
>     frequency for which the frequency/power ratio is within
>     some threshold of the highest frequency/power ratio.
>     A fixed decrease in frequency results in smaller
>     decrease in power at frequencies less than RPe than
>     at frequencies above RPe.
> 
>     v2: Following suggestions from Chris Wilson and
>     Daniel Vetter to extend and rename parse_rp_state_cap
>     and to open-code a poorly named function.
> 
>     Signed-off-by: Tom O'Rourke <Tom.O'Rourke at intel.com>
>     Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
>     [danvet: Remove unused variables.]
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> I'm not at all familiar with this hardware, but I took a quick look into
> what changed with this commit for my laptop. Before the commit,
> rps.min_freq_softlimit is 4 (from rps.min_freq) and
> rps.max_freq_softlimit is 22.
> 
> After the commit, rps.min_freq_softlimit is set to the
> rps.efficient_freq value read from pcode, which is 34 on my laptop.
> So later when gen6_set_rps() is called with rps.min_freq_softlimit that
> warning is hit.
> 
> Any thoughts? It certainly seems fishy that this commit causes
> rps.min_freq_softlimit to be greater than rps.max_freq_softlimit.

Sounds like the rpe value on your firmware is rather bogus, and we
probably need to sanity-check it. Tom?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch