If you publish the code to a branch, and show exactly the errors you get, I
could try to look at it.

Alex

On Thu, 20 May 2021 at 22:29, Alexander Kanavin [off-list ref]
wrote:

You cannot hardcode the ip address like that; it's set dynamically when
qemu starts, and you can only access it from selftest or runtime test.

Alex

On Thu, 20 May 2021 at 12:06, Vinay Kumar [off-list ref] wrote:

quoted

Hi Alex,

Tried your suggestions to copy and run in rust.py without any issue as
below.
===============================
builddir = get_bb_var("B", "rust-testsuite")
ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user="root",
timeout=600)
ssh.copy_to(builddir + "/" +
"build/x86_64-unknown-linux-gnu/stage2-tools-bin/remote-test-server","~/")
t_thread = threading.Thread(target=ssh.run,
args=("~/remote-test-server -v remote",))
t_thread.start()
===============================

If we set "TEST_DEVICE_ADDR" in rust.py through "runCmd" as shown
below,  the remote-test-client does not connect  to the image.
So a lot of tests fail.
===============================
"cmd  = "export TEST_DEVICE_ADDR=%s:12345;" % qemu.ip"
runCmd(cmd)
bitbake("{} -c check".format(recipe))
===============================

Also, I tried to move do_check content to rust.py without any success.
===============================
cmd = "export PATH=%s/../recipe-sysroot-native/usr/lib/rustlib/:" %
builddir
cmd= cmd + "%s/../recipe-sysroot-native/usr/bin:$PATH;" % builddir
cmd = cmd + "export
RUST_TARGET_PATH=%s/../recipe-sysroot-native/usr/lib/rustlib/;" %
builddir
cmd = cmd + "cd " + builddir + ";"
cmd  = "export TEST_DEVICE_ADDR=\"%s:12345\";" % qemu.ip
cmd = cmd + "python3 src/bootstrap/bootstrap.py -j 40 --verbose test
--no-fail-fast --bless --target aarch64-poky-linux > summary.txt 2>&1"

Error:
File
"/ala-lpggp31/vinay/review-2/poky-contrib/meta/lib/oeqa/utils/commands.py",
line 210, in runCmd
raise AssertionError("Command '%s' returned non-zero exit status
%d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'export
TEST_DEVICE_ADDR="192.168.7.2:12345";python3
src/bootstrap/bootstrap.py -j 40 --verbose test --no-fail-fast --bless
--target aarch64-poky-linux > summary.txt 2>&1' returned non-zero exit
status 2:
===============================

So in rust.py only copy and execution of "remote-test-server" is taken
care of.
And the test execution is by  do_check of rust-testsuite.inc as below,
===============================
do_check () {
    export TEST_DEVICE_ADDR="192.168.7.2:12345"
    rust_runx test --no-fail-fast --bless --target "${TARGET_SYS}" >
summary.txt 2> /dev/null
}

Let me know if this ok. will send patches with changes for review.

Regards,
Vinay

On Mon, May 17, 2021 at 8:57 PM Vinay Kumar via lists.openembedded.org
[off-list ref] wrote:

quoted

Hi Alex,

Tried testing outside oe-selftest framework, it works fine without any

errors,

quoted

export TEST_DEVICE_ADDR="192.168.7.4:12345"
rust_runx test --no-fail-fast --bless --target "aarch64-poky-linux" >
summary.txt 2> /dev/null

Also, log (summary.txt) shows "remote-test-client" is connecting to
the image without any issue.
=======================================
running:

"/ala-lpggp31/vinay/review-2/b1/tmp/work/cortexa57-poky-linux/rust-testsuite/1.46.0-r0/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/remote-test-client"

quoted

"spawn-emulator" "aarch64-poky-linux"

"/ala-lpggp31/vinay/review-2/b1/tmp/work/cortexa57-poky-linux/rust-testsuite/1.46.0-r0/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/remote-test-server"

quoted

"/ala-lpggp31/vinay/review-2/b1/tmp/work/cortexa57-poky-linux/rust-testsuite/1.46.0-r0/rustc-1.46.0-src/build/tmp"

quoted

Connecting to remote device 192.168.7.4:12345 ...

Will integrate these changes in oe-selftest and let you know.

Regards,
Vinay

On Mon, May 17, 2021 at 8:11 PM Vinay Kumar [off-list ref]

wrote:

quoted

quoted

Checking suggestions, the booted image with tap seems to be working by
passing "-monitor  telnet:127.0.0.1:1234,server,nowait"
so I will execute testing and update you.
==========================
root@qemuarm64:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:02
          inet addr:192.168.7.4  Bcast:192.168.7.255

Mask:255.255.255.0

quoted

quoted

          inet6 addr: fe80::5054:ff:fe12:3402/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:116 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:945121 (922.9 KiB)  TX bytes:9529 (9.3 KiB)

root@qemuarm64:~# ./remote-test-server -v remote
starting test server
listening on 0.0.0.0:12345!
==========================

Regards,
Vinay

On Mon, May 17, 2021 at 8:02 PM Alexander Kanavin
[off-list ref] wrote:

quoted

Thanks, can you please look into the error? The line where it

happens and the way to get a backtrace is right there :)

quoted

quoted

quoted

There's no reason it shouldn't work.

Alex

On Mon, 17 May 2021 at 15:21, Vinay Kumar [off-list ref]

wrote:

quoted

quoted

quoted

quoted

Hi Alex,

Error on qemu  image (ex. Aarch64) booted with tap interface.
===========================
root@qemuarm64:~# ./remote-test-server
starting test server
thread 'main' panicked at 'TcpListener::bind(bind_addr) failed with
Cannot assign requested address (os error 99)',
src/tools/remote-test-server/src/main.rs:90:20
note: run with `RUST_BACKTRACE=1` environment variable to display

a backtrace

quoted

quoted

quoted

quoted

===========================

On Mon, May 17, 2021 at 5:16 PM Alexander Kanavin
[off-list ref] wrote:

quoted

On Mon, 17 May 2021 at 13:34, Vinay Kumar <

vinay.m.engg@gmail.com> wrote:

quoted

quoted

quoted

quoted

quoted

quoted

"remote-test-server" on qemu-image with a tap interface throws

an error.

quoted

quoted

quoted

quoted

quoted

quoted

The emulators for rust testing are with tcp port forwarding so

used

quoted

quoted

quoted

quoted

quoted

quoted

slirp method with added rust port.

I'm not sure I understand - what kind of error? In both cases

the server starts listening on a port, so in slirp scenario the address is
127.0.0.1:12345 (prone to breakage if something else on the build host
took that port btw, including another instance of the same test), in tap it
would be 192.168.7.2:12345. For the client you simply supply that via
TEST_DEVICE_ADDR. No?

quoted

quoted

quoted

quoted

quoted

Alex