lava-users

lava-users@lists.lavasoftware.org

2 participants
936 discussions

Cannot click to see job results if request is running.

by cnspring2002

Hi, with lava2019.09 will has next issue, seems ok in 2019.01:if request is running, click something like next:http://lava_ip/results/171It will show:500 Internal Server Errorlist index out of range Oops, something has gone wrong! But if the request finish, the link ok again.

6 years, 1 month

Run LTP from LAVA

by Ilya Fedusiv

Hello! I run ltp test on my device. And now ltp's output goes in one test log output. Is it possible to separate output of ltp testcases? To show fail or pass on each test? Ilya.

6 years, 1 month

VTS and CTS timeout in Lava because of the maximum timeout of 60 min

by George Nistor

Hi, I have a Lava job which runs VTS and CTS and Lava gives me time out because the maximum timeout I could set was 60 min. How do I set no-Timeout for my test? Is it possible? george

6 years, 1 month

Re: [Lava-users] Lavacli jobs list usage

by Remi Duraffort

Perfect then. Thanks Le mer. 23 oct. 2019 à 09:42, Philippe BEGNIC <philippe.begnic(a)st.com> a écrit : > Hello Remi, > > The "start" parameters allows me to slice the windows by packets of 100 > jobs. This is OK for my usage. > > Thanks for your support > > Philippe Begnic > On 10/22/19 5:32 PM, Remi Duraffort wrote: > > Hello, > > this is the lava server that limit the number of jobs that will be > returned. But the api allows to iterate by setting the "start" parameter. > See https://validation.linaro.org/api/help/#scheduler.jobs.list > > > Rgds > > Le mar. 22 oct. 2019 à 16:17, Philippe BEGNIC <philippe.begnic(a)st.com> a > écrit : > >> Hello everyone, >> >> I am using Lavacli to calculate basic statistics on the daily jobs >> executed with LAVA. (Nbr of complete//incomplete//canceled jobs). >> I also display the failure reason of the incomplete and canceled jobs by >> parsing the jobs logs. >> I can only do this operation for a limited number of jobs, because it >> seems that Lavacli has a restriction on the number of jobs to be treated. >> (100 jobs) >> >> Here the command lines I am using : >> > lavacli jobs list --health INCOMPLETE --limit 200 >> >> To count the number of computed jobs: >> > lavacli jobs list --health INCOMPLETE --limit 200 |wc -l >> > 101 >> >> So, I have requested 200 jobs, and Lavacli has treated only 100 jobs ( >> Note that our jobs database contains more than 200 jobs incomplete) >> >> Is it possible to remove or to increase the limitation on the number of >> jobs to be treated ? >> >> >> Best regards >> >> >> Philippe Begnic >> STMicroelectronics | MDG Group – MCD Division >> >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users(a)lists.lavasoftware.org >> https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > -- > Rémi Duraffort > LAVA Architect > Linaro > > -- Rémi Duraffort LAVA Architect Linaro

6 years, 1 month

overlay-unpack timeout error

by Philippe BEGNIC

Hello everyone, I have got an error in a lava job during to overlay unpacking operations. This happen with jobs that flash the DUT before executing the tests. When the partitions are flashed on the DUT, I reboot the boards. After kernel has started, the kernel boot prompt is detected. Then the commands to downloads the tests overlay are launched. ( wget ... ) But in my case, these commands are not immediately executed, because the DUT is beeing resizing the root filesystem to fit available disk space on the SDCard. This operation take time ( depending on capacity and characteristics of the SDCard), and cause overlay-unpack<https://citools.st.com/results/testcase/2039053> to fail with a timeout error, because the command wget is not executed in the expected time ( 30 sec is the default time ). I have tried to add a time out settings in the transfer_overlay part of my jobs, but this has no effect. Is it possible to set specific "timeout trigger" for the "overlay-unpack" operation ? My Lava version: 2019.01+stretch Best regards Philippe Begnic STMicroelectronics

6 years, 1 month

Re: [Lava-users] Unexpected crash. (Remi Duraffort)

