On 28 Jan 2019, at 11:20, Neil Williams neil.williams@linaro.org wrote:
On Mon, 28 Jan 2019 at 11:02, Diego Russo Diego.Russo@arm.com wrote:
Hello,
I have the following setup: a WaRP7 which exposes a network connection over USB gadget driver (http://trac.gateworks.com/wiki/linux/OTG#g_etherGadget)
As long as the device is capable of raising the network interface from a POSIX test action on the device, there is no need to even care that this is a USB anything. It's TCP/IP and that's all that any other test action needs to know.
Exactly, I’m passing the usb0 interface to the container having the following in /et/lxc/default.conf
lxc.network.1.type = phys lxc.network.1.link = usb0 lxc.network.1.name = usb0 lxc.network.1.flags = up
This means the usb0 network interfaces will be passed to the container as usb0. This works as far as the usb0 interface exists on the host.
Please think carefully and describe EXACTLY what you are aiming to do because it sounds like there is confusion here about how to interact with the device.
My aim for this specific test is: * “Install" an application on the slave which interacts with the WaRP7 * this application is a CLI application which interacts with the WaRP7 using the usb0 interface * Flash and boot the Warp7 * Tests are run ON the lava slave using the application installed earlier * the application uses the usb0 interface on the slave * There are no tests running on the Warp7 but this might be rebooted while running above tests
The USB gadget interface is the wrong side of the interface - you already have a POSIX test action running on the device, so use that to raise and configure the TCP/IP by accessing the relevant driver support directly on the device.
On the device I don’t need to run anything. The “issue” is on the host (lava slave) side.
A possible test case is to have some process running on the LAVA dispatcher (within a LXC container) which targets the WaRP7 over this network interface.
LXC support does not provide any means of synchronisation across test actions. Strict sequence only. If anything isn't ready, the test definition will either have to just cope with the situation or fail the entire test job.
Why are you trying to do USB device passthrough when you have this network interface? This device doesn't need an LXC to run a standard test job. https://staging.validation.linaro.org/scheduler/job/248129
Therefore, avoid using the LXC protocol in the first place and communicate over the network. You'll need to declare the IP address of the device but that's a standard MultiNode API call from a POSIX shell on the device.
The process running the test case does NOT have to be on the LAVA dispatcher if it is targetting the device over TCP/IP. All it needs is the IP address, nothing USB at all.
In our case we don’t need to run anything on the WaRP7. The WaRP7 just needs to be up and running and be visible via usb0 from the dispatcher. Tests are run on lava dispatcher
WaRP7 <—> usb0 net iface <———> usb0 net iface <—> LAVA slave
This WArp7 has a physical connection via USB with the LAVA slave (from the OS point of view is a yet another network interface) and I don’t think it can be reached by other nodes.
Through LXC I'm able to passtrhough this interface from the host to the container and use it within the container (via /etc/lxc/default.conf)
How are you passing it through? If the device is dynamic, you must declare the board_id of the device in the device dictionary so that LAVA will create a suitable udev rule to add the re-enumerated device back to the LXC when udev sees an ADD event.
I’m passing the usb0 network interface to LXC as stated at the beginning of the email. usb0 is just.
I tried also to use the board_id but unfortunately it doesn’t have any iSerial (only usb and vendo id). Better the iSerial field is 0.
If a test requires the reboot of the WaRP7, the usb0 interface disappears from the container. When the WaRP7 boots again the usb0 interface is available on the host (but not in the container).
The usb0 interface is accessible from the device and you're already running a POSIX shell in the test action on the device, so that test action needs to take care of re-establishing the network connection (and possibly re-declaring the IP address to the other node).
Again, the problem is on the container side. As soon as the board is up and running I have usb0 network interface both on WaRP7 and host. The container though loses visibility.
Things I tried or thought about:
- I tried synchronizing boots both of the WaRP7 and LXC container but it seems not possible to "reboot" (restart) a container within the same job execution.
- Is it possible to "restart" a container during a job execution?
No. This has nothing to do with the start of the LXC.
Well it does because if I restart the LXC container AFTER the board has rebooted, usb0 is re-passed through and it has visibility of this network interface.
- Outside LAVA it is possible to run a command (lxc-device --name diegor-test -- add usb0) which re-passthrough the interface from Linux to LXC container.
- Is it possible to run the above command ad job execution time on the lava dispatcher?
How can I solve this situation?
If you do want to do passthrough:
https://master.lavasoftware.org/static/docs/v2/admin-lxc-deploy.html#deployi...
https://lava.codehelp.co.uk/scheduler/job/4313#action_1-2
https://lava.codehelp.co.uk/scheduler/device/tom/devicedict#defline11
As said earlier, the board_id is 0.
If you want to use MultiNode, use a QEMU device as the second node which communicates with the other node using the MultiNode API.
https://master.lavasoftware.org/static/docs/v2/multinode.html
I think using the multinode won’t help for this specific case.
Cheers
-- Diego Russo Staff Software Engineer - diego.russo@arm.com Direct Tel. no: +44 1223 405920 Main Tel. no: +44 1223 400400 ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - http://twitter.com/diegor http://www.linkedin.com/in/diegor
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. _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
-- 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.