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
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
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
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
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
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
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
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
actions:
- repeat:
count: 2
I just add above in job, and web submit validator told me:
Job submission error: extra keys not allowed @ data['actions'][1]['repeat']
Does it still work now?
