- l4-hackers - example.com Site

Dataspaces mappings for L4Linux
by Julian Grizzard 21 Dec '05

21 Dec '05

All, I'm running Fiasco on i386 with L4Linux 2.6. Is there an easy way to find out where all L4Linux DMphys DS's are mapped in its virtual memory? My goal is to get the entire mapping of DS's to virtual memory location in L4Linux. I am able to get some of these mappings from the dump-l4 example and from data printed out from L4Linux. However, I don't know where all DS's are mapped (e.g. "L4thread stack"...). Here's some specific questions I am trying to answer: 1) Where is "L4RM heap" mapped? 2) Where are "syms vmlinux" and "lines vmlinux" mapped? 3) Where is "L4thread TCB table" mapped? 4) Where are the "L4thread stack" DS's mapped? 5) Where is "Ghost page 1" mapped? What is that DS by the way? 6) There seems to be some DS's for L4Linux that are created by the loader and there is also the "L4Linux main memory" DS. Are there any other mappings in L4Linux's virtual memory? Thanks! Julian

2 1

wrong gcc major version "2"- use 3.x for l4io
by Konstantinos Pachopoulos 21 Dec '05

21 Dec '05

Hi, issuing a "make" in /usr/src/l4linux/l4, i end up with this error: ----------------------------------------------------- ===Building IDL & includes of "l4io"=== PWD= /usr/src/l4linux/l4/pkg/l4io make -C l4io idl make[2]: Entering directory '/usr/src/l4linux/l4/pkg/l4io' Makefile:8: ***Wrong gcc major version "2"- use 3.x for l4io. Stop. make[2]: Leaving directory '/usr/src/l4linux/l4/pkg/l4io' make[1]: ***[l4io.headers] Error 2 make[1]: Leaving directory '/usr/src/l4linux/l4/pkg' make: ***[pkg] Error 2 kastor:/usr/src/l4linux/l4# ----------------------------------------------------- I use gcc-2.95 for this. However, using gcc-3.3, i ended up with exactly the same error. Having problems using byacc, i changed the conf file and now i use bison, without any problems from this point. I am using the latest sources from CVS- downloaded yesterday in fact. Any ideas about the l4io problem? Thanks, Kostas ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 1

Is it a problem to use l4env_freebsd - mode?
by Arthur Mielimonka 21 Dec '05

21 Dec '05

Hello, I was told recently that you are currently in the process of dumping oskit in favor of uclibc or dietlibc. For my work, I need the log_net server which only compiles with oskit. So I cannot abandon it. Are they any problems or reasons why one shouldn't use oskit? Is it possilble to use a mixed configuration (e.g. compile log_net with oskit and own packages with dietlibc and use them together)? Thanks, Arthur

6 5

Track Program_Counter(PC)/regs of L4Linux Task
by Julian Grizzard 19 Dec '05

19 Dec '05

All, I am currently running L4Linux2.6.14 on the Fiasco l4v2 microkernel using i386 arch with mostly default configurations. I need the ability to track the program counter and registers of all threads in the L4Linux task. Here's exactly what I would like to be able to do from a monitoring L4 task: -Obtain the PC/regs for the first thread (thread 0) for L4Linux just before the thread executes it's first instruction. It would be nice to make the thread wait for a signal before beginning execution. -Obtain the PC/regs for any additional thread created or any thread moved for L4Linux (i.e. from a l4_thread_ex_regs call) just before that thread executes. Again, it would be nice to make that thread wait for a signal before beginning its execution. -Randomly preemptively obtain the PC/regs for all threads of L4Linux. -Obtain the PC/regs for all threads of L4Linux on demand. -Receive notification of thread exit for all threads of L4Linux. There are a few items that I do not yet fully understand that *may* make matters more difficult: -The setup code executing in libloader.s.so. -Trampoline code There are a few assumptions I am willing to have for initial testing to make the development easier: -Assume Task number of L4Linux is known by the microkernel (i.e. hard code it in). -Assume Task number of monitoring thread is known by the microkernel. As a first crack, I have added some code to the microkernel to print out information on the L4Linux task, to see if that information would be good to transfer to the monitoring task. Below is a summary of things I have tried and results seen: MODIFICATION #1 l4/kernel/fiasco/src/kern/context.cpp Context::schedule() Goal: Track current PC of L4Linux threads ======================= ... /* in the for loop */ Sys_task_new_frame *regs = sys_frame_cast<Sys_task_new_frame>(next_to_run->regs()); L4_uid id = regs->dst(); if (id.task() == 0xC) // hard coded task of L4Linux { unsigned int ip = next_to_run->regs()->ip(); unsigned int sp = next_to_run->regs()->sp(); printf("task: %d.%d @ ip: %08x sp: %08x\n", id.task(), id.lthread(), ip, sp); } ... ======================= Results: task: 12.3 @ ip: 004ccb0b sp: b00fff80 task: 12.3 @ ip: 004cd303 sp: b01fff7c task: 12.4 @ ip: 004cca9d sp: b00fff80 task: 12.5 @ ip: 00402ae6 sp: 00657f50 ======================= Notes: 004ccb0b - right after an 'int 0x30' in timer_irq_thread 004cd303 - right after an 'int 0x30' in irq_thread_hw 004cca9d - right after an 'int 0x30' in timer_irq_thread 00402ae6 - right after an 'int 0x30' in l4x_idle MODIFICATION #2 l4/kernel/fiasco/src/kern/thread-syscall.cpp Thread::sys_task_new() Goal: Track starting PC of main L4Linux thread (i.e. thread 0) ======================= ... /* near tail of for loop, just before return */ if (taskno == 0xC) // hard coded L4Linux task ID { printf("new task: %d @ ip: %08x sp: %08x\n", taskno, regs->ip(), regs->sp()); } ======================= Results: new task: 12 @ ip: 00015ea0 sp: 00008f6c ======================= Notes: 00015ea0 - part of the libloader.s.so code MODIFICATION #3 l4/kernel/fiasco/src/kern/thread-syscall.cpp Thread::sys_thread_ex_regs() Goal: Track PC entry of new L4Linux threads ======================= ... if (!dst->exists()) { unsigned int task_num = dst_id.task(); unsigned int lthread_num = regs->thread(); new_thread = true; check (new (dst_id) Thread (dst_task, dst_id, sched()->prio(), mcp()) == dst); if (taskno == 0xC) { printf("new thread: %d.%d @ ip: %08x sp: %08x\n", task_num, lthread_num, regs->ip(), regs->sp()); } } else { unsigned int task_num = dst_id.task(); unsigned int lthread_num = regs->thread(); if (taskno == 0xC) { printf("modified thread: %d.%d @ ip: %08x sp: %08x\n", task_num, lthread_num, regs->ip(), regs->sp()); } } ... ======================= Results: modified thread: 12.0 @ ip: ffffffff sp: ffffffff modified thread: 12.0 @ ip: ffffffff sp: ffffffff new thread: 12.1 @ ip: 0001ac10 sp: afe00000 new thread: 12.2 @ ip: 0001ac10 sp: aff00000 modified thread: 12.2 @ ip: ffffffff sp: ffffffff new thread: 12.3 @ ip: 0001ac10 sp: 00657ff8 modified thread: 12.3 @ ip: ffffffff sp: ffffffff new thread: 12.4 @ ip: 0001ac10 sp: b0100000 modified thread: 12.3 @ ip: ffffffff sp: ffffffff new thread: 12.5 @ ip: 0001ac10 sp: b0200000 modified thread: 12.3 @ ip: ffffffff sp: ffffffff new thread: 12.6 @ ip: 0001ac10 sp: b0300000 new thread: 12.7 @ ip: 0001ac10 sp: b0400000 ======================= Notes: 0001ac10 - part of the libloader.s.so code ffffffff - not really useful. wrong data perhaps. QUESTIONS: GENERAL QUESTIONS -Is there any easy to delay execution of newly created threads, both new task thread 0 and additional threads? -Is there an easy way to randomly interrupt L4Linux threads to check their PC value? -Do any L4Linux threads exit? MODIFICATION #1 -Seems like threads resume execution right after an interrupt. I don't see threads getting preempted in the middle of servicing a system call, for example. Any ideas why not? Further, is there one thread dedicated to handling system calls? -Is there any better way to track where all the L4Linux threads are? Maybe somewhere else besides the scheduler? Are any other classes/functions helpful to get this information? MODIFICATION #2 -I believe this is working correctly. See anything wrong here? MODIFICATION #3 -I would like to catch all instances of creating new threads for L4Linux. Will this current approach work, or is it not correct? If my implementation is correct: -Why are L4Linux threads getting modified? -Any idea why my ip and sp values are 0xffffffff for modified threads? -Looks like all new threads start at the same place. How would they distinguish from one another in terms of functionality? Is that encoded in their stack (e.g. when they issue a 'ret', they'll return to different locations or maybe arguments to their function are on the stack?) Any other comments you have would also be appreciated. Thanks! Julian

