Re: [Xenomai] Weird behavior during debug
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. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Weird behavior during debug
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 > > > >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. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] 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, 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Weird behavior during debug
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.kis...@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_AOUTif 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.kis...@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 PIDCLASS 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 264rt cobalt 20 - XT > packetfilter > >> >> 1 279rt 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 > >> >> > >> >> ___
Re: [Xenomai] Weird behavior during debug
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.kis...@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_AOUTif 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.kis...@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 PIDCLASS 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 264rt cobalt 20 - XT packetfilter >> >> 1 279rt 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 mi
Re: [Xenomai] Weird behavior during debug
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_AOUTif 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.kis...@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 PIDCLASS 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 264rt cobalt 20 - XT packetfilter > >> 1 279rt 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
Re: [Xenomai] Weird behavior during debug
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_AOUTif 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.kis...@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 PIDCLASS 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 264rt cobalt 20 - XT packetfilter >> 1 279rt 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: Wi
Re: [Xenomai] Weird behavior during debug
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 PIDCLASS 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 264rt cobalt 20 - XT packetfilter > 1 279rt 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Weird behavior during debug
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 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 264rt cobalt 20 - XT packetfilter 1 279rt 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 ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] 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
