l4-hackers

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

2827 discussions

Re: l4-hackers Digest, Vol 124, Issue 4
by Иван Филиппов 06 Aug '13

06 Aug '13

Hi Lluis, Have pretty much the same as you sad - can't load both qemu for unknown memory address, neither for grub2 for Ubuntu 13.04, but it compiles well. I`ll ask what happens tomorrow on upcoming russian Fiasco/Virtualization school with Bjorn Doebel at al. and tell you what happens. Probably the best choose is Qemu emulator, if you don't have already written software, not to reload system every time you need. I compiled with i386 option both FiascoOC/L4RE and them works well. just as here: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/<http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html> 004894.html<http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html> I have 4.7 compiler too. Best wishes, 2013/8/5 <l4-hackers-request(a)os.inf.tu-dresden.de> > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > or, via email, send a message with subject or body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > > Today's Topics: > > 1. Unable to boot Fiasco.OC on amd64 (Llu?s Vilanova) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 04 Aug 2013 22:44:24 +0300 > From: Llu?s Vilanova <vilanova(a)ac.upc.edu> > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: Unable to boot Fiasco.OC on amd64 > Message-ID: <87eha95jhj.fsf(a)fimbulvetr.bsc.es> > Content-Type: text/plain; charset="us-ascii" > > Hi there, > > After having to play with the load addresses of both fiasco and some of the > modules [1], I've been able to boot fiasco, but only to find it chokes on > some > assertion, immediately following a pager warning (see error.jpg > screenshot). > > Sorry for using a screenshot, but I've been unable to make the serial > console > work, so no copy&paste is available. > > As I'm new to L4, I don't know if the error is due to my changes or due to > some > other mis-configuration on the boot process. See the attached grub2.txt > for the > GRUB2 entries I've tried (the error corresponds to the first entry). > > I'm using the l4re-core-2013060718 tarball, all compiled on a debian > testing > (gcc 4.7.3). > > Any help on the boot or the serial console support is much appreciated. > > > Thanks a lot, > Lluis > > [1] To avoid some region overlaps, see attached l4.patch, and memory.jpg > for the > memory range configuration of the machine. > >

3 10

mmap2 on L4Linux rev 37
by Sebastian Sumpf 06 Aug '13

06 Aug '13

Hi L4 hackers, recently I started to use L4Linux r37 on ARM and experienced some issues with the 'sys_mmap_pgoff'-system call. When a user-level task tried to map a file the 'pgoff' parameter was usually bogus. Doing a little research I found that it was caused by the 'sys_mmap2' implementation in 'entry.S'. The function overwrites the 'pgoff' argument on the stack with r5 (as it is usually passed from user land), since in L4Linux this code gets called from the dispatch routine, 'pgoff' was set to whatever r5 was, and thus leading to bus errors later on. Cheers, Sebastian -- Sebastian Sumpf Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 1

why Fiasco kernel is named as fiasco
by Raja Sekhar 05 Aug '13

05 Aug '13

Hello to all, I just want to know that why fiasco micro-kernel named as fiasco ..... can you please give me the answer....... * Thanks,* Raja Sekhar

2 1

Unable to boot Fiasco.OC on amd64
by Lluís Vilanova 04 Aug '13

04 Aug '13

Hi there, After having to play with the load addresses of both fiasco and some of the modules [1], I've been able to boot fiasco, but only to find it chokes on some assertion, immediately following a pager warning (see error.jpg screenshot). Sorry for using a screenshot, but I've been unable to make the serial console work, so no copy&paste is available. As I'm new to L4, I don't know if the error is due to my changes or due to some other mis-configuration on the boot process. See the attached grub2.txt for the GRUB2 entries I've tried (the error corresponds to the first entry). I'm using the l4re-core-2013060718 tarball, all compiled on a debian testing (gcc 4.7.3). Any help on the boot or the serial console support is much appreciated. Thanks a lot, Lluis [1] To avoid some region overlaps, see attached l4.patch, and memory.jpg for the memory range configuration of the machine. menuentry "L4" { multiboot /boot/l4/bootstrap -serial module /boot/l4/fiasco /fiasco -serial_esc module /boot/l4/l4f/sigma0 /sigma0 module /boot/l4/l4f/moe /moe module /boot/l4/l4f/hello /hello } menuentry "L4 - L4re" { multiboot /boot/l4/bootstrap -serial module /boot/l4/fiasco /fiasco -serial_esc module /boot/l4/l4f/sigma0 /sigma0 module /boot/l4/l4f/moe /moe --init=rom/hello module /boot/l4/l4f/l4re /l4re module /boot/l4/l4f/hello /hello } -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth

1 0

Use of the PC value in interrupt/exception handlers
by Piyus Kedia 03 Aug '13

03 Aug '13

Dear all, We are working on developing a dynamic binary translator for the kernel. Towards this, we wanted to confirm if the interrupted PC value pushed on stack by an interrupt/exception is used by the interrupt/exception handlers? For example, is the PC value compared against a fixed address to determine the handler behaviour (like Linux's page fault handler compares the faulting PC against an exception table, to allow functions like copy_from_user to fault). Basically, we are wondering if it is safe to replace the pushed PC value on stack by another value. This would be safe if the PC value is only used for returning from interrupt, or for reading contents at that PC address (e.g., to decode the instruction at current PC). It would be unsafe if the value of the address itself is meaningful to the handler. We found that in FreeBSD segment-not-present exception handler checks the trapped PC value against some fixed kernel PC by looking at the code, except that it is only used for debugging purposes. It would be nice if somebody could also confirm this. Thanks, Piyus

2 2

l4linux: l4x_setup_memory:Cant get main memory
by Rudolf Weber 01 Aug '13

01 Aug '13

2 13

Fwd: Interrupt Handlers
by Piyus Kedia 01 Aug '13

01 Aug '13

Hi All, I am working on dynamic binary translator. Please tell me if anybody know if in L4-microkernel interrupted kernel PC is ever used in interrupt handlers? Thanks and regards, Piyus

2 1

Using the tmpfs library
by Michael Weiß 01 Aug '13

01 Aug '13

Hi, I want to do some file operations in a native l4re application. using fopen, fgetc, fprintf... from libc. I know that this is possible for the rom filesystem. However, I want to create new files during runtime which are also writable. I found the VFS implementation l4/pkg/tmpfs. but I do not really understand how that VFS stuff works, as there also is no header file for tmpfs. How can I access the tmpfs functionality within my application? For my application it would be sufficient to just have temporary files, which I think is exactly what the tmpfs lib provides. I already linked the tmpfs lib to my application and tried to use mount from sys/mount.h. However, I have no idea which parameters and how the path than has to look like for fopen. Is there some example code which shows howto use this lib in an application? Thanks, Michael

2 1

Unexpected trap while booting Fiasco
by Stefan Fritsch 01 Aug '13

01 Aug '13

Hi, sometimes I get 'Unexpected trap while booting Fiasco' when booting L4Re with grub 0.97. How often this happens seems to depend on the loaded modules, but I haven't been able to determine some rule when it will happen. It does not depend on the number or total size of the modules reaching a certain size. However, since we upgraded to l4re-snapshot-2013060718 from -2013021819, it always happen for me in the below module configuration (it only happened rarely before the upgrade). It looks like parts of fiasco are not mapped at the correct address. Do you have any idea what could cause this? Cheers, Stefan L4 Bootstrapper Build: #1 Mon Jul 29 19:27:21 CEST 2013, x86-32, 4.4.5 Limiting 'RAM' region [ 40005000, c4eb9fff] { 84eb5000} to [ 40005000, bcffffff] { 7cffb000} due to 3024 MB address limit Dropping 'RAM' region [ c50bc000, d82eefff] { 13233000} due to 3024 MB address limit Dropping 'RAM' region [ dafff000, daffffff] { 1000} due to 3024 MB address limit Dropping 'RAM' region [100000000, 11e5fffff] { 1e600000} due to 3024 MB address limit RAM: 0000000000000000 - 000000000009d7ff: 630kB RAM: 0000000000100000 - 000000001fffffff: 523264kB RAM: 0000000020200000 - 0000000040003fff: 522256kB RAM: 0000000040005000 - 00000000bcffffff: 2047980kB Total RAM: 3021MB Moving up to 22 modules behind 1100000 moving module 00 { 319000-3adc23 } -> { a669000-a6fdc23 } [609316] moving module 01 { 3ae000-3f0a71 } -> { a6fe000-a740a71 } [273010] moving module 02 { 3f1000-5be834 } -> { a741000-a90e834 } [1890357] moving module 03 { 5bf000-6ae6e5 } -> { 9882000-99716e5 } [980710] moving module 04 { 6af000-792266 } -> { 9972000-9a55266 } [930407] moving module 05 { 793000-996b94 } -> { 9a56000-9c59b94 } [2112405] moving module 06 { 997000-99802b } -> { 9c5a000-9c5b02b } [4140] moving module 07 { 999000-12e9408 } -> { 9c5c000-a5ac408 } [9765897] moving module 08 { 12ea000-12eab20 } -> { 1100000-1100b20 } [2849] moving module 09 { 12eb000-12eb547 } -> { 1101000-1101547 } [1352] moving module 10 { 12ec000-13da7a1 } -> { 1102000-11f07a1 } [976802] moving module 11 { 13db000-1a39b4e } -> { 11f1000-184fb4e } [6679375] moving module 12 { 1a3a000-7839fff } -> { 1850000-764ffff } [98566144] moving module 13 { 783a000-7c6b5ee } -> { 7650000-7a815ee } [4396527] moving module 14 { 7c6c000-8eebfff } -> { 7a82000-8d01fff } [19398656] moving module 15 { 8eec000-8eec025 } -> { 8d02000-8d02025 } [38] moving module 16 { 8eed000-8ef0f17 } -> { 8d03000-8d06f17 } [16152] moving module 17 { 8ef1000-8f5d42b } -> { 8d07000-8d7342b } [443436] moving module 18 { 8f5e000-942ca58 } -> { 8d74000-9242a58 } [5040729] moving module 19 { 942d000-9610fff } -> { 9243000-9426fff } [1982464] moving module 20 { 9611000-9880749 } -> { 9427000-9696749 } [2553674] moving module 21 { 9881000-988119e } -> { 9697000-969719e } [415] moving module 03 { 9882000-99716e5 } -> { 9698000-97876e5 } [980710] moving module 04 { 9972000-9a55266 } -> { 9788000-986b266 } [930407] moving module 05 { 9a56000-9c59b94 } -> { 986c000-9a6fb94 } [2112405] moving module 06 { 9c5a000-9c5b02b } -> { 9a70000-9a7102b } [4140] moving module 07 { 9c5c000-a5ac408 } -> { 9a72000-a3c2408 } [9765897] Scanning /l4/fiasco -serial_esc -esc -noscreen Scanning /l4/sigma0 Scanning /l4/moe rom/vs-top.cfg Bootloader MMAP: [ 0, 9d800) RAM (1) [ 9d800, a0000) reserved (2) [ e0000, 100000) reserved (2) [ 100000, 20000000) RAM (1) [ 20000000, 20200000) reserved (2) [ 20200000, 40004000) RAM (1) [ 40004000, 40005000) reserved (2) [ 40005000, c4eba000) RAM (1) [ c4eba000, c50bc000) reserved (2) [ c50bc000, d82ef000) RAM (1) [ d82ef000, daeef000) reserved (2) [ daeef000, daf9f000) ACPI NVS (4) [ daf9f000, dafff000) ACPI (3) [ dafff000, db000000) RAM (1) [ db000000, dfa00000) reserved (2) [ f8000000, fc000000) reserved (2) [ fec00000, fec01000) reserved (2) [ fed08000, fed09000) reserved (2) [ fed10000, fed18000) reserved (2) [ fed18000, fed19000) reserved (2) [ fed19000, fed1a000) reserved (2) [ fed1c000, fed20000) reserved (2) [ fee00000, fee01000) reserved (2) [ ffca0000, 100000000) reserved (2) [100000000, 11e600000) RAM (1) Relocated mbi to [0x2e0000-0x2e0304] Loading /l4/fiasco Loading /l4/sigma0 Loading /l4/moe find kernel info page... found kernel info page at 0x400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern /l4/fiasco [ 9d800, 9ffff] { 2800} Arch BIOS [ e0000, fffff] { 20000} Arch BIOS [ 100000, 10a1b3] { a1b4} Sigma0 /l4/sigma0 [ 140000, 18c25f] { 4c260} Root /l4/moe [ 2d0000, 2e4427] { 14428} Boot bootstrap [ 2e0000, 2e0401] { 402} Root Multiboot info [ 300000, 38ffff] { 90000} Kern /l4/fiasco [ 400000, 49dfff] { 9e000} Kern /l4/fiasco [ 1100000, a3c2408] { 92c2409} Root Module [ 20000000, 201fffff] { 200000} Arch BIOS [ 40004000, 40004fff] { 1000} Arch BIOS [ c4eba000, c50bbfff] { 202000} Arch BIOS [ d82ef000, daeeefff] { 2c00000} Arch BIOS [ daeef000, daf9efff] { b0000} Arch BIOS [ daf9f000, daffefff] { 60000} Arch BIOS [ db000000, df9fffff] { 4a00000} Arch BIOS [ f8000000, fbffffff] { 4000000} Arch BIOS [ fec00000, fec00fff] { 1000} Arch BIOS [ fed08000, fed08fff] { 1000} Arch BIOS [ fed10000, fed19fff] { a000} Arch BIOS [ fed1c000, fed1ffff] { 4000} Arch BIOS [ fee00000, fee00fff] { 1000} Arch BIOS [ ffca0000, ffffffff] { 360000} Arch BIOS API Version: (87) experimental Sigma0 config ip:001001dc sp:002df150 Roottask config ip:001401c4 sp:00000000 Starting kernel /l4/fiasco at 00300834 EAX f0000000 EBX 2BADB002 ECX 00303000 EDX 00400000 ESI 00035dac EDI 002d81cf EBP 0038fd28 ESP 0038fd20 EIP f00653f0 EFLAGS 00013046 CS 0010 SS 0018 DS 0018 ES 0018 FS 0000 GS 0000 trapno 14, error 00000000, from kernel mode page fault linear address f00653f0 00300055 002dce5c 002dcfe8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Unexpected trap while booting Fiasco! objdump shows that EIP/pagefault address is the start of init_global_kip(): f00653f0 g F .text 00000014 _ZN3Kip15init_global_kipEPS_ -- genua Gesellschaft fuer Netzwerk- und Unix-Administration mbH Domagkstrasse 7, 85551 Kirchheim bei Muenchen tel +49 89 991950-0, fax -999, www.genua.de Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander, Bernhard Schneck. Amtsgericht Muenchen HRB 98238

2 2

Build errors with L4
by Bob Stewart 29 Jul '13

29 Jul '13

I pulled down revisions 56 of l4re per the l4re download instructions on an x86 platform running Ubuntu 13.04. I'm cross compiling for an ARM 8 Beaglebone platform. I created a set of tool links pointing to gcc, g++, ar, ld, etc. from the current Genode toolchain. I then followed the l4 build instructions. The build proceeded normally until is started to link in libc static libraries at which point the following errors killed the build: ... make[5]: Entering directory `/home/bob/fiasco/builds/l4/pkg/loader/server/src/OBJ-arm_armv7a-l4f' ... Compiling main.o ... Compiling slab_alloc.o ... Compiling region.o ... Compiling app_task.o ... Compiling name_space.o ... Compiling log.o ... Compiling global.o ... Compiling sched_proxy.o ... Compiling alloc.o ==> Linking loader /home/bob/fiasco/builds/l4/lib/arm_armv7a/l4f/libuc_c.a(__exit_handler.o): In function `__new_exitfn': /home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/stdlib/_atexit.c:259: undefined reference to `__emutls_v.__libc_errno' /home/bob/fiasco/builds/l4/lib/arm_armv7a/l4f/libuc_c.a(malloc.o): In function `malloc': /home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/stdlib/malloc-standard/malloc.c:1018: undefined reference to `__emutls_v.__libc_errno' /home/bob/fiasco/builds/l4/lib/arm_armv7a/l4f/libuc_c.a(fwrite.__DO_UNLOCKED.o): In function `fwrite_unlocked': /home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/stdio/fwrite.c:36: undefined reference to `__emutls_v.__libc_errno' /home/bob/fiasco/builds/l4/lib/arm_armv7a/l4f/libuc_c.a(__errno_location.o): In function `__errno_location': /home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/misc/internals/__errno_location.c:16: undefined reference to `__emutls_v.__libc_errno' /home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/misc/internals/__errno_location.c:16: undefined reference to `__emutls_v.__libc_errno' /home/bob/fiasco/builds/l4/lib/arm_armv7a/l4f/libuc_c.a(_trans2w.o):/home/bob/fiasco/builds/l4/pkg/uclibc/lib/uclibc/src/libc/stdio/_trans2w.c:67: more undefined references to `__emutls_v.__libc_errno' follow make[5]: *** [loader] Error 1 Is there some undocumented compiler flag related to TLS I should be setting somewhere to fix these library references? Thanks you Bob Stewart

5 7

Jump to page:

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