Hello,
while searching for possibilities of testing external interfaces of my DUTs I found this presentation:
https://wiki.linaro.org/Internal/lava/Lava-lmp?action=AttachFile&do=get&tar…
Is the LAVA LMP project still active? If yes, how can I find information on this?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com<http://www.garz-fricke.com/>
WE MAKE IT YOURS!
[cid:image001.jpg@01D4B71E.962E36E0]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
I'm sorry, as surely this is an FAQ but I've spent quite a bit of time
troubleshooting and reading. This is very similar to Kevin's thread from
May subject 'u-boot devices broken after 2018.4 upgrade, strange u-boot
interaction'. In that thread's case, the issue was that interrupt_char
was being set to "\n". My symptoms are the same, but interrupt_char is
set to " " or "d".
I'm running LAVA from the latest released containers (2018.11), and
trying to use a beaglebone-black with a more recent u-boot than exists
in validation.l.o. qemu works fine.
The problem seems to be that LAVA thinks there's a prompt when there
isn't, and so it sends commands too quickly. Here's example output from
the serial console (job link[2]):
U-Boot 2017.07 (Aug 31 2017 - 15:35:58 +0000)
CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net: cpsw, usb_ether
Press SPACE to abort autoboot in 10 seconds
=>
=> setenv autoload no
=> setenv initrd_high 0xffffffff
=> setenv fdt_high 0xffffffff
=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 10.100.0.55 (1006 ms)
=> 172.28.0.4
Unknown command '172.28.0.4' - try 'help'
=> tftp 0x82000000 57/tftp-deploy-t7xus3ey/kernel/vmlinuz
link up on port 0, speed 100, full duplex
*** ERROR: `serverip' not set
...
When I u-boot manually, after I hit SPACE (or 'd', both work), u-boot
*deletes* the character and then prints '=> ' (is that delete the root
cause?). When LAVA runs, it shows an extra => and starts typing as seen
above. dhcp takes a second or two, and so the subsequent command starts
to get lost (in the above log we see an IP, because 'setenv serverip'
got lost).
If I set boot_character_delay to like 1000, it works because it gives
enough time for dhcp to finish before typing the next character, but
obviously makes the job very slow, and still not reliable.
I'm out of ideas.. help?
P.S. Two interesting things I've learned recently:
1) boot_character_delay must be specified in device_types file. it's
ignored when specified in the device file (surprising, as I see it
listed in some people's device files[3]).
2) If you install ser2net from sid, you can set max-connections and do
some _very handy_ voyeurism on the serial console while lava does its
thing (hat tip Kevin Hilman for that one).
Thanks,
Dan
[1] https://lists.lavasoftware.org/pipermail/lava-users/2018-May/001064.html
[2] https://lava.therub.org/scheduler/job/57
[3] https://git.linaro.org/lava/lava-lab.git/tree/lkft.validation.linaro.org/ma…
--
Linaro - Kernel Validation
100 testcases, submit to lava before leave the office, expect to get all the results next morning.
If everything is ok, get 100 results next morning, and check every issues.
Then, e.g. the 10th cases OOM, I wish from 11st case to 100th cases can continue run during the night, so I want to reboot the device after 10th case which I find it OOM. Then after reboot, continue 11st case to 100 the cases.
I know OOM not automation related, but if I do not resume the 11st ~ 100th cases during this night. I had to resubmit these cases tomorrow morning after I back to office, maybe the 100th case also have some bug, I wish it could send a result, then that morning I could assign other guy to fix it quickly, not wait I back to office then remove the 10th issue case, resubmit it, wait another 8 hours, finally execute the 100th case. 8 hours passed, we do not want the process's efficiency so low! This is our aim.
------------------------------------------------------------------
发件人：lava-users-request <lava-users-request(a)lists.lavasoftware.org>
发送时间：2019年1月25日(星期五) 16:55
收件人：lava-users <lava-users(a)lists.lavasoftware.org>
主 题：Lava-users Digest, Vol 5, Issue 37
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. reboot during test (cnspring2002)
2. Re: AOSP multiple node job (Neil Williams)
3. Re: reboot during test (Neil Williams)
4. Re: AOSP multiple node job (Chase Qi)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jan 2019 20:11:39 +0800
From: cnspring2002 <cnspring2002(a)aliyun.com>
To: lava-users(a)lists.lavasoftware.org
Subject: [Lava-users] reboot during test
Message-ID: <C0C4B61B-7B5A-4DAB-B644-849E77F0119B(a)aliyun.com>
Content-Type: text/plain; charset=us-ascii
Dear all,
In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
------------------------------
Message: 2
Date: Thu, 24 Jan 2019 15:06:56 +0000
From: Neil Williams <neil.williams(a)linaro.org>
To: Chase Qi <chase.qi(a)linaro.org>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] AOSP multiple node job
Message-ID:
<CAC6CAR3v_i-vOv4BVe56RHR4PahMihexpNa6v4w44UNb+_PVuw(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote:
>
> Hi,
>
> In most cases, we don't need multiple node job as we can control AOSP
> DUT from lxc via adb over USB. However, here is the use case.
>
> CTS/VTS tradefed-shell --shards option supports to split tests and run
> them on multiple devices in parallel. To leverage the feature in LAVA,
> we need multinode job, right?
If more than one device needs to have images deployed and booted
specifically for this test job, then yes. MultiNode is required. To be
sure that each device is at the same stage (as deploy and boot timings
can vary), the test job will need to wait for all test jobs to be
synchronised to the same point in each test job - synchronisation is
currently restricted to POSIX shells.
> And in multinode job, master-node lxc
> needs access to DUTs from salve nodes via adb over tcpip, right?
Not necessarily. From the LXC, the device can be controlled using USB.
There is no need for devices to have a direct connection to each other
just to use MultiNode. The shards implementation may require that
though.
> Karsten shared a job example here[1]. This probably is the most
> advanced usage of LAVA
All MultiNode is a complex usage of LAVA but VLANd used by the
networking teams is more complex than your use case.
>, and probably also not encouraged? To make it
> more clear, the connectivity should look like this.
There is a problem in this model: Every DUT will have it's own LXC and
that device will be connected to the LXC using USB.
> master.lxc <----adb over usb----> master.dut
> master.lxc <----adb over tcpip ---> slave1.dut
> master.lxc <----adb over tcpip ---> slave2.dut
Do not separate the LXC from the DUT - the LXC and it's DUT are a single node.
Master DUT has a master LXC.
Slave1 DUT has a Slave1 LXC
Slave2 DUT has a Slave2 LXC.
Depending on the boards in use, you may be able to configure each DUT,
including the master DUT, to have TCP/IP networking. That then allows
the processes running in the Master node to access the slave nodes.
(The following model is based on a theoretical device which doesn't
have the crippling USB OTG problem of the hikey - but the hikey can
work in this model if the IP addresses are determined statically and
therefore are available to each slave LXC.)
0: A program executing in the Master LXC which uses USB to send
commands to the master DUT which allow the Master LXC to retrieve the
IP address of the master DUT.
1: That program in the Master LXC then uses the MultiNode API
(lava-send) to declare that IP address to all the slave nodes. This is
equivalent to how existing jobs declare the IP address of the device
when using secondary connections.
2: Each slave node waits for the master-ip-addr message and sets that
value in a program executing in the slave LXC. The slave LXC is
connected to the slave DUT directly using USB so can use this to set
the master IP address, if that is required.
3: Each slave node now runs a program in each slave LXC to connect to
the slave DUT over USB and extract the slave DUT IP address
4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so
the first slave sends slave-1-ip-addr containing an IP address, slave
2 sends slave-2-ip-addr containing a different IP address.
5: The master node is waiting for all of these messages to be sent and
retrieves the values in turn. This information is now available to a
program executing inside the master LXC. This program could use USB to
set these values in the master DUT, if that is required.
6: During this time, all the slave nodes are waiting for the master
node to broadcast another message saying that the work on the master
is complete.
7: Once the master sends the complete message, each slave node picks
up this message from the MultiNode API and the script executing in the
slave LXC then ends the Lava Test Definition and the slave test job
completes.
8: The master can then do some other stuff and then complete.
https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini…https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini…
Don't obsess about the LXC either. With upcoming changes for docker
support, we could remove the presence of the LXC entirely. The LXC
with android devices only exists as a unit of isolation for the
benefit of the dispatcher. It has useful side effects but the reason
for the LXC to exist is to separate the fastboot operations from the
dispatcher operations.
For hikey and it's broken USB OTG support:
0: Each slave test job turns off the USB OTG support once the slave
LXC has deployed all the test image files and determined that the
slave DUT has booted correctly. If not, use lava-test-raise.
1: Next, each slave LXC uses the IP address of it's own slave DUT to
check connectivity. If this fails, use lava-test-raise.
2: Each slave LXC uses the MultiNode API to declare the IP address of
the slave DUT (because the slave node has determined that this IP is
working).
3: The master node is waiting for these messages and these are picked
up by the master LXC test definition.
4: The master LXC test definition issues commands to the master DUT -
now depending on how the sharding works, this could be over USB (turn
the USB OTG off later) or over TCP/IP (turn off the master USB OTG at
the start of this test definition).
5: The master DUT has enough information to drive the sharding across
the slave DUTs. The slave LXCs are waiting for the master to finish
the sharding. (lava-wait)
6: When the master LXC determines that the master DUT has finished the
sharding, then the master LXC sends a message to all the slave nodes
that the test is complete.
7: Each slave node picks up the completion message in the slave LXC
and the test definition finishes.
8: The master node can continue to do other tasks or can also complete
it's test definition.
> ....
>
> I see two options for adb over tcpip.
>
> Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
> cmds from lxc. I am not using it for two reasons.
Agreed, this doesn't need to rely on WiFi.
>
> * WiFi isn't reliable for long cts/vts test run.
> * In Cambridge lab, WiFi sub-network isn't accessible from lxc
> network. Because of security concerns, there is no plan to change
> that.
>
> Option #2: Wired Ethernet. On devices like hikey, we need to run
> 'pre-os-command' in boot action to power off OTG port so that USB
> Ethernet dongle works. Once OTG port is off, lxc has no access to the
> DUT, then test definition should be executed on DUT, right? I am also
> having the following problems to do this.
Before the OTG is switched, all data from the DUT needs to be
retrieved (and set) using the USB connection.
What information you need to set depends on how the sharding works.
The problem, as I see it, is that the slave DUTs have no way to
declare their IP address to the slave LXC once the OTG port is
switched. Therefore, you will need to put in a request for the boards
to have static IP addresses declared in the device dictionary. Then
the OTG can be switched and things become easier because the LXC knows
the IP address and can simply declare that to the MultiNode API so
that the master LXC can know which IP matches which node. There are
already a number of hikey devices with the static_ip device tag and
you can specify this device tag in your MultiNode test definition.
>
> * Without context overriding, overlay tarball will be applied to
> '/system' directory and test job reported "/system/bin/sh:
Why are you talking about /system ??? MultiNode only operates in a
POSIX shell - the POSIX shell is in the LXC and each DUT has a
dedicated LXC. In this use case, MultiNode API calls are only going to
be made from each LXC. The master LXC sends some information and then
receives information from test definitions running in each of the
slave LXCs.
The overlay is to be deployed to the LXC, not the DUT because this is
an Android system. What the android system does is determined either
by commands run inside the slave LXC to deploy files (before the OTG
switch) or commands run inside the master LXC (with knowledge of the
IP address from the MultiNode API) to execute commands on the DUT over
TCP/IP.
Use the LXC to deploy the files and boot the device, then to declare
information about each particular node. Once that is done, whatever
thing is controlling the test needs to just use TCP/IP to communicate
and use the MultiNode API to send messages and allow some nodes to
wait for other nodes whilst the test proceeds.
> /lava-247856/bin/lava-test-runner: not found"[2].
> * With the following job context, LAVA still runs
> '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
> tested in my local LAVA instance, test job definition and test log
> attached. Maybe my understanding on the context overriding is wrong, I
> thought LAVA should execute '/system/lava-24/bin/lava-test-runner
> /system/lava-24/0' instead. Any suggestions would be appreciated.
>
> context:
> lava_test_sh_cmd: '/system/bin/sh'
> lava_test_results_dir: '/system/lava-%s'
>
> I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
> really run lava-test-runner. The shebang line seems problematic.
>
> --- hacking ---
> hikey:/system/lava-24/bin # ./lava-test-runner
> /system/bin/sh: ./lava-test-runner: No such file or directory
> hikey:/system/lava-24/bin # cat lava-test-runner
> #!/bin/bash
>
> #!/bin/sh
>
> ....
> # /system/bin/sh lava-test-runner
> lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
> file or directory
> --- ends ---
>
> I had a discussion with Milosz. He proposed the third option which
> probably will be the most reliable one, but it is not supported in
> LAVA yet. Here is the idea. Milosz, feel free to explain more.
>
> **Option #3**: Add support for accessing to multiple DUTs in single node job.
>
> * Physically, we need the DUTs connected via USB cable to the same dispatcher.
I don't see that this solves anything and it adds a lot of unnecessary
lab configuration - entirely duplicating the point of having ethernet
connections to the boards. Assign static IP addresses to each board
and when the test job starts, each dedicated LXC can declare the
static information according to whichever board was assigned to
whichever node.
The DUTs only need to be visible to programs running on the master
node and that can be done by declaring static IP addresses using the
MultiNode API.
> * In single node job, LAVA needs to add the DUTs specified(somehow) or
> assigned randomly(lets say both device type and numbers defined) to
> the same lxc container. Test definitions can take over from here.
No - the LXC is used to issue commands to deploy test images to the
DUT. The LXC is a transparent part of the dispatcher, it is not just
for test definitions. The LXC cannot be used for multiple test jobs,
it is part of the one dispatcher.
>
> Is this can be done in LAVA? Can I require the feature? Any
> suggestions on the possible implementations?
>
>
> Thanks,
> Chase
>
> [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
> [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
------------------------------
Message: 3
Date: Thu, 24 Jan 2019 15:09:58 +0000
From: Neil Williams <neil.williams(a)linaro.org>
To: cnspring2002 <cnspring2002(a)aliyun.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] reboot during test
Message-ID:
<CAC6CAR3fV+b1p5T2EVxUCPP7d=Erno-20MNVxPaZPVf3tbK3Yg(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 24 Jan 2019 at 12:13, cnspring2002 <cnspring2002(a)aliyun.com> wrote:
>
> Dear all,
>
> In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
The out of memory killer is a fatal device error. The test job is not
going to be able to continue because the failure mode is
unpredictable.
The cause of the OOM needs to be determined through standard triage,
not automation. (Although automation may help create a data matrix of
working and failing combinations and test operations.)
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
------------------------------
Message: 4
Date: Fri, 25 Jan 2019 15:45:56 +0800
From: Chase Qi <chase.qi(a)linaro.org>
To: Neil Williams <neil.williams(a)linaro.org>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] AOSP multiple node job
Message-ID:
<CADzYPRFJiX8qKt_NyHZCi0qs5iotx0wg0OMN9o7SOi84sYYTow(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Neil,
Thanks a lot for your guidance. It is really good to see you back :)
On Thu, Jan 24, 2019 at 11:07 PM Neil Williams <neil.williams(a)linaro.org> wrote:
>
> On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote:
> >
> > Hi,
> >
> > In most cases, we don't need multiple node job as we can control AOSP
> > DUT from lxc via adb over USB. However, here is the use case.
> >
> > CTS/VTS tradefed-shell --shards option supports to split tests and run
> > them on multiple devices in parallel. To leverage the feature in LAVA,
> > we need multinode job, right?
>
> If more than one device needs to have images deployed and booted
> specifically for this test job, then yes. MultiNode is required. To be
> sure that each device is at the same stage (as deploy and boot timings
> can vary), the test job will need to wait for all test jobs to be
> synchronised to the same point in each test job - synchronisation is
> currently restricted to POSIX shells.
>
> > And in multinode job, master-node lxc
> > needs access to DUTs from salve nodes via adb over tcpip, right?
>
> Not necessarily. From the LXC, the device can be controlled using USB.
> There is no need for devices to have a direct connection to each other
> just to use MultiNode. The shards implementation may require that
> though.
CTS/VTS sharding shards a run into given number of independent chunks,
to run on multiple devices that connected to the same host. The host
will be the master lxc in our case.
>
> > Karsten shared a job example here[1]. This probably is the most
> > advanced usage of LAVA
>
> All MultiNode is a complex usage of LAVA but VLANd used by the
> networking teams is more complex than your use case.
>
> >, and probably also not encouraged? To make it
> > more clear, the connectivity should look like this.
>
> There is a problem in this model: Every DUT will have it's own LXC and
> that device will be connected to the LXC using USB.
>
> > master.lxc <----adb over usb----> master.dut
> > master.lxc <----adb over tcpip ---> slave1.dut
> > master.lxc <----adb over tcpip ---> slave2.dut
>
> Do not separate the LXC from the DUT - the LXC and it's DUT are a single node.
>
> Master DUT has a master LXC.
> Slave1 DUT has a Slave1 LXC
> Slave2 DUT has a Slave2 LXC.
>
> Depending on the boards in use, you may be able to configure each DUT,
> including the master DUT, to have TCP/IP networking. That then allows
> the processes running in the Master node to access the slave nodes.
>
Yes, that is what I am trying to do. The above connectivity topology I
wrote is the goal not the initial state with LAVA design. Master lxc
needs access to all the DUT nodes, either via USB or tcpip.
> (The following model is based on a theoretical device which doesn't
> have the crippling USB OTG problem of the hikey - but the hikey can
> work in this model if the IP addresses are determined statically and
> therefore are available to each slave LXC.)
>
> 0: A program executing in the Master LXC which uses USB to send
> commands to the master DUT which allow the Master LXC to retrieve the
> IP address of the master DUT.
>
> 1: That program in the Master LXC then uses the MultiNode API
> (lava-send) to declare that IP address to all the slave nodes. This is
> equivalent to how existing jobs declare the IP address of the device
> when using secondary connections.
>
> 2: Each slave node waits for the master-ip-addr message and sets that
> value in a program executing in the slave LXC. The slave LXC is
> connected to the slave DUT directly using USB so can use this to set
> the master IP address, if that is required.
>
> 3: Each slave node now runs a program in each slave LXC to connect to
> the slave DUT over USB and extract the slave DUT IP address
>
> 4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so
> the first slave sends slave-1-ip-addr containing an IP address, slave
> 2 sends slave-2-ip-addr containing a different IP address.
>
> 5: The master node is waiting for all of these messages to be sent and
> retrieves the values in turn. This information is now available to a
> program executing inside the master LXC. This program could use USB to
> set these values in the master DUT, if that is required.
>
> 6: During this time, all the slave nodes are waiting for the master
> node to broadcast another message saying that the work on the master
> is complete.
>
> 7: Once the master sends the complete message, each slave node picks
> up this message from the MultiNode API and the script executing in the
> slave LXC then ends the Lava Test Definition and the slave test job
> completes.
>
> 8: The master can then do some other stuff and then complete.
>
> https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini…
>
> https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini…
>
> Don't obsess about the LXC either. With upcoming changes for docker
> support, we could remove the presence of the LXC entirely. The LXC
> with android devices only exists as a unit of isolation for the
> benefit of the dispatcher. It has useful side effects but the reason
> for the LXC to exist is to separate the fastboot operations from the
> dispatcher operations.
>
> For hikey and it's broken USB OTG support:
>
> 0: Each slave test job turns off the USB OTG support once the slave
> LXC has deployed all the test image files and determined that the
> slave DUT has booted correctly. If not, use lava-test-raise.
>
> 1: Next, each slave LXC uses the IP address of it's own slave DUT to
> check connectivity. If this fails, use lava-test-raise.
>
> 2: Each slave LXC uses the MultiNode API to declare the IP address of
> the slave DUT (because the slave node has determined that this IP is
> working).
>
> 3: The master node is waiting for these messages and these are picked
> up by the master LXC test definition.
>
> 4: The master LXC test definition issues commands to the master DUT -
> now depending on how the sharding works, this could be over USB (turn
> the USB OTG off later) or over TCP/IP (turn off the master USB OTG at
> the start of this test definition).
>
> 5: The master DUT has enough information to drive the sharding across
> the slave DUTs. The slave LXCs are waiting for the master to finish
> the sharding. (lava-wait)
>
> 6: When the master LXC determines that the master DUT has finished the
> sharding, then the master LXC sends a message to all the slave nodes
> that the test is complete.
>
> 7: Each slave node picks up the completion message in the slave LXC
> and the test definition finishes.
>
> 8: The master node can continue to do other tasks or can also complete
> it's test definition.
>
>
> > ....
> >
> > I see two options for adb over tcpip.
> >
> > Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
> > cmds from lxc. I am not using it for two reasons.
>
> Agreed, this doesn't need to rely on WiFi.
>
> >
> > * WiFi isn't reliable for long cts/vts test run.
> > * In Cambridge lab, WiFi sub-network isn't accessible from lxc
> > network. Because of security concerns, there is no plan to change
> > that.
> >
> > Option #2: Wired Ethernet. On devices like hikey, we need to run
> > 'pre-os-command' in boot action to power off OTG port so that USB
> > Ethernet dongle works. Once OTG port is off, lxc has no access to the
> > DUT, then test definition should be executed on DUT, right? I am also
> > having the following problems to do this.
>
> Before the OTG is switched, all data from the DUT needs to be
> retrieved (and set) using the USB connection.
>
> What information you need to set depends on how the sharding works.
>
> The problem, as I see it, is that the slave DUTs have no way to
> declare their IP address to the slave LXC once the OTG port is
> switched. Therefore, you will need to put in a request for the boards
That is the problem I had. And that is why I was trying to run test
definition on Android DUT directly to enable adb over tcpip and
declare IP address. As you mentioned below, it is the wrong direction.
> to have static IP addresses declared in the device dictionary. Then
> the OTG can be switched and things become easier because the LXC knows
> the IP address and can simply declare that to the MultiNode API so
> that the master LXC can know which IP matches which node. There are
> already a number of hikey devices with the static_ip device tag and
> you can specify this device tag in your MultiNode test definition.
Brilliant and brand new idea to me. I didn't realize static-ip tag is
the solution. I have managed to enable and test adb over tcpip in this
way(In my local instance). I have attached my test job definition here
in case it is any help for other LAVA users. The following definitions
are essential.
tags:
- static-ip
reboot_to_fastboot: false
- test:
namespace: tlxc
timeout:
minutes: 10
protocols:
lava-lxc:
- action: lava-test-shell
request: pre-os-command
timeout:
minutes: 2
Thanks,
Chase
>
> >
> > * Without context overriding, overlay tarball will be applied to
> > '/system' directory and test job reported "/system/bin/sh:
>
> Why are you talking about /system ??? MultiNode only operates in a
> POSIX shell - the POSIX shell is in the LXC and each DUT has a
> dedicated LXC. In this use case, MultiNode API calls are only going to
> be made from each LXC. The master LXC sends some information and then
> receives information from test definitions running in each of the
> slave LXCs.
>
> The overlay is to be deployed to the LXC, not the DUT because this is
> an Android system. What the android system does is determined either
> by commands run inside the slave LXC to deploy files (before the OTG
> switch) or commands run inside the master LXC (with knowledge of the
> IP address from the MultiNode API) to execute commands on the DUT over
> TCP/IP.
>
> Use the LXC to deploy the files and boot the device, then to declare
> information about each particular node. Once that is done, whatever
> thing is controlling the test needs to just use TCP/IP to communicate
> and use the MultiNode API to send messages and allow some nodes to
> wait for other nodes whilst the test proceeds.
>
> > /lava-247856/bin/lava-test-runner: not found"[2].
> > * With the following job context, LAVA still runs
> > '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
> > tested in my local LAVA instance, test job definition and test log
> > attached. Maybe my understanding on the context overriding is wrong, I
> > thought LAVA should execute '/system/lava-24/bin/lava-test-runner
> > /system/lava-24/0' instead. Any suggestions would be appreciated.
> >
> > context:
> > lava_test_sh_cmd: '/system/bin/sh'
> > lava_test_results_dir: '/system/lava-%s'
> >
> > I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
> > really run lava-test-runner. The shebang line seems problematic.
> >
> > --- hacking ---
> > hikey:/system/lava-24/bin # ./lava-test-runner
> > /system/bin/sh: ./lava-test-runner: No such file or directory
> > hikey:/system/lava-24/bin # cat lava-test-runner
> > #!/bin/bash
> >
> > #!/bin/sh
> >
> > ....
> > # /system/bin/sh lava-test-runner
> > lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
> > file or directory
> > --- ends ---
> >
> > I had a discussion with Milosz. He proposed the third option which
> > probably will be the most reliable one, but it is not supported in
> > LAVA yet. Here is the idea. Milosz, feel free to explain more.
> >
> > **Option #3**: Add support for accessing to multiple DUTs in single node job.
> >
> > * Physically, we need the DUTs connected via USB cable to the same dispatcher.
>
> I don't see that this solves anything and it adds a lot of unnecessary
> lab configuration - entirely duplicating the point of having ethernet
> connections to the boards. Assign static IP addresses to each board
> and when the test job starts, each dedicated LXC can declare the
> static information according to whichever board was assigned to
> whichever node.
>
> The DUTs only need to be visible to programs running on the master
> node and that can be done by declaring static IP addresses using the
> MultiNode API.
>
> > * In single node job, LAVA needs to add the DUTs specified(somehow) or
> > assigned randomly(lets say both device type and numbers defined) to
> > the same lxc container. Test definitions can take over from here.
>
> No - the LXC is used to issue commands to deploy test images to the
> DUT. The LXC is a transparent part of the dispatcher, it is not just
> for test definitions. The LXC cannot be used for multiple test jobs,
> it is part of the one dispatcher.
>
> >
> > Is this can be done in LAVA? Can I require the feature? Any
> > suggestions on the possible implementations?
> >
> >
> > Thanks,
> > Chase
> >
> > [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
> > [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
> > _______________________________________________
> > Lava-users mailing list
> > Lava-users(a)lists.lavasoftware.org
> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
Dear all,
In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
Hello list,
Apologies if this question has been asked already. I have a test framework which spits out a junit file.
What’s the best way to import data from the junit file into LAVA?
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist .
I have few questions:
* Does LAVA support those cases?
* If yes, does LAVA support multiple reboots?
* If yes, how can I write tests in order to run different sets of tests at any boot.
* Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful
* How can I structure my pipeline?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
>
> When Lava start test or finish the test job, squad zmq SUB socket seems
> not receive log message from lava-server.
>
> It just print out '[2019-01-22 08:26:24 +0000] [DEBUG]
> nexell.lava.server2: connected to tcp://192.168.1.20:2222:5500'.
>
The url is really strange as two port numbers are specified. Should be
"tcp://192.168.1.20:5500"
Rgds
--
Rémi Duraffort
LAVA Team, Linaro
Hello,
we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist .
I have few questions:
* Does LAVA support those cases?
* If yes, does LAVA support multiple reboots?
* If yes, how can I write tests in order to run different sets of tests at any boot.
* Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful
* How can I structure my pipeline?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Dear Lava users,
I'm trying to create a job that performs the following steps :
Deploy to flasher our custom tool (OK)
Boot in bootloader mode - u-boot (OK)
Test in interactive mode (OK)
From interactive mode start kernel (OK)
Launch a test from kernel (KO)
The last part fails because I don't know where to check the kernel prompt. I cannot add a boot stage and declare an additional prompt because I don't want to reboot, that would reset the configuration done in interactive mode.
Do you have any piece of advice or example of job showing how to proceed to manage the kernel prompt & autologin in such a job?
Best regards,
Denis
Hello,
A request from some Lava users internally.
We have 3 boot stages, TF-A, U-boot, and kernel.
Is there a way, in a Lava job, to test that these components' versions are the expected ones?
That would mean, as far as I understand, not testing the embedded software itself, but the Lava job log...
Best regards,
Denis
