On 12/19/2017 07:57 PM, Jan Kiszka wrote:
> On 2017-12-19 14:44, Lange Norbert wrote:
>>
>> Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at
>> boot (likely no good support for this SOC).
>> Used program is attached, it is being executed twice, once directly via
>> serial
On 12/20/2017 06:49 PM, Lange Norbert wrote:
> >-Original Message-
> >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
> >Sent: Dienstag, 19. Dezember 2017 19:57
> >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Philippe Gerum
> >Subject: Re: Weird behavior during debug
> >
>
>-Original Message-
>From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>Sent: Dienstag, 19. Dezember 2017 19:57
>To: Lange Norbert; Xenomai (xenomai@xenomai.org); Philippe Gerum
>Subject: Re: Weird behavior during debug
>
>EMAIL from a NON-ANDRITZ SOURCE: as a security measure,
On 2017-12-19 14:44, Lange Norbert wrote:
>
> Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at boot
> (likely no good support for this SOC).
> Used program is attached, it is being executed twice, once directly via
> serial or ssh, once via gdbserver or gdb (tested
Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at boot
(likely no good support for this SOC).
Used program is attached, it is being executed twice, once directly via serial
or ssh, once via gdbserver or gdb (tested various combinations).
The directly executed program
On 2017-12-19 09:56, Lange Norbert wrote:
> Hello Jan,
>
> My follow-up post was done after running the latest ipipe-4.9.y patch, with
> your fix added on top.
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 834e6117f5f8..b9f6121c8530 100644
> --- a/arch/x86/Kconfig
> +++
On 2017-12-18 15:49, Lange Norbert wrote:
> Same issue with latest ipipe. Threads look like this (when the instance is
> halted in the debugger).
> Somehow, atleast the RT Tasks will block waiting on a timerfd when one task
> is in state XT (whatever that means)
>
> # cat
Same issue with latest ipipe. Threads look like this (when the instance is
halted in the debugger).
Somehow, atleast the RT Tasks will block waiting on a timerfd when one task is
in state XT (whatever that means)
# cat /proc/xenomai/sched/threads
CPU PIDCLASS TYPE PRI TIMEOUT
Hello,
I tried debugging a cobalt application, and when I hit a breakpoint most of the
system freezes.
If I run for example top over Serial or SSH, then the display won`t be
refreshed anymore,
A separate program running as RT Task, waiting for an timer-event (occurring 10
times a second) will