by cnspring2002

Hi, Remi, You said: > lava-master is receiving an invalid zmq message. I guess you are not using encryption? Are you fuzzing it? Sorry, I did not catch you. What does fuzzing it mean? I did not do anything special for LAVA. Meanwhile, what does "not using encryption" mean? Is this a LAVA master configure item or something else? I did not change anything related to this. And as I said, it could work ok for some a period, then I leave the whole environment there, no touch for anything. Then severial days later, it may encountered the issue. BTW, even such things happen, why no a exception handing in LAVA to ignore such issue? Currently it just close the zeromq connection. ------------------------------------------------------------------ Sender:lava-users-request <lava-users-request(a)lists.lavasoftware.org> Sent At:2019 Oct. 15 (Tue.) 00:25 Recipient:lava-users <lava-users(a)lists.lavasoftware.org> Subject:Lava-users Digest, Vol 14, Issue 10 Send Lava-users mailing list submissions to lava-users(a)lists.lavasoftware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.lavasoftware.org/mailman/listinfo/lava-users or, via email, send a message with subject or body 'help' to lava-users-request(a)lists.lavasoftware.org You can reach the person managing the list at lava-users-owner(a)lists.lavasoftware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..." Today's Topics: 1. Re: lava job without any flashing on a real device (George Nistor) 2. Re: Unexpected crash. (Remi Duraffort) 3. Re: repeat in lava not work (Diego Russo) ---------------------------------------------------------------------- Message: 1 Date: Mon, 14 Oct 2019 13:17:55 +0000 From: George Nistor <george.n(a)l4b-software.com> To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: Re: [Lava-users] lava job without any flashing on a real device Message-ID: <VI1PR01MB38711749B69B27E8410ABB41F0900(a)VI1PR01MB3871.eurprd01.prod.exchangelabs.com> Content-Type: text/plain; charset="utf-8" Yes, In my case the only way I could make lava to see the fastboot device was via running pre-power-command, and I run a script (I customized device descriptor to run a this script as pre-power-command) which does: 1. Power Off Wait 5s 2.Power On Wait 30s 3. Login as root Wait 5s 4. echo reboot bootloader. # make it go in fastboot mode Immediately after this script runs, the udev rule is triggered and device id added (seen from Lava). Otherwise the reboot does not work for me. The line: nice lxc-attach -n lxc-hikey-test-186 -- fastboot -s xxxxxxx reboot gives timeout. Because the device is not seen. To make the job work without any flashing I removed the - deploy section which does flashing entirely For my case: I have added to boot this section protocols: lava-lxc: - action: fastboot-boot request: pre-power-command timeout: minutes: 5 george The full job I cannot post due to company policy with confidentiality on projects. -----Original Message----- From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> Sent: luni, 14 octombrie 2019 15:58 To: George Nistor <george.n(a)l4b-software.com> Subject: Re: lava job without any flashing on a real device Could you send the question to ML? I don't know why adb is not enough. Maybe LAVA waits for udev event? milosz On Mon, 14 Oct 2019 at 13:51, George Nistor <george.n(a)l4b-software.com> wrote: > > I have managed after all to do it with a job like this: > My problem was to be able to run pre-power-command before boot, to make lava to see the fastboot device - trigger that python script lxc-device-add. > > > -----Original Message----- > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> > Sent: Monday, October 14, 2019 15:02 > To: George Nistor <george.n(a)l4b-software.com> > Subject: Re: lava job without any flashing on a real device > > There was a feature called 'dummy deploy' but I can't find it any more. Did you try simply removing 'deploy' action? This should do the trick but you will need transfer_overlay in your boot section. > > milosz > > On Mon, 14 Oct 2019 at 12:33, George Nistor <george.n(a)l4b-software.com> wrote: > > > > Hi Milosz, > > > > > > > > I have a small question: > > > > Is it possible to run a lava job without any deploy – flashing sequence on a real device? > > > > > > > > I attach the job I’m working on. > > > > > > > > george ------------------------------ Message: 2 Date: Mon, 14 Oct 2019 15:34:24 +0200 From: Remi Duraffort <remi.duraffort(a)linaro.org> To: cnspring2002 <cnspring2002(a)aliyun.com> Cc: lava-users <lava-users(a)lists.lavasoftware.org> Subject: Re: [Lava-users] Unexpected crash. Message-ID: <CANJfhHchH1UZOy=ScC5CUnPkZ55yi3QXrNPqqjk6wSJBFZbrzg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, lava-master is receiving an invalid zmq message. I guess you are not using encryption? Are you fuzzing it? Le lun. 14 oct. 2019 à 11:18, cnspring2002 <cnspring2002(a)aliyun.com> a écrit : > Hi, Sometimes, lava master will show next error, then seems zemomq crash, > do you know what's the potential cause? > > 2019-08-20 09:14:39,576 DEBUG lava-worker-1 => PING(20) > 2019-08-20 09:14:39,578 DEBUG lava-worker-2 => PING(20) > 2019-08-20 09:14:39,580 DEBUG lava-worker-3 => PING(20) > 2019-08-20 09:14:44,467 ERROR [CLOSE] Unknown exception raised, leaving! > > 2019-08-20 09:14:44,467 ERROR 'utf-8' codec can't decode byte 0xc0 in position 10: invalid start byte > Traceback (most recent call last): > > File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 687, in handle > self.main_loop(options) > > File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 731, in main_loop > while self.controler_socket(): # Unqueue all pending messages > > File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 234, in controler_socket > hostname = u(msg[0]) > > File "/usr/lib/python3/dist-packages/zmq/utils/strtypes.py", line 34, in cast_unicode > return s.decode(encoding, errors) > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 10: invalid start byte > > 2019-08-20 09:14:44,467 INFO [CLOSE] Closing the controler socket and dropping messages > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users -- Rémi Duraffort LAVA Tech Lead Linaro

