lava-users

lava-users@lists.lavasoftware.org

2 participants
945 discussions

Request for new XML RPC endpoints to add remote control for devices

by Quentin Schulz

Hi all, We are using LAVA to run jobs from KernelCI which is a test automation system used to test latest versions of the kernel (upstream, next, stable, ...). Our main goal is to put in our lab a maximum of boards which are not yet in KernelCI to provide boot reports for these boards. However, for some of these, we own a single copy while we definitely need to work on them to add new features or improve them. What we could do (and what we are currently doing), is to manually put a board in maintenance mode, take it physically outside of the lab, work on it and put it back in the lab when we have finished working on it. This is not really efficient and during the time the board is physically outside of the lab, not a single job (from KernelCI or ours) can run. We would like to create a tool to be able to remotely control our boards while they still are physically in the lab. We need to be able to do everything we could do if the board would be on our desk. This means getting the serial connection, powering on or off the board and sending files (kernel, DTB, initramfs, ...) to it. For the latter, we just have to copy the files in the directory used by the TFTP server of LAVA master node. I would like to know if it is possible to add an endpoint in the API to power on or off a given board? Is it possible to get the serial connection over the API? To put a board virtually outside of the lab, we need to put it into maintenance mode in LAVA. As of yet, this is only possible from the browser, right? It would be great if we could add two endpoints to the API: one for putting a board offline and one for putting a board online, so we can remotely manage from our program whether a board is in the lab. We may have few people working on the same board. Therefore, we need a way to ensure only one person is able to use this board at a certain time. I've seen the "created_by" attribute in the DeviceStateTransition[1] which could help us to find who last put the board virtually outside of the lab and thus denying access to other users. However, we do not have a way to get this information today via the API. Is it possible to add an endpoint to get the status of a given device (like in 'all_devices'[2] but for one device) and the associated user responsible of the last device state transition? I can help with patches if you agree to add these endpoints to the API. Thanks, Quentin [1] https://github.com/Linaro/lava-server/blob/release/lava_scheduler_app/model… [2] https://github.com/Linaro/lava-server/blob/release/lava_scheduler_app/api.p…

10 years

Re: [Lava-users] [RFC] utils (http_proxy): fix url string search in url list

by Matt Hart

The Cambridge LAVA Lab has a transparent squid proxy which saves having to configure each dispatcher and device to use it. Outgoing HTTP traffic from the lab has no choice as it is intercepted at the internet gateway. We did this because even after configuring the dispatcher, and devices, it's almost impossible to make all test shell tasks use the proxy. LAVA sets a shell environment inside a job but many of the clients in the various different types of job simply ignore it. Chasing every test writer was not feasible as the lab usage is so large, but might be ok in a smaller lab with tighter control of the jobs. We don't proxy HTTPS requests because that's becomes very complicated with faking certificates etc >>Marc Titinger <mtitinger at baylibre.com> writes: >> >> I had to make this change to get squid3 going with our LAVA 1.0 machine. >> I thought this could be useful. I did not test extensively though. > >FWIW, I had problems getting lava-dispatcher to use my local squid proxy >also. Seems setting LAVA_PROXY in lava-dispatcher.conf was working for >the the devices (lava set the environment variable after booting the >target), but lava-dispatcher itself was not using the proxy. > >I'll give this a try as well. > >Kevin

10 years

[RFC] utils (http_proxy): fix url string search in url list

by Marc Titinger

