- l4-hackers - example.com Site

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

L4Linux on fiasco UX problem
by Jugwan Eom 24 Nov '05

24 Nov '05

Hi, I tried runnig L4Linux on fiasco UX but it didn't work. I enabled three options for the L4Linux. (Exception IPC / Inter-task ex-regs syscall / Handle and preserve segments) I have no idea why l4linux causes the trap. Anyone could help me? Followings are log and disassembling of vmlinux. Thanks in advance. ------------------------------------------------------------------------------------ $ ./lx con /home/zugwan/boot/fiasco_ux/fiasco -m 256 -symbols /home/zugwan/boot/fiasco_ux/Symbols -lines /home/zugwan/boot/fiasco_ux/Lines -rmgr /home/zugwan/boot/l4bin/rmgr-ux -symbols -lines -sigma0 /home/zugwan/boot/l4bin/sigma0-ux -fb_program /home/zugwan/boot/fiasco_ux/ux_con -irq0 /home/zugwan/boot/fiasco_ux/irq0 -t 32768 -G 640x480@16 -l /home/zugwan/boot/l4bin/names -l /home/zugwan/boot/l4bin/log -l /home/zugwan/boot/l4bin/dm_phys -l /home/zugwan/boot/l4bin/simple_ts -l /home/zugwan/boot/l4bin/fuxfprov -n9 -l /home/zugwan/boot/l4bin/rtc-ux -n10 -l /home/zugwan/boot/l4bin/l4exec -l /home/zugwan/boot/l4bin/con-ux -n12 -l /home/zugwan/boot/l4bin/loader /home/zugwan/boot/l4bin/run /home/zugwan/boot/cfg/l4linux26.ux Fiasco-UX on Linux 2.6.10-5-386 (i686) Native Syscall Map: 0x1600 Mapped 256 MB Memory + 4096 KB Framebuffer + 4 MB Input Area on FD 3 Loading Module 0x00090000-0x00094dc0 [/home/zugwan/boot/l4bin/sigma0-ux] Loading Module 0x00100000-0x001c61c0 [/home/zugwan/boot/l4bin/rmgr-ux] Copying Module 0x0ea66000-0x0ea843d6 [/home/zugwan/boot/fiasco_ux/Symbols] Copying Module 0x0ea33000-0x0ea6518f [/home/zugwan/boot/fiasco_ux/Lines] Copying Module 0x0ea08000-0x0ea327ac [/home/zugwan/boot/l4bin/names] Copying Module 0x0e9e1000-0x0ea0745f [/home/zugwan/boot/l4bin/log] Copying Module 0x0e982000-0x0e9e000d [/home/zugwan/boot/l4bin/dm_phys] Copying Module 0x0e953000-0x0e981b65 [/home/zugwan/boot/l4bin/simple_ts] Copying Module 0x0e8b1000-0x0e95281f [/home/zugwan/boot/l4bin/fuxfprov] Copying Module 0x0e88e000-0x0e8b0273 [/home/zugwan/boot/l4bin/rtc-ux] Copying Module 0x0e7a1000-0x0e88dd64 [/home/zugwan/boot/l4bin/l4exec] Copying Module 0x0e6d9000-0x0e7a0c7f [/home/zugwan/boot/l4bin/con-ux] Copying Module 0x0e619000-0x0e6d8a04 [/home/zugwan/boot/l4bin/loader] Bootstrapping... Welcome to Fiasco(ux)! DD-L4(v2)/x86 microkernel (C) 1998-2005 TU Dresden Rev: Thu Nov 24 08:46:52 2005 compiled with gcc 3.4.4 for Intel Pentium Starting Framebuffer: 640x480@16 CPU: GenuineIntel (F:4:1:0) Model: Pentium 4E (Prescott/Nocona) at 3190 MHz 64 Entry I TLB (4K or 4M pages) 64 Entry D TLB (4k or 4M pages) 12K \uffff-ops T Cache (8-way associative) 16 KB L1 D Cache (8-way associative, 64 bytes per line) 1024 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 24576 bytes (6 pages) SIGMA0: Hello! Found Fiasco: KIP syscalls: no. Allocated 68kB for maintenance structures. RMGR: Hello! running on Fiasco bootloader loaded 9 modules at 0e619000-0ea843d7 L4 symbols at 0e5fa000-0e6183d8 (120kB), lines at 0e5c7000-0e5f918f (200kB) total RAM size = 261120 KB (reported by bootloader) received 239300 KB RAM from sigma0 1128 KB reserved for RMGR received no I/O ports attached irqs = [ <!0> 1 2 3 4 5 6 7 8 9 a b c d e f ] RMGR: Starting tasks. #05: loading "/home/zugwan/boot/l4bin/names " from 0ea08000-0ea327ac to [ 00240000-002467ea 00247000-00253000 ] starting at entry 00240000 via trampoline page code 0000c464 symbols at 0ea86000-0ea88000 (8kB), lines at 0ea81000-0ea86000 (20kB) #06: loading "/home/zugwan/boot/l4bin/log" from 0e9e1000-0ea0745f to [ 00400000-00406c11 00407000-00439510 ] starting at entry 00400000 via trampoline page code 0000d460 symbols at 0ea7f000-0ea81000 (8kB), lines at 0ea7a000-0ea7f000 (20kB) #07: loading "/home/zugwan/boot/l4bin/dm_phys " from 0e982000-0e9e000d to [ 01500000-01511baa 01512000-015193d0 ] starting at entry 01500000 via trampoline page code 0000e468 symbols at 0ea76000-0ea7a000 (16kB), lines at 0ea6a000-0ea76000 (48kB) #08: loading "/home/zugwan/boot/l4bin/simple_ts " from 0e953000-0e981b65 to [ 01400000-01407ede 01408000-01413830 ] starting at entry 01400000 via trampoline page code 0000f468 symbols at 0ea68000-0ea6a000 (8kB), lines at 0ea62000-0ea68000 (24kB) #09: loading "/home/zugwan/boot/l4bin/fuxfprov" from 0e8b1000-0e95281f to [ 00500000-00521c96 00522000-0053e000 ] starting at entry 00500000 via trampoline page code 00010468 symbols at 0ea5d000-0ea62000 (20kB), lines at 0ea4a000-0ea5d000 (76kB) #0a: loading "/home/zugwan/boot/l4bin/rtc-ux" from 0e88e000-0e8b0273 to [ 01080000-01084abd 01085000-0108a000 ] starting at entry 01080000 via trampoline page code 00011464 symbols at 0ea48000-0ea4a000 (8kB), lines at 0ea44000-0ea48000 (16kB) #0b: loading "/home/zugwan/boot/l4bin/l4exec" from 0e7a1000-0e88dd64 to [ 01100000-01127dee 01128000-01132000 ] starting at entry 01100000 via trampoline page code 00012464 symbols at 0ea3c000-0ea44000 (32kB), lines at 0ea24000-0ea3c000 (96kB) #0c: loading "/home/zugwan/boot/l4bin/con-ux " from 0e6d9000-0e7a0c7f to [ 00b00000-00b23fe2 00b24000-00b2f000 ] starting at entry 00b00000 via trampoline page code 00013464 symbols at 0ea1d000-0ea24000 (28kB), lines at 0ea05000-0ea1d000 (96kB) #0d: loading "/home/zugwan/boot/l4bin/loader /home/zugwan/boot/l4bin/run /home/zugwan/boot/cfg/l4linux26.ux" from 0e619000-0e6d8a04 to [ 01300000-01325306 01326000-01338000 ] starting at entry 01300000 via trampoline page code 000144a4 symbols at 0e9ff000-0ea05000 (24kB), lines at 0e9e9000-0e9ff000 (88kB) simplets| Configured for 64 tasks. fuxfprov| OSKit support: using 128KB at 0x00100000 as heap (growing) fuxfprov| File provider started, registered as 9.02 exec | OSKit support: using 4096KB at 0x00400000 as heap (growing) con | OSKit support: using 128KB at 0x00100000 as heap con | Character size is 8x14, font has 256 characters con | VESA reports 640x480@16 1280bpl (0000) [4096kB] con | Color mapping: red=11:5 green=5:6 blue=0:5 res=0:0 con | Found Fiasco/UX con | Found VHW descriptor, provider is 24195 con | Mapping I/O UX video mem c0000000 => 00400000+000000 [4096kB] con | Using MMXEXT for colorspace transform con | map_inputmemory: paddr = 0xc0400000 con | Input memory page mapped to 0x00c00000 loader | OSKit support: using 128KB at 0x00100000 as heap loader | Can't map tbuf status page (map=00004000, error=00 result=00004000) con | Started input interrupt thread C.03! con | Running as C.02. Video mode is 640x480@16. fuxfprov| open "/home/zugwan/boot/l4bin/run" by D.02 loader | "/home/zugwan/boot/l4bin/run" is a valid binary image loader | Setting libpath to /home/zugwan/boot/l4bin/ exec | run: Loading exec | run: Merging psec 01312000-01314000 with psec 0130d000-01313000 exec | run: Saved 14133 bytes of symbols exec | libloader.s.so: Loading fuxfprov| open "/home/zugwan/boot/l4bin//libloader.s.so" by B.02 exec | libloader.s.so: Saved 21533 bytes of symbols exec | libloader.s.so: Relocating to 00010000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 00004ff0 => 00014ff0 exec | libloader.s.so: Setting section flag 0800 exec | run: Setting section flag 0800 loader | run: Starting l4env-style application loader | run,#e: Starting at l4loader_init (000156a0) exec | run: Linking exec | run: Relocating entry 01300000 => 01300000 exec | run: Packed 25941 bytes of symbols exec | run: Packed 96567 bytes of lines loader | run,#e: Continue at l4env_init (000156b0, libloader.s.so) fuxfprov| open "/home/zugwan/boot/cfg/l4linux26.ux" by D.02 loader | sleeping for 1000 ms run | OSKit support: using 256KB at 0x00040000 as heap (growing) con | vc_loop(): vc[1] running as C.04 con | vc_open_out(): vc[1] 640x480@16, gmode:0x15 run | contxt_init(): 640x462, cols:80, lines:33, sb_lines:1033 fuxfprov| open "/home/zugwan/boot/lx/vmlinuz26.ux" by D.02 exec | vmlinuz26.ux: Loading exec | vmlinuz26.ux: Interpreter section found, contains "/usr/lib/libc.so.1 exec : " exec | vmlinuz26.ux: Saved 756346 bytes of symbols exec | libloader.s.so: Relocating to 00010000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 00004ff0 => 00014ff0 exec | libloader.s.so: Setting section flag 0800 exec | vmlinuz26.ux: Setting section flag 0800 loader | vmlinuz26.ux: Starting l4env-style application loader | vmlinuz26.ux,#f: Starting at l4loader_init (000156a0) exec | vmlinuz26.ux: Linking exec | vmlinuz26.ux: Relocating entry 00400000 => 00400000 exec | vmlinuz26.ux: Packed 600616 bytes of symbols exec | vmlinuz26.ux: Packed 1616968 bytes of lines loader | vmlinuz26.ux,#f: Continue at l4env_init (000156b0, libloader.s.so) l4lx | crt0_construction called. l4lx | ======> L4Linux 2.6 starting... <======== l4lx | Binary name: vmlinuz26.ux l4lx | Kernel command line (8 args): mem=44M noreplacement root=1:0 load_ram l4lx : disk=1 ramdisk_size=16384 l4env_rd=/home/zugwan/boot/rd/rd1 panicblin l4lx : k=0 lang=us l4lx | Image: 00400000 - 0068a1a0 [2600 KiB]. l4lx | Areas: Text: 00400000 - 005b5000 [1748kB] (a bit longer) l4lx | Data: 005b5000 - 005f04cc [237kB] l4lx | Initdata: 005f4000 - 00618000 [144kB] l4lx | BSS: 00618008 - 0068a1a0 [456kB] l4lx | l4lx_thread_create: Created thread 0f.03 (server) l4lx | main thread will be 0f.03 l4lx | l4env_register_pointer_section: addr = 005f2000 size = 159744 l4lx | sec-w-init: virt: 0x005f2000 to 0x00618fff [156 KiB] l4lx | sec-w-init: Number of physical regions: 1, 159744 Bytes l4lx | sec-w-init: 1: Phys: 0x00f69000 to 0x00f90000, Size: 159744 l4lx | l4env_linux_startup thread 3. l4lx | main thread: received startup message. l4lx | setup_l4env_memory: Forcing superpages for main memory l4lx | Main memory size: 44MB l4lx | Main memory: virt: 0x00800000 to 0x033fffff [45056 KiB] l4lx | Main memory: Number of physical regions: 1, 46137344 Bytes l4lx | Main memory: 1: Phys: 0x0b800000 to 0x0e400000, Size: 46137344 l4lx | Filling lower ptabs... l4lx | Main thread running, waiting... l4lx | Done (1263 entries). l4lx | l4env_rd_path: /home/zugwan/boot/rd/rd1 l4lx | Loading: /home/zugwan/boot/rd/rd1 fuxfprov| open "/home/zugwan/boot/rd/rd1" by F.03 l4lx | INITRD: Size of RAMdisk is 16384KiB l4lx | RAMdisk from 03400000 to 04400000 [16384KiB] l4lx | l4lx_thread_create: Created thread 0f.04 (timer.i0) KERNEL: f.3 (tcb=00000000203c1800) killed: Unhandled trap ip:60965b EAX 00000001 EBX 00000001 ECX 0107fe80 EDX 00000cfb ESI 00000000 EDI 00828000 EBP 00829fa4 ESP 00829f98 EIP 0060965b EFLAGS 00010046 CS 0002 SS 007b DS 007b ES 007b FS 0000 GS 0007 trap 13 (General Protection), error 00000000, from user mode (internal event regarding GDT entry no. 0x00) --------------------------------------------------------------------------------------------------- /home/zugwan/l4/l4linux-2.6/vmlinux: file format elf32-i386 Disassembly of section .text: Disassembly of section .plt: Disassembly of section .init.text: 006095db <pci_sanity_check+0x3b>: pci_sanity_check(): /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:193 6095db: 83 c4 18 add $0x18,%esp 6095de: 85 c0 test %eax,%eax 6095e0: 75 e4 jne 6095c6 <pci_sanity_check+0x26> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:195 6095e2: 8b 45 f0 mov 0xfffffff0(%ebp),%eax 6095e5: 3d 00 06 00 00 cmp $0x600,%eax 6095ea: 0f 94 c2 sete %dl 6095ed: 3d 00 03 00 00 cmp $0x300,%eax 6095f2: 0f 94 c0 sete %al 6095f5: 09 d0 or %edx,%eax 6095f7: a8 01 test $0x1,%al 6095f9: 75 2c jne 609627 <pci_sanity_check+0x87> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:198 6095fb: 56 push %esi 6095fc: 6a 02 push $0x2 6095fe: 6a 00 push $0x0 609600: 53 push %ebx 609601: 6a 00 push $0x0 609603: 6a 00 push $0x0 609605: ff 17 call *(%edi) 609607: 83 c4 18 add $0x18,%esp 60960a: 85 c0 test %eax,%eax 60960c: 75 b8 jne 6095c6 <pci_sanity_check+0x26> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:200 60960e: 8b 45 f0 mov 0xfffffff0(%ebp),%eax 609611: 3d 86 80 00 00 cmp $0x8086,%eax 609616: 0f 94 c2 sete %dl 609619: 3d 11 0e 00 00 cmp $0xe11,%eax 60961e: 0f 94 c0 sete %al 609621: 09 d0 or %edx,%eax 609623: a8 01 test $0x1,%al 609625: 74 9f je 6095c6 <pci_sanity_check+0x26> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:201 609627: b8 01 00 00 00 mov $0x1,%eax /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:206 60962c: 8d 65 f4 lea 0xfffffff4(%ebp),%esp 60962f: 5b pop %ebx 609630: 5e pop %esi 609631: 5f pop %edi 609632: 5d pop %ebp 609633: c3 ret /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:205 609634: 31 c0 xor %eax,%eax 609636: eb f4 jmp 60962c <pci_sanity_check+0x8c> 609638: 90 nop 609639: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi 00609640 <pci_check_type1>: pci_check_type1(): /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:209 609640: 55 push %ebp 609641: 89 e5 mov %esp,%ebp 609643: 56 push %esi 609644: 53 push %ebx 609645: 51 push %ecx /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:214 609646: e8 a5 7c df ff call 4012f0 <l4x_local_save_flags> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:212 60964b: 31 f6 xor %esi,%esi /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:214 60964d: 89 c3 mov %eax,%ebx 60964f: e8 7c 7c df ff call 4012d0 <l4x_local_irq_disable> /home/zugwan/l4/l4linux-2.6/include/asm-l4/l4-arch/asm/io.h:395 609654: b0 01 mov $0x1,%al 609656: ba fb 0c 00 00 mov $0xcfb,%edx 60965b: ee out %al,(%dx) /home/zugwan/l4/l4linux-2.6/include/asm-l4/l4-arch/asm/io.h:397 60965c: b2 f8 mov $0xf8,%dl 60965e: ed in (%dx),%eax 60965f: 89 45 f4 mov %eax,0xfffffff4(%ebp) 609662: b8 00 00 00 80 mov $0x80000000,%eax 609667: ef out %eax,(%dx) 609668: ed in (%dx),%eax 609669: 3d 00 00 00 80 cmp $0x80000000,%eax 60966e: 74 20 je 609690 <pci_check_type1+0x50> 609670: ba f8 0c 00 00 mov $0xcf8,%edx 609675: 8b 45 f4 mov 0xfffffff4(%ebp),%eax 609678: ef out %eax,(%dx) /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:223 609679: 53 push %ebx 60967a: e8 81 7c df ff call 401300 <l4x_local_irq_restore> 60967f: 58 pop %eax /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:226 609680: 8d 65 f8 lea 0xfffffff8(%ebp),%esp 609683: 89 f0 mov %esi,%eax 609685: 5b pop %ebx 609686: 5e pop %esi 609687: 5d pop %ebp 609688: c3 ret 609689: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi /home/zugwan/l4/l4linux-2.6/include/asm-l4/l4-arch/asm/io.h:397 609690: 68 58 82 5c 00 push $0x5c8258 609695: e8 06 ff ff ff call 6095a0 <pci_sanity_check> 60969a: 5a pop %edx 60969b: 85 c0 test %eax,%eax 60969d: 74 d1 je 609670 <pci_check_type1+0x30> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:220 60969f: 66 be 01 00 mov $0x1,%si 6096a3: eb cb jmp 609670 <pci_check_type1+0x30> 6096a5: 8d 74 26 00 lea 0x0(%esi),%esi 6096a9: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi 006096b0 <pci_check_type2>: pci_check_type2(): /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:229 6096b0: 55 push %ebp 6096b1: 89 e5 mov %esp,%ebp 6096b3: 57 push %edi 6096b4: 56 push %esi 6096b5: 53 push %ebx /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:233 6096b6: e8 35 7c df ff call 4012f0 <l4x_local_save_flags> /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:231 6096bb: 31 f6 xor %esi,%esi /home/zugwan/l4/l4linux-2.6/arch/l4/pci/../../i386/pci/direct.c:233 6096bd: 89 c3 mov %eax,%ebx 6096bf: e8 0c 7c df ff call 4012d0 <l4x_local_irq_disable> /home/zugwan/l4/l4linux-2.6/include/asm-l4/l4-arch/asm/io.h:395 6096c4: 31 c0 xor %eax,%eax 6096c6: ba fb 0c 00 00 mov $0xcfb,%edx 6096cb: ee out %al,(%dx) 6096cc: bf f8 0c 00 00 mov $0xcf8,%edi 6096d1: 89 fa mov %edi,%edx 6096d3: ee out %al,(%dx) 6096d4: b9 fa 0c 00 00 mov $0xcfa,%ecx 6096d9: 89 ca mov %ecx,%edx Disassembly of section .altinstr_replacement: Disassembly of section .exit.text:

2 1

ANNOUNCE: Qualcomm uses L4!
by Gernot Heiser 23 Nov '05

23 Nov '05

NICTA today announced a collaborative effort with QUALCOMM Incorporated to use NICTA versions of the L4 Microkernel and the Iguana operating system together with select versions of QUALCOMM's Mobile Station)TM) chipsets. See http://www.ertos.nicta.com.au/press/051124_L4_Qualcomm_vfinal.pdf for the full press release. Gernot -- Gernot Heiser Program Leader Professor of Operating Systems Embedded, Real-Time, and Operating Systems University of New South Wales National ICT Australia (NICTA) http://gernot.web.cse.unsw.edu.au http://ertos.nicta.com.au Phone: +61 2 8306 0550 Fax: +61 2 8306 0406

1 0

ANNOUNCE: NICTA embedded OS framework released
by Gernot Heiser 23 Nov '05

23 Nov '05

The NICTA ERTOS team is pleased to announce the fist official release of its embedded OS framework, consisting of: * NICTA::Pistachio-embedded, the first kernel conforming to the L4-embedded API. NICTA::Pistachio is based on L4Ka::Pistachio; * Iguana, an L4-based OS personality developed specifically for embedded systems; * Kenge, a set of packages for building microkernel-based systems; * Wombat, a de-privileged (para-virtualised) Linux server running on top of L4/Iguana. Presently the full package works on ARM and x86 platforms. MIPS64 is fully supported except for Wombat (which is due for release shortly) and an Alpha version is not far behind. The system is very mature (in commercial deployment); NICTA::Pistachio-embedded is the fastest and most mature L4 kernel on ARM. See also the http://www.ertos.nicta.com.au/Research/news/. Gernot -- Gernot Heiser Program Leader Professor of Operating Systems Embedded, Real-Time, and Operating Systems University of New South Wales National ICT Australia (NICTA) http://gernot.web.cse.unsw.edu.au http://ertos.nicta.com.au Phone: +61 2 8306 0550 Fax: +61 2 8306 0406

1 0

Re: What happens on timeslice overrun?
by Udo A. Steinberg 23 Nov '05

23 Nov '05

On Sun, 14 Aug 2005 22:16:09 +0200 Rene Wittmann (RW) wrote: RW> I have 2 questions on the RT part in DROPS: RW> RW> 1.) I have 2 RT working threads, each with 3 timeslices: RW> Thread 1: period=10ms RW> ts1=30ms prio1=50 RW> ts2=10ms prio2=30 RW> ts3=20ms prio3=50 RW> RW> Thread 2: period=10ms RW> ts1=20ms prio1=40 RW> ts2=5ms prio2=30 RW> ts3=10ms prio3=40 RW> RW> Assume both threads are ready at the same time. RW> So thread 1 starts and does its work until it RW> releases the voluntarily or it's preempted by RW> its preempter-thread. So say it releases RW> voluntarily after 20ms. When you say "it's preempted by its preempter thread", do you mean the situation when a preempter with a higher priority than the current thread receives a preemption IPC from the kernel and thus preempts the current thread? RW> Who will get the left 10ms? I guess nobody. When a thread is preempted (that means it gets involuntarily descheduled), the remaining time quantum is saved and later restored when the thread is scheduled again. If the thread yields its scheduling context (that means it voluntarily gives it away), the time quantum is no longer available to the thread. A yield can happen in two ways depending on the target thread id specified: 1) if the target ID is the NIL_ID, then the thread yields its active scheduling context to noone - the time is effectively gone. This is what next_reservation does. Note that the kernel checks the user-specified ID, to guard against the case where a thread wants to yield its active scheduling context and the time quantum on that scheduling context expires simultaneously. 2) if the target ID is a valid thread ID in the system, then the action depends on whether the specified thread is ready to run: a) if it is, then the current thread donates the current scheduling context to the specified thread and that thread then becomes the current thread. This is similar to what happens during a donating IPC. b) if the specified thread is not ready, then the current scheduling context is gone, similar to 1) RW> Or can I assign my left time to a specific RW> thread, say ts2 of thread 1, that is has 20ms RW> after recognizing that ts1 was finished 10ms RW> earlier?I could do with l4_rt_change_timeslice(), RW> but this would probably not work for the the RW> current period! (or yes?) A thread can yield the current scheduling context to another thread as described in 2a) above. Note that the thread will yield the current scheduling context (which may not necessarily be the thread's own active scheduling context). As an example consider: A sends a donating IPC to B, now B runs on A's scheduling context. If B yields to C, then C will run on A's time and B will not donate its own scheduling context. If the current scheduling context is in fact the active scheduling context of the donating thread, then realize that the donating thread will likely encounter a timeslice overrun soon after the yield (the donatee will consume the time quantum until it runs out). If you'd rather avoid that, then the donatee will have to yield the scheduling context back to the owner (the original donator) who then has to yield it to noone. Changes to the time quantum of a scheduling context are only visible the next time that scheduling context becomes the current scheduling context. That means if you change the current scheduling context, then the change will not be visible immediately. RW> 2.) Consider we have a deadline miss. And we say RW> l4_rt_next_period(): would it wait for the beginning RW> of the next (which means: RW> period 1: deadline miss RW> period 2: call next period (because we think we're RW> still in period 1)+ wait to end of period RW> period 3: normal work) RW> Or do I have to care that we do not call RW> l4_rt_next_period() in case of a deadline miss? If your thread misses its deadline right before it wanted to call l4_rt_next_period, then l4_rt_next_period blocks the thread until the end of the new period started due to the deadline miss. Since this is likely not what the thread intended to do, it's the preempter's job to handle that situation, e.g. by ex_regs'ing the thread out of it's l4_rt_next_period call. RW> BTW: I compiled the fiasco-kernel with apic+one shot RW> mode. But this should not be relevant for my question. It is indeed not relevant. -Udo.

3 11

how do I...
by Michael Scheibel 22 Nov '05

22 Nov '05

Good evening, I am currently playing around with L4Linux+DOpE and would like to 1. Start and kill L4 processes at runtime (fprov-l4 and run-l4 do not work). 2. Disable the DOpE mouse pointer in the L4Linux console window. 3. Resize the L4Linux console window without just stretching it. 3. Play Quake :) (where do I get it?) Any hints highly appreciated. Regards, Michael -- Sirrix AG security technologies - http://www.sirrix-ag.de Michael Scheibel eMail: m.scheibel(a)sirrix.com Tel +49(234) 610 071-124 Public key on demand Fingerprint 009B 9963 7B28 4356 CA43 5BFD 17A4 AE0F 6943 4B54 This email may contain confidential legal information: if received by not authorised person please advice our firm and destroy it. Anyway every transmitted information shall be treated strictly confidentially.

4 12