On 11.07.19 22:48, Richard Weinberger wrote:
> On Thu, Jul 11, 2019 at 8:30 PM Jan Kiszka wrote:
>>
>> On 11.07.19 12:25, Richard Weinberger wrote:
>>> On Thu, Jul 11, 2019 at 12:21 PM Jan Kiszka wrote:
Can't reproduce so far, even with a while-true loop. Can you share your
.config?
On Thu, Jul 11, 2019 at 8:30 PM Jan Kiszka wrote:
>
> On 11.07.19 12:25, Richard Weinberger wrote:
> > On Thu, Jul 11, 2019 at 12:21 PM Jan Kiszka wrote:
> >> Can't reproduce so far, even with a while-true loop. Can you share your
> >> .config?
> >
> > Sure, see attachment.
> >
>
> This seems
From: Jan Kiszka
Likely needed since c942cee46bba which split enabling and startup.
This fixes unpopulated vectors in the IOAPIC on x86 at least, possibly
more.
Signed-off-by: Jan Kiszka
---
kernel/irq/chip.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/irq/chip.c
From: Jan Kiszka
x86 may generate one, so change the signature.
Signed-off-by: Jan Kiszka
---
include/linux/ipipe.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/ipipe.h b/include/linux/ipipe.h
index f7c07a207093..45e8c87bff93 100644
---
This included the patches from v1, the addition (patch 3), and the new
patches needed to add return codes and irq enabling to some services.
Jan
Jan Kiszka (6):
ipipe: Restore trace_hardirqs_on_virt_caller
ipipe: lockdep: Remove duplicate context checks
ipipe: Add missing include for
From: Jan Kiszka
Breaks in non-debug builds otherwise, e.g.
https://travis-ci.com/xenomai-ci/xenomai/jobs/212725223
Signed-off-by: Jan Kiszka
---
include/linux/kernel.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index
From: Jan Kiszka
It's time to let ipipe_enable_irq return a proper error as it will gain
another function that may fail. Drop the WARN_ON_ONCE in favor of that.
Signed-off-by: Jan Kiszka
---
include/linux/ipipe.h | 2 +-
kernel/irq/chip.c | 12 +++-
2 files changed, 8
On 11.07.19 18:48, Philippe Gerum wrote:
> On 7/11/19 6:34 PM, Jan Kiszka wrote:
>> On 11.07.19 18:00, Philippe Gerum wrote:
>>> On 7/11/19 5:09 PM, Jan Kiszka wrote:
On 11.07.19 16:40, Philippe Gerum wrote:
> On 7/5/19 9:38 AM, Jan Kiszka wrote:
>
>> This addresses it on x86 for
On 11.07.19 20:30, Jan Kiszka wrote:
> On 11.07.19 12:25, Richard Weinberger wrote:
>> On Thu, Jul 11, 2019 at 12:21 PM Jan Kiszka wrote:
>>> Can't reproduce so far, even with a while-true loop. Can you share your
>>> .config?
>>
>> Sure, see attachment.
>>
>
> This seems to fix the issue here:
On 11.07.19 12:25, Richard Weinberger wrote:
> On Thu, Jul 11, 2019 at 12:21 PM Jan Kiszka wrote:
>> Can't reproduce so far, even with a while-true loop. Can you share your
>> .config?
>
> Sure, see attachment.
>
This seems to fix the issue here:
diff --git a/arch/x86/entry/entry_64.S
On 7/11/19 6:34 PM, Jan Kiszka wrote:
> On 11.07.19 18:00, Philippe Gerum wrote:
>> On 7/11/19 5:09 PM, Jan Kiszka wrote:
>>> On 11.07.19 16:40, Philippe Gerum wrote:
On 7/5/19 9:38 AM, Jan Kiszka wrote:
> This addresses it on x86 for me:
>
> diff --git a/kernel/irq/chip.c
On 7/11/19 5:09 PM, Jan Kiszka wrote:
> On 11.07.19 16:40, Philippe Gerum wrote:
>> On 7/5/19 9:38 AM, Jan Kiszka wrote:
>>
>>> This addresses it on x86 for me:
>>>
>>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
>>> index 6c279e065879..d503b875f086 100644
>>> --- a/kernel/irq/chip.c
>>>
On 7/11/19 5:34 PM, Richard Weinberger wrote:
> Philippe,
>
> On Thu, Jul 11, 2019 at 4:30 PM Philippe Gerum wrote:
>>> If I have a mutex m1 and a misbehaving RT_TASK rt1 which exits right after
>>> acquiring mutex m1, what is the recommended way to get the lock back into a
>>> well defined
Philippe,
On Thu, Jul 11, 2019 at 4:30 PM Philippe Gerum wrote:
> > If I have a mutex m1 and a misbehaving RT_TASK rt1 which exits right after
> > acquiring mutex m1, what is the recommended way to get the lock back into a
> > well defined state?
> >
>
> Unfortunately, I see no option other than
On 11.07.19 16:40, Philippe Gerum wrote:
> On 7/5/19 9:38 AM, Jan Kiszka wrote:
>
>> This addresses it on x86 for me:
>>
>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
>> index 6c279e065879..d503b875f086 100644
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -1099,7 +1099,8 @@
On 7/5/19 9:38 AM, Jan Kiszka wrote:
> This addresses it on x86 for me:
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 6c279e065879..d503b875f086 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -1099,7 +1099,8 @@ void ipipe_enable_irq(unsigned int irq)
>
On 7/11/19 10:15 AM, Richard Weinberger via Xenomai wrote:
> Hi!
>
> doc/asciidoc/MIGRATION.adoc states:
> - For consistency with the standard glibc implementation, deleting a
> RT_MUTEX object in locked state is no longer a valid operation.
>
> I'm not sure how this affects my Xenomai 2
On 7/10/19 11:20 AM, Lange Norbert wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Mittwoch, 10. Juli 2019 08:13
>> To: Lange Norbert ; Xenomai
>> (xenomai@xenomai.org) ; Philippe Gerum
>>
>> Subject: Re: Best way to detect if a filedescriptor is a cobalt
>>
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 10. Juli 2019 23:31
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
>
> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
tion/x-config
Size: 121667 bytes
Desc: not available
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20190711/0d3c0780/attachment.bin>
On 11.07.19 00:29, Richard Weinberger via Xenomai wrote:
> Hi!
>
> I can reliable kill Linux on qemu by writing a few times 1 and 0 to
> /sys/kernel/debug/tracing/events/cobalt_core/enable
>
> Didn't test on real hardware so far.
> The following splat happened on ipipe-core-4.19.57-x86-3 plus
>
On 7/10/19 11:46 PM, Richard Weinberger via Xenomai wrote:
> Since cobalt adds 0xfccf to si_value we can no longer
> use the raw value.
>
> Signed-off-by: Richard Weinberger
> ---
> demo/alchemy/altency.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi!
doc/asciidoc/MIGRATION.adoc states:
- For consistency with the standard glibc implementation, deleting a
RT_MUTEX object in locked state is no longer a valid operation.
I'm not sure how this affects my Xenomai 2 application which is being
ported to Xenomai 3.
If I have a mutex m1 and a
23 matches
Mail list logo
