Lava-users

lava-users@lists.linaro.org

358 discussions

u-boot devices broken after 2018.4 upgrade, strange u-boot interaction

by Kevin Hilman

Hello, After upgrading to 2018.4 (also tried .5) many of our device-types using base-uboot.jinja2 are broken. While I really like the major improvement to run commands individually, there seems to be some problems and the LAVA output logs are very confusing, showing concatenated strings, etc. Here is an example for an upstream device-type (meson-gxbb-p200), and here is where it starts interacting with u-boot: http://khilman.ddns.net/scheduler/job/15#L336 The "Parsed boot commands" look perfect, and all the commands in black all look good, but notice the commands at the u-boot prompt, they appear to be concatenated, starting right away at the "setenv initrd_high ..." However, observing the commands on the actual serial port (I use conmux, so can observe the serial console interactions directly), I'm not seeing concatenated strings, but the "setenv serverip ..." never shows up, so the TFTP downloads fail, and the job fails. Here's what I see directly on the serial console: Hit Enter or space or Ctrl+C key to stop autoboot -- : 0 gxb_p200_v1# gxb_p200_v1#setenv autoload no gxb_p200_v1#setenv initrd_high 0xffffffff gxb_p200_v1#setenv fdt_high 0xffffffff gxb_p200_v1#dhcp dwmac.c9410000 Waiting for PHY auto negotiation to complete.. done Speed: 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.0.216 (267 ms) gxb_p200_v1#tftp 0x1080000 14/tftp-deploy-5v1wo7fv/kernel/uImage Speed: 100, full duplex Using dwmac.c9410000 device TFTP from server 192.168.0.1; our IP address is 192.168.0.216 Filename '14/tftp-deploy-5v1wo7fv/kernel/uImage'. Load address: 0x1080000 Loading: * TFTP error: 'File not found' (1) Even more interesting is that on the same setup, a beaglebone-black device, using the same base-uboot.jinja2 is working just fine: http://khilman.ddns.net/scheduler/job/1 Any help would be appreciated, I'm thoroughly confused by what's going on here. Thanks, Kevin

6 years, 6 months

QEMU health check apparently not running

by Robert Marshall

At some point last week - I think because of network connectivity issues a job got stuck and I I cancelled it, it when run again it again appeared to hang. I again cancelled it and am now seeing the health check not start (at least no output appears on the job's webspage. Looking at the output.yaml (in /var/lib/lava-server/default/media/job-output/2018/05/23/32 ) I see ... progress output for downloading https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz - {"dt": "2018-05-23T07:39:54.728015", "lvl": "debug", "msg": "[common] Preparing overlay tarball in /var/lib/lava/dispatcher/tmp/32/lava-overlay-aye3n2ke"} - {"dt": - "2018-05-23T07:39:54.728root@stretch:/var/lib/lava-server/default/media/job-output/2018/05/23/32 But none of this appears in http://localhost:8080/scheduler/job/32 and at the head of that page I see the message: Unable to parse invalid logs: This is maybe a bug in LAVA that should be reported. which other logs are best for checking whether this is an error that should be fed back? (LAVA 2018.4) Robert

6 years, 6 months

Unable to run test on multiple devices using Lava-multi-node functionality

by Onkar Bokshe

Hi All, I am trying to run test on multiple ssh devices using multi-node functionality(protocols,tags and ssh connection) , device is detected in multi-node information as below but no unable to get the debug log i.e no actions are processing after devices detection please help me to resolve this. Following is working fine a) I am able to run test using single node on both devices b) Framework detects devices mentioned in protocols as mentioned below Mulitnode info : 125.0 <http://134.86.62.95/scheduler/job/125.0> (125) on: uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> as: node1 125.1 <http://134.86.62.95/scheduler/job/125.1> (126) on: nano-mel <http://134.86.62.95/scheduler/device/nano-mel> as: node2 125.2 <http://134.86.62.95/scheduler/job/125.2> (127) No device assigned as node2. Job Info is displaying : 13*6** Submitted* *ssh* python-test-suite obokshe May28, 8:47a.m. — — 12*5** Scheduling* uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> python-test-suite obokshe May28, 8:47a.m. — — *124 Scheduling* nano-mel <http://134.86.62.95/scheduler/device/nano-mel> python-test-suite obokshe May28, 8:47a.m. — — Please find test definition used by me for lava-multinode test run at https://pastebin.com/Tdp7q6SF Thanks and Regards, Onkar

6 years, 6 months

Unable to run test on multiple devices using Lava-multi-node functionality

by Onkar Bokshe

6 years, 6 months

Test on Device which doesn't stop at bootloader

by Nikita Gupta

Hi Lava-Users, I have a device 'raspberry-pi' whose boot method doesn't stop at bootloader. I tried removing 'method' from boot-action but then it doesn't accept it as valid test job. Changing of method from u-boot to fastboot or to any other also gives error as not supported boot methods for this device. After device bring up, it gives u-boot interrupt timed-out and job gets incomplete. Is there any way thru which we can run tests on such devices? -- Regards, Nikita Gupta

6 years, 7 months

multiple devices job submission

by Hemanth K V

