Hi,
first of all: sorry for my late answer, I've been away...
On Thu, Aug 04, 2005 at 03:09:12PM +0200, Adam Lackorzynski wrote:
On Thu Aug 04, 2005 at 13:45:12 +0200, Rene Wittmann wrote:
I have also the problem that I want to output some of my symbols+values during the execution of my application. Furthermore I'm working in the RT scheduling mode (with APIC one shot mode).
I have three timeslices:
- mandatory
- optional
- "mandatory" (if part of optional was executed)
The preempter recognizes timeslice overruns and sets a global variable, the working thread checks this variable and therefore knows about those "events".
This works fine if my priorites are set to 50,30,50, but fails after a few periods with a pagefault if setting the priorities to 200,190,200.
In each part I use some calls to LOG() to output a few things I'm interested in. If I leave out those LOG()-calls, it works also with the high priorites (200,190,200). So I assume, there's a LOG-buffer overflow (as the LOG priority is not that high)?
Could I prevent this by using printf instead of LOG or is LOG just a kind of macro for printf?
printf is usually also a log function.
The priorities of the logserver are at 32, so in the first example they're inbetween and in the latter one completely below.
Does the PF go away when you add --prio 210 (or similar) as an argument to log?
Yes, it goes away. But I thought that, if you have a real-time application running it will not be influenced by some "time-sharing" application as the logserver should be.
Can you send me a backtrace with unstripped binaries when the PF happens? Thanks.
Sure, I can if you tell me how to do it...
The exact error message is:
app| L4RM: [PF] write at 0x01306f58, eip 0380e48b, src 9.02 app| [9.0] l4rm/lib/src/pagefault.c:78:__unknown_pf(): app| unhandled page fault
And then it enters the kernel debugger. I've compiled my program with "CFLAGS = -g" so it should be unstripped, right?
But when typing "bt<CR>" in the kernel debugger, there are no symbols and the output just looks like this
#4 f000763b #5 f0027332 #6 f000e718 #7 f000627a #8 f000e1fd #9 f000627a #10 f000e1fd #11 f000acb0 #12 f0005f6d #13 f000627a #14 f0006280 #15 f0005c3f #16 f000627a #17 f0006280 #18 f0005aec #19 f999c5f5 #20 f00176ed #21 f0006d54 #22 f0027300 #23 f000cfa5 #24 f0006a5a #25 f000784b #26 f00272dc
So I don't expect any helpful information in there or is it?
BTW: my grub config looks like this:
title llv1_decode (all layers, log locally) root (hd0,2) kernel /drops/bin/x86_586/l4v2/rmgr -sigma0 modaddr 0x08000000 module /l4/kernel/fiasco/build/fiasco_apic -nokdb -nowait -serial -serial_esc module /drops/bin/x86_586/l4v2/sigma0 module /drops/bin/x86_586/l4v2/log_net -net -local -ip 131.188.36.211 -buffer 4096 module /drops/bin/x86_586/l4v2/names module /drops/bin/x86_586/l4v2/dm_phys module /drops/bin/x86_586/l4v2/simple_ts module /drops/bin/x86_586/l4v2/app
OK, this modaddr seems huge, but my data is just linked to the binary and I need this huge value...
So how would one produce a useful backtrace inside fiasco? Or is there a way to use another debugger (gdb?)?
Greetings, Rene