lava-users

lava-users@lists.lavasoftware.org

1 participants
912 discussions

Using Connection timeout for expected silence time on shell

by Paweł Wieczorek

Hi Lava Users, I'm working on a LAVA test that is not very chatty (little to no output during execution). I'm looking for a way to set expected silence time in that test and break its execution in case it's exceeded. I thought Connection timeout [1] would be my solution but by setting: timeouts: connections: lava-test-shell: seconds: 5 I was unable to get any difference in the job execution. I intentionally made timeout ridiculously small to see how it would affect the job. Please let me know if using Connection timeout for this purpose is a dead end. I'm also open for any solution suggestions (wrapping test with a script that would emit checkpoints on serial?) [1] https://lava.readthedocs.io/en/latest/technical-references/job-definition/t… Thanks, Paweł Wieczorek

3 years, 3 months

Alternate Bank booting support on NXP Layerscape boards

by Sahil Malhotra

Hi, We are working on integrating NXP Layerscape boards in LAVA. On Layerscape boards, we have a mechanism of having multiple banks. This is done mainly to protect board from getting bricked if wrong images gets flashed on board. Board is set to boot from a Bank 1 by default (controlled by switches). Now you use this bank also to flash your images, but in case the images are corrupt, board will get bricked and you will need to connect JTAG to recover the board. So here concept of Alternate Bank boot comes to help. By default board boots from Bank 1, but we will not flash the images on Bank 1, instead we will flash images on Bank 2. After flashing the images, we will boot from Bank 2 with a certain command on u-boot "qixis_reset altbank". With this command, Board boots from the Bank 2 and now we can boot up kernel on board. Since in this case, we have flashed the images on Bank 2 and even if images are corrupt, Bank 2 will get bricked, but since we have set board to boot from Bank 1 by default, Board will still be usable and you can flash the correct images on Bank 2 and get that working. So this was the concept and why we are using it. Now when we try to replicate the same behavior with LAVA, we are facing some issues. When we issue command "qixis_reset altbank" on u-boot, it just prints "=>", which lava takes as a success and issue next command and then starts waiting for the "Starting Kernel", which will not happen. Infact what should happen is that, after "qixis_reset altbank" is issued, lava should wait for some time and let board boot from Bank 2 (On Bank 2 board again will boot the u-boot only). and wait for "Hit Any key to stop autoboot" and then interrupt the board. Here is job.yaml for your reference. https://git.lavasoftware.org/lava/lava/uploads/2a530894990eca6c69648e6ad637… Please help me on this, how can i achieve this way of booting the board. Thanks Sahil Malhotra

3 years, 3 months

Error of results.get_testcase_results_yaml

by Larry Shen

Hi, guys, When I call `results.get_testcase_results_yaml`, there is a small probability that I will get the error: Post https://xiaotian:***@lava.sw.nxp.com/RPC2: EOF What does "EOF" here mean, what could be the possible root cause? Thanks.

3 years, 4 months

Any method to directly get device name from test shell?

by Larry Shen

Hi, guys, In lava, if we define e.g. "imx8mm-evk-sh01.jinja2" device dict, and run a job on this device, if possible we could get the name (imx8mm-evk-sh01) of this device directly in test shell? I don't want to define environment again and again in jinja2 file something like "{% set environment = {'DEVICE_NAME': " imx8mm-evk-sh01"} %}"..., there possible fault & mismatch when define this. Thanks.

3 years, 4 months

Android iperf test hung.

by Hedy Lamarr

