Re: [Xenomai] segfault in printer_loop()

[Jan Kiszka]

On 2017-11-10 07:58, C Smith wrote:
> Agreed the segfault is inside pthread_cond_wait(), the contents of the
> args are seen in previous post.
> dmesg says this:
> app[12316]: segfault at c ip b76fe0db sp b771c268 error 4 in
> libpthread-2.15.so [b76f4000+16000]
> 
> And gdb shows me the same address. After a segfault generated inside gdb:
> p $_siginfo._sifields._sigfault.si_addr
> $9 = (void *) 0xc
> 
> I've done further testing and in gdb I found that my app segfaults
> before hitting the first line of main().
> Thus I am unable to catch it in gdb with a hardware watchpoint. I
> attempted to do so by first making my
> app hit a breakpoint on the first line of main(), then I set a
> watchpoint on 0xC in
> gdb and run, but I never get a segfault after that point, after over 100
> runs.

You can set a breakpoint on __rt_print_init, e.g.

> 
> Note that the app launches only 1 realtime thread now in these tests (in
> original tests it had 3 threads).
> Here is the one way I was able to get the app to run without
> segfaulting, even with multiple real
> time threads: I set kernel boot option maxcpus=1.  (on a SMP kernel with
> 4 cores). I was then able to run
> the app over 80 times with no segfault.
> 
> So the segfault is happening on about 10% of runs, in printer_loop(),
> apparently before the first line of main(), and I am unable to
> catch the bad memory access in a debugger with a watchpoint.
> Do you have a suggestion as to how to further debug this?

See above. Maybe that alone will give you a hint: if that function, for
what ever reason, happens to be called twice, that could explain the
issue as well. Then please catch the backtraces of all invocations.

Jan

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Won`t build on new Debian Stable

[Jan Kiszka]

On 2017-11-09 10:38, Philippe Gerum wrote:
> On 10/19/2017 06:55 PM, Henning Schild wrote:
>> On Thu, 19 Oct 2017 12:03:33 +0200
>> Philippe Gerum  wrote:
>>
>>> On 10/13/2017 01:36 PM, Norbert Lange wrote:
 I works, because collect2 (the "compiler driver", which documents
 the -r option) now knows about the -r flag, using -Wl,-[U]r would
 mean the flags aren't even looked at.
 It can then disable functionality that is not supposed to be done at
 this point (see gcc/collect2.c, search for 'early_exit'). It might
 actually be in conflict with the -Ur option from the comments, but I
 don't know what this is trying to solve (the constructor tables
 would then be built in the second step?)

 I would prefer the compiler driver knowing about the flags and
 correctly dealing with them, instead of replicating this logic in
 scripts (and keeping it up to date with this internal logic).  
>>>
>>> Ack.
>>>
 Might be that your wrapper script is doing something similarly by
 filtering out the arguments for the first step, which might be the
 same functionally that is skipped when adding '-r'

 I dont know what the -Ur flag is trying to solve, and the first
 patch adding -no-pie is way less likely to change something (given
 that I would not have compiled with -pie before).
 The new patch would however leave more of the magic to the toolchain
 and seems more "correct" to me, for whatever that's worth. But it
 might have some subtle differences to before, got some testcase
 where lacking the -Ur flag made a difference?  
>>>
>>> I don't know the original intent about passing -Ur to the linker,
>>> except maybe to stick to the ld manpage which states that the last
>>> partial link command should be given such option.
>>>
>>> However my understanding is that we don't need it in wrap-link.sh,
>>> since the script eventually completes the link stage to produce a
>>> fully resolved executable. That implies collecting the ctors/dtors and
>>> resolving all references from the partially linked object file anyway.
>>>
>>> Some testing only passing -r here seems to confirm this assumption
>>> with C++ apps; C++ users may want to check this too:
>>
>> I just told some C++ power users to give that a try. I am not sure how
>> fast the feedback will arrive, i hope in the next two weeks.
>>
>> Henning
>>
>>>
>>> diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
>>> index aab7899..fa83bd5 100755
>>> --- a/scripts/wrap-link.sh
>>> +++ b/scripts/wrap-link.sh
>>> @@ -204,7 +204,7 @@ done
>>>
>>>  if $stage2; then
>>>  $verbose && set -x
>>> -$dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
>>> +$dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
>>>  $dryrun $cc -o "$output" "$output.tmp" $stage2_args
>>>  $dryrun rm -f $output.tmp
>>>  else
>>>
> 
> Any news from the Xenomai/C++ folks regarding this change? I plan to
> merge it next week if nobody complains.
> 

(Henning is on vacation) What I heard from our folks who could test this
extensively is that they are unfortunately busy right now. So, if you
want to merge, you should probably not wait for this feedback.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai-git] Philippe Gerum : cobalt/x86: use symbolic trap names

[git repository hosting]

Module: xenomai-3
Branch: stable-3.0.x
Commit: 3c0e29d83c94b4cd330f1be9938b1813eda1b6ef
URL:
http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=3c0e29d83c94b4cd330f1be9938b1813eda1b6ef

Author: Philippe Gerum 
Date:   Thu Nov  9 14:42:12 2017 +0100

cobalt/x86: use symbolic trap names

---

 kernel/cobalt/arch/x86/include/asm/xenomai/thread.h |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index 2568621..f174a82 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
 typedef union thread_xstate x86_fpustate;
@@ -55,10 +56,10 @@ struct xnarchtcb {
 #define xnarch_fault_trap(d)   ((d)->exception)
 #define xnarch_fault_code(d)   ((d)->regs->orig_ax)
 #define xnarch_fault_pc(d) ((d)->regs->ip)
-#define xnarch_fault_fpu_p(d)  ((d)->exception == 7)
-#define xnarch_fault_pf_p(d)   ((d)->exception == 14)
+#define xnarch_fault_fpu_p(d)  ((d)->exception == X86_TRAP_NM)
+#define xnarch_fault_pf_p(d)   ((d)->exception == X86_TRAP_PF)
 #define xnarch_fault_bp_p(d)   ((current->ptrace & PT_PTRACED) &&  \
-((d)->exception == 1 || (d)->exception == 3))
+((d)->exception == X86_TRAP_DB || 
(d)->exception == X86_TRAP_BP))
 #define xnarch_fault_notify(d) (!xnarch_fault_bp_p(d))
 
 void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to);


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai-git

Re: [Xenomai] [PATCH v2 2/3] RTDM: uapi: Define ioctl code to set an IRQ affinity.

[Christoph Müllner]

> On 9 Nov 2017, at 11:04, Philippe Gerum <r...@xenomai.org> wrote:
> 
> On 11/06/2017 10:46 AM, Christoph Muellner wrote:
>> This patch adds an ioctl code to set a GPIO IRQ's CPU affinity
>> to the RTDM user space API.
>> 
>> Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>
>> ---
>> include/rtdm/uapi/gpio.h | 6 ++
>> 1 file changed, 6 insertions(+)
>> 
>> diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
>> index f846f48b2..e70da2621 100644
>> --- a/include/rtdm/uapi/gpio.h
>> +++ b/include/rtdm/uapi/gpio.h
>> @@ -18,10 +18,16 @@
>> #ifndef _RTDM_UAPI_GPIO_H
>> #define _RTDM_UAPI_GPIO_H
>> 
>> +typedef struct {
>> +void* mask;
> 
> Asking explicitly for unsigned long * may give a better hint about what
> is expected.

I agree, but then we need a cast when using cpu_set_t in user space, which is 
even more ugly.

This is user code, which works atm:

cpu_set_t mask;
CPU_ZERO();
CPU_SET(4, ); //CPU 4 only
rtdm_cpumask_t rtdm_mask;
rtdm_mask.mask =  //assignment of mask
rtdm_mask.size = sizeof(mask);

When making mask a unsigned long*, then the assignment of mask does not work 
anymore
without having the compiler complaining about incompatible types.
The reason is, that libc uses the following type hierarchy for cpu_set_t 
(bits/sched.h):

typedef unsigned long int __cpu_mask;
typedef struct
{
  __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
} cpu_set_t;

So besides casting, only something like this would work:

...
rtdm_mask.mask = __bits;
...

Making mask a cpu_set_t* is problematic, because this type is only available in
user space and not in kernel.

So I saw two choices: making a wrapper function rtdm_gpio_setirqaff(int fd, 
cpu_set_t ),
which hides the cast or use void* for the mask. The wrapper function would hide 
the cpu_set_t
from the kernel by using #ifndef __KERNEL__ around it.

Do you prefer the wrapper function?

Thanks,
Christoph


> 
>> +size_t size;
>> +} rtdm_cpumask_t;
>> +
>> #define GPIO_RTIOC_DIR_OUT   _IOW(RTDM_CLASS_GPIO, 0, int)
>> #define GPIO_RTIOC_DIR_IN_IO(RTDM_CLASS_GPIO, 1)
>> #define GPIO_RTIOC_IRQEN _IOW(RTDM_CLASS_GPIO, 2, int) /* GPIO 
>> trigger */
>> #define GPIO_RTIOC_IRQDIS_IO(RTDM_CLASS_GPIO, 3)
>> +#define GPIO_RTIOC_IRQAFF   _IOW(RTDM_CLASS_GPIO, 4, 
>> rtdm_cpumask_t*)
>> 
>> #define GPIO_TRIGGER_NONE0x0 /* unspecified */
>> #define GPIO_TRIGGER_EDGE_RISING 0x1
>> 
> 
> 
> --
> Philippe.

------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20171109/3674f3e9/attachment.sig>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH v2 2/3] RTDM: uapi: Define ioctl code to set an IRQ affinity.

[Philippe Gerum]

On 11/06/2017 10:46 AM, Christoph Muellner wrote:
> This patch adds an ioctl code to set a GPIO IRQ's CPU affinity
> to the RTDM user space API.
> 
> Signed-off-by: Christoph Muellner 
> ---
>  include/rtdm/uapi/gpio.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
> index f846f48b2..e70da2621 100644
> --- a/include/rtdm/uapi/gpio.h
> +++ b/include/rtdm/uapi/gpio.h
> @@ -18,10 +18,16 @@
>  #ifndef _RTDM_UAPI_GPIO_H
>  #define _RTDM_UAPI_GPIO_H
>  
> +typedef struct {
> + void* mask;

Asking explicitly for unsigned long * may give a better hint about what
is expected.

> + size_t size;
> +} rtdm_cpumask_t;
> +
>  #define GPIO_RTIOC_DIR_OUT   _IOW(RTDM_CLASS_GPIO, 0, int)
>  #define GPIO_RTIOC_DIR_IN_IO(RTDM_CLASS_GPIO, 1)
>  #define GPIO_RTIOC_IRQEN _IOW(RTDM_CLASS_GPIO, 2, int) /* GPIO 
> trigger */
>  #define GPIO_RTIOC_IRQDIS_IO(RTDM_CLASS_GPIO, 3)
> +#define GPIO_RTIOC_IRQAFF_IOW(RTDM_CLASS_GPIO, 4, 
> rtdm_cpumask_t*)
>  
>  #define GPIO_TRIGGER_NONE0x0 /* unspecified */
>  #define GPIO_TRIGGER_EDGE_RISING 0x1
> 


-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH v2 1/3] cobalt: rtdm: Add function rtdm_irq_affinity().

[Philippe Gerum]

On 11/06/2017 10:46 AM, Christoph Muellner wrote:
> This patch adds a RTDM API to set a IRQ's CPU affinity.
> 
> Signed-off-by: Christoph Muellner 
> ---
>  include/cobalt/kernel/rtdm/driver.h |  6 ++
>  kernel/cobalt/rtdm/drvlib.c | 18 ++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/include/cobalt/kernel/rtdm/driver.h 
> b/include/cobalt/kernel/rtdm/driver.h
> index 0c7b62e75..803cdbfe4 100644
> --- a/include/cobalt/kernel/rtdm/driver.h
> +++ b/include/cobalt/kernel/rtdm/driver.h
> @@ -874,6 +874,12 @@ static inline int rtdm_irq_disable(rtdm_irq_t 
> *irq_handle)
>   xnintr_disable(irq_handle);
>   return 0;
>  }
> +
> +static inline int rtdm_irq_affinity(rtdm_irq_t *irq_handle, cpumask_t tgt)
> +{
> + xnintr_affinity(irq_handle, tgt);
> + return 0;
> +}

At the end of the day, we should be passing cpumasks by address only.

So, in order to preserve this new routine from future change regarding
the cpumask argument once ipipe_set_irq_affinity() (or its successor) is
fixed, what about receiving a pointer to cpumask_t instead, fixing the
signature of xnintr_affinity() along the way too? The latter belongs to
the internal Cobalt API, we have no backward compatibility issue there.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe + preempt_rt : spinlock issue

[Cédric Perles]

Hi Philippe,

Thank's for your answere.
Replacing spin lock calls by equivalent raw spin lock in gpio_generic did 
the trick.

Thank's a lot.

Cédric


-Message d'origine-
De : Philippe Gerum [mailto:r...@xenomai.org]
Envoyé : mercredi 1 novembre 2017 21:57
À : Cédric Perles; xenomai@xenomai.org
Objet : Re: [Xenomai] ipipe + preempt_rt : spinlock issue

On 10/31/2017 12:03 PM, Cédric Perles wrote:
> Hi,
>
>
>
> I’m working on an iMX6 based board with NXP kernel 4.1.15.
>
> I made a Xenomai 3.0.5/ipipe bsp that works well and I also made a
> preempt-rt bsp that works well too.
>
>
>
> However, now I would like to make a Xenomai/ipipe + preempt_rt bsp.
>
>
>
> I adapted preempt_rt patch to fit to ipipe patched kernel but during
> compilation I’m facing issues concerning spinlocks:
>
>
>
> drivers/gpio/gpio-generic.c:496:2: note: in expansion of macro
> 'spin_lock_init'
>
>   spin_lock_init(>lock);
>
>   ^
>
> include/linux/spinlock_rt.h:17:24: error: '__ipipe_spinlock_t {aka
> struct }' has no member named 'lock'
>
>   rt_mutex_init(&(slock)->lock);   \
>
>

gpio-generic should use raw spinlock accessors (e.g. spin_lock_init -> 
raw_spin_lock_init()).

>
>
>
> Searching some help on internet, I realized that only a few people
> tried to use both Xenomai and Preempt-rt.
>
> => Is it an heresy ? if so, Why ?
>

Not particularly.

> I thought it was the best way to limit preemption for the tasks that
> switched temporarily to secondary mode.
>
>

That may not be the best reason to use such combo, i.e. if this is about 
papering over issues caused by dual kernel's rt threads escaping the proper 
runtime mode. Those threads should not do that in the first place.

A legitimate reason to use such combo is rather to have different classes of 
rt requirements in a single application, which are best served by combined 
approaches.

>
> => If it is not a stupid idea, did somebody already resolve this kind
> of conflict ?

Yes, this may seem daunting at first, but there are usually only a few of 
them, almost only in include/spinlock*. Conflicts in sched/core may be a bit 
trickier to address though, but they don't appear frequently.

> and how ?
>
>
Well, just as you are doing: making sense of the changes, and figuring out 
how to fix the few conflicts.

--
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Won`t build on new Debian Stable

[Philippe Gerum]

On 10/19/2017 06:55 PM, Henning Schild wrote:
> On Thu, 19 Oct 2017 12:03:33 +0200
> Philippe Gerum  wrote:
> 
>> On 10/13/2017 01:36 PM, Norbert Lange wrote:
>>> I works, because collect2 (the "compiler driver", which documents
>>> the -r option) now knows about the -r flag, using -Wl,-[U]r would
>>> mean the flags aren't even looked at.
>>> It can then disable functionality that is not supposed to be done at
>>> this point (see gcc/collect2.c, search for 'early_exit'). It might
>>> actually be in conflict with the -Ur option from the comments, but I
>>> don't know what this is trying to solve (the constructor tables
>>> would then be built in the second step?)
>>>
>>> I would prefer the compiler driver knowing about the flags and
>>> correctly dealing with them, instead of replicating this logic in
>>> scripts (and keeping it up to date with this internal logic).  
>>
>> Ack.
>>
>>> Might be that your wrapper script is doing something similarly by
>>> filtering out the arguments for the first step, which might be the
>>> same functionally that is skipped when adding '-r'
>>>
>>> I dont know what the -Ur flag is trying to solve, and the first
>>> patch adding -no-pie is way less likely to change something (given
>>> that I would not have compiled with -pie before).
>>> The new patch would however leave more of the magic to the toolchain
>>> and seems more "correct" to me, for whatever that's worth. But it
>>> might have some subtle differences to before, got some testcase
>>> where lacking the -Ur flag made a difference?  
>>
>> I don't know the original intent about passing -Ur to the linker,
>> except maybe to stick to the ld manpage which states that the last
>> partial link command should be given such option.
>>
>> However my understanding is that we don't need it in wrap-link.sh,
>> since the script eventually completes the link stage to produce a
>> fully resolved executable. That implies collecting the ctors/dtors and
>> resolving all references from the partially linked object file anyway.
>>
>> Some testing only passing -r here seems to confirm this assumption
>> with C++ apps; C++ users may want to check this too:
> 
> I just told some C++ power users to give that a try. I am not sure how
> fast the feedback will arrive, i hope in the next two weeks.
> 
> Henning
> 
>>
>> diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
>> index aab7899..fa83bd5 100755
>> --- a/scripts/wrap-link.sh
>> +++ b/scripts/wrap-link.sh
>> @@ -204,7 +204,7 @@ done
>>
>>  if $stage2; then
>>  $verbose && set -x
>> -$dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
>> +$dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
>>  $dryrun $cc -o "$output" "$output.tmp" $stage2_args
>>  $dryrun rm -f $output.tmp
>>  else
>>

Any news from the Xenomai/C++ folks regarding this change? I plan to
merge it next week if nobody complains.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai cannot be built in Debian Stretch

[Leopold Palomo-Avellaneda]

On 08/11/17 16:12, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> 
> I'm trying to build Xenomai 3.0.5 in a Debian Stretch/Buster Amd64 env.
> I'm getting this error:
> 
> /usr/bin/ld: -r and -pie may not be used together
> 
> 
> It's because the default -pie in gcc. I have tried to investigate, but I
> have not found the "-r". probably because the wrap-link script.
> 
> Please, could you give me some idea how to solve it?

I'm answer myself. It seems that yesterday I was obfuscated. Just

export CFLAGS="$CFLAGS -no-pie"

solved the problem.

Best regards,

Leopold

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai