Hello everyone,
I have two cases in which I need to reboot my device during tests:
1. Reboot is active part of the test (e.g. store some persistent settings, reboot, check if persistent settings are correctly loaded after reboot)
2. Reboot is triggered and has to be evaluated (e.g. activate watchdog, stop resetting it, wait, check if system reboots automatically)
How can I hadle these two cases in LAVA?
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.comhttp://www.garz-fricke.com/ SOLUTIONS THAT COMPLETE! [cid:image001.jpg@01D407D7.E4232AA0] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
On Tue, 19 Jun 2018 at 13:27, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
Hello everyone,
I have two cases in which I need to reboot my device during tests:
Depends entirely on the deployment/boot method used by the device.
Does the device-type support BMC?
Exactly which device-types are you wanting to use for this? If any of these are not merged upstream, please attach the full device-type Jinja2 template in the reply.
Reboot is active part of the test (e.g. store some persistent
settings, reboot, check if persistent settings are correctly loaded after reboot)
Lava Test Shell is not re-entrant. A separate test shell action will be required - *unless* this is an LXC test job where the test shell occurs in the LXC and the LXC has a way to do the reboot, e.g. a fastboot device.
Reboot is triggered and has to be evaluated (e.g. activate
watchdog, stop resetting it, wait, check if system reboots automatically)
Triggered - how?
How can I hadle these two cases in LAVA?
At the moment, all boot actions need to be defined in the test job in advance and then managed by LAVA. Even with that, some device-types do not successfully get back to a usable point.
Mit freundlichen Grüßen / Best regards
*Tim Jaacks *DEVELOPMENT ENGINEER Garz & Fricke GmbH
Tempowerkring 2 21079 Hamburg
Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Hi Neil,
thanks for your reply.
On Tue, 19 Jun 2018 at 13:27, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote:
Hello everyone,
I have two cases in which I need to reboot my device during tests:
?Depends entirely on the deployment/boot method used by the device.
Does the device-type support BMC?
What is BMC?
Exactly which device-types are you wanting to use for this? If any of these are not merged upstream, please attach the full device-type Jinja2 template in the reply.
We have implemented our own (still hacky) device type using our own bootloader. See the attached Jinja2 template.
Reboot is active part of the test (e.g. store some persistent
settings, reboot, check if persistent settings are correctly loaded after reboot)
?Lava Test Shell is not re-entrant. A separate test shell action will be required - *unless* this is an LXC test job where the test shell occurs in the LXC and the LXC has a way to do the reboot, e.g. a fastboot device.
Okay, we do not use fastboot. So I assume I have to add a test action for the first part, then a boot action to handle the reboot, and then add another test action for the latter part. Would that work?
Reboot is triggered and has to be evaluated (e.g. activate
watchdog, stop resetting it, wait, check if system reboots automatically)
?Triggered - how??
As I described it above: using a watchdog. This is actually a test whether the watchdog service works correctly. I activate the watchdog, make it trigger a reboot and need to check whether this reboot actually happens. Is there a way to achieve this?
How can I hadle these two cases in LAVA?
?At the moment, all boot actions need to be defined in the test job in advance and then managed by LAVA. Even with that, some device-types do not successfully get back to a usable point.?
Mit freundlichen Grüßen / Best regards
*Tim Jaacks *DEVELOPMENT ENGINEER Garz & Fricke GmbH
Tempowerkring 2 21079 Hamburg
Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks at garz-fricke.com www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Lava-users mailing list Lava-users at lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams at linaro.org http://www.linux.codehelp.co.uk/
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
On Tue, 19 Jun 2018 at 14:04, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
Hi Neil,
thanks for your reply.
On Tue, 19 Jun 2018 at 13:27, Tim Jaacks <tim.jaacks at garz-fricke.com>
wrote:
Hello everyone,
I have two cases in which I need to reboot my device during tests:
?Depends entirely on the deployment/boot method used by the device.
Does the device-type support BMC?
What is BMC?
Baseboard Management Controller
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Base...
(I'll reply to the rest of the email later once I've had a look at the template.)
Exactly which device-types are you wanting to use for this? If any of
these
are not merged upstream, please attach the full device-type Jinja2
template
in the reply.
We have implemented our own (still hacky) device type using our own bootloader. See the attached Jinja2 template.
Reboot is active part of the test (e.g. store some persistent
settings, reboot, check if persistent settings are correctly loaded
after
reboot)
?Lava Test Shell is not re-entrant. A separate test shell action will be required - *unless* this is an LXC test job where the test shell occurs in the LXC and the LXC has a way to do the reboot, e.g. a fastboot device.
Okay, we do not use fastboot. So I assume I have to add a test action for the first part, then a boot action to handle the reboot, and then add another test action for the latter part. Would that work?
Reboot is triggered and has to be evaluated (e.g. activate
watchdog, stop resetting it, wait, check if system reboots
automatically)
?Triggered - how??
As I described it above: using a watchdog. This is actually a test whether the watchdog service works correctly. I activate the watchdog, make it trigger a reboot and need to check whether this reboot actually happens. Is there a way to achieve this?
How can I hadle these two cases in LAVA?
?At the moment, all boot actions need to be defined in the test job in advance and then managed by LAVA. Even with that, some device-types do not successfully get back to a usable point.?
Mit freundlichen Grüßen / Best regards
*Tim Jaacks *DEVELOPMENT ENGINEER Garz & Fricke GmbH
Tempowerkring 2 21079 Hamburg
Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks at garz-fricke.com www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Lava-users mailing list Lava-users at lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams at linaro.org http://www.linux.codehelp.co.uk/
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Hi Tim,
Following up in a slightly different style to Neil... :-)
On Tue, Jun 19, 2018 at 12:27:26PM +0000, Tim Jaacks wrote:
I have two cases in which I need to reboot my device during tests:
OK. This *can* be problematic, depending on the device - as Neil says. However, if your device and bootloader play nicely then it's perfectly possible. You can define multiple boot: and test: blocks in your test job to do this.
Reboot is active part of the test (e.g. store some persistent settings,
reboot, check if persistent settings are correctly loaded after reboot)
OK, so you'd need one deploy block, then:
boot: # first boot block do stuff test: # first test block do stuff store settings # maybe call sync, etc. - hard reboot coming
# After this test action block, LAVA will look for another block to # execute...
# At the beginning of the next boot action block, LAVA will # automatically power-cycle the board
boot: # second boot block catch the bootloader messages and boot into the system again test: # second test block check the settings were stored ok
Reboot is triggered and has to be evaluated (e.g. activate watchdog,
stop resetting it, wait, check if system reboots automatically)
This is more difficult, I'm afraid - LAVA doesn't (yet!) have support for this kind of thing. While you might *try* something like the following:
boot: # first boot block do stuff test: # first test block do stuff enable watchdog # maybe write a file as a flag for a later test block to know # we've done this? sleep N # longer than the watchdog timeout boot: # second boot block catch the bootloader messages and boot into the system again test: # second test block do stuff # maybe check for the flag file and say "watchdog test successful"?
I'm afraid at the moment this isn't going to work - at the end of the first test block, LAVA will still be waiting for the test shell prompt and won't pick up on the next boot messages. It'll time out and fail. If you try to hack around that (e.g. with a short timeout on the first test block), LAVA will then do a hard power-cycle like in your first test case - this won't be actually testing your watchdog. We're looking at adding soft reboots in between action blocks for this kind of test requirement, but it's not there yet.
Cheers,