Re: [seL4] Devel Digest, Vol 76, Issue 8
Thanks Damon for your help.
I've reinstalled Haskell stack this morning> This time I tried
fault-handlers tutorial. It appears the reinstall had made the difference
as ninja indeed spawned the process:
$ stack build --fast
and after just a minute or two (yesterday the whole thing was hanging for a
good 20-30min before I lost patience), a long log was produced. Among tons
of messages, I found this warning:
Copied executables to
/home/chris/sel4_tutorials/fault-handlers_build/capDL-tool:
- parse-capDL
Warning: Installation path
/home/chris/sel4_tutorials/fault-handlers_build/capDL-tool
not found on the PATH environment variable.
I hope the warning won't stop me, although I'm curious why capDL wants to
live in (and have a path to) a tutorial build directory rather than some
common bin dirs like /usr/bin:/snap/bin or such...
Thanks again,
Chris
On Tue, Sep 15, 2020 at 10:53 PM
Send Devel mailing list submissions to devel@sel4.systems
To subscribe or unsubscribe via the World Wide Web, visit https://sel4.systems/lists/listinfo/devel or, via email, send a message with subject or body 'help' to devel-request@sel4.systems
You can reach the person managing the list at devel-owner@sel4.systems
When replying, please edit your Subject line so it is more specific than "Re: Contents of Devel digest..."
Today's Topics:
1. Re: CAmkES Linux VM Tutorial/Minimal Build Issue (Lee, Damon (Data61, Kensington NSW)) 2. Re: ADL tool hangs (Lee, Damon (Data61, Kensington NSW)) 3. capability name change (Sachin More)
----------------------------------------------------------------------
Message: 1 Date: Tue, 15 Sep 2020 02:16:43 +0000 From: "Lee, Damon (Data61, Kensington NSW)"
To: "devel@sel4.systems" Subject: Re: [seL4] CAmkES Linux VM Tutorial/Minimal Build Issue Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi Jim,
So there I was having a lovely time doing the seL4 Tutorials...and I got hit with debug output #1 below, so I confirmed that I indeed had nested virtualization working by making an running an Ubuntu VM in side of an Ubuntu VM on an Ubuntu box in using kvm and qemu, so I do not think it is that. I tried passing the host processor through just to see if there something was getting in the way to no avail.
I took a look at the debug output and it looks like there's something funny going on with the kernel and the VMM. I was able to replicate your issue using the manifest available on GitHub, but it was working fine using our internal manifests. So I suspect there were probably fixes that haven't been propagated to GitHub yet via our internal CI processes.
I'll take a look at why our CI haven't propagated changes to GitHub and in the meantime, I've created a fork[1] on GitHub of our internal tutorial manifest so you can use that instead.
[1] https://github.com/nomadeel/sel4-tutorials-manifest
Hope this helps, Damon
------------------------------
Message: 2 Date: Tue, 15 Sep 2020 02:25:57 +0000 From: "Lee, Damon (Data61, Kensington NSW)"
To: "devel@sel4.systems" Subject: Re: [seL4] ADL tool hangs Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi Chris,
I have recently messed up my ubuntu host seL4 building machine and I had to recreate it from scratch. But I have missed something on the way. So I have a problem building anything that involves Camkes components. It appears that a tool generating ADL or linking capDL or something along is missing and results in a hang during building. For example when building ipc tutorial (for x85 platform):
root@ubuntu:/home/chris/sel4_tutorials/ipc_build# ninja [0/8] Generating capDL-tool/parse-capDL^C ninja: build stopped: interrupted by user.
Or mcs tutorial:
root@ubuntu:/home/chris/sel4_tutorials/mcs_build# ninja [0/8] Generating capDL-tool/parse-capDL^C ninja: build stopped: interrupted by user.
This build step builds the capDL-tools which is written in Haskell. 'stack' is the toolchain used to build the capDL-tools and we've seen examples of it taking a *very* long time on specific distributions like Ubuntu. To verify this, perhaps try `ps aux | grep stack` or similar to see if 'stack' is being run.
We do cache the build after the first time it's being run, so subsequent builds shouldn't take too long. If this build step doesn't finish even after waiting for a long time (30 minutes or so), let us know and we'll be happy to help.
Regards, Damon
------------------------------
Message: 3 Date: Tue, 15 Sep 2020 08:51:15 -0400 From: Sachin More
To: devel@sel4.systems Subject: [seL4] capability name change Message-ID: Content-Type: text/plain; charset="UTF-8" Hi:
Between version 9.0.1 and 10.0.0, the capability name seL4_CapIOPort changed to seL4_CapIOPortControl in the file seL4/libsel4/include/sel4/bootinfo_types.h. I have some legacy code written for 9.0.1 that I want to port to 10.0.0. When I changed the occurrences of seL4_CapIOPort to seL4_CapIOPortControl, I am getting the following:
Warning: copy: seL4_CNode_Copy (0x7) returned 3
followed some time later by:
Warn<
> What am I doing wrong?
thanks in advance, Sachin
------------------------------
Subject: Digest Footer
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
------------------------------
End of Devel Digest, Vol 76, Issue 8 ************************************
Hi Chris,
Among tons of messages, I found this warning:
Copied executables to /home/chris/sel4_tutorials/fault-handlers_build/capDL-tool: - parse-capDL
Warning: Installation path /home/chris/sel4_tutorials/fault-handlers_build/capDL-tool not found on the PATH environment variable.
I hope the warning won't stop me, although I'm curious why capDL wants to live in (and have a path to) a tutorial build directory rather than some common bin dirs like /usr/bin:/snap/bin or such...
The warning shouldn't stop you, and it's probably a legacy of some old design decision that we haven't gotten rid of yet. Off the top of my head, I think it makes sense for the capDL tool to live inside a build directory as there may changes that people want to test without having those changes be visible outside that particular project. Regards, Damon
participants (2)
-
Chris Koziarz
-
Lee, Damon (Data61, Kensington NSW)