Hello Stevan, Thanks for quick response.Is there any reference of creating and assigning device tag to specific device. The issue I am facing is whatever device tags are created are getting default assigned to all devices. Thanks, Hemanth. ___________________________________________________________________________________________ Hi Hemanth, You can achieve this by adding device tags to the devices and then specifying which tags you'd like to use in the test job definition. Please take a look at https://validation.linaro.org/static/docs/v2/developing-tests.html#device-t… HTH, On 05/16/2018 12:26 PM, Hemanth K V wrote: >* Hello Lava-Users, *>>* When we have multiple devices of same device-type in LAVA Instance and *>* want to submit job on a particular device how can this be achieved in *>* LAVA.Tried to follow *>* https://validation.linaro.org/static/docs/v2/first-job.html <https://validation.linaro.org/static/docs/v2/first-job.html> but didn't *>* find how device can be specified. *>>* Thanks, *>* Hemanth. *>>>* _______________________________________________ *>* Lava-users mailing list *>* Lava-users at lists.linaro.org <https://lists.linaro.org/mailman/listinfo/lava-users> *>* https://lists.linaro.org/mailman/listinfo/lava-users <https://lists.linaro.org/mailman/listinfo/lava-users> *

6 years, 7 months

multiple devices job submission

by Hemanth K V

Hello Lava-Users, When we have multiple devices of same device-type in LAVA Instance and want to submit job on a particular device how can this be achieved in LAVA.Tried to follow https://validation.linaro.org/static/docs/v2/first-job.html but didn't find how device can be specified. Thanks, Hemanth.

6 years, 7 months

submit multinode tests via XML-RPC API

by steffen＠volkmann.com

Hi all, I am using the XML-RPC API to submit test jobs from a jenkins server to lava server. The used methode is described here: https://validation.linaro.org/api/help/#scheduler.jobs.submit In the case of multi node tests with first role is 'Server' and second role is "Client", the API returns a list of created job ID's (e.g. [500.0, 500.1]). How can I determine which ID is the 'Server' job and wich ID is the 'Client' job? Best Regards Steffen Volkmann

6 years, 7 months

support bootm and booti from a single device-type

by Kevin Hilman

I'd like a single device-type to list load addrs for booti, bootz, and bootm so it can support all three modes. That seems ok. Next, I'd like the device-dict (not the job parameters) to be able to decide which of those to use. For example, device-A and device-B share this same device-type. device-A runs mainline uboot and can use booti, but device-B runs a vendor uboot, which doesn't support booti, so it needs LAVA to convert the kernel "image" to a "uimage". But the job submitter is not (and should not be) aware which of the devices will be chosen, so the job submitter always submits a job with "kernel_type: image" (Yes, this is similar to the thread started by Corentin[1], but I'm trying to rephrase.) So, device-B needs to put the text_offset in its dict, possibly override some other vars for the vendor uboot (e.g. bootloader_prompt), and that all works swimmingly. However, the problem is that the decision to convert to uimage is made based on job paramaters (e.g. kernel_type == "uimage'[2]). But, that implies that the job *sender* needs to know whether the device to be selected supports booti or bootm, and that defeats the whole goal of LAVA hiding that. The job should just pass in an kernel with "type: image" and the device-dict is the one that should decide whether to convert to a uimage. IOW, is there a way for the device-dict to say "I know I recevied an image of kernel_type=image, but please convert to kernel_type=uimage." ? >From what I can tell by checking the code[2], if kernel_type = "image" and "booti" is in device_params (and it always will be because it's set in the device-type), then a uimage will never be created. For this to work, the device-dict for device-B has to *remove* the booti_*_addr set by the device-type. I suppose that's possible in jinja2, but that seems a bit ugly. I'm hoping there's a cleaner way for the device-dict to say "please force uimage conversion and use bootm. Thanks, Kevin [1] https://lists.linaro.org/pipermail/lava-users/2018-April/000994.html [2] https://github.com/Linaro/lava/blob/master/lava_dispatcher/actions/deploy/p…

6 years, 7 months

Git duplication in test jobs

by Denis HUMEAU

Hello Lava users, I'm coming back with an old question that I think is worth asking again. Here is an example of a test definition from Lava documentation: test: failure_retry: 3 timeout: minutes: 10 name: kvm-basic-singlenode definitions: - repository: git://git.linaro.org/lava-team/lava-functional-tests.git from: git path: lava-test-shell/smoke-tests-basic.yaml name: smoke-tests - repository: http://git.linaro.org/lava-team/lava-functional-tests.git from: git path: lava-test-shell/single-node/singlenode03.yaml name: singlenode-advanced revision: 441b61 In this example, 2 tests are defined, and they're contained in the same git repo. The test overlay will be built by Lava using this type of tree: Lava_session_number/test1/ Lava_session_number/test2/ In each test folder, a git clone will be performed and data will be duplicated. Nowadays, I understand that the trend is to test more in and embedded configurations, and less in nfs configurations. This is what we do for our product validation. Embedded storages are limited, therefore we need to carefully think about our git management: - First strategy: have a single git containing all the tests. In this case size of test overlay may increase dangerously - Second strategy: one git per test. This is not the spirit of a git, but you solve the size issue. The last time we asked the question, more than a year ago, there was no solution or workaround to prevent duplicating the same git in a Lava job. Has the situation changed? If not, I believe it would be great to have a mechanism to store gits no longer in the test folder itself, but in a common repository folder. I know this cannot be done in every case, for example you may have 2 tests on the same git but on a different branch, but this may be an optional feature trigger by a "shared" tag in the job definition. If shared is declared, links to the common repo would be created in the test overlay folder. For example: test: failure_retry: 3 timeout: minutes: 10 name: kvm-basic-singlenode definitions: - repository: git://git.linaro.org/lava-team/lava-functional-tests.git from: git shared: yes path: lava-test-shell/smoke-tests-basic.yaml name: smoke-tests - repository: http://git.linaro.org/lava-team/lava-functional-tests.git from: git shared: yes path: lava-test-shell/single-node/singlenode03.yaml name: singlenode-advanced What do you think? Am I the only one needing this, are you aware of a better solution? Best regards, Denis

6 years, 7 months

← Newer
1
...
6
7
8
9
10
11
12
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Lava-users