[Xenomai] gdb / threads on beaglebone black

[Xenomai] gdb / threads on beaglebone black

[Drew]

I'm seeing unexpected behavior running under gdb on a beaglebone black
using a machinekit debian SD image:

http://www.machinekit.net/deb/rootfs/wheezy/debian-7.4-machinekit-armhf-2014-05-09-4gb.img.xz

I'm curious if the behavior repeats on other platforms, and what I might be
doing wrong. My understanding is that xenomai should work OK under GDB as
long as you don't mind the mode switching.

The code is at

http://pastebin.com/MUgLAbGX

It is a modified version of
xenomai-2.6/examples/native/trivial-periodic.c

I build and run in gdb:

cd xenomai-2.6/examples/native
export MY_CFLAGS="-g"
make trivial-periodic
gdb ./trivial-periodic
run

At this point, I get two "New Thread" messages, two "Thread Exited"
messages, a 3 second pause, then "hello world" and nothing else.

Outside of gdb, the program works as expected.

I'm confused why the threads have exited before I have even called
rt_task_start on either of them. This has been reproduced by another
machinekit user; he suggested I try the Xenomai list.

Thanks in advance

Drew

PS I posted this to the list on May 22, but I hadn't joined the list at the
time. I don't see it in the archives so I'm re-posting. Hope it isn't a
duplicate.

Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum]

On 05/26/2014 03:49 AM, Drew wrote:
> I'm seeing unexpected behavior running under gdb on a beaglebone black
> using a machinekit debian SD image:
>
> http://www.machinekit.net/deb/rootfs/wheezy/debian-7.4-machinekit-armhf-2014-05-09-4gb.img.xz
>
> I'm curious if the behavior repeats on other platforms, and what I might be
> doing wrong. My understanding is that xenomai should work OK under GDB as
> long as you don't mind the mode switching.
>
> The code is at
>
> http://pastebin.com/MUgLAbGX
>
> It is a modified version of
> xenomai-2.6/examples/native/trivial-periodic.c
>
> I build and run in gdb:
>
> cd xenomai-2.6/examples/native
> export MY_CFLAGS="-g"
> make trivial-periodic
> gdb ./trivial-periodic
> run
>
> At this point, I get two "New Thread" messages, two "Thread Exited"
> messages, a 3 second pause, then "hello world" and nothing else.
>
> Outside of gdb, the program works as expected.
>
> I'm confused why the threads have exited before I have even called
> rt_task_start on either of them. This has been reproduced by another
> machinekit user; he suggested I try the Xenomai list.
>

Any change with this?

- pause();
+ for (;;)
+    pause();

-- 
Philippe.

Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum]

On 05/26/2014 02:50 PM, Drew wrote:
>
> On Mon, May 26, 2014 at 3:09 AM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
>
>
>     Any change with this?
>
>     - pause();
>     + for (;;)
>     +    pause();
>
>     --
>     Philippe.
>
>
> I get the "thread exited" messages before the "hello, world" is
> printed.. that's before the pause() call and even before the tasks have
> been started..

Do not trust stdio printouts for debugging in a dual kernel system, they 
may be delayed in different ways, despite your termios are set to 
canonical mode.

In addition, testing return codes of syscalls would be a good idea, e.g. 
rt_task_start(), assuming rt_task_create() did succeed since GDB told 
you about two new threads.

PS: please keep the list posted.

-- 
Philippe.

Re: [Xenomai] gdb / threads on beaglebone black

[Drew]

Philippe: There is no change.

The "Thread Exited" messages come almost immediately. I put the sleep(3) in
there to be sure.. the order is definitely New Thread (x2), Thread Exited
(x2) - 3 second pause - hello world.
The sleep also influences the thread exit.. Without the sleep, only the
first thread created exits before it is started... unless you single step;
in that case, the first thread created exits when you "next" over the
creation of the second thread, then the second thread created exits when
you "next" over the next line. (the printf, here.)

I'm pretty sure I'm seeing threads exiting before they are even started..
Kinda like something in rt_task_create is accidentally starting the thread
without even knowing which function to execute on the thread.

PS: thanks for putting my reply on the list; I must have hit "reply"
instead of "reply all"

Re: [Xenomai] gdb / threads on beaglebone black

[Drew]

rt_task_create does not return an error.

Looking through src/skins/native/task.c, I see that rt_task_create actually
does start another thread.. rt_task_trampoline. So, I'm thinking possibly
this is the thread that gdb is telling me has exited, not my thread?

rt_task_start does return an error... -3.. which is "no such process" (I
think..) that would be consistent with my thread exiting prematurely.

It looks like rt_task_trampoline is supposed to hang around until
rt_task_start is executed, (the do while loop) but perhaps that loop exits
with an error other than EINTR? It seems possible that do while could exit
and still have a null entry pointer..

I'm guessing that trampoline is named that way because you bounce from that
task into the real task at the entry(cookie) line..

Re: [Xenomai] gdb / threads on beaglebone black

[Drew]

Yes, my guess was correct.
The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
If I change line 110 of skins/native/task.c:

- while(err == -EINTR)
+ while(err == -EINTR || err == -ENOSYS)

then I'm able to single-step in gdb. :-)

Is my change a hack, or is it the correct thing to do?
It looks like rt_task_trampoline is only expecting EINTR to occur. Is some
other bug causing ENOSYS? Or are there a few other valid errors that may be
returned while waiting on the barrier? (the comment above the loop says "to
process Linux signals" but the code only checks for one thing.) Should
rt_task_trampoline somehow warn a user if the do-while encounters an error
it doesn't expect? (or does it already, through another debug mechanism I'm
not using?)

As an aside, another question is why rt_task_trampoline at all? Why fire up
the new thread when it doesn't yet know what it will be executing? I'm
guessing it is for speed, so that when rt_task_start actually does execute,
it will execute immediately...

Drew

Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum]

On 05/28/2014 04:08 PM, Drew wrote:
> Yes, my guess was correct.
> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
> If I change line 110 of skins/native/task.c:
>
> - while(err == -EINTR)
> + while(err == -EINTR || err == -ENOSYS)
>
> then I'm able to single-step in gdb. :-)
>
> Is my change a hack, or is it the correct thing to do?

No Xenomai call should ever return ENOSYS. Something is definitely wrong 
with the current setup.

> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
> some other bug causing ENOSYS?

This means that the 'barrier' syscall did not get to Xenomai core, but 
was rejected as undefined.

Could any of the hints mentioned here apply in your case?
http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys

  Or are there a few other valid errors
> that may be returned while waiting on the barrier? (the comment above
> the loop says "to process Linux signals" but the code only checks for
> one thing.) Should rt_task_trampoline somehow warn a user if the
> do-while encounters an error it doesn't expect? (or does it already,
> through another debug mechanism I'm not using?)

The loop only cares for non-restartable syscalls, which receive EINTR 
when interrupted by a signal handler.

>
> As an aside, another question is why rt_task_trampoline at all? Why fire
> up the new thread when it doesn't yet know what it will be executing?
> I'm guessing it is for speed, so that when rt_task_start actually does
> execute, it will execute immediately...
>

Correct, rt_task_create() does all the resource reservation, all the 
lengthy stuff. When successful, we know that we'll be able to start the 
task code upon rt_task_start(), provided the task descriptor is valid. 
rt_task_start() is only about unleashing a ready-to-run thread context.

-- 
Philippe.

Re: [Xenomai] gdb / threads on beaglebone black

[Michael Haberler]

Am 28.05.2014 um 16:24 schrieb Philippe Gerum <rpm@xenomai.org>:

> On 05/28/2014 04:08 PM, Drew wrote:
>> Yes, my guess was correct.
>> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
>> If I change line 110 of skins/native/task.c:
>> 
>> - while(err == -EINTR)
>> + while(err == -EINTR || err == -ENOSYS)
>> 
>> then I'm able to single-step in gdb. :-)
>> 
>> Is my change a hack, or is it the correct thing to do?

I reproduced the behavior on an slightlier earlier kernel version than Drew used:

config: http://static.mah.priv.at/public/config.txt
dmesg: http://static.mah.priv.at/public/dmesg.txt

$ cat /proc/ipipe/version
3
$ cat /proc/xenomai/version
2.6.3

> 
> No Xenomai call should ever return ENOSYS. Something is definitely wrong with the current setup.
> 
>> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
>> some other bug causing ENOSYS?
> 
> This means that the 'barrier' syscall did not get to Xenomai core, but was rejected as undefined.
> 
> Could any of the hints mentioned here apply in your case?
> http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys

as above, I'm not seeing a violation of any of those conditions?

thanks,

Michael

> Or are there a few other valid errors
>> that may be returned while waiting on the barrier? (the comment above
>> the loop says "to process Linux signals" but the code only checks for
>> one thing.) Should rt_task_trampoline somehow warn a user if the
>> do-while encounters an error it doesn't expect? (or does it already,
>> through another debug mechanism I'm not using?)
> 
> The loop only cares for non-restartable syscalls, which receive EINTR when interrupted by a signal handler.
> 
>> 
>> As an aside, another question is why rt_task_trampoline at all? Why fire
>> up the new thread when it doesn't yet know what it will be executing?
>> I'm guessing it is for speed, so that when rt_task_start actually does
>> execute, it will execute immediately...
>> 
> 
> Correct, rt_task_create() does all the resource reservation, all the lengthy stuff. When successful, we know that we'll be able to start the task code upon rt_task_start(), provided the task descriptor is valid. rt_task_start() is only about unleashing a ready-to-run thread context.
> 
> -- 
> Philippe.
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix]

On 05/28/2014 04:45 PM, Michael Haberler wrote:
> 
> Am 28.05.2014 um 16:24 schrieb Philippe Gerum <rpm@xenomai.org>:
> 
>> On 05/28/2014 04:08 PM, Drew wrote:
>>> Yes, my guess was correct.
>>> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
>>> If I change line 110 of skins/native/task.c:
>>>
>>> - while(err == -EINTR)
>>> + while(err == -EINTR || err == -ENOSYS)
>>>
>>> then I'm able to single-step in gdb. :-)
>>>
>>> Is my change a hack, or is it the correct thing to do?
> 
> I reproduced the behavior on an slightlier earlier kernel version than Drew used:
> 
> config: http://static.mah.priv.at/public/config.txt
> dmesg: http://static.mah.priv.at/public/dmesg.txt
> 
> $ cat /proc/ipipe/version
> 3
> $ cat /proc/xenomai/version
> 2.6.3
> 
>>
>> No Xenomai call should ever return ENOSYS. Something is definitely wrong with the current setup.
>>
>>> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
>>> some other bug causing ENOSYS?
>>
>> This means that the 'barrier' syscall did not get to Xenomai core, but was rejected as undefined.
>>
>> Could any of the hints mentioned here apply in your case?
>> http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys
> 
> as above, I'm not seeing a violation of any of those conditions?

Is there no message printed on the kernel console which would explain
why this syscall gets rejected?


-- 
                                                                Gilles.

Re: [Xenomai] gdb / threads on beaglebone black

[Drew]

On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

>
> Is there no message printed on the kernel console which would explain
> why this syscall gets rejected?
>

A good idea! Unfortunately, after hooking up my debug serial cable I don't
see any message when this happens. Running tail -f /var/log/messages
doesn't show anything suspicious either. (well, it did find some things I
didn't clean up in my main application... ;-)

Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does
that contain the kernel side of the do while loop? I notice that
xnshadow_sys_trace (which seems debugger related to me..) defaults its
error to -ENOSYS...

Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum]

On 05/28/2014 09:19 PM, Drew wrote:
> On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>>
>> Is there no message printed on the kernel console which would explain
>> why this syscall gets rejected?
>>
>
> A good idea! Unfortunately, after hooking up my debug serial cable I don't
> see any message when this happens. Running tail -f /var/log/messages
> doesn't show anything suspicious either. (well, it did find some things I
> didn't clean up in my main application... ;-)
>
> Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does
> that contain the kernel side of the do while loop? I notice that
> xnshadow_sys_trace (which seems debugger related to me..) defaults its
> error to -ENOSYS...

It's not related to GDB, but to the internal tracing system available 
with CONFIG_IPIPE_TRACE. The call is likely dismissed even before 
Xenomai handles it. A brute force but straightforward way to get some 
hints would be to instrument the syscall router in the interrupt 
pipeline code.

-- 
Philippe.

Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix]

On 05/28/2014 09:19 PM, Drew wrote:
> On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>>
>> Is there no message printed on the kernel console which would explain
>> why this syscall gets rejected?
>>
> 
> A good idea! Unfortunately, after hooking up my debug serial cable I don't
> see any message when this happens. Running tail -f /var/log/messages
> doesn't show anything suspicious either. (well, it did find some things I
> didn't clean up in my main application... ;-)
> 
> Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does
> that contain the kernel side of the do while loop? I notice that
> xnshadow_sys_trace (which seems debugger related to me..) defaults its
> error to -ENOSYS...
> 

If you enable CONFIG_IPIPE_DEBUG_INTERNAL, do you see the following message:

[  292.460803] kernel BUG at arch/arm/kernel/ipipe.c:445!

(the line number may be a bit different as I am testing Xenomai on Linux
3.14).

-- 
                                                                Gilles.

Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix]

On 05/28/2014 09:19 PM, Drew wrote:
> On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>>
>> Is there no message printed on the kernel console which would explain
>> why this syscall gets rejected?
>>
> 
> A good idea! Unfortunately, after hooking up my debug serial cable I don't
> see any message when this happens. Running tail -f /var/log/messages
> doesn't show anything suspicious either. (well, it did find some things I
> didn't clean up in my main application... ;-)
> 
> Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does
> that contain the kernel side of the do while loop? I notice that
> xnshadow_sys_trace (which seems debugger related to me..) defaults its
> error to -ENOSYS...
> 
The problem is syscall restarting by calling the syscall
sys_restart_syscall. When it appeared in entry.S, I made the assumption
that it would only be used for Linux syscall, that Xenomai syscall would
never have anything else than current_thread_info()->restart_block.fn
equal to "do_not_restart_syscall". This seems to be right most of the
time, except when running under gdb, where the kernel may want to
restart xenomai syscalls.

This implies reworking entry.S somehow. I do not see how yet, but I am
on it.

-- 
                                                                Gilles.

Re: [Xenomai] gdb / threads on beaglebone black

[Michael Haberler]

Am 28.05.2014 um 19:54 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:

> On 05/28/2014 04:45 PM, Michael Haberler wrote:
>> 
>> Am 28.05.2014 um 16:24 schrieb Philippe Gerum <rpm@xenomai.org>:
>> 
>>> On 05/28/2014 04:08 PM, Drew wrote:
>>>> Yes, my guess was correct.
>>>> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
>>>> If I change line 110 of skins/native/task.c:
>>>> 
>>>> - while(err == -EINTR)
>>>> + while(err == -EINTR || err == -ENOSYS)
>>>> 
>>>> then I'm able to single-step in gdb. :-)
>>>> 
>>>> Is my change a hack, or is it the correct thing to do?
>> 
>> I reproduced the behavior on an slightlier earlier kernel version than Drew used:
>> 
>> config: http://static.mah.priv.at/public/config.txt
>> dmesg: http://static.mah.priv.at/public/dmesg.txt
>> 
>> $ cat /proc/ipipe/version
>> 3
>> $ cat /proc/xenomai/version
>> 2.6.3
>> 
>>> 
>>> No Xenomai call should ever return ENOSYS. Something is definitely wrong with the current setup.
>>> 
>>>> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
>>>> some other bug causing ENOSYS?
>>> 
>>> This means that the 'barrier' syscall did not get to Xenomai core, but was rejected as undefined.
>>> 
>>> Could any of the hints mentioned here apply in your case?
>>> http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys
>> 
>> as above, I'm not seeing a violation of any of those conditions?
> 
> Is there no message printed on the kernel console which would explain
> why this syscall gets rejected?

this is the complete session on the console:

machinekit@beaglebone:~/xenomai-2.6/examples/native$ gdb trivial-periodic
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/machinekit/xenomai-2.6/examples/native/trivial-periodic...done.
(gdb) r
Starting program: /home/machinekit/xenomai-2.6/examples/native/trivial-periodic
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb6fc0470 (LWP 649)]
[New Thread 0xb6e83470 (LWP 650)]
[Thread 0xb6fc0470 (LWP 649) exited]
[Thread 0xb6e83470 (LWP 650) exited]
hello world

^C
Program received signal SIGINT, Interrupt.
0xb6fa6fcc in pause () from /lib/arm-linux-gnueabihf/libpthread.so.0
(gdb)

dmesg is empty here

- Michael


> 
> 
> -- 
>                                                                Gilles.

Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum]

On 05/28/2014 10:31 PM, Michael Haberler wrote:
>
> Am 28.05.2014 um 19:54 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
>> On 05/28/2014 04:45 PM, Michael Haberler wrote:
>>>
>>> Am 28.05.2014 um 16:24 schrieb Philippe Gerum <rpm@xenomai.org>:
>>>
>>>> On 05/28/2014 04:08 PM, Drew wrote:
>>>>> Yes, my guess was correct.
>>>>> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
>>>>> If I change line 110 of skins/native/task.c:
>>>>>
>>>>> - while(err == -EINTR)
>>>>> + while(err == -EINTR || err == -ENOSYS)
>>>>>
>>>>> then I'm able to single-step in gdb. :-)
>>>>>
>>>>> Is my change a hack, or is it the correct thing to do?
>>>
>>> I reproduced the behavior on an slightlier earlier kernel version than Drew used:
>>>
>>> config: http://static.mah.priv.at/public/config.txt
>>> dmesg: http://static.mah.priv.at/public/dmesg.txt
>>>
>>> $ cat /proc/ipipe/version
>>> 3
>>> $ cat /proc/xenomai/version
>>> 2.6.3
>>>
>>>>
>>>> No Xenomai call should ever return ENOSYS. Something is definitely wrong with the current setup.
>>>>
>>>>> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
>>>>> some other bug causing ENOSYS?
>>>>
>>>> This means that the 'barrier' syscall did not get to Xenomai core, but was rejected as undefined.
>>>>
>>>> Could any of the hints mentioned here apply in your case?
>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys
>>>
>>> as above, I'm not seeing a violation of any of those conditions?
>>
>> Is there no message printed on the kernel console which would explain
>> why this syscall gets rejected?
>
> this is the complete session on the console:
>
> machinekit@beaglebone:~/xenomai-2.6/examples/native$ gdb trivial-periodic
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabihf".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/machinekit/xenomai-2.6/examples/native/trivial-periodic...done.
> (gdb) r
> Starting program: /home/machinekit/xenomai-2.6/examples/native/trivial-periodic
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> [New Thread 0xb6fc0470 (LWP 649)]
> [New Thread 0xb6e83470 (LWP 650)]
> [Thread 0xb6fc0470 (LWP 649) exited]
> [Thread 0xb6e83470 (LWP 650) exited]
> hello world
>
> ^C
> Program received signal SIGINT, Interrupt.
> 0xb6fa6fcc in pause () from /lib/arm-linux-gnueabihf/libpthread.so.0
> (gdb)
>
> dmesg is empty here

Even with CONFIG_IPIPE_DEBUG_INTERNAL turned on?

-- 
Philippe.

Re: [Xenomai] gdb / threads on beaglebone black

[Drew]

I've only been using the machinekit pre-built kernel so rebuilding might
take me a little while figure out.

Gilles: you think you have this bug in a corner (entry.S?)

Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix]

On 05/28/2014 11:01 PM, Drew wrote:
> I've only been using the machinekit pre-built kernel so rebuilding might
> take me a little while figure out.
> 
> Gilles: you think you have this bug in a corner (entry.S?)

I can reproduce the bug. It is most certainly related to system call
restarting, but I am not quite sure of what happens yet. My BUG_ON
trigs, but I do not understand why, and the reason of the BUG_ON is not
what causes the -ENOSYS. I can not really use the I-pipe tracer, because
everything happens in assembly code with very few function calls.

So, it may be a while before I produce a fix.

-- 
                                                                Gilles.

Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix]

On 05/28/2014 11:08 PM, Gilles Chanteperdrix wrote:
> On 05/28/2014 11:01 PM, Drew wrote:
>> I've only been using the machinekit pre-built kernel so rebuilding might
>> take me a little while figure out.
>>
>> Gilles: you think you have this bug in a corner (entry.S?)
> 
> I can reproduce the bug. It is most certainly related to system call
> restarting, but I am not quite sure of what happens yet. My BUG_ON
> trigs, but I do not understand why, and the reason of the BUG_ON is not
> what causes the -ENOSYS. I can not really use the I-pipe tracer, because
> everything happens in assembly code with very few function calls.
> 
> So, it may be a while before I produce a fix.
> 
The result is embarrassingly simple: the BUG_ON is wrong, and we simply 
need to pass restarted syscalls through __ipipe_syscall_root.


diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 68a80d3..8f29cb1 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -446,6 +446,7 @@ ENTRY(vector_swi)
 	eor	scno, scno, #__NR_SYSCALL_BASE	@ check OS number
 #endif
 
+local_restart:
 #ifdef CONFIG_IPIPE
 	mov	r1, sp
 	mov	r0, scno
@@ -457,7 +458,6 @@ ENTRY(vector_swi)
 	ldmia	sp, { r0 - r3 }
 #endif /* CONFIG_IPIPE */
 
-local_restart:
 	ldr	r10, [tsk, #TI_FLAGS]		@ check for syscall tracing
 	stmdb	sp!, {r4, r5}			@ push fifth and sixth args
 
diff --git a/arch/arm/kernel/ipipe.c b/arch/arm/kernel/ipipe.c
index abdbe29..3a2266c 100644
--- a/arch/arm/kernel/ipipe.c
+++ b/arch/arm/kernel/ipipe.c
@@ -440,10 +440,6 @@ asmlinkage int __ipipe_syscall_root(unsigned long scno, struct pt_regs *regs)
 
 	fast_irq_enable(flags);
 out:
-#ifdef CONFIG_IPIPE_DEBUG_INTERNAL
-	BUG_ON(ret > 0 && current_thread_info()->restart_block.fn !=
-	       do_no_restart_syscall);
-#endif
 	return ret;
 }
 


-- 
                                                                Gilles.