3 7

Postdoc position at Nijmegen (ROBIN project on OS verification)
by Erik Poll 15 Dec '05

15 Dec '05

(Apologies for multiple copies) The SoS (Security of Systems) group at the Radboud University of Nijmegen in the Netherlands has a vacancy for a postdoc for a 2-year period starting February 1 2006. The vacancy is in the EU project ROBIN (Robust Open Infrastructure), which is a joint project in collaboration with TU Dresden (more specifically Hermann Härtig's operating systems group), ST Micro Electronics and Secunet. The goal of the ROBIN project is to develop a robust platform (Operating System kernel) that can host legacy operating systems and their applications, but that is small enough (in the order of 50-100k lines of code) to apply rigorous formal analysis and construction techniques. The kernel of the robust platform will be written in C++ (with very small parts in assembly). The work in Nijmegen concentrates on the formal specification and verification of key security properties of the kernel. The objectives are to develop, evaluate and assess tool-supported formal methods for the specification and verification of low level systems code, especially operating-system kernel source-code. The aim is not a full verification of the kernel, but rather to show a perspective of what can be achieved with formal methods. A starting point for this work is the VFiasco project at TU Dresden. We are looking for candidates with a recent PhD in Computing Science, a strong background in formal methods, and an interest in applying formal methods to low-level system programs, such as operating system kernels. Experience with (interactive) theorem provers, program verification, or static analysis is a pré, as is an interest in security. You'll be collaborating with a second postdoc working on this project in Nijmegen for two years, Hendrik Tews, who'll be joining the SoS group starting February 2006. Pre-tax salary starts at 2625,- euro per month, but can be more depending on experience. For more info, contact Erik Poll <erikpoll(a)cs.ru.nl> or Hendrik Tews <tews(a)tcs.inf.tu-dresden.de>. The ROBIN project proposal is available on request from either Erik or Hendrik. You can apply by sending a letter of motivation and a detailed cv (preferably in PDF format) and contact details of at least two references to Erik Poll <erikpoll(a)cs.ru.nl> by January 2, 2006. Relevant links: - SoS group at Nijmegen: http://www.cs.ru.nl/sos - VFiasco project at Dresden: http://os.inf.tu-dresden.de/vfiasco/

1 0

L4Linux-2.6.14 perfomance question
by Der Herr Hofrat 12 Dec '05

12 Dec '05

HI ! I'm very new to L4Linux so my question might be obvious - anyway did not find anything directly related in the archive. For a start I did a quick performance comparison using lmbench-3.0. This comparison is based on the L4Linux-2.6 running a debina ramdisk lmbench-3.0 vs Linux-2.6.14 running from harddisk (though data files were in tempfs in both cases - so the HD should not really have much of an impact). L4Linux Linux 2.6.14 com lat.: (us) lat_pipe 14.1-14.5 2.0 lat_fifo 13.9-14.6 2.2 lat_unix 19.4-19.5 3.2 lat_sem 3.5 0.6 lat_proc: (us) fork 805-1249 80-82 exec 3124-3784 212-230 shell 9992-9997 2480-2592 tlb: 7,8,32 always 32 bw com: (MB/s) bw_pipe 921-958 1338-1352 bw_unix 429-753 1122-1138 lat mem: oopses under L4Linux - no results bw_mem: (MB/s) bcopy 3856-4066 5056-5080 rdwr 11937-13242 16052 syscall: (us) null 2.4-2.8 0.13 read 2.6-3.3 0.26-0.31 stat 4.4-4.9 0.89 open 6.5-8.1 1.16-1.39 The thing that supprises me is that the performance variation is much higher than on regular linux - in both cases the system was idle except for lmbench running, so I'm excluding any syslog parties or cron jobs fireing at inconvenient times (i.e bandwidth of UNIX sockets has a variance of almost 50% ?). Generally the performance difference is much larger than I would have expected, especially also in areas where I don't quite understand where the u-kenrel can impact the Linux system (i.e. bcopy, memory read-write) Are these values in the usual range or did I screw up fundamentally ? thx ! Prof. Nicholas Mc Guire University of Lanzhou Distributed & Embedded System Lab http://dslab.lzu.edu.cn School of Information Science and Engeneering mcguire(a)lzu.edu.cn Tianshui South Road 222. Lanzhou 730000 .P.R.China Tel:+86-931-8912025 Fax:+86-931-8912022 Lichtensteinstr. 31, Mistelbach A-2130 Austria Tel:+43-2572-201082 Fax:+43-2572-201084

2 1

Compiling fiasco for ARM
by Marko Wolf 07 Dec '05

07 Dec '05

Hi there! I tried to compile your current CVS Fiasco with the SA1100 ARM CPU target with all other options at default. I used the, at www.arm.com officially mentioned, GNU Toolchain for ARM Processors from www.codesourcery.com. Both target platform versions arm-bare-gcc-3.4.4 (target platform bare metal) and arm-linux-gcc-3.4.4 (target platform linux) fail at final linking with the attached error message. Maybe, I'm using the wrong arm-linux-compiler. What am I doing wrong? Are other mandatory configuration settings? What ARM compiler are you using? Best regards Marko ######### with arm-bare-gcc-3.4.4 ########## ==> Linking fiasco.image arm-linux-ld: Warning: size of symbol `__DTOR_LIST__' changed from 4 in libc.a(construction.o) to 8 in /opt/arm-bare-gcc-3.4.4/bin/../lib/gcc/arm-none-eabi/3.4.4/libgcc.a(_ctors.o) arm-linux-ld: Warning: size of symbol `__CTOR_LIST__' changed from 4 in libc.a(construction.o) to 8 in /opt/arm-bare-gcc-3.4.4/bin/../lib/gcc/arm-none-eabi/3.4.4/libgcc.a(_ctors.o) arm-linux-ld: section .excp [c0026000 -> c002697f] overlaps section .bss._ZGVZN23mapping_tree_allocators8instanceEvE15tree_allocators [c0026000 -> c0026003] arm-linux-ld: section .bss._ZZN23mapping_tree_allocators8instanceEvE15tree_allocators [c0026004 -> c0026027] overlaps section .excp [c0026000 -> c002697f] uart_console.o: In function `uart_console_init_stage1()':uart_console.cc: (.text._Z24uart_console_init_stage1v+0x88): undefined reference to `__aeabi_atexit' kernel_uart.o: In function `Kernel_uart::uart()':kernel_uart.cc: (.text._ZN11Kernel_uart4uartEv+0x3c): undefined reference to `__aeabi_atexit' kernel_console.o: In function `Kconsole::console()':kernel_console.cc: (.text._ZN8Kconsole7consoleEv+0x50): undefined reference to `__aeabi_atexit' mapdb.o: In function `Mapdb::~Mapdb()':mapdb.cc:(.text._ZN5MapdbD1Ev+0xe4): undefined reference to `__aeabi_atexit' mapdb.o: In function `Mapdb::~Mapdb()':mapdb.cc:(.text._ZN5MapdbD2Ev+0xe4): undefined reference to `__aeabi_atexit' mapdb.o:mapdb.cc:(.text._ZN5Mapdb4freeEP7Mapping+0x270): more undefined references to `__aeabi_atexit' follow /opt/arm-bare-gcc-3.4.4/bin/../lib/gcc/arm-none-eabi/3.4.4/libgcc.a(unwind-arm.o): In function `get_eit_entry':unwind-arm.c:(.text+0x45c): undefined reference to `__exidx_start' :unwind-arm.c:(.text+0x460): undefined reference to `__exidx_end' /opt/arm-bare-gcc-3.4.4/bin/../lib/gcc/arm-none-eabi/3.4.4/libgcc.a(unwind-arm.o): In function `unwind_phase2':unwind-arm.c:(.text+0x4c8): undefined reference to `abort' /opt/arm-bare-gcc-3.4.4/bin/../lib/gcc/arm-none-eabi/3.4.4/libgcc.a(unwind-arm.o): In function `__gnu_Unwind_Resume':unwind-arm.c:(.text+0x6f4): undefined reference to `abort' make[3]: *** [fiasco.image] Fehler 1 ######### with arm-linux-gcc-3.4.4 ########## ==> Linking fiasco.image arm-linux-ld: Warning: size of symbol `__CTOR_LIST__' changed from 4 in libc.a(construction.o) to 8 in /opt/arm-linux-gcc-3.4.4/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/libgcc.a(_ctors.oS) arm-linux-ld: Warning: size of symbol `__DTOR_LIST__' changed from 4 in libc.a(construction.o) to 8 in /opt/arm-linux-gcc-3.4.4/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/libgcc.a(_ctors.oS) arm-linux-ld: section .excp [c0026000 -> c002697f] overlaps section .bss._ZGVZN23mapping_tree_allocators8instanceEvE15tree_allocators [c0026000 -> c0026003] arm-linux-ld: section .bss._ZZN23mapping_tree_allocators8instanceEvE15tree_allocators [c0026004 -> c0026027] overlaps section .excp [c0026000 -> c002697f] uart_console.o: In function `uart_console_init_stage1()':uart_console.cc: (.text._Z24uart_console_init_stage1v+0x80): undefined reference to `__aeabi_atexit' kernel_uart.o: In function `Kernel_uart::uart()':kernel_uart.cc: (.text._ZN11Kernel_uart4uartEv+0x38): undefined reference to `__aeabi_atexit' kernel_console.o: In function `Kconsole::console()':kernel_console.cc: (.text._ZN8Kconsole7consoleEv+0x4c): undefined reference to `__aeabi_atexit' mapdb.o: In function `Mapdb::~Mapdb()':mapdb.cc:(.text._ZN5MapdbD1Ev+0xd8): undefined reference to `__aeabi_atexit' mapdb.o: In function `Mapdb::~Mapdb()':mapdb.cc:(.text._ZN5MapdbD2Ev+0xd8): undefined reference to `__aeabi_atexit' mapdb.o:mapdb.cc:(.text._ZN5Mapdb4freeEP7Mapping+0x13c): more undefined references to `__aeabi_atexit' follow /opt/arm-linux-gcc-3.4.4/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/libgcc.a(_divdi3.oS): (.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' /opt/arm-linux-gcc-3.4.4/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/libgcc.a(_udivdi3.oS): (.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' make[3]: *** [fiasco.image] Fehler 1

2 3

fprintf(stderr, ...) fails
by Arthur Mielimonka 29 Nov '05

29 Nov '05

Hello, for my project I'm using sources, which heavily make use of code like this: fprintf (stderr, "...."); Even if compiling works fine, the executions of the program failes with the following error message, when the program reaches the respective code: Program| OSKit support: using 4096KB at 0x00100000 as heap Program| Program| Exiting with rc=-2147467262 No error occurs on printf("..") - commands. I am using the "l4env_freebsd" mode, but even in "l4env" mode an (another) error occurs. I'm starting fiasco-ux with the command: ./fiasco-ux -m 256 -l names -l name_server -l dm_phys -l log -l simple_ts -l Program Thanks for any help, Arthur

3 4

dde_linux26 down_trylock bug
by Wei Shen 28 Nov '05

28 Nov '05

Hi, In dde_linux26/include/ARCH-x86/asm/semaphore.h: static inline int down_trylock(struct semaphore * sem) { return l4semaphore_try_down(&sem->l4_sema); } It seems incorrect. Maybe it should be: static inline int down_trylock(struct semaphore * sem) { return (l4semaphore_try_down(&sem->l4_sema) != 1); } Regards, Wei

2 1

Failed Assertion @ auto/kmem.h:162
by Julian Grizzard 27 Nov '05

27 Nov '05

All, I'm upgrading my Fiasco/L4Linux setup to the latest CVS version. My machine is a Pentium IV with 1 Gig RAM. Using the same configuration that worked before, I've run into an assertion problem when the system boots with the latest CVS. Below is the contents of menu.lst, L4 kernel configuration (globalconfig.out), and the boot log showing the assertion error. Further, I cannot enter the kernel debugger with "k"; instead, the offending address changes to 0xf0014fc7 with the same assertion thus failing to enter the debugger. Any idea what is wrong? Thanks! Julian ################ menu.lst ################## title L4Linux-2.6 root (hd0,0) kernel /boot/l4/rmgr -sigma0 task modname "bmodfs" module module module modaddr 0x02000000 module /boot/l4/main -nokdb -nowait -serial -comport 1 module /boot/l4/sigma0 module /boot/l4/names module /boot/l4/log module /boot/l4/dm_phys module /boot/l4/simple_ts -t 300 #module /boot/l4/rtc module /boot/l4/l4io --noirq module /boot/l4/l4exec module /boot/l4/bmodfs module /boot/l4/libloader.s.so module /boot/l4/run-script module /boot/vmlinuz26 module /boot/l4/loader --fprov=BMODFS run-script ############## /boot/l4/run-script ############### sleep 2 task "vmlinuz26" "noreplacement mem=64M root=/dev/hda1" ################ globalconfig.out ################ # # Automatically generated, don't edit # # Generated on: linux1 # At: Thu, 24 Nov 2005 18:22:02 +0000 # Linux version 2.6.8-2-686 (horms(a)tabatha.lab.ultramonkey.org) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Thu May 19 17:53:30 JST 2005 # # Main menu # CONFIG_EXPERIMENTAL=y # # Target System Options # # # Target Platform # CONFIG_PF_PC=y CONFIG_PF_UX=n CONFIG_PF_SA1100=n CONFIG_PF_XSCALE=n CONFIG_PF_ISG=n # # Target CPU Family # CONFIG_IA32=y CONFIG_ARM=n CONFIG_AMD64=n # # Target processor # CONFIG_IA32_486=n CONFIG_IA32_586=n CONFIG_IA32_686=n CONFIG_IA32_P2=n CONFIG_IA32_P3=n CONFIG_IA32_P4=y CONFIG_IA32_PM=n CONFIG_IA32_K6=n CONFIG_IA32_K7=n CONFIG_IA32_K8=n # # Target processor # CONFIG_AMD64_K8=n CONFIG_REGPARM3=y # # Kernel Options # # # Kernel ABI Version # CONFIG_ABI_V2=y CONFIG_ABI_X0=n # # ABI Extensions # CONFIG_DECEIT_BIT_DISABLES_SWITCH=y CONFIG_KIP_SYSCALLS=n CONFIG_MULTI_IRQ_ATTACH=n CONFIG_EXCEPTION_IPC=y CONFIG_SYSCALL_ITER=y CONFIG_HANDLE_SEGMENTS=y CONFIG_LOCAL_IPC=n CONFIG_ACTIVATION_IPC=n CONFIG_PL0_HACK=n CONFIG_ASSEMBLER_IPC_SHORTCUT=n CONFIG_SMALL_SPACES=n CONFIG_CONTEXT_4K=y # # Scheduling Timer # CONFIG_SCHED_PIT=y CONFIG_SCHED_RTC=n CONFIG_SCHED_APIC=n CONFIG_ONE_SHOT=n CONFIG_SYNC_TSC=n CONFIG_FINE_GRAINED_CPUTIME=n CONFIG_IO_PROT=n CONFIG_UX_CON=n CONFIG_UX_NET=n # # Kernel Debugging # CONFIG_INLINE=y CONFIG_NDEBUG=n CONFIG_PROFILE=n CONFIG_NO_FRAME_PTR=n CONFIG_STACK_DEPTH=n CONFIG_LIST_ALLOC_SANITY=n CONFIG_BEFORE_IRET_SANITY=n CONFIG_GSTABS=y CONFIG_POWERSAVE_GETCHAR=y CONFIG_SERIAL=y CONFIG_KDB=y CONFIG_JDB=y CONFIG_JDB_LOGGING=n CONFIG_JDB_ACCOUNTING=n CONFIG_JDB_MISC=n CONFIG_WATCHDOG=y # # Runtime warning level # CONFIG_WARN_NONE=n CONFIG_WARN_ANY=y # # Compiling and Building # CONFIG_CC="gcc" CONFIG_CXX="g++" CONFIG_VERBOSE=n CONFIG_MAINTAINER_MODE=n # # Derived symbols # CONFIG_BIT32=y CONFIG_XARCH="ia32" CONFIG_IA32_TARGET="Intel Pentium 4" CONFIG_WARN_LEVEL=2 CONFIG_BIT64=n CONFIG_PERF_CNT=y CONFIG_ABI="v2" # # That's all, folks! ################# BOOT LOG ################# [Multiboot-elf, <0x100000:0x20e18:0x0>, <0x121e20:0x49fc:0xa4784>, shtab=0x1 cb2f8, entry=0x100000] modaddr 0x02000000 Setting module load address to 0x2000000 module /boot/l4/main -nokdb -nowait -serial -comport 1 [Multiboot-module @ 0x2000000, 0x591ac bytes] module /boot/l4/sigma0 [Multiboot-module @ 0x205a000, 0xe94b bytes] module /boot/l4/names [Multiboot-module @ 0x2069000, 0x2a831 bytes] module /boot/l4/log [Multiboot-module @ 0x2094000, 0x26a93 bytes] module /boot/l4/dm_phys [Multiboot-module @ 0x20bb000, 0x5f2b2 bytes] module /boot/l4/simple_ts -t 300 [Multiboot-module @ 0x211b000, 0x2ef4f bytes] module /boot/l4/l4io --noirq [Multiboot-module @ 0x214a000, 0x1d1360 bytes] module /boot/l4/l4exec [Multiboot-module @ 0x231c000, 0xf4b72 bytes] module /boot/l4/bmodfs [Multiboot-module @ 0x2411000, 0x88b4c bytes] module /boot/l4/libloader.s.so [Multiboot-module @ 0x249a000, 0x88c3f bytes] module /boot/l4/run-script [Multiboot-module @ 0x2523000, 0x40 bytes] module /boot/vmlinuz26 [Multiboot-module @ 0x2524000, 0xd967f6 bytes] module /boot/l4/loader --fprov=BMODFS run-script [Multiboot-module @ 0x32bb000, 0xc8ed6 bytes] Welcome to Fiasco(ia32)! DD-L4(v2)/x86 microkernel (C) 1998-2005 TU Dresden Rev: Tue Nov 22 22:45:10 2005 compiled with gcc 3.3.5 for Intel Pentium 4 Performance-critical config option(s) detected: CONFIG_ASSEMBLER_IPC_SHORTCUT is off CONFIG_NDEBUG is off CONFIG_NO_FRAME_PTR is off Enabling special fully nested mode for PIC Using the PIT (i8254) on IRQ 0 for scheduling CPU: GenuineIntel (F:2:7:9) Model: Pentium 4 (Northwood/Prestonia) at 2519 MHz 128 Entry I TLB (4K or 4M pages) 64 Entry D TLB (4k or 4M pages) 12K µ-ops T Cache (8-way associative) 8 KB L1 D Cache (4-way associative, 64 bytes per line) 512 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 20480 bytes (5 pages) Assertion failed: 'Mem_layout::Tcbs_end == Mem_layout::Tcbs + (Config::thread_block_size * Config::max_threads())' in auto/kmem.h:162 at f0007cb1 Return reboots, "k" enters L4 kernel debugger... <k> Assertion failed: 'Mem_layout::Tcbs_end == Mem_layout::Tcbs + (Config::thread_block_size * Config::max_threads())' in auto/kmem.h:162 at f0014fc7 Return reboots, "k" enters L4 kernel debugger...

2 2