lava-users

lava-users@lists.lavasoftware.org

1 participants
930 discussions

lava-wait-all in 2016.11

by James Oakley

I have a multi-node test involving 13 roles that is no longer syncing properly after upgrading to 2016.11 this morning. It seems that 2 or 3 nodes end up waiting for a specific message while the other ones finish the message and move on to the next. Looking at the dispatcher log, I don't see any errors, but it's only logging that it's sending to some of the nodes. For example, I see a message like this for the nodes that work in a run: 2016-11-10 13:10:37,295 Sending wait messageID 'qa-network-info' to /var/lib/lava/dispatcher/slave/tmp/7615/device.yaml in group 2651c0a0-811f-4b77-bc07-22af31744fe5: {"/var/lib/lava/dispatcher/slave/tmp/7619/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7613/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7623/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tm p/7620/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7611/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7621/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7622/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7617/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7618/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7614/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7615/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7616/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7612/device.yaml": {}} 2016-11-10 13:10:37,295 Sending wait response to /var/lib/lava/dispatcher/slave/tmp/7615/device.yaml in group 2651c0a0-811f-4b77-bc07-22af31744fe5: {"message": {"/var/lib/lava/dispatcher/slave/tmp/7619/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7613/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7623/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7620/ device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7611/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7621/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7622/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7617/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7618/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7614/device.yaml": {}, "/var/l ib/lava/dispatcher/slave/tmp/7615/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7616/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7612/device.yaml": {}}, "response": "ack"} For the nodes that get stuck, there is no message like above. All of the nodes are qemu type, all on the same host. The nodes that fail are not consistent, but there seems to be always 2 or 3 that fail in every run I tried. Is there anything I can look at here to figure out what is happening? -- James Oakley james.oakley(a)multapplied.net

8 years, 9 months

Re: [Lava-users] Change in lava/lava-dispatcher[master]: Add support for the depthcharge bootloader

by Tomeu Vizoso

[Moving to lava-users as suggested by Neil] On 11/07/2016 03:20 PM, Neil Williams (Code Review) wrote: > Neil Williams has posted comments on this change. > > Change subject: Add support for the depthcharge bootloader > ...................................................................... > > > > Patch Set 3: > > (1 comment) > > https://review.linaro.org/#/c/15203/3/lava_dispatcher/pipeline/actions/depl… > > File lava_dispatcher/pipeline/actions/deploy/tftp.py: > > Line 127: def _ensure_device_dir(self, device_dir): >> Cannot say that I have fully understood it yet. Would it be correct >> if the > > The Strategy classes must not set or modify anything. The accepts > method does some very fast checks and returns True or False. Anything > which the pipeline actions need to know must be specified in the job > submission or the device configuration. So either this is restricted > to specific device-types (so a setting goes into the template) or it > has to be set for every job using this method (for situations where > the support can be used or not used on the same hardware for > different jobs). > > What is this per-device directory anyway and how is it meant to work > with tftpd-hpa which does not support configuration modification > without restarting itself? Jobs cannot require that daemons restart - > other jobs could easily be using that daemon at the same time. So each firmware image containing Depthcharge will also contain hardcoded values for the IP of the TFTP server, and for the paths of a cmdline.txt file and a FIT image. The FIT image containing a kernel and a DTB file, and optionally a ramdisk. Because the paths are set when the FW image is flashed, we cannot use the per-job directory. Thus we add a parameter to the device that is to be set in the device-specific template of Chrome devices. If that parameter is present, then a directory in the root of the TFTP files tree will be created with the value of that parameter. The TFTP server doesn't need to be restarted because its configuration is left unchanged, we just create a directory where depthcharge will look for the files. Thanks, Tomeu > I think this needs to move from IRC and gerrit to a thread on the > lava-users mailing list where the principles can be checked through > more easily. > >

8 years, 9 months

correct way to do ci with lava?

by alfonso

Hi everyone, As I have probably mentioned in previous emails, Im using the yocto project to generate some linux images that I want to test using lava as part of the continuous integration development. So far so good, i can submit the job description to lava using lava-tool and it will start the tests. I'm happy so far with all the results. Now my question is to ask you what would be the correct way do this procedure. Do you think it is reasonable to have a lava-tool submit-job followed by a waiting step using lava-tool job-status to report the final build result? or there is a nicer way to do this? Thanks a lot for your help in advance :) Best, Alfonso

8 years, 10 months

[PATCH] device-types: add TI da850-lcdk

by Kevin Hilman

Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- .../lava-dispatcher/device-types/da850-lcdk.conf | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf new file mode 100644 index 000000000000..dd10b0da0f80 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf @@ -0,0 +1,45 @@ +client_type = bootloader + +bootloader_prompt = U-Boot +send_char = False + +uimage_only = True +uimage_xip = True +append_dtb = True +# don't add u-boot header to ramdisk +ramdisk_raw = True + +u_load_addrs = + 0xc1000000 + 0xc2000000 + 0xc1f00000 + +z_load_addrs = + 0xc1000000 + 0xc2000000 + 0xc1f00000 + +boot_cmds_ramdisk = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv bootargs "'console=ttyS2,115200n8'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; setenv bootargs ${bootargs} initrd=${initrd_addr_r},0x${initrd_size}; printenv bootargs; bootm ${kernel_addr_r}'", + boot + +boot_cmds_nfs = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv bootargs "'console=ttyS2,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; printenv bootargs; bootm ${kernel_addr_r}'", + boot + +boot_options = + boot_cmds + +[boot_cmds] +default = boot_cmds_ramdisk -- 2.5.0

8 years, 10 months

[PATCH] bootloader: add ramdisk_raw option

by Kevin Hilman

By default, a uboot header is automatically added to the ramdisk image. For bootloaders without INITRD_ATAG support, the ramdisk needs to be passed on the command line and cannot have the uboot header added. To enable this feature, add a "ramdisk_raw" option that device files can set so that a uboot header is not added. Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- Patch applies on 2016.9 lava_dispatcher/config.py | 1 + lava_dispatcher/device/bootloader.py | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/lava_dispatcher/config.py b/lava_dispatcher/config.py index 66a9e70021fa..c91c5634280d 100644 --- a/lava_dispatcher/config.py +++ b/lava_dispatcher/config.py @@ -312,6 +312,7 @@ class DeviceSchema(schema.Schema): uimage_xip = schema.BoolOption(default=False) append_dtb = schema.BoolOption(default=False) prepend_blob = schema.StringOption(default=None) + ramdisk_raw = schema.BoolOption(default=False) # for dynamic_vm devices dynamic_vm_backend_device_type = schema.StringOption(default='kvm') diff --git a/lava_dispatcher/device/bootloader.py b/lava_dispatcher/device/bootloader.py index 634d22ef3311..c88fba8937e6 100644 --- a/lava_dispatcher/device/bootloader.py +++ b/lava_dispatcher/device/bootloader.py @@ -208,7 +208,7 @@ class BootloaderTarget(MasterImageTarget): decompress=False) extract_overlay(overlay, ramdisk_dir) ramdisk = create_ramdisk(ramdisk_dir, self._tmpdir) - if self._is_uboot(): + if self._is_uboot() and not self.config.ramdisk_raw: # Ensure ramdisk has u-boot header if not self._is_uboot_ramdisk(ramdisk): ramdisk_uboot = ramdisk + ".uboot" -- 2.5.0

8 years, 10 months

Help: job email notification log and deivce state change command

by kingboli

Hello everyone, Can you help me on below two questions? 1. I did email notification settings for sending emails after job complete or incomplete. How can I get whole logs (where are logs?) about email sending process? I need to debug email sending. 2. I want to use script to control device state periodically. How can I set device to maintenance state using command, like lava-tool command? Thanks in advance.

8 years, 10 months

lava-dispatcher and lava-tool

by alfonso

Hello everyone, just a simple question. I might be wrong but I understand that submitting a job through lava-dispatch and lava-tool should lead to the same process. Now, with the dispacher you can already specify an specific target device encoded in yaml format. Does the lava-tool at some point reach a similar target configuration? does it generate it or it is stored somewhere? in the latter case, where is it stored? thanks in advance :) Best, Alfonso

8 years, 10 months

test zipped qemu image

by alfonso

Hello everyone, just a quick question. I am trying to run a job to test a qemu image which is stored remotely. The image is packed in a tar.xz file with both the kernel and the file system. is there a way to specify in the job description json file that before the deploy action it must open this tar.xz file and then use the kernel and filesystem? Thanks a lot :) Best, Alfonso

8 years, 10 months

Installing on Ubuntu 16.04

by Alfonso Ros Dos Santos

Hello guys, I am currently trying to install the lava-server/dispatcher on my local pc with Ubuntu 16.04. Unfortunately, I had little success installing the source projects from github.com/linaro. I just wanted to ask if you could recommend me what would be the best approach for me. Thanks for your help. Best regards, Alfonso

8 years, 11 months

matching results to requested tests

by Milosz Wasilewski

Hi, I'm trying to get the proper relationship between requested tests and results in LAVA v2. Here is example job: https://validation.linaro.org/scheduler/job/1109234 and results for this job: https://validation.linaro.org/results/1109234 How can I tell: - which result matches which test? - if there are multiple occurrences of the same test with different parameters, how to recognize the results? In LAVA v1 the matching was a very arduous process. One had to download the job definition, look for lava-test-shell actions, pull the test definition yaml sources and match yaml ID and to ID found in result bundle. How does this work in v2? milosz

8 years, 11 months

← Newer
1
...
86
87
88
89
90
91
92
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users