Dear community, We are new to lava and try to use lava in our android test. We have issues when test iperf. Job: job_name: android iperf test timeouts: job: minutes: 10080 action: minutes: 120 connection: minutes: 5 priority: medium visibility: public protocols: lava-multinode: roles: device: count: 1 device_type: dragonboard-410c timeout: minutes: 5 host: count: 1 device_type: ssh timeout: minutes: 5 context: ssh_host: localhost ssh_user: root ssh_port: 22 ssh_identity_file: /root/.ssh/id_rsa actions: - deploy: role: - host timeout: minutes: 2 to: ssh os: debian - boot: role: - host method: ssh connection: ssh prompts: - '@labpc1' - test: role: - host timeout: minutes: 120 definitions: - from: inline name: smoke-case path: inline/test.yaml repository: metadata: format: Lava-Test Test Definition name: smoke description: Run smoke case run: steps: - sleep 60 - lava-send "server_ready" - iperf -s -V -P 1 - test: role: - device definitions: - from: inline name: cts_cts-media_test path: inline/cts_cts-media_test.yaml repository: metadata: description: cts cts-media test run format: Lava-Test Test Definition 1.0 name: cts-cts-media-test-run run: steps: - adb wait-for-device - adb devices - adb root - adb wait-for-device - adb devices - lava-wait "server_ready" - sleep 3 - lava-test-case "Case1" --shell adb shell /data/local/iperf -c 10.191.253.21 -t 10 docker: image: terceiro/android-platform-tools timeout: minutes: 4200 The job log for dragonboard-410c is: + lava-wait server_ready <LAVA_WAIT_DEBUG preparing Wed Jun 8 10:07:22 CST 2021> <LAVA_WAIT_DEBUG started Wed Jun 8 10:07:22 CST 2021> <LAVA_MULTI_NODE> <LAVA_WAIT server_ready> <LAVA_WAIT_DEBUG finished Wed Jun 8 10:07:22 CST 2021> <LAVA_WAIT_DEBUG finished Wed Jun 8 10:07:22 CST 2021> <LAVA_WAIT_DEBUG starting to wait Wed Jun 8 10:07:22 CST 2021> NOTE: it looks hung at this step, the job can't continue. The job log for ssh is: + lava-send server_ready <LAVA_SEND_DEBUG lava_multi_node_send preparing Wed Jun 8 10:07:53 CST 2021> <LAVA_SEND_DEBUG _lava_multi_node_send started Wed Jun 8 10:07:53 CST 2021> <LAVA_MULTI_NODE> <LAVA_SEND server_ready> Received Multi_Node API <LAVA_SEND> messageID: SEND-server_ready lava-multinode lava-send Handling signal <LAVA_SEND {"request": "lava_send", "messageID": "server_ready", "message": {}, "timeout": 300}> Setting poll timeout of 300 seconds requesting lava_send server_ready message: {} requesting lava_send server_ready with args {} request_send server_ready {} Sending {'request': 'lava_send', 'messageID': 'server_ready', 'message': {}} final message: {"port": 3079, "blocksize": 4096, "poll_delay": 3, "host": "10.191.253.109", "hostname": "lavaslave1", "client_name": "3035", "group_name": "8a362e2a-6ee9-4f48-bddb-378ac2425f06", "role": "host", "request": "lava_send", "messageID": "server_ready", "message": {}} Connecting to LAVA Coordinator on 10.191.253.109:3079 timeout=300 seconds. case: multinode-send-server_ready case_id: 39177 definition: 0_smoke-case result: pass <LAVA_SEND_DEBUG _lava_multi_node_send finished Wed Jun 8 10:07:53 CST 2021> <LAVA_SEND_DEBUG lava_multi_node_send finished Wed Jun 8 10:07:53 CST 2021> + iperf -s -V -P 1 ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ It seems that one node can't receive server-ready from another node, what's wrong with my job? Please help! Thanks, Hedy Lamarr

3 years, 4 months

How to exit job in advance.

by Larry Shen

Hi, guys, We have a scenario like next: action: - test definitions: - from: inline name: test1 - test definitions: - from: inline name: test2 For some reasons, we have to use 2 tests here, everything is ok now. But, if `test1`, that is ` /lava-3102/0/tests/0_test1/run.sh` finished with non-zero, from web we can see the suite fail. Then, we want to exit the job at once, not continue to run `test2`. If possible here? Regards, Larry

3 years, 5 months

Set boot settings with x86 / PXE

by Fabiano Ferronato

Hi everybody, I'm trying to figure out how to set boot parameters (nfsroot) for a x86 board (Intel NUC10 ). >From this job definition I understand it's possible using iPXE: https://lkft.validation.linaro.org/scheduler/job/2959364/definition But I can't understand what interface is being used to get terminal output and remote control: https://lkft.validation.linaro.org/scheduler/device/x86-01/devicedict Look's like is using UART, I'm not sure I can get terminal console on boot time on my board (NUC). The options I can get from the information found are the following (please add any corrections or suggestions): 1) iPXE + terminal console: PXE alone can't get nfsroot settings dynamically. PXE + iPXE should be added to the chain and LAVA should have access to terminal console. 2) iPXE + environment variables: LAVA sets environment variables and PXE + iPXE gets nfsroot settings from environment variables. No terminal console needed. 3) PXE + static folder: LAVA fetches and extract rootfs always to the same folder. PXE reads static configuration file. 4) PXE + dynamic folder: LAVA sets the nfsroot folder name directly on the PXE configuration file (file is machine specific). 5) PXE + INITRAMFS: fetches root file system from file server and extracts to memory. Let me know your thoughts! Best Regards Fabiano

3 years, 5 months

Difference of next 2 docker options.

by Hedy Lamarr

Dear, I'm a little confused about the next 2 options: a) https://lava.readthedocs.io/en/latest/user/advanced-tutorials/running-arbit… b) https://lava.readthedocs.io/en/latest/admin/basic-tutorials/device-setup/do… It seems they both run a docker container on pc, what's the difference between them? Could one replace another? What I expect to get is something like: for xx scenario, you need to use option a, while for xxx scenario, you need to use option b. Thanks, Hedy Lamarr

3 years, 5 months

Providing Arguments from Job to Test Shell (definition?)

by Westermann, Oliver

Hey, We're using lava to test multiple of our devices. While most tests are similar ("does the device still have a working ethernet connection"), some slightly differ. For example a device might have LEDs 1-3, another the LEDs 1-5. Today I save multiple test shell definitions test1-device1.yaml, test1-device2.yaml, ..., which all just differ by providing "device1", "device2", ... in an argument to the actual test script, so the run: section looks like this: run: steps: - cd ./testdir/ - ./run_test.py device1 I would like to get rid of the two, separate .yaml files and only have a `./run_test.py ${device}` or similar. Is there any way to provide a variable from the job definition to the test shell definition? Or are things like the device type set in the environment so I could access them? Best regards, Olli

3 years, 6 months

How to quickly find other guys' job.

by Hedy Lamarr

Dear, I wonder if it is possible on the job page, I could quickly find other guys' jobs with a search function? I tried next, but returned nothing. owner_query=hedy.lamarr Thanks, Hedy Lamarr

3 years, 6 months

← Newer
1
...
11
12
13
14
15
16
17
...
92
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users