I’m attempting to build the seL4 tutorials on a local VM (Ubuntu 18.04 "Linux ubuntu 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux”). I have confirmed that the VM has the pre-reqs present and the repository was synced using repo this afternoon. The builds succeed, but running the VM produces a kernel exception. Here is sample output from attempting to build the dynamic-1 tutorial: https://pastebin.com/NnShcREU A similar error occurs when I build the completed solution, as well. Using GDB, it appears that main is never reached. Thanks for any assistance, Jeremiah Peschka
Hi Jeremiah, According to your output, the kernel doesn't finish booting and crashes before user-mode is entered. I am unable to replicate the error that you are experiencing unfortunately. It is likely that the issue is being caused by different host tooling than what we use. Here are some options about what you could try: - Building and running dynamic-1 using the docker image we use for testing the apps: trustworthysystems/camkes. We use this to run the integration tests for the tutorials currently. - Building and running sel4test to see if the crash is related to the tutorials project, or to the kernel binary artifact that your setup is producing. - Making either a copy of your VM, or the images it produces (dynamic-1-image-x86_64-pc99 and kernel-x86_64-pc99, found in dynamic-1_build/images/) available for download to make it easier for me to reproduce the problem. Regards, Kent
Thanks for the detailed response. I attempted building sel4test in my local VM and I’ve run into the same issue. I have uploaded the both the seL4test and dynamic_1 images to Dropbox and you can retrieve them from https://www.dropbox.com/sh/lfyv1lvnvkzszex/AABhxvA_xisyIFY_5CuGsWAUa?dl=0 That being said, everything is working inside the Docker container (I had to remove sharing /etc/localtime since I’m running Docker directly on macOS). I’ll proceed using the Docker based environment for now and will revisit running in the VM in the next few weeks - there’s a chance I misconfigured something or grabbed the wrong version of a library. I noticed there’s a big difference in the kernel version number between the docker image and the current Ubuntu 18.04 kernel, so something else may have changed that is incompatible. Again, thank you for the nudge in the right direction. Jeremiah Peschka
Happy that it is working for you in the Docker container. Based on the images you provided, it seems that the compiler is generating instructions for a newer microarchitecture than what qemu is simulating. This is why seL4test is getting a user exception. Do you tweak the microarchitecture settings at all? Otherwise what version is the compiler in the VM that you are using? Kent.
I have not tweaked the microarchitecture settings for qemu - I rely on it for my teaching assistant duties as well as for seL4, so I leave it alone. Plus, this is a fresh VM that only exists for seL4, so I’ve changed almost nothing on it. GCC: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 Clang: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) qemu: QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.6) The qemu command being run is: qemu-system-x86_64 -cpu Nehalem,-vme,+pdpe1gb,-xsave,-xsaveopt,-xsavec,-fsgsbase,-invpcid,enforce -nographic -serial mon:stdio -m size=512M -kernel images/kernel-x86_64-pc99 -initrd images/hello-world-image-x86_64-pc99 The only other odd thing that it might be is that I have enabled VT-x/EPT support for the VM in VMware, I wouldn’t think that would cause any problems, though... Jeremiah Peschka On Oct 22, 2018, 23:37 -0700, Kent.Mcleod@data61.csiro.au, wrote:
Happy that it is working for you in the Docker container. Based on the images you provided, it seems that the compiler is generating instructions for a newer microarchitecture than what qemu is simulating. This is why seL4test is getting a user exception. Do you tweak the microarchitecture settings at all? Otherwise what version is the compiler in the VM that you are using?
Kent.
Changing the VMware settings shouldn't cause the problem. If you find yourself trying to solve this again in the future, maybe run "ninja -j1 -v" into a log file, and see if gcc is being invoked with the correct flags: "-march=nehalem -mno-mmx -mno-sse -mno-sse2 -mno-3dnow". These should prevent the instructions that are causing the user exception to occur in seL4test, yet the binary that you sent had instructions from the AVX SIMD extensions which the nehalem microarch doesn't have.
Kind regards,
Kent.
________________________________
From: Jeremiah Peschka
Thank you for digging into this. Through your advice, I was able to track this down to an errant CFLAGS += “-march=native” in my environment configuration. Jeremiah Peschka On Oct 24, 2018, 05:11 -0700, Kent.Mcleod@data61.csiro.au, wrote:
the binary that you sent had instructions from the AVX SIMD extensions which the nehalem microarch doesn't have.
participants (2)
-
Jeremiah Peschka -
Kent.Mcleod＠data61.csiro.au