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@xxxxxxxxx> > 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@xxxxxxxxx> > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > [danvet: Remove unused variables.] > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
