l4-hackers December 2005

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

12 participants
10 discussions

Ore on Intel Pro/1000
by Michael Scheibel 07 Feb '06

07 Feb '06

Hello list, I am running Ore on native HW and Intel(R) PRO/1000 Network Connection. Ore seems to recognize the network card correctly but quits when I try to setup eth0. L4Linux error message: eth0: Overwriting IRQ type for IRQ 0 with l4ore type! eth0: request_irq(0, ...) failed. Any hint 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.

3 6

L4Linux (dm_phys?) problem
by Jugwan Eom 12 Jan '06

12 Jan '06

Hello, I have a problem with runnig L4Linux. On both native and ux, the error is similar. (see the following log) Before this problem happened, I didn't any problem. IMHO, dm_phys seems to be the source of this error. I tried different mode (uclibc, dietlibc) with the same error. Best regards, Jugwan 1) On ux ---------------------------------------------------------------------------------------------------------------------- zugwan@getgid:~/boot/l4.oskit/runux$ ./lx con /home/zugwan/boot/l4.oskit/fiasco/fiasco -m 256 -symbols /home/zugwan/boot/l4.oskit/fiasco/Symbols -lines /home/zugwan/boot/l4.oskit/fiasco/Lines -rmgr /home/zugwan/boot/l4.oskit/l4v2/rmgr-ux -symbols -lines -sigma0 /home/zugwan/boot/l4.oskit/l4v2/sigma0-ux -fb_program /home/zugwan/boot/l4.oskit/fiasco/ux_con -irq0 /home/zugwan/boot/l4.oskit/fiasco/irq0 -t 32768 -G 640x480@16 -l /home/zugwan/boot/l4.oskit/l4v2/names -l /home/zugwan/boot/l4.oskit/l4v2/log -l /home/zugwan/boot/l4.oskit/l4v2/dm_phys -l /home/zugwan/boot/l4.oskit/l4v2/simple_ts -l /home/zugwan/boot/l4.oskit/l4v2/fuxfprov -n9 -l /home/zugwan/boot/l4.oskit/l4v2/rtc-ux -n10 -l /home/zugwan/boot/l4.oskit/l4v2/l4exec -l /home/zugwan/boot/l4.oskit/l4v2/con-ux -n12 -l /home/zugwan/boot/l4.oskit/l4v2/loader /home/zugwan/boot/l4.oskit/l4v2/run /home/zugwan/boot/l4.oskit/cfg/l4linux26.ux Fiasco-UX on Linux 2.6.11 (i686) Native Syscall Map: 0x1600 Mapped 256 MB Memory + 4096 KB Framebuffer + 4 MB Input Area on FD 3 Loading Module 0x00090000-0x00095060 [/home/zugwan/boot/l4.oskit/l4v2/sigma0-ux] Loading Module 0x00100000-0x001c6220 [/home/zugwan/boot/l4.oskit/l4v2/rmgr-ux] Copying Module 0x0ea66000-0x0ea84685 [/home/zugwan/boot/l4.oskit/fiasco/Symbols] Copying Module 0x0ea33000-0x0ea65cdd [/home/zugwan/boot/l4.oskit/fiasco/Lines] Copying Module 0x0ea07000-0x0ea32a7e [/home/zugwan/boot/l4.oskit/l4v2/names] Copying Module 0x0e9df000-0x0ea066c1 [/home/zugwan/boot/l4.oskit/l4v2/log] Copying Module 0x0e97d000-0x0e9de1fb [/home/zugwan/boot/l4.oskit/l4v2/dm_phys] Copying Module 0x0e94d000-0x0e97cd2b [/home/zugwan/boot/l4.oskit/l4v2/simple_ts] Copying Module 0x0e8a4000-0x0e94cdc1 [/home/zugwan/boot/l4.oskit/l4v2/fuxfprov] Copying Module 0x0e880000-0x0e8a345d [/home/zugwan/boot/l4.oskit/l4v2/rtc-ux] Copying Module 0x0e784000-0x0e87fcfa [/home/zugwan/boot/l4.oskit/l4v2/l4exec] Copying Module 0x0e6b1000-0x0e783b26 [/home/zugwan/boot/l4.oskit/l4v2/con-ux] Copying Module 0x0e5ea000-0x0e6b0c9a [/home/zugwan/boot/l4.oskit/l4v2/loader] Bootstrapping... Welcome to Fiasco(ux)! DD-L4(v2)/x86 microkernel (C) 1998-2005 TU Dresden Rev: Thu Dec 22 23:02:20 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 0e5ea000-0ea84686 L4 symbols at 0e5cb000-0e5e9687 (121kB), lines at 0e598000-0e5cacdd (203kB) total RAM size = 261120 KB (reported by bootloader) received 239296 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/l4.oskit/l4v2/names " from 0ea07000-0ea32a7e to [ 00240000-00246812 00247000-00253000 ] starting at entry 00240000 via trampoline page code 0000c46c symbols at 0ea86000-0ea88000 (8kB), lines at 0ea81000-0ea86000 (20kB) #06: loading "/home/zugwan/boot/l4.oskit/l4v2/log" from 0e9df000-0ea066c1 to [ 00400000-00406c31 00407000-00439510 ] starting at entry 00400000 via trampoline page code 0000d468 symbols at 0ea7f000-0ea81000 (8kB), lines at 0ea7a000-0ea7f000 (20kB) #07: loading "/home/zugwan/boot/l4.oskit/l4v2/dm_phys " from 0e97d000-0e9de1fb to [ 01500000-01511ca2 01512000-015193d0 ] starting at entry 01500000 via trampoline page code 0000e470 symbols at 0ea76000-0ea7a000 (16kB), lines at 0ea6a000-0ea76000 (48kB) #08: loading "/home/zugwan/boot/l4.oskit/l4v2/simple_ts " from 0e94d000-0e97cd2b to [ 01400000-01407ede 01408000-01413830 ] starting at entry 01400000 via trampoline page code 0000f470 symbols at 0ea68000-0ea6a000 (8kB), lines at 0ea62000-0ea68000 (24kB) #09: loading "/home/zugwan/boot/l4.oskit/l4v2/fuxfprov" from 0e8a4000-0e94cdc1 to [ 00500000-00521d4a 00522000-0053e000 ] starting at entry 00500000 via trampoline page code 00010470 symbols at 0ea5d000-0ea62000 (20kB), lines at 0ea4a000-0ea5d000 (76kB) #0a: loading "/home/zugwan/boot/l4.oskit/l4v2/rtc-ux" from 0e880000-0e8a345d to [ 01080000-01084abd 01085000-0108a000 ] starting at entry 01080000 via trampoline page code 0001146c symbols at 0ea48000-0ea4a000 (8kB), lines at 0ea44000-0ea48000 (16kB) #0b: loading "/home/zugwan/boot/l4.oskit/l4v2/l4exec" from 0e784000-0e87fcfa to [ 01100000-01127ec2 01128000-01132000 ] starting at entry 01100000 via trampoline page code 0001246c symbols at 0ea3c000-0ea44000 (32kB), lines at 0ea24000-0ea3c000 (96kB) #0c: loading "/home/zugwan/boot/l4.oskit/l4v2/con-ux " from 0e6b1000-0e783b26 to [ 00b00000-00b242da 00b25000-00b30000 ] starting at entry 00b00000 via trampoline page code 0001346c symbols at 0ea1d000-0ea24000 (28kB), lines at 0ea05000-0ea1d000 (96kB) #0d: loading "/home/zugwan/boot/l4.oskit/l4v2/loader /home/zugwan/boot/l4.oskit/l4v2/run /home/zugwan/boot/l4.oskit/cfg/l4linux26.ux" from 0e5ea000-0e6b0c9a to [ 01300000-013253f6 01326000-01338000 ] starting at entry 01300000 via trampoline page code 000144bc symbols at 0e9ff000-0ea05000 (24kB), lines at 0e9e9000-0e9ff000 (88kB) simplets| Configured for 64 tasks. DMphys | (0x000161f8-0x000181f8),(0x00016258-0x00020000),(0x00102000-0x00103 DMphys : 000) DMphys | [7.0] dm_phys/server/src/pages.c:249:__add_area(): DMphys | DMphys: new area overlaps existing area! --PANIC, 'g' for exit-------------------------------ESP:01513ab0 EIP:01502146 (7.00) jdb: ^ Exiting, wait... 2) On native -------------------------------------------------------------------------------------------------------------------- RMGR: Stage1 Using extended multiboot info loading (hd1,0)/oskit/l4/v2/sigma0 loading kernel (hd1,0)/oskit/l4/v2/fiasco -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 kernel at 00001000-003906a4 detected new-style DD-L4(v2)/Fiasco configuring sigma0: 00090000-00096000, start: 00090000 reserve modules memory range: 02055000-0455ec9b starting kernel (hd1,0)/oskit/l4/v2/fiasco -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 proto=0x101fc0 @ 0x0030090c Welcome to Fiasco(ia32)! DD-L4(v2)/x86 microkernel (C) 1998-2005 TU Dresden Rev: Thu Dec 22 23:02:20 2005 compiled with gcc 3.4.4 for Intel Pentium Performance-critical config option(s) detected: CONFIG_ASSEMBLER_IPC_SHORTCUT is off CONFIG_NDEBUG is off Enabling special fully nested mode for PIC Using the PIT (i8254) on IRQ 0 for scheduling CPU: GenuineIntel (F:4:8: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: 20480 bytes (5 pages) SIGMA0: Hello! Found Fiasco: KIP syscalls: no. Allocated 107kB for maintenance structures. RMGR: Stage2 running on Fiasco bootloader loaded 17 modules at 02065000-0455ec9b total RAM size = 158270 KB (reported by bootloader) received 144292 KB RAM from sigma0 812 KB reserved for RMGR My symbols at 08e6c000-08e6f000 (12kB), lines at 08e60000-08e6c000 (48kB) received no I/O ports attached irqs = [ <!0> 1 <!2> 3 <!4> 5 6 7 8 9 a b c d e f ] RMGR: Parsing the config options of command line. configured task 0x0c: [ m:0,ffffffff,ffffffff hm:0,ffffffff,ffffffff t:0,ffff,ffff i:ffff lmcp:ffff s:0,ff,ff mcp:ff prio:10 small:ff ] log_mask: 00000000, log_types: 00000000 RMGR: Starting tasks. #05: loading "(hd1,0)/oskit/l4/v2/names" from 02065000-02090a7e to [ 00240000-00246812 00247000-00253000 ] starting at entry 00240000 via trampoline page code 00056460 symbols at 08e5e000-08e60000 (8kB), lines at 08e59000-08e5e000 (20kB) #06: loading "(hd1,0)/oskit/l4/v2/log" from 02091000-020b86c1 to [ 00400000-00406c31 00407000-00439510 ] starting at entry 00400000 via trampoline page code 0005745c symbols at 08e57000-08e59000 (8kB), lines at 08e52000-08e57000 (20kB) #07: loading "(hd1,0)/oskit/l4/v2/dm_phys --isa=0x00800000 -v" from 020b9000-0211a1fb to [ 01500000-01511ca2 01512000-015193d0 ] starting at entry 01500000 via trampoline page code 00058474 symbols at 08e4e000-08e52000 (16kB), lines at 08e42000-08e4e000 (48kB) #08: loading "(hd1,0)/oskit/l4/v2/simple_ts -t 380" from 0211b000-0214ad2b to [ 01400000-01407ede 01408000-01413830 ] starting at entry 01400000 via trampoline page code 0005946c symbols at 08e40000-08e42000 (8kB), lines at 08e3a000-08e40000 (24kB) #09: loading "(hd1,0)/oskit/l4/v2/rtc" from 0214b000-0216ceca to [ 01080000-01084b69 01085000-0108a000 ] starting at entry 01080000 via trampoline page code 0005a45c symbols at 08e38000-08e3a000 (8kB), lines at 08e34000-08e38000 (16kB) #0a: loading "(hd1,0)/oskit/l4/v2/l4io" from 0216d000-0233e01b to [ 00b80000-00ba237e 00ba3000-00bd7000 ] starting at entry 00b80000 via trampoline page code 0005b460 symbols at 08dfc000-08e34000 (224kB), lines at 08de5000-08dfc000 (92kB) #0b: loading "(hd1,0)/oskit/l4/v2/omega0 --l4io" from 0233f000-02374bd0 to [ 00360000-003683d5 00369000-0038257c ] starting at entry 00360000 via trampoline page code 0005c468 symbols at 08de3000-08de5000 (8kB), lines at 08ddc000-08de3000 (28kB) #0c: loading "(hd1,0)/oskit/l4/v2/bmodfs" from 02375000-0240047f to [ 01220000-0123634c 01237000-0123f000 ] passing module (hd1,0)/oskit/l4/v2/libloader.s.so [ 02401000-0248de37 ] passing module (hd0,0)/l4/cfg/run.bmodfs.cfg [ 0248e000-0248e078 ] passing module (hd1,0)/oskit/l4/v2/run [ 0248f000-024dc6e7 ] passing module (hd1,0)/oskit/l4/lx/vmlinuz26 [ 024dd000-0322576b ] passing module (hd0,0)/l4/cfg/lx/l4linux26_rd.cfg [ 03226000-0322609b ] passing module (hd0,0)/l4/rd/rd1 [ 03227000-04227000 ] starting at entry 01220000 via trampoline page code 0005d460 symbols at 08dd7000-08ddc000 (20kB), lines at 08dc8000-08dd7000 (60kB) #13: loading "(hd1,0)/oskit/l4/v2/l4exec" from 04227000-04322cfa to [ 01100000-01127ec2 01128000-01132000 ] starting at entry 01100000 via trampoline page code 0005e460 symbols at 08dc0000-08dc8000 (32kB), lines at 08da8000-08dc0000 (96kB) #14: loading "(hd1,0)/oskit/l4/v2/con --l4io" from 04323000-04497302 to [ 00b00000-00b4e4ba 00b4f000-00b61000 ] starting at entry 00b00000 via trampoline page code 0005f464 symbols at 08d9b000-08da8000 (52kB), lines at 08d69000-08d9b000 (200kB) #15: loading "(hd1,0)/oskit/l4/v2/loader --fprov=BMODFS run.bmodfs.cfg l4linux26 _rd.cfg" from 04498000-0455ec9a to [ 01300000-013253f6 01326000-01338000 ] starting at entry 01300000 via trampoline page code 00060490 symbols at 08d63000-08d69000 (24kB), lines at 08d4d000-08d63000 (88kB) DMphys | DMphys memory map: DMphys | phys. memory 0x00000000-0x09af0000 (from L4 kernel info page) DMphys | using 0x00100000-0x09af0000 DMphys | Memory area Pool PS Flags DMphys | 0x00000000-0x00100000 -- -- RESERVED DMphys | 0x00100000-0x00119000 7 12 MAPPED DMphys | 0x00119000-0x00193000 -- -- DENIED DMphys | 0x00193000-0x00240000 7 12 MAPPED DMphys | 0x00240000-0x00253000 -- -- DENIED DMphys | 0x00253000-0x00360000 7 12 MAPPED DMphys | 0x00360000-0x00383000 -- -- DENIED DMphys | 0x00383000-0x00400000 7 12 MAPPED DMphys | 0x00400000-0x0043a000 -- -- DENIED DMphys | 0x0043a000-0x009ea000 7 12 MAPPED DMphys | 0x009ea000-0x00b00000 0 12 MAPPED DMphys | 0x00b00000-0x00b61000 -- -- DENIED DMphys | 0x00b61000-0x00b80000 0 12 MAPPED DMphys | 0x00b80000-0x00bd7000 -- -- DENIED DMphys | 0x00bd7000-0x00c00000 0 12 MAPPED DMphys | 0x00c00000-0x01000000 0 22 MAPPED DMphys | 0x01000000-0x01080000 0 12 MAPPED DMphys | 0x01080000-0x0108a000 -- -- DENIED DMphys | 0x0108a000-0x01100000 0 12 MAPPED DMphys | 0x01100000-0x01132000 -- -- DENIED DMphys | 0x01132000-0x01220000 0 12 MAPPED DMphys | 0x01220000-0x0123f000 -- -- DENIED DMphys | 0x0123f000-0x01300000 0 12 MAPPED DMphys | 0x01300000-0x01338000 -- -- DENIED DMphys | 0x01338000-0x01400000 0 12 MAPPED DMphys | 0x01400000-0x01414000 -- -- DENIED DMphys | 0x01414000-0x01500000 0 12 MAPPED DMphys | 0x01500000-0x0151a000 -- -- RESERVED DMphys | 0x0151a000-0x01800000 0 12 MAPPED DMphys | 0x01800000-0x02400000 0 22 MAPPED DMphys | 0x02400000-0x02401000 0 12 MAPPED DMphys | 0x02401000-0x04227000 -- -- DENIED DMphys | 0x04227000-0x04400000 0 12 MAPPED DMphys | 0x04400000-0x08c00000 0 22 MAPPED DMphys | 0x08c00000-0x08d4d000 0 12 MAPPED DMphys | 0x08d4d000-0x09af0000 -- -- DENIED DMphys | DMphys | DMphys memory pools: DMphys | pool 0 (Default memory pool): DMphys | size: 102160KB total, 102160KB free, 32KB reserved DMphys | 0x009ea000-0x00b00000 ( 1112KB, 1MB) DMphys | 0x00b61000-0x00b80000 ( 124KB, 0MB) DMphys | 0x00bd7000-0x01080000 ( 4772KB, 5MB) DMphys | 0x0108a000-0x01100000 ( 472KB, 0MB) DMphys | 0x01132000-0x01220000 ( 952KB, 1MB) DMphys | 0x0123f000-0x01300000 ( 772KB, 1MB) DMphys | 0x01338000-0x01400000 ( 800KB, 1MB) DMphys | 0x01414000-0x01500000 ( 944KB, 1MB) DMphys | 0x0151a000-0x02401000 ( 15260KB, 15MB) DMphys | 0x04227000-0x08d4d000 ( 76952KB, 75MB) DMphys | pool 7 (ISA DMA memory pool): DMphys | size: 8192KB total, 8192KB free, 0KB reserved DMphys | 0x00100000-0x00119000 ( 100KB, 0MB) DMphys | 0x00193000-0x00240000 ( 692KB, 1MB) DMphys | 0x00253000-0x00360000 ( 1076KB, 1MB) DMphys | 0x00383000-0x00400000 ( 500KB, 0MB) DMphys | 0x0043a000-0x009ea000 ( 5824KB, 6MB) simplets| Configured for 380 tasks. rtc | Date:26.12.2005 Time:16:48:44 RMGR: task a.00 at 00b99b61 is trying to get page 00100000 allocated by task 7 ---------------------------------------------------------IP: 0011b7fa --double page fault (4.00) jdb:

3 8

Re: L4Linux (dm_phys?) problem
by Jugwan Eom 29 Dec '05

29 Dec '05

Oh, I had many many many mistake. :( This is the right image.

1 0

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

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 December 2005