From: Marc Titinger <mtitinger(a)baylibre.com> search_substr_from_array would return a false positive in lava_dispatcher/downloader.py when trying to match 'no_proxy' exclusion list with the download object url. This now uses a (too?) simple substring matching rather than a greedy regex. Signed-off-by: Marc Titinger <mtitinger(a)baylibre.com> --- lava_dispatcher/utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lava_dispatcher/utils.py b/lava_dispatcher/utils.py index f2fd79a..037f6b5 100644 --- a/lava_dispatcher/utils.py +++ b/lava_dispatcher/utils.py @@ -640,7 +640,7 @@ def search_substr_from_array(string, array, sep=','): Strings in array are separated by default with ',' """ for obj in array.split(sep): - if re.search('.*' + str(obj) + '.*', str(string)): + if str(obj).find(string) is not -1: return True return False -- 2.5.0

10 years

About the cursor movement in the device config file.

by Elaine Wu (wuyanjun)

hi, all, I am using the new uefi, it use the cursor movement and the Enter to enter the entry. So I use the config file to write it, but I found it can not work well. the config is below. boot_cmds_ramdisk_sata = expect "Move Highlight", sendline "\033[B", sendline "\033[B", sendcontrol "M", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendcontrol "M", expect "D02", sendline "provision {SERVER_IP} -u htsat -p hello8943217 -f Image_D02 -a 10000", expect "succ" , sendline "norwfmem 100000 100000 1f00000", expect "OK", sendline "provision {SERVER_IP} -u htsat -p hello8943217 -f hip05-d02.dtb -a 100000", expect "succ", sendline "spiwfmem 100000 300000 100000", expect "OK", expect "OK", sendline "exit", expect "Select Language", sendline "\033[B", sendline "\033[B", sendcontrol "M", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendline "\033[B", sendcontrol "M" After I read the source code of LAVA. I found it use the pexpect.spawn to interact with the terminal, So I directly writte a python file to directly use spawn to interact with the terminal, and it can work well . The source code is below. import sys from pexpect import spawn child = spawn("board_connect 2") # this is similar with minicom logfile = "/tmp/test_for_terminal.log" fd = open(logfile, 'a+') child.logfile = fd child.expect("to stop automatical booting", timeout=120) child.sendline("b") child.expect("Move Highlight") ## boot from sata child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.expect("D02") child.sendline("provision 192.168.6.100 -u htsat -p hello8943217 -f Image_D02 -a 10000") child.expect("succ") child.sendline("norwfmem 100000 100000 1f00000") child.expect("OK") child.sendline("provision 192.168.6.100 -u htsat -p hello8943217 -f hip05-d02.dtb -a 100000") child.expect("succ") child.sendline("spiwfmem 100000 300000 100000") child.expect("OK") child.expect("OK") #child.interact() child.sendline("exit") child.expect("Select Language") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendline("\033[B") child.sendcontrol("M") child.interact() So I don't know why in LAVA it can not work. Also I have realized a function named /sendcursor /similar with the sendcontrol in the lava_dispatcher package especially in the /usr/lib/python2.7/dist-package/lava_dispatcher/utils.py, and it call the pexpect.spawn.sendline to send contents to the child process. But it still have the same phenomenon with using sendline(namely won't select the entry in the uefi menu). Does this problem is caused by the dashboard showing? The attached files are the log files when I use the python file to execute the interaction and the one when LAVA execute it. Thanks for your help. Elaine Hisilicon turing software and architecture

10 years

Configuration file for new devices

by Quentin Schulz

Hi, We are building a LAVA lab which will be soon integrated to KernelCI. We want to add most of our boards to LAVA that's why we created configuration files for the old dispatcher (the one used by KernelCI at this moment) for all device types we own. I would like to know if you were interested in getting those configuration files to put them in your git repository (we are using some from: https://github.com/Linaro/lava-dispatcher/tree/release/lava_dispatcher/defa… If yes, what is your naming convention? I've seen sama53d for the SAMA5D3 Xplained for example. This is the list of boards currently added to our lab: Board name Current configuration file's name NextThingCo. CHIP sun5i-r8-chip Boundary Devices Nitrogen6x imx6q-nitrogen6x ATMEL at91rm9200ek at91rm9200ek ATMEL at91sam9261ek at91sam9261ek ATMEL at91sam9m10g45ek at91sam9m10g45ek ATMEL at91sam9x25ek at91sam9x25ek ATMEL at91sam9x35ek at91sam9x35ek ATMEL sama5d31ek sama5d31ek ATMEL sama5d36ek sama5d36ek ATMEL sama5d44ek sama5d4ek Marvell Armada 385 AP armada-385-db-ap Solidrun Clearfog armada-388-clearfog Plathome OpenBlocks AX3 armada-xp-openblocks-ax3-4 Regards, Quentin

10 years

[PATCH] device-types: add meson8b-odroidc1.conf default

by Marc Titinger

From: Marc Titinger <mtitinger(a)baylibre.com> - specific u-boot prompt - specific C-c interrupt char - uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz) Signed-off-by: Marc Titinger <mtitinger(a)baylibre.com> --- .../device-types/meson8b-odroidc1.conf | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf new file mode 100644 index 0000000..96232b4 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf @@ -0,0 +1,44 @@ +client_type = bootloader +send_char = False +uimage_only = True +append_dtb = True + +u_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +z_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +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=ttyAML0,115200n8 root=/dev/ram0 ip=dhcp'", + setenv bootcmd "'dhcp; dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; {BOOTX}'", + run bootcmd + +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 loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv nfsargs "'setenv bootargs console=ttyAML0,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; run nfsargs; {BOOTX}'", + run bootcmd + +bootloader_prompt = odroidc# +interrupt_boot_prompt = key to stop autoboot +interrupt_boot_control_character = c + +boot_options = + boot_cmds + +[boot_cmds] +default = boot_cmds -- 2.5.0

10 years

lava job strucked when execute the config file.

by Wu Yanjun (Elaine)

hi, I have two questions to ask: 1. I am using the lava to boot the D02 board, it can successfully execute before. But it failed after I update the uefi and rewrite the config file. But when I execute the config file manually, it succeed booting the board. And I can figure out what is wrong. The version of LAVA I used is 2015.9.post1, and I use LAVA v1. From the figure, we can see it is strucked when booting the kernel. then The log file of the lava job, the log of boot manually and the config file has been attached. 2. The uefi is used need to control by cursor movement, so I need to send KEY-DOWN in the d02.conf file. But when I use 'sendline "\033[A"' or ‘sendline "\16[A"', I found it can not work in the LAVA. So I want to know if we have any method to realize it? Thank you very much. -- Best Wishes wuyanjun (Elaine) Hisilicon Turing Software and Architecture

10 years

the board uefi use dialog to boot, how can I configuare the lava device-type config file.

by Elaine Wu (wuyanjun)

hi, all, The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu. As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi? The menu of the uefi is below. and Thank you very much. Elaine (wuyanjun) Hisilicon, Turing Architecture and Software

10 years

adding per-action comment or brief description or meta-data into the bundle

by Marc Titinger

Hi Neil and all, how do I add per-action comments or meta data so that I can parse them from the result bundle: the following for instance will pass the schema validation, but the result bundle will degenerate into keeping only the last "comment" metadata entry, while I'd like a per-action metadata entry. { "command": "lava_command_run", "metadata": { "comment": "comment1" }, "parameters": { "commands": [ "uname -a" ] } }, { "command": "lava_command_run", "metadata": { "comment": "comment2" }, "parameters": { "commands": [ "ls -al" ] } }, The result bundle will contain the same metadata for each lava-command: "attributes": { "comment": "comment2", <=== same value "image.type": "kernel-ci", .... snip ... "logging_level": "DEBUG", "device.tree": "omap4-panda-es.dtb" }, "test_id": "lava-command" IOW, how do I assign a brief description to an action ? Thanks and regards, Marc.

10 years

Reviews

by Neil Williams

https://review.linaro.org/#/c/10593/ and https://review.linaro.org/#/c/10595/ have some comments which need to be addressed. The simplest way is to register for a Linaro Community account and then you can login to gerrit yourself. Alternatively, the comments can be addressed by email and the reviews updated. https://ci.linaro.org/job/lava-dispatcher/836/console -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

10 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users