lava-users

lava-users@lists.lavasoftware.org

4 participants
935 discussions

by Hemanth K V

Hello Lava-users, In lava do we have support of booting x86 target boards which has systemd-boot as bootloader. Thanks, Hemanth.

6 years, 2 months

by Jerome BESNARD

Hello, I am working with Denis HUMEAU for STMicroelectronics. I have a problem to perform several reboot with LAVA job when I am using an image with requested login. I do not understand why 'root' login is sent to device under test when the prompt is received (lines 941, 942, 943, 944 in job_43624.log file). 'root' login should be sent only when a 'login_prompt' is received (like in lines 696, 697, 698, 699, 701, 702 in job_43624.log file). Could you help me to solve this problem, please ? Regards, [Description: Description: Description: Description: Description: Description: logo_big5] Jerome BESNARD | TINA: 166 7142 | Tel: +33 (0)244027142 | Mobile: +33 (0)623392912 MDG | SW Validation Ingineer

6 years, 2 months

Accessing DUTs for hacking sessions from an external network

by Tim Jaacks

Hello everyone, I have the following LAVA setup: LAVA server - 1 LAVA worker - 16 DUTs The LAVA server and the LAVA worker are located in my company network (172.20.0.0/16). The DUTs are connected to the LAVA worker in a local network (192.168.20.0/24). Thus, the DUTs are not accessible from outside the worker. What is a good way to allow for hacking sessions to a DUT (let's say 192.168.20.247) from the company network? I can think of the following solutions: 1. Use SSH forwarding on lava-worker: ssh -g -L 50000:localhost:22 -N root(a)192.168.20.247 2. Forward the SSH port via netcat on lava-worker: nc -l -p 50000 -c "nc 192.168.20.247 22" 3. Forward the SSH port via iptables on lava-worker: iptables -t nat -A PREROUTING -p tcp --dport 50000 -j DNAT --to 192.168.20.247:22 All of these make the device accessible via "ssh -p 50000 root@lava-worker" from the company network. So far, so good. However, in an ideal world this forwarding would be active only during the hacking session, so that in normal test jobs the DUT is not accessible. Is there a way to achieve this? Does anyone have experience with such a scenario? How do you handle DUT access for hacking sessions? 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

6 years, 3 months

Help needed with gateway and sensors testing

by Diego Russo

Hello LAVA experts, I need your help for a more complex test we would need to run. We'd like to test a gateway node that talks to remote sensors. * the gateway node is a Cortex-A like (E.g.: RPi3) board * sensors might be a mixture of Cortex-M (non-Linux) and Cortex-A (Linux) devices * communication between the gateway node and sensors might happen with different protocols: bluetooth, wifi, lora, zigbee. * besides the gateway node, we need to control every sensor and be able to provision and to power cycle them. We are pretty confident on running tests on single boards (with and without interaction with LXC containers) but as the above example is more complex we need some guidance on how this can be achieved with LAVA. The main question mark we have is how LAVA interacts with Cortex-M devices, especially for their deployment. Does anyone of you have a similar scenario? What are the main challenges? How complicated and/or robust to run something similar with LAVA? Can you point us to documentation, examples? Any help is very much appreciated. Thanks! -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

Expected failures

by Pete Dyer

Hello, We have some tests that are currently expected to fail, and should then become passes once the implementation of the feature is complete. Is this something LAVA results can support? As far as I can see the result can be pass/fail/skip (and possibly unknown). Suggestions welcome. Thanks. Pete IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

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

6 years, 3 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

6 years, 4 months

adb device lost during cts/vts

by Axel Lebourhis

Hi all, I'm facing a pretty frustrating issue when running CTS/VTS with LAVA. I'm using Linaro's tradefed test definition : https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade… During some runs, the adb connection is lost, leading to incomplete test job. Do you know if this behavior is known and mostly general ? Or is it a bad configuration on my side ? Maybe someone knows some way to keep a reliable adb connection to the target ? Best regards, Axel

6 years, 4 months

What's the difference of lava log feedback & log output on the web page?

by Larry Shen

Sometimes, I can see the lava log feedback to repeat the the lava log output, sometimes cannot. Could you give an example simple inline test, so I can always see some log feedback? Something like: - test: timeout: minutes: 1 definitions: - from: inline name: smoke-case path: inline/test.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-case-run description: Run smoke case run: steps: - lava-test-case "Case_001" --shell 'echo "Case001 gstreamer ok";' How could I let ` Case001 gstreamer ok` also been seen in feedback log level?

6 years, 4 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

6 years, 4 months

← Newer
1
...
41
42
43
44
45
46
47
...
94
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users