6 years, 1 month

VTS does not start because of the adb

by George Nistor

I am still having this problem inside the lxc container with 'adb start-server' failed. Should I define something special in the jinja2 device descriptor regarding adb or in the job to be able to use it? george -----Original Message----- From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> Sent: Wednesday, October 16, 2019 12:59 To: George Nistor <george.n(a)l4b-software.com> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] VTS does not start because of the adb George, I understand what the LAVA job is doing. I'm asking you to check whether there is _any_ adb server running on the host? If there is, the server you're running in a container will not be able to connect to the device. milosz On Wed, 16 Oct 2019 at 08:46, George Nistor <george.n(a)l4b-software.com> wrote: > > Hi Lava users, > > My adb is not running on the host but in the lxc container lava creates at runtime. > I have tried to put also an: adb kill-server command before starting vts but I got the same error. > > The lava log looks like this: > <LAVA_SIGNAL_STARTRUN 0_device-helpers 219_1.8.4.1> > + cd /home/android-vts/tools > + adb kill-server > Received signal: <STARTRUN> 0_device-helpers 219_1.8.4.1 Starting test > lava.0_device-helpers (219_1.8.4.1) Skipping test definition patterns. > * server not running * > + ./vts-tradefed > Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644) Use > \"help\" or \"help all\" to get more information on running commands. > 10-16 07:30:15 E/adb: ADB server didn't ACK > 10-16 07:30:15 E/ddms: 'adb start-server' failed -- run manually if > necessary > 10-16 07:30:15 E/adb: * failed to start daemon * > 10-16 07:30:15 E/adb: error: cannot connect to daemon > [udev_trigger-lxc-hikey-test-219-07:30:23] device /dev/bus/usb/001/008 > added > > george > > > -----Original Message----- > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> > Sent: Tuesday, October 15, 2019 17:11 > To: George Nistor <george.n(a)l4b-software.com> > Cc: lava-users(a)lists.lavasoftware.org > Subject: Re: [Lava-users] VTS does not start because of the adb > > Do you have adb server running on the host? If so, please kill it and > try again. As with LoTR - there is only one adb server to rule them > all :) > > milosz > > On Tue, 15 Oct 2019 at 15:01, George Nistor <george.n(a)l4b-software.com> wrote: > > > > Hello Lava users, > > > > > > > > Thanks to Tim Jaaks for previous problem I reported. I managed to configure default external shared folder for the lava lxc container. > > > > > > > > However, > > > > I try to run VTS from Lava but after displaying initial string with VTS I get an error saying adb server could not start. I have tried restart, no success. The adb seems to be installed in the container. > > > > Does anyone know how to solve this error? > > > > > > > > + ./vts-tradefed > > > > Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644) > > > > Use \"help\" or \"help all\" to get more information on running commands. > > > > 10-15 13:45:22 E/adb: ADB server didn't ACK > > > > 10-15 13:45:22 E/ddms: 'adb start-server' failed -- run manually if > > necessary > > > > 10-15 13:45:22 E/adb: * failed to start daemon * > > > > 10-15 13:45:22 E/adb: error: cannot connect to daemon > > > > [udev_trigger-lxc-hikey-test-214-13:45:29] device > > /dev/bus/usb/001/005 added > > > > > > > > > > > > > > > > The adb is put in tlcx deploy > > > > > > > > actions: > > > > - deploy: > > > > namespace: tlxc > > > > timeout: > > > > minutes: 5 > > > > to: lxc > > > > packages: > > > > - adb > > > > - fastboot > > > > - wget > > > > - unzip > > > > - default-jre > > > > os: debian > > > > > > > > > > > > george > > > > _______________________________________________ > > Lava-users mailing list > > Lava-users(a)lists.lavasoftware.org > > https://lists.lavasoftware.org/mailman/listinfo/lava-users > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users

