Hello,
I'm currently trying to get fiasco's built-in profiling working. The problem is, as soon as roottask has been started, an error (mcount: tos overflow) occurs which apparently prevents profiling. Later on no gmon.out.uu is generated. Is that supposed to work? Or what am I doing wrong here? I attached a log showing the error message.
From the JDB source code, it sounds like you can enable and disable kernel profiling from JDB. How can this be accomplished?
Thanks for any help
Stefan
L4 Bootstrapper Scaning /bin/fiasco -profile -profstart -nokdb -nowait -serial -comport 1 -serial_esc Scaning /bin/sigma0 Scaning /bin/roottask Bootloader MMAP available [00000000,0009fc00) RAM (1) [0009fc00,000a0000) RAM (1) [000f0000,00100000) reserved (2) [ffb00000,00000000) reserved (2) [00100000,1fff0000) RAM (1) [1fff3000,20000000) ACPI (3) [1fff0000,1fff3000) ACPI NVS (4) Relocated mbi to [0x61000-0x611b3] Loading /bin/fiasco Loading /bin/sigma0 Loading /bin/roottask find kernel info page... found kernel info page at 0x1000 API Version: (87) experimental Sigma0 config ip:00094cd0 sp:00106100 Roottask config ip:00120000 sp:00109528 [00001000-00002000) /bin/fiasco [00002000-00052680) /bin/fiasco [00052680-0005add0) /bin/fiasco [0005b000-0005e861) /bin/fiasco [0005e880-00061000) /bin/fiasco [00090000-00099380) /bin/sigma0 [0009f000-00100000) BIOS area [00100000-00109764) bootstrap [00120000-001345d0) /bin/roottask [00135000-0013f9bb) /bin/roottask [001409c0-002be9f4) /bin/roottask [00300000-003017ec) /bin/fiasco [00302000-0038fce0) /bin/fiasco [03000000-03152c1d) Modules Memory [1fff0000-ffffffff) Deep Space Starting kernel /bin/fiasco at 003007e8
Welcome to Fiasco(ia32)! DD-L4(v2)/x86 microkernel (C) 1998-2006 TU Dresden Rev: Thu Dec 21 08:55:14 2006 compiled with gcc 4.1.1 for Pentium M Performance-critical config option(s) detected: CONFIG_SCHED_RTC is on CONFIG_ASSEMBLER_IPC_SHORTCUT is off CONFIG_PROFILE is on CONFIG_NO_FRAME_PTR is off CONFIG_JDB_ACCOUNTING is on
Enabling special fully nested mode for PIC Using the RTC on IRQ 8 (1kHz) for scheduling SERIAL ESC: allocated IRQ 4 for serial uart Absolute KIP Syscalls using: Sysenter CPU: GenuineIntel (F:2:4:9) Model: Pentium 4 (Northwood/Prestonia) at 1992 MHz
64 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: 24576 bytes (6 pages)
Calibrating timer loop... done. SIGMA0: Hello! KIP @ 1000 Found Fiasco: KIP syscalls: yes allocated 4KB for maintenance structures
Roottask. Command line found: "/bin/roottask" mcount: tos overflow
523840kB ( 511MB) total RAM (reported by bootloader) 479676kB ( 469MB) received RAM from Sigma0 1816kB ( 2MB) 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 ]
Roottask: Loading 1 module. #05: loading "/bin/hello" from [0312d000-03152c1d] to [01000000-01002eea][01003000-010055c0] entry at 0005b064 via trampoline page code symbols at [1d6fa000-1d6fb000] (4kB), lines at [1d6f7000-1d6fa000] (12kB)
hello: My thread-id is 5.0 hello: My thread-id is 5.0 hello: My thread-id is 5.0
On Mon Apr 09, 2007 at 13:46:26 +0200, Stefan Scheler wrote:
I'm currently trying to get fiasco's built-in profiling working. The problem is, as soon as roottask has been started, an error (mcount: tos overflow) occurs which apparently prevents profiling. Later on no gmon.out.uu is generated. Is that supposed to work? Or what am I doing wrong here? I attached a log showing the error message.
From the JDB source code, it sounds like you can enable and disable kernel profiling from JDB. How can this be accomplished?
I fear nobody has tried profiling in some time. Could you find out yourself what's going on and report?
Thanks, Adam
Hello,
I fear nobody has tried profiling in some time. Could you find out yourself what's going on and report?
Well, here we go. I meanwhile managed to get that working but encountered several problems. Especially problem 2 seems a bit odd to me. Feedback is greatly appreciated.
I'm cc'ing also Martin Pohlack, because I was told he is the man for profiling :).
1) gprof wants to allocate larger junks of memory than alloc() in class Buddy_t_base can currently handle (limit 65535 bytes). So trying to allocate larger pieces of memory, alloc() returned always 0 bytes. Increasing NUM_SIZES von 8 to 10 seems to fix this issue.
2) Next, fiasco crashes executing this line of code:
s_scale = (int)(( (float) monsize / o ) * SCALE_1_TO_1);
with the following error message:
KERNEL: Denying 0.0 to send fault message (pfa=00000008, code=00000000) to 7ff.7f
KERNEL: 0.0 (tcb=c0000000) killed: Unhandled trap
EAX 000000fe EBX 00000000 ECX f0055efe EDX 00000001 ESI 00000000 EDI 00000204 EBP c0000718 ESP c000070c EIP f000477e EFLAGS 00210282 CS 0008 SS 0010 DS 0023 ES 0023 FS 0023 GS 0023 trap 14 (Page Fault), error 00000000, from kernel mode page fault linear address 00000008
I really don't understand this one. I can execute this statement perfectly well in a separate c program on my machine (with monsize = 189784, o = 379568 and SCALE_1_TO_1 = 65536). I "fixed" this by setting s_scale manually to the calculation's result of 32768.
3) The gzipped and uuencoded output thing does not produce any output here. I didn't have the time to look into this until now. For now I disabled this and send the data in a hexadecimal encoding over the serial line.
Stefan
Hi Stefan,
Just a quick reply for now:
[...]
I'm cc'ing also Martin Pohlack, because I was told he is the man for profiling :).
I'm also reading l4-hackers.
[...]
- Next, fiasco crashes executing this line of code:
s_scale = (int)(( (float) monsize / o ) * SCALE_1_TO_1);
You really should not do floating point stuff in the kernel.
Maybe you can activate the code path two lines below which uses only integer math?
Cheers, Martin
Hi,
On Tue May 01, 2007 at 09:18:47 +0200, Stefan Scheler wrote:
I fear nobody has tried profiling in some time. Could you find out yourself what's going on and report?
Well, here we go. I meanwhile managed to get that working but encountered several problems. Especially problem 2 seems a bit odd to me. Feedback is greatly appreciated.
I'm cc'ing also Martin Pohlack, because I was told he is the man for profiling :).
- gprof wants to allocate larger junks of memory than alloc() in class
Buddy_t_base can currently handle (limit 65535 bytes). So trying to allocate larger pieces of memory, alloc() returned always 0 bytes. Increasing NUM_SIZES von 8 to 10 seems to fix this issue.
Ok, I think this is just a configuration thing.
- Next, fiasco crashes executing this line of code:
s_scale = (int)(( (float) monsize / o ) * SCALE_1_TO_1);
with the following error message:
KERNEL: Denying 0.0 to send fault message (pfa=00000008, code=00000000) to 7ff.7f
KERNEL: 0.0 (tcb=c0000000) killed: Unhandled trap
EAX 000000fe EBX 00000000 ECX f0055efe EDX 00000001 ESI 00000000 EDI 00000204 EBP c0000718 ESP c000070c EIP f000477e EFLAGS 00210282 CS 0008 SS 0010 DS 0023 ES 0023 FS 0023 GS 0023 trap 14 (Page Fault), error 00000000, from kernel mode page fault linear address 00000008
I really don't understand this one. I can execute this statement perfectly well in a separate c program on my machine (with monsize = 189784, o = 379568 and SCALE_1_TO_1 = 65536). I "fixed" this by setting s_scale manually to the calculation's result of 32768.
As Martin already said, one cannot just do floating point stuff in the kernel without special treatment. Best is to avoid it.
- The gzipped and uuencoded output thing does not produce any output
here. I didn't have the time to look into this until now. For now I disabled this and send the data in a hexadecimal encoding over the serial line.
This was buggy and has been fixed by now.
Adam
l4-hackers@os.inf.tu-dresden.de