From 961a46c82b4fe558ea726833aa9d390382742a10 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 26 Mar 2014 22:15:12 +0100 Subject: [PATCH] tests/pm_rps: Add a new testcase to provoke the "stuck at max" bug Note that the sleep(5); to fully idle the gpu is _really_ important. Without it the bug is not exhibited. The issue at hand is that after gem_quiescent_gpu we are at max (expected, since the blocking waits peg to max), but then we never go down to a lower freq again until we're fully idle. The tiny load is sufficient to keep the gpu at max. I've played around with this a bit and even ridiculously low loads (like one MI_STORE per 50ms) are enough to keep the gpu at max freq. Signed-off-by: Daniel Vetter --- tests/pm_rps.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/tests/pm_rps.c b/tests/pm_rps.c index 7898e78..09ae349 100644 --- a/tests/pm_rps.c +++ b/tests/pm_rps.c @@ -522,6 +522,43 @@ static void reset(void) idle_check(); } +static void blocking(void) +{ + int pre_freqs[NUMFREQ]; + int post_freqs[NUMFREQ]; + + int fd = drm_open_any(); + igt_assert(fd >= 0); + + /* + * quiescent_gpu upsets the gpu and makes it get pegged to max somehow. + * Don't ask. + */ + sleep(10); + + igt_debug("Apply low load...\n"); + load_helper_run(LOW); + stabilize_check(pre_freqs); + load_helper_stop(); + + sleep(5); + + igt_debug("Kick gpu hard ...\n"); + /* This relies on the blocking waits in quiescent_gpu and the kernel + * boost logic to ramp the gpu to full load. */ + gem_quiescent_gpu(fd); + gem_quiescent_gpu(fd); + + igt_debug("Apply low load again...\n"); + load_helper_run(LOW); + stabilize_check(post_freqs); + load_helper_stop(); + matchit(pre_freqs, post_freqs); + + igt_debug("Removing load...\n"); + idle_check(); +} + static void pm_rps_exit_handler(int sig) { if (origfreqs[MIN] > readval(stuff[MAX].filp)) { @@ -583,4 +620,7 @@ igt_main igt_subtest("reset") reset(); + + igt_subtest("blocking") + blocking(); } -- 2.7.4