From: Jeff McGee <jeff.mcgee@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] tests/pm_rps: ducttape for igt fork helper cleanup issues
Date: Fri, 14 Mar 2014 09:29:13 -0500 [thread overview]
Message-ID: <20140314142913.GA5686@jeffdesk> (raw)
In-Reply-To: <1394789268-28703-1-git-send-email-daniel.vetter@ffwll.ch>
On Fri, Mar 14, 2014 at 10:27:46AM +0100, Daniel Vetter wrote:
> We don't call cleanup handlers when exiting a subtest currently, only
> when exiting the entire binary. Which means pm_rps falls over when it
> fails more than one subtest.
>
> Cc: Jeff McGee <jeff.mcgee@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> tests/pm_rps.c | 32 +++++++++++++++++++-------------
> 1 file changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index a652cf580dc7..b1cd13fc33a7 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -196,9 +196,27 @@ static void emit_store_dword_imm(uint32_t val)
> }
>
> #define LOAD_HELPER_PAUSE_USEC 500
> +static void load_helper_set_load(enum load load)
> +{
> + assert(lh.igt_proc.running);
> +
> + if (lh.load == load)
> + return;
> +
> + lh.load = load;
> + kill(lh.igt_proc.pid, SIGUSR2);
> +}
> +
> static void load_helper_run(enum load load)
> {
> - assert(!lh.igt_proc.running);
> + /*
> + * FIXME fork helpers won't get cleaned up when started from within a
> + * subtest, so handle the case where it sticks around a bit too long.
> + */
> + if (lh.igt_proc.running) {
> + load_helper_set_load(load);
> + return;
> + }
>
> igt_require(lh.ready == true);
>
> @@ -229,20 +247,8 @@ static void load_helper_run(enum load load)
> }
> }
>
> -static void load_helper_set_load(enum load load)
> -{
> - assert(lh.igt_proc.running);
> -
> - if (lh.load == load)
> - return;
> -
> - lh.load = load;
> - kill(lh.igt_proc.pid, SIGUSR2);
> -}
> -
> static void load_helper_stop(void)
> {
> - assert(lh.igt_proc.running);
> kill(lh.igt_proc.pid, SIGUSR1);
> igt_wait_helper(&lh.igt_proc);
> }
> --
> 1.8.4.rc3
>
Unfortunately there are probably several ways in which a failed subtest will
contaminate subsequent subtests if all are run in the same process instance.
I asked about that earlier and you said that we don't concern too much about
it because the preferred way to run is with a test runner and each subtest
executed in a separate instance. If we do in fact care about supporting all
subtests in a single instance, can we put in place a subtest exit handler?
That would solve all issues similar to this.
-Jeff
next prev parent reply other threads:[~2014-03-14 14:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 9:27 [PATCH 1/3] tests/pm_rps: ducttape for igt fork helper cleanup issues Daniel Vetter
2014-03-14 9:27 ` [PATCH 2/3] tests/pm_rps: simplify load helper setup Daniel Vetter
2014-03-14 14:34 ` Jeff McGee
2014-03-14 15:31 ` Daniel Vetter
2014-03-14 9:27 ` [PATCH 3/3] tests/pm_rps: load harder Daniel Vetter
2014-03-14 14:41 ` Jeff McGee
2014-03-14 15:47 ` Daniel Vetter
2014-03-14 14:29 ` Jeff McGee [this message]
2014-03-14 15:34 ` [PATCH 1/3] tests/pm_rps: ducttape for igt fork helper cleanup issues Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140314142913.GA5686@jeffdesk \
--to=jeff.mcgee@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.