6 years, 1 month

any vland users out there?

by Milosz Wasilewski

Hi, Today I started looking at our LAVA testing setup and discovered that vland has been stopped for the last 7 months. Since no one complained I assume it's either working flawlessly in production environments or it's not needed. If there are any vland users, please reply to this message so I know that fixing our testing setup is not a waste of time. milosz

6 years, 1 month

lxc container rootfs not found

by Fedusiv Ilya

Hello, LAVA Team! I tried to run test on lxc, but get error message: Lxc container rootfs not found Inline: Job description: https://pastebin.com/5ibuzqD9 Errors log: https://pastebin.com/6X8c548r Git: Job description https://pastebin.com/iffydGYc Error log: https://pastebin.com/62pXctFd Ilya

6 years, 1 month

Potential issue with multiple uarts

by Nick Schutt

Hi, I have a board with 4 uarts connected to a lava worker via ser2net. LAVA is giving me some strange results when I try to use two uarts (uart0 and uart2) in the same testcase. The results are not consistent. Sometimes it works, but most of the time it gives an error: KeyError: 'uart2' At the end of the job, LAVA prints: LAVABug: This is probably a bug in LAVA, please report it.error_type: Bug error_msg: 'uart2' case: job result: fail definition: lava <http://lava-master.sw.nxp.com/results/testcase/16283386> ---- The connection parts of the device definition are: % set connection_list = ['uart0', 'uart1', 'uart2', 'uart3'] %} {% set connection_tags = {'uart0': ['primary', 'telnet']} %} {% set connection_commands = {'uart0': 'telnet localhost 7001', 'uart1': 'telnet localhost 7002', 'uart2': 'telnet localhost 7003', 'uart3': 'telnet localhost 7004'} %} The job uses two boots; one primary to boot non-POSIX to uboot, then it switches to 'uart2' to access another processor. The job seems to work fine if I define only two uarts: % set connection_list = ['uart0', 'uart1'] %} {% set connection_tags = {'uart0': ['primary', 'telnet']} %} {% set connection_commands = {'uart0': 'telnet localhost 7001', 'uart1': 'telnet localhost 7003 } %} Thank you, Nick

6 years, 1 month

← Newer
1
...
35
36
37
38
39
40
41
...
94
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users