lava-users April 2016

lava-users@lists.lavasoftware.org

12 participants
8 discussions

by Leo Yan

Hi there, When I run LAVA hacking session on Juno but found sometimes Juno cannot be allocated IP properly: - I created multinode definition for Juno: https://validation.linaro.org/scheduler/job/845471.0: this definition is to launch kvm so I can run testing suits on it; https://validation.linaro.org/scheduler/job/845471.1: this definition is to launch "deploy_linaro_image" on Juno board; - After launched these two images, the kvm usually can work well and I can smoothly log in it with ssh; - But for juno board, it will have below log for ssh: 395.1 ./setup_session_oe: line 38: /etc/init.d/ssh: No such file or directory 395.2 <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=sshd-restart RESULT=fail> 395.3 sshd re-start failed 395.4 Target's Gateway: 10.0.0.1 395.5 ip: RTNETLINK answers: Network is unreachable 395.6 395.7 395.8 ********************************************************************************************* 395.9 Please connect to: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@ (juno-07) 395.10 ********************************************************************************************* 395.11 So finally I cannot get the info for Juno's IP and cannot log in it with ssh. It's not everytime I can reproduce this failure, so sometimes it's lucky so I can get a correct IP. - As a workaroud, I found if I create two saperated definitions for Juno and kvm independently, then Juno's IP issue can be resolved: https://validation.linaro.org/scheduler/job/845552 https://validation.linaro.org/scheduler/job/845561 So could you help give suggestions for this? Thanks, Leo Yan

8 years, 5 months

lava testing

by pradeepkumar

Hi, I have made a test setup with LAVA to run some test cases on my AM335X based platform. I want to execute some simple test cases like testing the status of "ifconfig eth0" command. I don't want to deploy any image and my goal is to execute only this test directly(target is booted with root file system mounted).I have the below job submitted to the lava worker. ethernet.yaml contains the shell script which actually performs the ifconfig test. ============================================================================================= { "actions": [ { "command": "dummy_deploy", "parameters": { "target_type": "oe" } }, { "command": "lava_test_shell", "parameters": { "testdef_repos": [ { "testdef": "/root/lava_tests/yaml/ethernet.yaml" } ], "timeout": 60 } }, { "command": "submit_results_on_host", "parameters": { "server": "http://10.24.252.13:81/RPC2/", "stream": "/anonymous/lavaserver/" } } ], "device_type": "ELIN", "health_check": false, "job_name": "elin-ethernet-test", "logging_level": "DEBUG", "timeout": 60 } ======================================================================================================= Lava dispatcher is able to connect to the target and start the job. But finally I am getting a timeout. Please find the attached log for details. I can see that after connecting with the target the dispatcher is checking/finding some information related to the file system, and looks like it is getting timed out there. How can I avoid this and make the dispatcher to directly perform the test on the target platform? Any help any help would be appreciated. Best Regards, Pradeepkumar Soman

8 years, 6 months

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…

8 years, 6 months

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

8 years, 6 months

[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

8 years, 6 months

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

8 years, 6 months

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

8 years, 6 months

[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

8 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users April 2016