Hi,
With Nitpicker, I try to start X server with ovlscreen driver. After a little while, I get the following message : l4lx | l4x_hybrid_return: Invalid hybrid return for 23.00 (0x0688d570, e, 0, l4lx : -1, f0020d5d)! l4lx | l4x_hybrid_return: Currently running: 00.00
After some debugging and tracing, I've found that this message happens when X server does a rmgr_get_task_id on names. I don't understand why this IPC fails as ping_call perfectly works (I enabled traces on roottask and saw ping_component call).
I tried to enable IPC monitoring with I* into jdb, but I get an assertion in Fiasco : Assertion failed: 'this == current()' in /home/chaland/l4/tudos/kernel/fiasco/src/kern/context.cpp:512 at f0023378
I don't understand what happens. Could you help me please ?
Regards Marc
Hi Marc,
On Wed Nov 07, 2007 at 11:05:49 +0100, Marc CHALAND wrote:
With Nitpicker, I try to start X server with ovlscreen driver. After a little while, I get the following message : l4lx | l4x_hybrid_return: Invalid hybrid return for 23.00 (0x0688d570, e, 0, l4lx : -1, f0020d5d)! l4lx | l4x_hybrid_return: Currently running: 00.00
After some debugging and tracing, I've found that this message happens when X server does a rmgr_get_task_id on names. I don't understand why this IPC fails as ping_call perfectly works (I enabled traces on roottask and saw ping_component call).
I've just tried to reproduce something like this but I had no 'luck'. I also do not understand how the code path can be taken with the given values. I suppose your sources are up to date? Is this reliably reproducible?
I tried to enable IPC monitoring with I* into jdb, but I get an assertion in Fiasco : Assertion failed: 'this == current()' in /home/chaland/l4/tudos/kernel/fiasco/src/kern/context.cpp:512 at f0023378
Oh. Would you be able to build a test case for me?
Adam
2007/11/7, Adam Lackorzynski adam@os.inf.tu-dresden.de:
I've just tried to reproduce something like this but I had no 'luck'. I also do not understand how the code path can be taken with the given values. I suppose your sources are up to date? Is this reliably reproducible?
Yes, I have latest svn version of fiasco, l4env packages and l4linux. I use gcc 4.1.1 as compiler. Each time I start X, this happens. Only first value into braces changes.
Oh. Would you be able to build a test case for me?
What do you want I do ?
Marc
On Thu Nov 08, 2007 at 12:21:53 +0100, Marc CHALAND wrote:
2007/11/7, Adam Lackorzynski adam@os.inf.tu-dresden.de:
I've just tried to reproduce something like this but I had no 'luck'. I also do not understand how the code path can be taken with the given values. I suppose your sources are up to date? Is this reliably reproducible?
Yes, I have latest svn version of fiasco, l4env packages and l4linux. I use gcc 4.1.1 as compiler. Each time I start X, this happens. Only first value into braces changes.
Oh. Would you be able to build a test case for me?
What do you want I do ?
What I'd like to have is a setup that I can run in Qemu. I know it's not easy with X in a ramdisk etc but maybe you have this already?
Adam
2007/11/8, Adam Lackorzynski adam@os.inf.tu-dresden.de:
What I'd like to have is a setup that I can run in Qemu. I know it's not easy with X in a ramdisk etc but maybe you have this already?
Sorry, we don't have a Qemu setup. However, we plan to do one...
Marc
Some news about my problem.
Fiasco catches an exception (it seems to be a page fault) into Thread::do_ipc function (do_ipc + 0xbd). As there are many inline functions, I decided to remove INLINE option to fiasco kernel. And... no more exception :/. Now ovlscreen driver works perfectly.
It seems that there is a bug, but I don't know if it is due to PIC (I tried to come back to gcc 3.4.4 without success) code or to a fiasco bug for long IPC ? Any idea ? If you want more info, I can give you or I can do some experiment.
Regards Marc
On Thu Nov 15, 2007 at 09:54:25 +0100, Marc CHALAND wrote:
Some news about my problem.
Fiasco catches an exception (it seems to be a page fault) into Thread::do_ipc function (do_ipc + 0xbd). As there are many inline functions, I decided to remove INLINE option to fiasco kernel. And... no more exception :/. Now ovlscreen driver works perfectly.
It seems that there is a bug, but I don't know if it is due to PIC (I tried to come back to gcc 3.4.4 without success) code or to a fiasco bug for long IPC ? Any idea ? If you want more info, I can give you or I can do some experiment.
You did use gcc-4.1.1-something, right? Could you use some recent gcc-4.2 and retest? That would be interesting.
Adam
2007/11/18, Adam Lackorzynski adam@os.inf.tu-dresden.de:
You did use gcc-4.1.1-something, right? Could you use some recent gcc-4.2 and retest? That would be interesting.
I tried gcc-4.2.2 and result is the same. I also tried to push some 0xdeadbeef into the stack of calling ipc (code of l4_ipc_call_tag into ipc-l42-gcc3-pic.h). When pf occurs, I don't find the markers into the stack of X thread. Maybe stack is corrupted or I don't understand what happens ?
Have you some hint, tips to understand what happens ?
Regards Marc
On Wed Nov 21, 2007 at 10:31:47 +0100, Marc CHALAND wrote:
2007/11/18, Adam Lackorzynski adam@os.inf.tu-dresden.de:
You did use gcc-4.1.1-something, right? Could you use some recent gcc-4.2 and retest? That would be interesting.
I tried gcc-4.2.2 and result is the same. I also tried to push some 0xdeadbeef into the stack of calling ipc (code of l4_ipc_call_tag into ipc-l42-gcc3-pic.h). When pf occurs, I don't find the markers into the stack of X thread. Maybe stack is corrupted or I don't understand what happens ?
Have you some hint, tips to understand what happens ?
Are you using 2k or 4k stack in Fiasco? If 2k, try 4k. Also, there's a stack depth debugging feature, i.e. when you look at the thread list there's figure how much stack is used. You could look at those figure too. I'd suspect inlining is using a bit more stack than without inlining.
Adam
l4-hackers@os.inf.tu-dresden.de