Hi,
In order to increase the Fiasco performance, I removed all debug-stuff from the kernel. But as soon as I remove the JDB, I receive a kernel trap on all starting apps:
2.00 IP=00103480 Trap=03 [Ret/Esc] 4.00 IP=00112bc0 Trap=03 [Ret/Esc]
Do you know what might cause these traps?
Attached is my fiasco.config and below some more output...
*snip* Welcome to Fiasco(ia32)!
DD-L4(v2)/ia32 microkernel (C) 1998-2008 TU Dresden
Rev: r6951 compiled with gcc 4.1.2 for Intel Pentium []
Enabling special fully nested mode for PIC Using the PIT (i8254) on IRQ 0 for scheduling Absolute KIP Syscalls using: Sysenter CPU: GenuineIntel (6:F:A:0) Model: Core 2 (Merom) at 1582 MHz
128 Entry I TLB (4K pages) 272 Entry D TLB (4K pages) 48 Entry D TLB (4M pages) 32 KB L1 I Cache (8-way associative, 64 bytes per line) 32 KB L1 D Cache (8-way associative, 64 bytes per line) 4096 KB L2 U Cache (16-way associative, 64 bytes per line)
Freeing init code/data: 16384 bytes (4 pages)
Calibrating timer loop... done. SIGMA0: Hello! KIP @ 1000 * 2.00 IP=00103480 Trap=03 [Ret/Esc] * Found Fiasco: KIP syscalls: yes allocated 4KB for maintenance structures
Roottask. Command line found: "(cd)/tcb/roottask -configfile -sigma0 task modname "bmodfs" attached 8 modules"
1048127kB (1023MB) total RAM (reported by bootloader) 980376kB ( 958MB) received RAM from Sigma0 71732kB ( 71MB) reserved RAM for RMGR Received I/O ports 0000-ffff Attached irqs = [ <!0> 1 <!2> 3 4 5 6 7 8 9 A B C D E F <!10> <!11> ]
Roottask: Parsing config file. configured task 0x02 (): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x04 (): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (rtc): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:10 small:ff mods:0 configured task 0x00 (names): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (dm_phys): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (simple_ts): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (l4exec): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (l4io): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (mgui): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (loader): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (l4dope): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:1 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (compmgrlientl4): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (compmgr): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (names_demo): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (bmodfs): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (events): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0 configured task 0x00 (pmngr): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:a0 small:ff mods:0
Roottask: Parsing command line config. configured task 0x00 (bmodfs): vm_offs:0 irq:3ffff lmcp:ffff allow_cli:0 mcp:ff prio:10 small:ff mods:8
Roottask: Loading 17 modules. #05: loading "(cd)/tcb/names" from [02100000-02143637] to [002d0000-002d6917][002d7000-002e2000] entry at 00020068 via trampoline page code * 4.00 IP=00112bc0 Trap=03 [Ret/Esc] *
[...] *snip*
On Mon Apr 06, 2009 at 14:21:35 +0200, Marcel Selhorst wrote:
Hi,
In order to increase the Fiasco performance, I removed all debug-stuff from the kernel. But as soon as I remove the JDB, I receive a kernel trap on all starting apps:
2.00 IP=00103480 Trap=03 [Ret/Esc] 4.00 IP=00112bc0 Trap=03 [Ret/Esc]
Do you know what might cause these traps?
Those a are debugger calls made from user-land. Ideally those should be removed. A dirty hack might be to bail out early in handle_not_nested_trap() in kern/shared/thread-ia32-amd64.cpp.
Adam
Hi Adam,
Do you know what might cause these traps?
Those a are debugger calls made from user-land. Ideally those should be removed. A dirty hack might be to bail out early in handle_not_nested_trap() in kern/shared/thread-ia32-amd64.cpp.
I commented out the according lines and now it works. Thanks!
Marcel
Hi Marcel,
it might be interesting for the members of this list to hear about the speedup you achieved by deacticating JDB. Could you please post your results?
Greets
l4-hackers@os.inf.tu-dresden.de