l4-hackers August 2010

l4-hackers@os.inf.tu-dresden.de

14 participants
10 discussions

Debugging applications on Fiasco.OC. and questions about L4re
by Pablo Montesinos 01 Sep '10

01 Sep '10

(sorry if it's a duplicate, I sent the previous one from an account outside the mailing list and I did not know whether it would go through) Hi, I need to debug an application that I've ported to Fiasco.OC and I was wondering what is the preferred way to do it. (The application works fine in Linux, but there must be something wrong with the libraries I ported). Jdb seems not very friendly if all you want to do is debugging an application. My second question is about L4re. So far, all the applications running on my Fiasco.OC are console-based. However, I would like to run more complex apps that might require a graphical environment. I noticed that, with L4env, it was possible to have it. Is it possible to do it with L4re? Any plans to add it in the near future. I would use Genode, but I've been told at the Genode list that Fiasco.OC is not supported by Genode. Is there an alternative to Genode on L4re? Thanks, Pablo

2 3

Fiasco.OC hangs in Intel Core 2 duo
by Karthik Vadambacheri Manian 29 Aug '10

29 Aug '10

Hi all, I compiled the new Fiasco.OC microkernel and L4RE in my Core 2 Duo PC with gcc 4.4.3. While configuring the Fiasco.OC microkernel I selected PC architecture as AMD64 and CPU type as Intel Core 2. But while configuring L4RE when I selected the PC architecture as AMD64 there is no option for CPU type as Intel Core 2. Hence I selected PC type as K8 which is one of the options. I created the cd image using *make grub2iso E=hello. *But when I run the virtual machine in qemu-system-x86_64 it hangs. I have tested the same with different PC type as K10/Barcelona, opteron, but got the same result. I have pasted the output below: ========================================================= $ qemu-system-x86_64 -m 1024m -cdrom hello.iso -boot d -serial stdio Welcome to Fiasco.OC (amd64)! L4/Fiasco.OC amd64 microkernel (C) 1998-2010 TU Dresden Rev: r16 compiled with gcc 4.4.3 for Intel Core2 [] Build: #1 Tue Aug 17 12:12:24 EDT 2010 Performance-critical config option(s) detected: CONFIG_NDEBUG is off Superpages: yes Kmem:: cpu page at 3fde6000 (4096Bytes) ACPI-Init ACPI: RSDP = 0xf8960 pRSDT = 3fffde30 pXSDT = 0 ACPI: OEM: BOCHS MADT = 0x201fdeb0 IO-APIC: struct: 0x201fdee4 adr=fec00000 IO-APIC: dual 8259: yes IO-APIC: ovr[ 0] 00 -> 2 IO-APIC: ovr[ 1] 05 -> 5 IO-APIC: ovr[ 2] 09 -> 9 IO-APIC: ovr[ 3] 0a -> a IO-APIC: ovr[ 4] 0b -> b IO-APIC: NOTE IRQ overrides are ignored! IO-APIC: pins 23 PIN[ 0m]: vector=20, del=0, dm=physical, dest=0 (high, edge) PIN[ 1m]: vector=21, del=0, dm=physical, dest=0 (high, edge) PIN[ 2m]: vector=22, del=0, dm=physical, dest=0 (high, edge) PIN[ 3m]: vector=23, del=0, dm=physical, dest=0 (high, edge) PIN[ 4m]: vector=24, del=0, dm=physical, dest=0 (high, edge) PIN[ 5m]: vector=25, del=0, dm=physical, dest=0 (high, edge) PIN[ 6m]: vector=26, del=0, dm=physical, dest=0 (high, edge) PIN[ 7m]: vector=27, del=0, dm=physical, dest=0 (high, edge) PIN[ 8m]: vector=28, del=0, dm=physical, dest=0 (high, edge) PIN[ 9m]: vector=29, del=0, dm=physical, dest=0 (high, edge) PIN[10m]: vector=2a, del=0, dm=physical, dest=0 (high, edge) PIN[11m]: vector=2b, del=0, dm=physical, dest=0 (high, edge) PIN[12m]: vector=2c, del=0, dm=physical, dest=0 (high, edge) PIN[13m]: vector=2d, del=0, dm=physical, dest=0 (high, edge) PIN[14m]: vector=2e, del=0, dm=physical, dest=0 (high, edge) PIN[15m]: vector=2f, del=0, dm=physical, dest=0 (high, edge) PIN[16m]: vector=30, del=0, dm=physical, dest=0 (high, edge) PIN[17m]: vector=31, del=0, dm=physical, dest=0 (high, edge) PIN[18m]: vector=32, del=0, dm=physical, dest=0 (high, edge) PIN[19m]: vector=33, del=0, dm=physical, dest=0 (high, edge) PIN[20m]: vector=34, del=0, dm=physical, dest=0 (high, edge) PIN[21m]: vector=35, del=0, dm=physical, dest=0 (high, edge) PIN[22m]: vector=36, del=0, dm=physical, dest=0 (high, edge) PIN[23m]: vector=37, del=0, dm=physical, dest=0 (high, edge) Allocate cpu_mem @ 0xfffffffffffe9000 Local APIC[00]: version=14 max_lvt=5 APIC ESR value before/after enabling: 00000000/00000000 Using the PIT (i8254) on IRQ 2 for scheduling CPU[0]: GenuineIntel (6:2:3:0) Model: Unknown CPU at 2397 MHz 32 KB L1 I Cache (8-way associative, 64 bytes per line) 32 KB L1 D Cache (8-way associative, 64 bytes per line) 2048 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 32768 bytes (8 pages) Calibrating timer loop... ======================================================== Also while creating image using *make grub2iso E=hello*, the fiasco microkernel could not be located by the make script. It said the following error. $ make grub2iso E=hello make[1]: Entering directory `/home/karthik/Research/tudos/src/l4' Processing entry 'hello' Could not find 'fiasco' with path ':/home/karthik/Research/tudos/src/ubuild/bin/amd64_K8:/home/karthik/Research/tudos/src/ubuild/bin/amd64_K8/l4f:/home/karthik/Research/tudos/src/ubuild/lib/amd64_K8:/home/karthik/Research/tudos/src/ubuild/lib/amd64_K8/l4f' at tool/lib/L4/ModList.pm line 271. But when I made a symbolic link to the fiasco microkernel built previously to one of the directories in the above path, it got resolved. It would be great if it could find the microkernel by itself. Please let me know how to overcome the above issues. Thanks a lot for your time, karthik

3 3

loading "dpci" module from vancouver fails.
by Shyamali Mukherjee 24 Aug '10

24 Aug '10

My grub menu entry looks like below: SARGS="S0_DEFAULT hostserial hostvga:0x40000,0x40000 hostkeyb:0,0x60,1,12 startlate:0xfffffffd" VMMARGS="PC_PS2 kbmodifier:0x40000" LABEL novaiommu MENU LABEL NOVA (IOMMU) KERNEL mboot.c32 APPEND /nul/hypervisor serial dmar --- \ /nul/sigma0.nul $SARGS --- \ /nul/vancouver.nul $VMMARGS dpci:2,0,0 82576vf:0xf7ce0000,0xf7cc0000 sigma0::dma sigma0::mem:64 --- \ /tools/munich sigma0::attach --- \ /demo/linux/bzImage root=/dev/ram0 clocksource=tsc sigma0::attach --- \ /demo/linux/initrd sigma0::attach --- \ /nul/tutor.nul TEXT HELP This setup has DMA remapping. The first Linux VM has direct access to your first network card and creates a bridge to the virtual network. You need Intel VT-d support for this. ENDTEXT Observation: -------------------- 1. I can not have "hypervisor serial dmar".. Can ONLY use "hypervisor dmar" or "serial". 2. I figured that it fails to load "dpci" module. I have looked at pcidirect.cc available under: nova-userland-0.2/vancouver/model/pcidirect.cc It says: "Example: Use 'dpci:2,,0,0x21' to attach the first network controller to 00:04.1.", Then from build_cd.sh I see "dcpi:2,0,0" But boot fails: Please see screenshot attached. 3. where can I find "sigma0" and "munich" sources. It seems in "NUL release 0.2" has these prebuilt. Only sources I see are like for vancouver.nul. --thanks

3 2

Using L4Linux on Fiasco.OC - How?
by Andreas Speier 10 Aug '10

10 Aug '10

Hi, I just started porting some Projects running on L4Linux on the "old" Fiasco to Fiasco.OC with the current L4Linux version. Starting with the "hello" example of the documentation was no problem, but I could not find out how things have to be configured when using L4Linux. Which dependencies must be regarded to make it run properly? Is there any documentation I could use, or can anyone publish some example documentation and configuration to run L4Linux on Fiasco.OC? Regards, Andreas

2 1

GUI: mag, dope, nitpicker, goos
by Taru Karttunen 09 Aug '10

09 Aug '10

Hello What exactly is the current situation with the various graphics related components? Mag appears to be a nitpicker replacement and dope ran under nitpicker. Goos is a new low level framework that is used by mag? Then there are various fb* like fb-drv and fbterminal. What is the current direction of the graphics and GUI components, how do they stack and what is the preferred way to get them to run? Are they documented somewhere? - Taru Karttunen

2 1

Userland [was] NOVA Microhypervisor 0.2 prerelease
by John van V. 07 Aug '10

07 Aug '10

About Userland: I am supporting a L4 drop-in replacement for Linux where a primary goal is to allow manufacturers to make drivers in the same way they make them for Micro$oft. Another goal is to streamline the creation of L4 development workstations that, for instance, can reside on a cell phone. I am doing this in this way because it makes sense to, and benefits, Userland. John Decade-old Linux Society blog: http://linux-society.blogspot.com/ -- Empathy http://thinman.com/empathy Photography http://thinman.com/photography Technology http://thinman.com

1 0

[ANNOUNCE] NOVA Microhypervisor 0.2 prerelease
by Udo A. Steinberg 06 Aug '10

06 Aug '10

Hi, The NOVA project is happy to announce that there is a new prerelease of the NOVA microhypervisor available for download at http://www.hypervisor.org/ or http://os.inf.tu-dresden.de/~us15/nova/ under the terms of the GNU General Public License version 2. NOVA is based on a modern microhypervisor written in C++ and assembler. The current implementation supports x86-32 SMP platforms with hardware virtualization features such as Intel VT-x/VT-d or AMD-V, and facilitates running multiple unmodified guest operating systems in virtual machines with near-native performance. On machines without VT-x or AMD-V, the functionality is reduced to that of a microkernel. The most prominent new feature is support for I/O virtualization and direct assignment of host devices to guest VMs using the IOMMU. For a list of other changes, please see the change log included with the source code. Cheers, - Udo

2 1

Fiasco support for ARM trustzone extensions
by Rosenberry, Robert D. 05 Aug '10

05 Aug '10

Hello, Which platforms are known to work with the ARM trustzone extensions for virtualization using the Fiasco kernel? Suggestions for preferred development boards would be appreciated. Rob

2 1

L4Re Makefile bug?
by Michael Kirkpatrick 03 Aug '10

03 Aug '10

I've downloaded the l4re-core-2010070715.tar.bz2 archive, and I've tried to build the project. I have no problem compiling the Fiasco.OC kernel, but the L4Re core build seems to be entering an infinite loop. After running for a few seconds, I get the following lines repeated forever: All checked ok. scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig make[11]: Nothing to be done for `all'. I also noticed that I get this same infinite loop if I do make config (after the menu exits) or make oldconfig. Something about the post-config clean-up seems to be continuously forking new processes and looping. The comment at line 179 of the [l4dir]/Makefile indicates that make is called again for postprocessing, but I don't know make well enough to debug this problem. Any ideas what's causing the problem? I've included the output below for reference. Thanks, Michael Kirkpatrick $ tar xf l4re-core-2010070715.tar $ cd l4re-core-2010070715/src/l4 $ make B=builddir --no-print-directory All checked ok. Creating build directory "builddir"... HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/basic/hash HOSTCC scripts/kconfig/conf.o [l4dir]/tool/kconfig/scripts/kconfig/conf.c: In function 'conf_askvalue': [l4dir]/tool/kconfig/scripts/kconfig/conf.c:105: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [l4dir]/tool/kconfig/scripts/kconfig/conf.c: In function 'conf_choice': [l4dir]/tool/kconfig/scripts/kconfig/conf.c:307: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -o [l4dir]/mk/Kconfig # # configuration written to .kconfig # scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig All checked ok. scripts/kconfig/conf -s [l4dir]/mk/Kconfig gcc -fPIC -Wall -pedantic -g -m32 -c [l4dir]/tool/gendep/deptrack.c -o [l4dir]/builddir/tool/gendep/deptrack.32.o gcc -fPIC -Wall -pedantic -g -m32 -c [l4dir]/tool/gendep/syscall.c -o [l4dir]/builddir/tool/gendep/syscall.32.o mkdir -p [l4dir]/builddir/tool/gendep/32 gcc -m32 -shared -Wl,-soname,[l4dir]/builddir/tool/gendep/32/libgendep.so -ldl -o [l4dir]/builddir/tool/gendep/32/libgendep.so [l4dir]/builddir/tool/gendep/deptrack.32.o [l4dir]/builddir/tool/gendep/syscall.32.o scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig All checked ok. scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig All checked ok. scripts/kconfig/conf -s [l4dir]/mk/Kconfig make[11]: Nothing to be done for `all'. scripts/kconfig/conf -s [l4dir]/mk/Kconfig scripts/kconfig/conf -s [l4dir]/mk/Kconfig All checked ok. scripts/kconfig/conf -s [l4dir]/mk/Kconfig ^Cmake[12]: *** Deleting file `[l4dir]/builddir/.config.all' make[15]: *** [silentoldconfig] Interrupt make[14]: *** [sub-make] Interrupt make[13]: *** [[l4dir]/builddir/.kconfig.auto] Interrupt make[12]: *** [[l4dir]/builddir/.config.all] Interrupt make[11]: *** [DROPSCONF_CONFIG_MK_POST_HOOK] Interrupt make[10]: *** [[l4dir]/builddir/.config.all] Interrupt make[9]: *** [DROPSCONF_CONFIG_MK_POST_HOOK] Interrupt make[8]: *** [[l4dir]/builddir/.config.all] Interrupt make[7]: *** [DROPSCONF_CONFIG_MK_POST_HOOK] Interrupt make[6]: *** [[l4dir]/builddir/.config.all] Interrupt make[5]: *** [[l4dir]/builddir/.config.all] Interrupt make[4]: *** [DROPSCONF_CONFIG_MK_POST_HOOK] Interrupt make[3]: *** [[l4dir]/builddir/.config.all] Interrupt make[2]: *** [[l4dir]/builddir/.config.all] Interrupt make[1]: *** [oldconfig] Interrupt make: *** [all] Interrupt

3 3

L4Re and Fiasco.OC on amd64
by Taru Karttunen 02 Aug '10

02 Aug '10

Hello I am trying to compile Fiasco.OC and L4Re on amd64, but the kernel fails to boot for some reason. Steps taken: 1) Checked out source from SVN 2) Compiled fiasco, make config, set amd64, make 3) Compiled L4Re (and set to amd64) 4) Created hello.iso with make grub1iso E=hello MODULE_SEARCH_PATH=bin/amd64_K8:~/l4r4/fiasco-build 5) Try to boot it with qemu-system-x86_64 -cdrom images/hello.iso -no-reboot -no-shutdown -cpu phenom 6) Fiasco crashes with http://aoi.yi.org/~taruti/crash.png Here is info on the repository: hydra:fiasco$ svn info Path: . URL: http://svn.tudos.org/repos/oc/tudos/trunk/kernel/fiasco Repository Root: http://svn.tudos.org/repos/oc/tudos Repository UUID: d050ee49-bd90-4346-b210-929a50b99cfc Revision: 11 Node Kind: directory Schedule: normal Depth: empty Last Changed Author: l4check Last Changed Rev: 11 Last Changed Date: 2010-07-07 12:49:37 +0300 (Wed, 07 Jul 2010) How do I debug this further? - Taru Karttunen

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers August 2010