Hi, all

Some information:

1. the boot time is about 2 minutes.
    tested with panda stable build.

2. the specification of timeout for each test is doing via this bp:
    https://blueprints.launchpad.net/lava-dispatcher/+spec/timeout-for-android-test-actions
    when this BP is completed, the timeout option is assumed that can be specified for each test 
    in LAVA_TEST_PLAN and each test of LAVA_TEST_X and each test of MONKEY_RUNNER_URL_X

Hi, Zach

| If glmark2 hangs, reboot the unit and restart on 0xbench.   

Do you mean reboot just when glmark2 timeout, or reboot when any test timeout?
And, If the android hangs at some test, lava should be able to reboot the image and continue the next test now.

Thanks,
Yongqin Liu



On 6 June 2012 02:52, Alexander Sack <asac@linaro.org> wrote:
On Tue, Jun 5, 2012 at 5:57 PM, Zach Pfeffer <zach.pfeffer@linaro.org> wrote:
> On 5 June 2012 23:34, Alexander Sack <asac@linaro.org> wrote:
>> On Tue, Jun 5, 2012 at 5:26 PM, Zach Pfeffer <zach.pfeffer@linaro.org> wrote:
>>> On 5 June 2012 18:23, Alexander Sack <asac@linaro.org> wrote:
>>>> I feel stopping and rebooting and continuing with the next test is
>>>> what we want to aim for.
>>>>
>>>> On this front I wonder if we should directly go for rebooting for
>>>> _all_ tests to ensure that every test gets executed the same runtime
>>>> environment.
>>>>
>>>> Big benefit is obviously that tests can then stop services, change
>>>> runtime state etc. as much as they like without bothering about
>>>> bringing the system back into a clean state.
>>>>
>>>> Would that be hard? Why wouldn't we do this?
>>>
>>> Seems like a good idea in theory, but in practice it may cause testing
>>> to take a long time. Plus, what constitutes a test boundary? I think
>>
>> I don't think this would really extend the testing time much. Majority
>> of time is usually spend in flashing the image. The booting and
>> running should be not of a big time sink; the little bit we loose we
>> get back from keeping the suite running "isolated".
>>
>>> if we do the fail then restart then we get the best of both worlds,
>>> we're able to run multiple tests and restart if we get the system into
>>> a really weird state.
>>
>> I would think "one suite" is a good test boundary (basically the names
>> you currently put in TEST_PLAN).
>
> Sure. I actually okay with this.
>
> If we do this though, we may want to change things so that each test
> is a tuple with a test name and a timeout for that test.
>

you mean you want to tune the timeout in your LAVA_TEST_PLAN=... line?
I guess that would be doable... however, ultimately we should think
about a better structured format to setup parameterization. I guess we
might want to tweak more stuff in the future :)...


--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog