* [Xenomai] Weird behavior during debug
@ 2017-12-18 13:43 Lange Norbert
0 siblings, 0 replies; 10+ messages in thread
From: Lange Norbert @ 2017-12-18 13:43 UTC (permalink / raw)
To: Xenomai (xenomai@xenomai.org)
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 block aswell.
So the debug session seems to block a rather big amount of events.
I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled faults over the head domain".
Looking at the logs and other threads there seems to be a bigger rework in progress?
I will retry with master, and report back.
Kind regards
Norbert Lange
________________________________
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 18:57 ` Jan Kiszka
2017-12-20 17:49 ` Lange Norbert
@ 2017-12-20 18:15 ` Philippe Gerum
1 sibling, 0 replies; 10+ messages in thread
From: Philippe Gerum @ 2017-12-20 18:15 UTC (permalink / raw)
To: Jan Kiszka, Lange Norbert, Xenomai (xenomai@xenomai.org)
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 or ssh, once via gdbserver or gdb (tested various combinations).
>>
>> The directly executed program will stop (supposedly at read), as soon as the debugged program is halted.
>
> OK, now I get the point: You need
> http://git.xenomai.org/xenomai-3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
> but that is only in next so far.
>
> What happens in stable (and also in older versions) is that all Xenomai
> timers in the system are stopped once one Xenomai application enters a
> ptrace state. That is going to vanish in the next version, and we may
> consider taking it to stable as well. What do you think, Philippe?
>
I did not see any regression on the next branch so far with this patch
in, so functionally speaking, there should be no issue in backporting
this code.
However this would break the build for out of tree drivers which depend
on XNTIMER_NOBLCK. A possible work-around would be to add a null
placeholder for XNTIMER_NOBLCK to the backport, along with that patch.
--
Philippe.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-20 17:49 ` Lange Norbert
@ 2017-12-20 18:07 ` Philippe Gerum
0 siblings, 0 replies; 10+ messages in thread
From: Philippe Gerum @ 2017-12-20 18:07 UTC (permalink / raw)
To: Lange Norbert, Jan Kiszka, Xenomai (xenomai@xenomai.org)
On 12/20/2017 06:49 PM, Lange Norbert wrote:
> >-----Original Message-----
> >From: Jan Kiszka [mailto:jan.kiszka@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, please exercise
> >caution with email content and any links or attachments.
> >
> >
> >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 various combinations).
> >>
> >> The directly executed program will stop (supposedly at read), as soon as the
> >debugged program is halted.
> >
> >OK, now I get the point: You need
> >http://git.xenomai.org/xenomai-
> >3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
> >but that is only in next so far.
>
> I applies cleanly on the wip/rtnet branch, so I did test it and indeed it fixes the issue.
>
> >
> >What happens in stable (and also in older versions) is that all Xenomai
> >timers in the system are stopped once one Xenomai application enters a
> >ptrace state. That is going to vanish in the next version, and we may
> >consider taking it to stable as well. What do you think, Philippe?
>
> I don't know the direction where you want to go with the cobalt functionality,
> this change is IMHO badly needed as digging into one process should never affect others.
> However, there still is a difference to Linux behavior, namely that a periodic timerfd will read the
> count of expired events after continuing. The cobalt implementation will just forget about them.
>
> I suppose this hackaround is necessary so one-shot events aren`t dropped?
>
> /* Hide overruns due to the most recent ptracing session. */
> if (xnthread_test_localinfo(waiter, XNHICCUP))
> return 0;
>
This is the core of the fix: force a zero overrun count when queried for
a thread which has just left the ptraced state. This means ignoring all
missed wakeup events that may have occurred while such thread was
stopped by the debugger, and therefore unable to wait for them.
--
Philippe.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 18:57 ` Jan Kiszka
@ 2017-12-20 17:49 ` Lange Norbert
2017-12-20 18:07 ` Philippe Gerum
2017-12-20 18:15 ` Philippe Gerum
1 sibling, 1 reply; 10+ messages in thread
From: Lange Norbert @ 2017-12-20 17:49 UTC (permalink / raw)
To: Jan Kiszka, Xenomai (xenomai@xenomai.org), Philippe Gerum
>-----Original Message-----
>From: Jan Kiszka [mailto:jan.kiszka@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, please exercise
>caution with email content and any links or attachments.
>
>
>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 various combinations).
>>
>> The directly executed program will stop (supposedly at read), as soon as the
>debugged program is halted.
>
>OK, now I get the point: You need
>http://git.xenomai.org/xenomai-
>3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
>but that is only in next so far.
I applies cleanly on the wip/rtnet branch, so I did test it and indeed it fixes the issue.
>
>What happens in stable (and also in older versions) is that all Xenomai
>timers in the system are stopped once one Xenomai application enters a
>ptrace state. That is going to vanish in the next version, and we may
>consider taking it to stable as well. What do you think, Philippe?
I don't know the direction where you want to go with the cobalt functionality,
this change is IMHO badly needed as digging into one process should never affect others.
However, there still is a difference to Linux behavior, namely that a periodic timerfd will read the
count of expired events after continuing. The cobalt implementation will just forget about them.
I suppose this hackaround is necessary so one-shot events aren`t dropped?
/* Hide overruns due to the most recent ptracing session. */
if (xnthread_test_localinfo(waiter, XNHICCUP))
return 0;
Norbert
>Jan
________________________________
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 13:44 ` Lange Norbert
@ 2017-12-19 18:57 ` Jan Kiszka
2017-12-20 17:49 ` Lange Norbert
2017-12-20 18:15 ` Philippe Gerum
0 siblings, 2 replies; 10+ messages in thread
From: Jan Kiszka @ 2017-12-19 18:57 UTC (permalink / raw)
To: Lange Norbert, Xenomai (xenomai@xenomai.org), Philippe Gerum
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 various combinations).
>
> The directly executed program will stop (supposedly at read), as soon as the debugged program is halted.
OK, now I get the point: You need
http://git.xenomai.org/xenomai-3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
but that is only in next so far.
What happens in stable (and also in older versions) is that all Xenomai
timers in the system are stopped once one Xenomai application enters a
ptrace state. That is going to vanish in the next version, and we may
consider taking it to stable as well. What do you think, Philippe?
Jan
>
> Norbert
>
> >-----Original Message-----
> >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
> >Sent: Dienstag, 19. Dezember 2017 10:35
> >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
> >Subject: Re: Weird behavior during debug
> >
> >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
> >caution with email content and any links or attachments.
> >
> >
> >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
> >> +++ b/arch/x86/Kconfig
> >> @@ -83,7 +83,7 @@ config X86
> >> select HAVE_AOUT if X86_32
> >> select HAVE_ARCH_AUDITSYSCALL
> >> select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
> >> - select HAVE_ARCH_JUMP_LABEL
> >> + select HAVE_ARCH_JUMP_LABEL if !IPIPE
> >> select HAVE_ARCH_KASAN if X86_64 &&
> >SPARSEMEM_VMEMMAP
> >> select HAVE_ARCH_KGDB
> >> select HAVE_ARCH_KMEMCHECK
> >>
> >
> >Does the problem persist with
> >- ipipe-core-4.9.51-x86-4
> >- ipipe-4.4
> >?
> >
> >Jan
> >
> >> Norbert
> >>
> >> >-----Original Message-----
> >> >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
> >> >Sent: Dienstag, 19. Dezember 2017 08:16
> >> >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
> >> >Subject: Re: Weird behavior during debug
> >> >
> >> >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please
> >exercise
> >> >caution with email content and any links or attachments.
> >> >
> >> >
> >> >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 /proc/xenomai/sched/threads
> >> >> CPU PID CLASS TYPE PRI TIMEOUT STAT NAME
> >> >> 0 0 idle core -1 - R [ROOT/0]
> >> >> 1 0 idle core -1 - R [ROOT/1]
> >> >> 2 0 idle core -1 - R [ROOT/2]
> >> >> 3 0 idle core -1 - R [ROOT/3]
> >> >> 2 264 rt cobalt 20 - XT packetfilter
> >> >> 1 279 rt cobalt 20 - W packetfilter
> >> >>
> >> >
> >> >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
> >> >Please retry either with the latest version or the last release
> >> >(ipipe-core-4.9.51-x86-4).
> >> >
> >> >Jan
> >> >
> >> >> >-----Original Message-----
> >> >> >From: Lange Norbert
> >> >> >Sent: Montag, 18. Dezember 2017 14:43
> >> >> >To: Xenomai (xenomai@xenomai.org)
> >> >> >Subject: Weird behavior during debug
> >> >> >
> >> >> >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 block aswell.
> >> >> >
> >> >> >So the debug session seems to block a rather big amount of events.
> >> >> >
> >> >> >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of
> >unhandled
> >> >> >faults over the head domain".
> >> >> >Looking at the logs and other threads there seems to be a bigger rework
> >in
> >> >> >progress?
> >> >> >I will retry with master, and report back.
> >> >> >
> >> >> >Kind regards
> >> >> >
> >> >> >Norbert Lange
> >> >>
> >> >> ________________________________
> >> >>
> >> >> This message and any attachments are solely for the use of the intended
> >> >recipients. They may contain privileged and/or confidential information or
> >> >other information protected from disclosure. If you are not an intended
> >> >recipient, you are hereby notified that you received this email in error and
> >that
> >> >any review, dissemination, distribution or copying of this email and any
> >> >attachment is strictly prohibited. If you have received this email in error,
> >please
> >> >contact the sender and delete the message and any attachment from your
> >> >system.
> >> >>
> >> >> ANDRITZ HYDRO GmbH
> >> >>
> >> >>
> >> >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung /
> >Corporation
> >> >>
> >> >> Firmensitz/ Registered seat: Wien
> >> >>
> >> >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
> >> >>
> >> >> Firmenbuchnummer/ Company registration: FN 61833 g
> >> >>
> >> >> DVR: 0605077
> >> >>
> >> >> UID-Nr.: ATU14756806
> >> >>
> >> >>
> >> >> Thank You
> >> >> ________________________________
> >> >>
> >> >> _______________________________________________
> >> >> Xenomai mailing list
> >> >> Xenomai@xenomai.org
> >> >> https://xenomai.org/mailman/listinfo/xenomai
> >> >>
> >> >
> >> >--
> >> >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> >> >Corporate Competence Center Embedded Linux
> >> ________________________________
> >>
> >> This message and any attachments are solely for the use of the intended
> >recipients. They may contain privileged and/or confidential information or
> >other information protected from disclosure. If you are not an intended
> >recipient, you are hereby notified that you received this email in error and that
> >any review, dissemination, distribution or copying of this email and any
> >attachment is strictly prohibited. If you have received this email in error, please
> >contact the sender and delete the message and any attachment from your
> >system.
> >>
> >> ANDRITZ HYDRO GmbH
> >>
> >>
> >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
> >>
> >> Firmensitz/ Registered seat: Wien
> >>
> >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
> >>
> >> Firmenbuchnummer/ Company registration: FN 61833 g
> >>
> >> DVR: 0605077
> >>
> >> UID-Nr.: ATU14756806
> >>
> >>
> >> Thank You
> >> ________________________________
> >>
> >
> >
> >--
> >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> >Corporate Competence Center Embedded Linux
> ________________________________
>
> This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
>
> ANDRITZ HYDRO GmbH
>
>
> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>
> Firmensitz/ Registered seat: Wien
>
> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>
> Firmenbuchnummer/ Company registration: FN 61833 g
>
> DVR: 0605077
>
> UID-Nr.: ATU14756806
>
>
> Thank You
> ________________________________
>
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 9:34 ` Jan Kiszka
@ 2017-12-19 13:44 ` Lange Norbert
2017-12-19 18:57 ` Jan Kiszka
0 siblings, 1 reply; 10+ messages in thread
From: Lange Norbert @ 2017-12-19 13:44 UTC (permalink / raw)
To: Jan Kiszka, Xenomai (xenomai@xenomai.org)
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 will stop (supposedly at read), as soon as the debugged program is halted.
Norbert
>-----Original Message-----
>From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
>Sent: Dienstag, 19. Dezember 2017 10:35
>To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>Subject: Re: Weird behavior during debug
>
>EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
>caution with email content and any links or attachments.
>
>
>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
>> +++ b/arch/x86/Kconfig
>> @@ -83,7 +83,7 @@ config X86
>> select HAVE_AOUT if X86_32
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
>> - select HAVE_ARCH_JUMP_LABEL
>> + select HAVE_ARCH_JUMP_LABEL if !IPIPE
>> select HAVE_ARCH_KASAN if X86_64 &&
>SPARSEMEM_VMEMMAP
>> select HAVE_ARCH_KGDB
>> select HAVE_ARCH_KMEMCHECK
>>
>
>Does the problem persist with
>- ipipe-core-4.9.51-x86-4
>- ipipe-4.4
>?
>
>Jan
>
>> Norbert
>>
>> >-----Original Message-----
>> >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
>> >Sent: Dienstag, 19. Dezember 2017 08:16
>> >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>> >Subject: Re: Weird behavior during debug
>> >
>> >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please
>exercise
>> >caution with email content and any links or attachments.
>> >
>> >
>> >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 /proc/xenomai/sched/threads
>> >> CPU PID CLASS TYPE PRI TIMEOUT STAT NAME
>> >> 0 0 idle core -1 - R [ROOT/0]
>> >> 1 0 idle core -1 - R [ROOT/1]
>> >> 2 0 idle core -1 - R [ROOT/2]
>> >> 3 0 idle core -1 - R [ROOT/3]
>> >> 2 264 rt cobalt 20 - XT packetfilter
>> >> 1 279 rt cobalt 20 - W packetfilter
>> >>
>> >
>> >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
>> >Please retry either with the latest version or the last release
>> >(ipipe-core-4.9.51-x86-4).
>> >
>> >Jan
>> >
>> >> >-----Original Message-----
>> >> >From: Lange Norbert
>> >> >Sent: Montag, 18. Dezember 2017 14:43
>> >> >To: Xenomai (xenomai@xenomai.org)
>> >> >Subject: Weird behavior during debug
>> >> >
>> >> >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 block aswell.
>> >> >
>> >> >So the debug session seems to block a rather big amount of events.
>> >> >
>> >> >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of
>unhandled
>> >> >faults over the head domain".
>> >> >Looking at the logs and other threads there seems to be a bigger rework
>in
>> >> >progress?
>> >> >I will retry with master, and report back.
>> >> >
>> >> >Kind regards
>> >> >
>> >> >Norbert Lange
>> >>
>> >> ________________________________
>> >>
>> >> This message and any attachments are solely for the use of the intended
>> >recipients. They may contain privileged and/or confidential information or
>> >other information protected from disclosure. If you are not an intended
>> >recipient, you are hereby notified that you received this email in error and
>that
>> >any review, dissemination, distribution or copying of this email and any
>> >attachment is strictly prohibited. If you have received this email in error,
>please
>> >contact the sender and delete the message and any attachment from your
>> >system.
>> >>
>> >> ANDRITZ HYDRO GmbH
>> >>
>> >>
>> >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung /
>Corporation
>> >>
>> >> Firmensitz/ Registered seat: Wien
>> >>
>> >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>> >>
>> >> Firmenbuchnummer/ Company registration: FN 61833 g
>> >>
>> >> DVR: 0605077
>> >>
>> >> UID-Nr.: ATU14756806
>> >>
>> >>
>> >> Thank You
>> >> ________________________________
>> >>
>> >> _______________________________________________
>> >> Xenomai mailing list
>> >> Xenomai@xenomai.org
>> >> https://xenomai.org/mailman/listinfo/xenomai
>> >>
>> >
>> >--
>> >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
>> >Corporate Competence Center Embedded Linux
>> ________________________________
>>
>> This message and any attachments are solely for the use of the intended
>recipients. They may contain privileged and/or confidential information or
>other information protected from disclosure. If you are not an intended
>recipient, you are hereby notified that you received this email in error and that
>any review, dissemination, distribution or copying of this email and any
>attachment is strictly prohibited. If you have received this email in error, please
>contact the sender and delete the message and any attachment from your
>system.
>>
>> ANDRITZ HYDRO GmbH
>>
>>
>> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>>
>> Firmensitz/ Registered seat: Wien
>>
>> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>>
>> Firmenbuchnummer/ Company registration: FN 61833 g
>>
>> DVR: 0605077
>>
>> UID-Nr.: ATU14756806
>>
>>
>> Thank You
>> ________________________________
>>
>
>
>--
>Siemens AG, Corporate Technology, CT RDA ITP SES-DE
>Corporate Competence Center Embedded Linux
________________________________
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: timerfd.c
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171219/ec797aab/attachment.c>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 8:56 ` Lange Norbert
@ 2017-12-19 9:34 ` Jan Kiszka
2017-12-19 13:44 ` Lange Norbert
0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2017-12-19 9:34 UTC (permalink / raw)
To: Lange Norbert, Xenomai (xenomai@xenomai.org)
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
> +++ b/arch/x86/Kconfig
> @@ -83,7 +83,7 @@ config X86
> select HAVE_AOUT if X86_32
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
> - select HAVE_ARCH_JUMP_LABEL
> + select HAVE_ARCH_JUMP_LABEL if !IPIPE
> select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_KMEMCHECK
>
Does the problem persist with
- ipipe-core-4.9.51-x86-4
- ipipe-4.4
?
Jan
> Norbert
>
> >-----Original Message-----
> >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
> >Sent: Dienstag, 19. Dezember 2017 08:16
> >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
> >Subject: Re: Weird behavior during debug
> >
> >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
> >caution with email content and any links or attachments.
> >
> >
> >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 /proc/xenomai/sched/threads
> >> CPU PID CLASS TYPE PRI TIMEOUT STAT NAME
> >> 0 0 idle core -1 - R [ROOT/0]
> >> 1 0 idle core -1 - R [ROOT/1]
> >> 2 0 idle core -1 - R [ROOT/2]
> >> 3 0 idle core -1 - R [ROOT/3]
> >> 2 264 rt cobalt 20 - XT packetfilter
> >> 1 279 rt cobalt 20 - W packetfilter
> >>
> >
> >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
> >Please retry either with the latest version or the last release
> >(ipipe-core-4.9.51-x86-4).
> >
> >Jan
> >
> >> >-----Original Message-----
> >> >From: Lange Norbert
> >> >Sent: Montag, 18. Dezember 2017 14:43
> >> >To: Xenomai (xenomai@xenomai.org)
> >> >Subject: Weird behavior during debug
> >> >
> >> >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 block aswell.
> >> >
> >> >So the debug session seems to block a rather big amount of events.
> >> >
> >> >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled
> >> >faults over the head domain".
> >> >Looking at the logs and other threads there seems to be a bigger rework in
> >> >progress?
> >> >I will retry with master, and report back.
> >> >
> >> >Kind regards
> >> >
> >> >Norbert Lange
> >>
> >> ________________________________
> >>
> >> This message and any attachments are solely for the use of the intended
> >recipients. They may contain privileged and/or confidential information or
> >other information protected from disclosure. If you are not an intended
> >recipient, you are hereby notified that you received this email in error and that
> >any review, dissemination, distribution or copying of this email and any
> >attachment is strictly prohibited. If you have received this email in error, please
> >contact the sender and delete the message and any attachment from your
> >system.
> >>
> >> ANDRITZ HYDRO GmbH
> >>
> >>
> >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
> >>
> >> Firmensitz/ Registered seat: Wien
> >>
> >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
> >>
> >> Firmenbuchnummer/ Company registration: FN 61833 g
> >>
> >> DVR: 0605077
> >>
> >> UID-Nr.: ATU14756806
> >>
> >>
> >> Thank You
> >> ________________________________
> >>
> >> _______________________________________________
> >> Xenomai mailing list
> >> Xenomai@xenomai.org
> >> https://xenomai.org/mailman/listinfo/xenomai
> >>
> >
> >--
> >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> >Corporate Competence Center Embedded Linux
> ________________________________
>
> This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
>
> ANDRITZ HYDRO GmbH
>
>
> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>
> Firmensitz/ Registered seat: Wien
>
> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>
> Firmenbuchnummer/ Company registration: FN 61833 g
>
> DVR: 0605077
>
> UID-Nr.: ATU14756806
>
>
> Thank You
> ________________________________
>
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-19 7:16 ` Jan Kiszka
@ 2017-12-19 8:56 ` Lange Norbert
2017-12-19 9:34 ` Jan Kiszka
0 siblings, 1 reply; 10+ messages in thread
From: Lange Norbert @ 2017-12-19 8:56 UTC (permalink / raw)
To: Jan Kiszka, Xenomai (xenomai@xenomai.org)
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
+++ b/arch/x86/Kconfig
@@ -83,7 +83,7 @@ config X86
select HAVE_AOUT if X86_32
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
- select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_JUMP_LABEL if !IPIPE
select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK
Norbert
>-----Original Message-----
>From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
>Sent: Dienstag, 19. Dezember 2017 08:16
>To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>Subject: Re: Weird behavior during debug
>
>EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
>caution with email content and any links or attachments.
>
>
>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 /proc/xenomai/sched/threads
>> CPU PID CLASS TYPE PRI TIMEOUT STAT NAME
>> 0 0 idle core -1 - R [ROOT/0]
>> 1 0 idle core -1 - R [ROOT/1]
>> 2 0 idle core -1 - R [ROOT/2]
>> 3 0 idle core -1 - R [ROOT/3]
>> 2 264 rt cobalt 20 - XT packetfilter
>> 1 279 rt cobalt 20 - W packetfilter
>>
>
>Philippe reverted a number of commits in ipipe-4.9.y some days ago.
>Please retry either with the latest version or the last release
>(ipipe-core-4.9.51-x86-4).
>
>Jan
>
>> >-----Original Message-----
>> >From: Lange Norbert
>> >Sent: Montag, 18. Dezember 2017 14:43
>> >To: Xenomai (xenomai@xenomai.org)
>> >Subject: Weird behavior during debug
>> >
>> >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 block aswell.
>> >
>> >So the debug session seems to block a rather big amount of events.
>> >
>> >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled
>> >faults over the head domain".
>> >Looking at the logs and other threads there seems to be a bigger rework in
>> >progress?
>> >I will retry with master, and report back.
>> >
>> >Kind regards
>> >
>> >Norbert Lange
>>
>> ________________________________
>>
>> This message and any attachments are solely for the use of the intended
>recipients. They may contain privileged and/or confidential information or
>other information protected from disclosure. If you are not an intended
>recipient, you are hereby notified that you received this email in error and that
>any review, dissemination, distribution or copying of this email and any
>attachment is strictly prohibited. If you have received this email in error, please
>contact the sender and delete the message and any attachment from your
>system.
>>
>> ANDRITZ HYDRO GmbH
>>
>>
>> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>>
>> Firmensitz/ Registered seat: Wien
>>
>> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>>
>> Firmenbuchnummer/ Company registration: FN 61833 g
>>
>> DVR: 0605077
>>
>> UID-Nr.: ATU14756806
>>
>>
>> Thank You
>> ________________________________
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> https://xenomai.org/mailman/listinfo/xenomai
>>
>
>--
>Siemens AG, Corporate Technology, CT RDA ITP SES-DE
>Corporate Competence Center Embedded Linux
________________________________
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
2017-12-18 14:49 Lange Norbert
@ 2017-12-19 7:16 ` Jan Kiszka
2017-12-19 8:56 ` Lange Norbert
0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2017-12-19 7:16 UTC (permalink / raw)
To: Lange Norbert, Xenomai (xenomai@xenomai.org)
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 /proc/xenomai/sched/threads
> CPU PID CLASS TYPE PRI TIMEOUT STAT NAME
> 0 0 idle core -1 - R [ROOT/0]
> 1 0 idle core -1 - R [ROOT/1]
> 2 0 idle core -1 - R [ROOT/2]
> 3 0 idle core -1 - R [ROOT/3]
> 2 264 rt cobalt 20 - XT packetfilter
> 1 279 rt cobalt 20 - W packetfilter
>
Philippe reverted a number of commits in ipipe-4.9.y some days ago.
Please retry either with the latest version or the last release
(ipipe-core-4.9.51-x86-4).
Jan
> >-----Original Message-----
> >From: Lange Norbert
> >Sent: Montag, 18. Dezember 2017 14:43
> >To: Xenomai (xenomai@xenomai.org)
> >Subject: Weird behavior during debug
> >
> >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 block aswell.
> >
> >So the debug session seems to block a rather big amount of events.
> >
> >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled
> >faults over the head domain".
> >Looking at the logs and other threads there seems to be a bigger rework in
> >progress?
> >I will retry with master, and report back.
> >
> >Kind regards
> >
> >Norbert Lange
>
> ________________________________
>
> This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
>
> ANDRITZ HYDRO GmbH
>
>
> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>
> Firmensitz/ Registered seat: Wien
>
> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>
> Firmenbuchnummer/ Company registration: FN 61833 g
>
> DVR: 0605077
>
> UID-Nr.: ATU14756806
>
>
> Thank You
> ________________________________
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Weird behavior during debug
@ 2017-12-18 14:49 Lange Norbert
2017-12-19 7:16 ` Jan Kiszka
0 siblings, 1 reply; 10+ messages in thread
From: Lange Norbert @ 2017-12-18 14:49 UTC (permalink / raw)
To: Xenomai (xenomai@xenomai.org)
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 PID CLASS TYPE PRI TIMEOUT STAT NAME
0 0 idle core -1 - R [ROOT/0]
1 0 idle core -1 - R [ROOT/1]
2 0 idle core -1 - R [ROOT/2]
3 0 idle core -1 - R [ROOT/3]
2 264 rt cobalt 20 - XT packetfilter
1 279 rt cobalt 20 - W packetfilter
>-----Original Message-----
>From: Lange Norbert
>Sent: Montag, 18. Dezember 2017 14:43
>To: Xenomai (xenomai@xenomai.org)
>Subject: Weird behavior during debug
>
>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 block aswell.
>
>So the debug session seems to block a rather big amount of events.
>
>I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled
>faults over the head domain".
>Looking at the logs and other threads there seems to be a bigger rework in
>progress?
>I will retry with master, and report back.
>
>Kind regards
>
>Norbert Lange
________________________________
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-12-20 18:15 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-18 13:43 [Xenomai] Weird behavior during debug Lange Norbert
2017-12-18 14:49 Lange Norbert
2017-12-19 7:16 ` Jan Kiszka
2017-12-19 8:56 ` Lange Norbert
2017-12-19 9:34 ` Jan Kiszka
2017-12-19 13:44 ` Lange Norbert
2017-12-19 18:57 ` Jan Kiszka
2017-12-20 17:49 ` Lange Norbert
2017-12-20 18:07 ` Philippe Gerum
2017-12-20 18:15 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.