Re: [Xenomai] RTnet fixes - testers needed
On 19/12/17 11:17, Andreas Glatz wrote: >> >> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from >> Sun >> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type >> >> I have created the packages and new kernel with the same configuration that >> I had. >> >> I run my application, that it's a POSIX application Wrapped and I still have >> the >> same error when I activate SMAP: > > I see that the page fault occurs in rt_packet_ioctl()... by the looks > of this bug it might be similar to the one I found in udp.c (see my > post from Sunday)... basically the ioctl still tries to access user > memory, which causes that stack trace. I'm currently a bit busy - I > hope I can continue debugging this by the end of this week. In the > meantime could you recompile your kernel with debug info which should > improve the kernel bug output? > I have compiled the kernel with CONFIG_DEBUG_KERNEL=Y. But, I have seen that there's another option. Which one could be the best for this case? 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
Re: [Xenomai] RTnet fixes - testers needed
>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from >>> Sun >>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type >>> >>> I have created the packages and new kernel with the same configuration that >>> I had. >>> >>> I run my application, that it's a POSIX application Wrapped and I still >>> have the >>> same error when I activate SMAP: >> >> I see that the page fault occurs in rt_packet_ioctl()... by the looks >> of this bug it might be similar to the one I found in udp.c (see my >> post from Sunday)... basically the ioctl still tries to access user >> memory, which causes that stack trace. I'm currently a bit busy - I >> hope I can continue debugging this by the end of this week. In the >> meantime could you recompile your kernel with debug info which should >> improve the kernel bug output? >> > > I have compiled the kernel with CONFIG_DEBUG_KERNEL=Y. But, I have seen that > there's another option. > > Which one could be the best for this case? > I think you want CONFIG_DEBUG_INFO, which depends on CONFIG_DEBUG_KERNEL=Y. On ARM I also enabled CONFIG_DEBUG_INFO_DWARF4... but the help says it's just for gdb + optimised code so I think you can leave it out. Cheers, A. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xenomai cyclictest negative Max value
On 12/20/2017 07:49 AM, Peng Fan wrote:
> On Mon, Dec 18, 2017 at 10:26:28AM +0800, Peng Fan wrote:
>> Hi All,
>>
>> I compiled xenomai-next on my ARM64 platform, but met Max and Avg not
>> correct.
>> See below:
>>
>> ./cyclictest -a -t10 -n -p99 -c 0
>> # /dev/cpu_dma_latency set to 0us
>> policy: fifo: loadavg: 0.97 0.51 0.21 1/135 3018
>> policy: fifo: loadavg: 1.00 0.76 0.38 1/128 3018
>> T:[ 200.650323] random: crng init done 0 Act:0 Avg:443149053456561
>> Max: -1
>> T: 0 ( 3002) P:99 I:1000 C: 373066 Min: 0 Act:0 Avg:395570629834068
>> Max: -11
>> T: 1 ( 3003) P:99 I:1500 C: 248710 Min: 0 Act:0 Avg:148339383810136
>> Max: -111
>> T: 2 ( 3004) P:99 I:2000 C: 186532 Min: 0 Act:0 Avg:593359125738518
>> Max: -1
>> T: 3 ( 3005) P:99 I:2500 C: 149359 Min: 0 Act:0 Avg:123506076458128
>> Max: -11
>> T: 4 ( 3006) P:99 I:3000 C: 124465 Min: 0 Act:0 Avg:592833136181562
>> Max: -1
>> T: 5 ( 3007) P:99 I:3500 C: 106684 Min: 0 Act:0 Avg:172910127795260
>> Max: -111
>> T: 6 ( 3008) P:99 I:4000 C: 93349 Min: 0 Act:0
>> Avg:1383273613171719 Max: -1
>> T: 7 ( 3009) P:99 I:4500 C: 82977 Min: 0 Act:0 Avg:666934598998863
>> Max: -1
>> T: 8 ( 3010) P:99 I:5000 C: 74679 Min: 0 Act:0 Avg:988055226969271
>> Max: -11
>>
>> Seems xenomai cyclictest and rt-tests cyclictest is not sync, or there are
>> some differecense. Could you please help me clarify what's the difference
>> between xenomai cyclictest and rt-tests cyclictest? I did not find out which
>> exact commit number when importing rt-tests cyclictest to xenomai.
>
> I add a debug info in cyclictest.c, see below:
>
> diff --git a/demo/posix/cyclictest/cyclictest.c
> b/demo/posix/cyclictest/cyclictest.c
> index 31d9e5d0b..b16321cd9 100644
> --- a/demo/posix/cyclictest/cyclictest.c
> +++ b/demo/posix/cyclictest/cyclictest.c
> @@ -920,6 +920,11 @@ void *timerthread(void *param)
> diff = calcdiff_ns(now, next);
> else
> diff = calcdiff(now, next);
> +
> + if (diff == -1) {
> + printf(" %ld %ld %ld %ld\n", now.tv_sec,
> now.tv_nsec, next.tv_sec, next.tv_nsec);
> + exit(0);
> + }
> if (diff < stat->min)
> stat->min = diff;
> if (diff > stat->max) {
>
> And I encounter the case that diff is -1,
> " 16124 21743627 16124 21744638"
> only 1ns difference between now and next.
> This means clock_nanosleep wakeup earlier than expected?
> I am using 4.9.51 kernel, and xenomai-next on ARM64. I am tracking
> the hrtimer things, but no good progress. Please advise, if you any ideas.
>
You need to calibrate the core timer with the "autotune" utility. Some
details available here:
https://xenomai.org/documentation/xenomai-3/html/man1/autotune/index.html
--
Philippe.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] RTnet fixes - testers needed
On 12/19/2017 11:17 AM, Andreas Glatz wrote: >> >> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from >> Sun >> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type >> >> I have created the packages and new kernel with the same configuration that >> I had. >> >> I run my application, that it's a POSIX application Wrapped and I still have >> the >> same error when I activate SMAP: > > I see that the page fault occurs in rt_packet_ioctl()... by the looks > of this bug it might be similar to the one I found in udp.c (see my Confirmed, same pattern. The network address is wrongly accessed in rt_packet_getsockname(). -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] RTnet fixes - testers needed
On 12/20/2017 11:17 AM, Philippe Gerum wrote: > On 12/19/2017 11:17 AM, Andreas Glatz wrote: >>> >>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from >>> Sun >>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type >>> >>> I have created the packages and new kernel with the same configuration that >>> I had. >>> >>> I run my application, that it's a POSIX application Wrapped and I still >>> have the >>> same error when I activate SMAP: >> >> I see that the page fault occurs in rt_packet_ioctl()... by the looks >> of this bug it might be similar to the one I found in udp.c (see my > > Confirmed, same pattern. The network address is wrongly accessed in > rt_packet_getsockname(). > Likewise for the bind side. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Cobalt core and Yocto
Am Tue, 19 Dec 2017 16:00:02 -0500
schrieb Steve Pavao :
> Hi Jan,
>
> > On Dec 19, 2017, at 2:24 PM, Jan Kiszka
> > wrote:
> >
> > On 2017-12-19 19:49, Steve Pavao wrote:
> >> Hi Lowell,
> >>
> >> Thanks for that tip. That’s what I was thinking I might need to
> >> do.
> >>
> >> I guess the solution in Yocto terms is to rework my I-PIPE patch
> >> recipe to not directly apply the I-PIPE patch, but rather to call
> >> prepare-kernel.sh and allow it to apply the patch, plus do the
> >> other things it needs to do. I guess that should happen in a
> >> do_configure() {} block.
> >
> > Actually, I would move the kernel patching out of the xenomai
> > recipe and rather have one recipe for the userspace packages and a
> > xenomai-kernel.inc which appends the kernel preparation task with
> > the prepare-kernel.sh invocation. It would also bring in (once
> > again) the xenomai sources so that its kernel elements get pulled
> > into the kernel build. In your kernel recipe, you would simply
> > include that file.
> >
> > This way, the kernel could come from various sources, including
> > git.xenomai.org/ipipe.git, and just needs to have the I-pipe patch
> > already applied, either in it git source or by adding a
> > corresponding patch to the custom kernel recipe.
> >
> > This seems similar to how ELDK modeled this:
> > http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk
> >
> >
>
> Thanks for your advice, Jan. I was hoping to keep things as simple
> as possible, though. The ELDK example has a highly-customized bb
> recipe.
If you want to keep things as simple as possible you could also diff
the kernel before and after prepare-kernel.sh and just add the patch
you get out of there to your patches in the bbappend.
This will tie you kernel recipe to the exact version of xenomai and
should be considered a hack.
Henning
> Could I achieve my ends If I use my initial idea, which is to call
> the prepare-kernel.sh from a do_configure block, rather than directly
> applying the I-PIPE patch? It seems like it won’t succeed, based on
> what you have said, perhaps because the recipe that calls
> prepare-kernel.sh is going to need to be more complex than simply
> calling that script. (You mentioned about needing to pull in the
> xenomai sources once again).
>
> I think I need to hand this task off to a colleague who has some more
> Linux internals experience.
>
> > That is outdated now, unfortunately. Do you plan to publish your
> > layer afterwards? I suppose some people would be happy about a
> > meta-xenomai with support for Xenomai 3.
>
> I’d have to check with my organization. Personally, I’d like to see
> anyone publish one, including us. Anything that allows folks to
> start using Xenomai 3 more easily from within their highly-customized
> Poky environments would be helpful.
>
> - Steve Pavao
> Korg R&D
>
>
>
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] RTnet fixes - testers needed
On 12/20/2017 11:19 AM, Philippe Gerum wrote: > On 12/20/2017 11:17 AM, Philippe Gerum wrote: >> On 12/19/2017 11:17 AM, Andreas Glatz wrote: I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type I have created the packages and new kernel with the same configuration that I had. I run my application, that it's a POSIX application Wrapped and I still have the same error when I activate SMAP: >>> >>> I see that the page fault occurs in rt_packet_ioctl()... by the looks >>> of this bug it might be similar to the one I found in udp.c (see my >> >> Confirmed, same pattern. The network address is wrongly accessed in >> rt_packet_getsockname(). >> > > Likewise for the bind side. > That one should help fixing the the AF_PACKET layer: http://git.xenomai.org/xenomai-3.git/commit/?h=wip/rtnet-fixes&id=3e388bcfde6c59bd9ec28bbcdb3757d32f19160b -- 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 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
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
