lava-users April 2019

lava-users@lists.lavasoftware.org

20 participants
24 discussions

External worker devices in LXC / connection to DUTs

by Tim Jaacks

Hello, we are trying to add external interfaces on the worker to connect with the DUTs, for example a 4-port USB-to-RS232 converter. Our DUTs have multiple RS232 ports which shall be tested using this remote interface. We have already figured out how to integrate this hardware into the LAVA environment, so that it can be used within the LAVA LXC (using static_info in the device dictionary, resulting in the four /dev/ttyUSB* devices being visible there). First question: We need multiple of these converters attached to the worker. How do we integrate these into LAVA? They all have the same board_id, vendor_id and product_id. If I specify the board_id in the device dictionary multiple times, the device is still added only once. Second question: We need a way to specify to which of the /dev/ttyUSB* ports a certain RS232 port of the DUT is connected. The place where I would assume to put such information is the device dictionary. But how can we access this information within a LAVA test shell? The documentation specifies some similar mechanism for energy probes: https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh… It says "Devices which are not directly attached to the worker can also be supported, for example energy probes which communicate over the network". As far as I can tell from the code, though, this seems to be a hard-coded feature without any possibility of adding other custom hardware. Is that correct? If yes, why isn't there a generic mechanism to supply static_info from the device dictionary in the LAVA test shell? Or is there? How can we implement our scenario described above using 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(a)garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

4 years, 10 months

query to retrieve Lava errors

by Denis HUMEAU

After getting stats on my setup robustness, the step forward is have a complete view on the lava errors we meet in incomplete jobs. >From what I see in incomplete jobs, my intention is to query on test suite lava and the name "job". In the query builder, if I use test suite as condition model, I can't use the job field name. Do you have any advice on how to proceed? Denis

4 years, 10 months

lava-test-case only handles lower case results strings

by Patryk Mungai Ndungu

Hello, I have recently upgraded from 2018.11 to 2019.03 and have noticed that the results of a lot of the tests I have been running no longer got parsed correctly by LAVA. This was because I was sending the results using upper case results strings. Eg. lava-test-case <test-case> PASS opposed to lava-test-case <test-case> pass This resulted in the following logs in the lava job: Received signal: <TESTCASE> TEST_CASE_ID=ETH_T_001 RESULT=PASS Bad test result: PASS Changing my results parsing script to only send lower case results strings fixed the issue, but was this restriction intended with the upgrade? Kind Regards, Patryk

4 years, 10 months

timeouts for deploy vs http-download

by Kevin Hilman

Hello, I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win. Based on the doc, I did this, I added the following to my job[2] timeouts: actions: http-download: minutes: 15 However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout. I got the same result when tryin to use timeouts: connections: What am I missing? Kevin [1] https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_d… [2] https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44 [3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1

4 years, 11 months

[PATCH] doc/v2/timeouts: fix http-download action name typos

by Kevin Hilman

The name of the action for http download uses a hyphen, not an underscore. Fix the typos. Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- doc/v2/timeouts.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/v2/timeouts.rst b/doc/v2/timeouts.rst index c330f9d89548..50070766abe0 100644 --- a/doc/v2/timeouts.rst +++ b/doc/v2/timeouts.rst @@ -259,7 +259,7 @@ block override. timeouts: actions: - http_download: + http-download: minutes: 2 .. _individual_connection_timeout_overrides: @@ -275,7 +275,7 @@ specific connection timeout which can be longer or shorter than the default. timeouts: connections: - http_download: + http-download: minutes: 2 .. _action_block_timeout_overrides: -- 2.21.0

4 years, 12 months

Current LAVA version in stretch-backports

by Tim Jaacks

Hello everyone, the current LAVA version in stretch-backports is still 2018-11. Is there a reason why it has not been updated since then? Will newer releases go into buster only? Or will there be updates in stretch-backports in the future? For stretch users, do you recommend using the LAVA repositories to upgrade to the latest version? Or should production systems keep using 2018-11 at this moment? 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(a)garz-fricke.com www.garz-fricke.com<http://www.garz-fricke.com/> WE MAKE IT YOURS! [cid:image001.jpg@01D4FF4A.A2ED9910] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

5 years

Re: [Lava-users] Handling of a kernel panic

by Remi Duraffort

Hello, as said in the previous email, that's currently not possible to see kernel crashes outside of the boot action. That's something we want to improve. I will soon create an issue in our gitlab instance where you would be able to comment. Rgds Le jeu. 11 avr. 2019 à 14:33, Frank, Matthias <Matthias.Frank(a)tq-group.com> > a écrit : > > Hi lava users, > > > > sometimes I how in memory allocator stress tests a kernel panic. How can I > evaluate this? Is it possible to set a testcase or job to fail if a kernel > panic occurs? > > > > Matthias > > > > Sometimes a test triggers a kernel panic and the dut will reboot to U-Boot > and stuck because there is no boot process. Lava waits until timeout and > stop the job. > > > -- Rémi Duraffort LAVA Team, Linaro

5 years

What's the difference between kernel ci's docker and official docker?

by Larry Shen

Hi, I'd like to know is this site official? https://github.com/kernelci/lava-docker Does this project same as the one in dockerhub, lavasoftware/lava-server?

5 years

Correct way to make device not affect others.

by cnspring2002

I attach a tag on one of my device, and when submit job I will add "tags:" to my job, it's ok. But, when others submit their job with same device-type which same as my device, as they did not specify "tags", they will have chance to run their job on my device. How to avoid it? I want the job not be scheduled to the device which have a tag if the job did not specify any tag. I tried to set the device as private, but then only me can use this device, I have other guys in groupA which want to use the device, while I hae another some guys in groupB which didid not want to use these devices as some modules on the device is not same.

5 years

device type alias redesign

by Milosz Wasilewski

Hi, There is an idea of device type 'alias' in LAVA. I don't quite understand what the use case for the current implementation was [1]. I tried using it but it wasn't very useful. My use case is that I need to submit jobs to a device type with different device type name. This is used to align device type naming between different labs in a bigger project (kernelci.org in this case). So the questions I have about current implementation: - is there anyone using current implementation? - if current implementation is used, how much trouble would it cause to change the behaviour? Change in behaviour is quite intrusive and will require database migration. [1] https://master.lavasoftware.org/static/docs/v2/glossary.html#term-alias Regards, milosz

5 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users April 2019