RE: Moving on
> -Original Message- > From: Xenomai On Behalf Of Philippe > Gerum via Xenomai > Sent: Montag, 2. Dezember 2019 17:05 > To: Xenomai@xenomai.org > Subject: Moving on > > > It has been two years since I stepped down as Xenomai's lead maintainer. > In the meantime, Jan took over and did a very good job in this role as > expected. > > Since this transition period is now taking an end, I'm switching focus to the > EVL project [1] I have been nurturing for some time, with the goal to make it > production-grade next year. In a nutshell, EVL is about laying the groundwork > for dual kernel systems to become first-class citizens of Linux. This work > includes a SMP scalable real-time core which can be maintained with > common kernel knowledge over the latest mainline kernel series, a standard > driver model, and a single, compact API > > I will still review patches coming my way for the I-pipe ARM and arm64 trees > for a few weeks, until the next maintainer is appointed for these > architectures. I'll be around to help with Xenomai core issues if needed. Doesnt seem like you will move too far away, good luck with EVL (and getting it upstreamed if that’s the aim). Norbert 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
Re: [ANNOUNCE] Xenomai v3.1-rc4 available
On 11.12.19 09:38, Lange Norbert wrote: > > >> -Original Message- >> From: Xenomai On Behalf Of Jan Kiszka >> via Xenomai >> Sent: Freitag, 6. Dezember 2019 15:44 >> To: Xenomai >> Subject: [ANNOUNCE] Xenomai v3.1-rc4 available >> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR >> ATTACHMENTS. >> >> >> Hi all, >> >> after running into a number of critical issues around the scheduler but also >> one of the new ABIs, this -rc is a fairly important one: >> >> https://gitlab.denx.de/Xenomai/xenomai/-/archive/v3.1-rc4/xenomai-v3.1- >> rc4.tar.bz2 >> https://gitlab.denx.de/Xenomai/xenomai/commits/v3.1-rc4 >> >> Changes since rc3: >> >> Jan Kiszka (15): >> rtdm: Do not return an error from send/recvmmsg if there are packets >> rtdm: Remove early exit from send/recvmmsg on vlan == 0 >> ci: Always build the latest release >> lib/cobalt: Fix help for --print-sync-delay >> alchemy: Fully initialize tcb->self >> testsuite/smokey/posix-cond: Make more robust for execution in VMs >> cobalt/posix/thread: Factor out thread_lookup_or_shadow >> cobalt/posix: Add thread_setschedprio >> lib/cobalt: Use new thread_setschedprio syscall >> Revert "cobalt/kernel: Introduce __SCHED_CURRENT policy to >> setschedparam_ex" >> testsuite/smokey: Fix setsched /wrt lazy scheduling parameter >> application >> testsuite/smokey: Add pthread_setschedprio to setsched test case >> debian: Enable lazy-setsched in userspace package >> cobalt/intr: Move IRQ exit trace point in non-shared case >> config: Bump version number >> >> Philippe Gerum (16): >> copperplate/heapobj-pshared: fix element size for array init >> testsuite/mq-2: clarify test implementation >> boilerplate/avl: fix NULL link representation in pshared mode - take #2 >> cobalt/process: skip trap handling for the root thread >> cobalt/thread: update inline documentation >> cobalt/posix: fix missed rescheduling opportunities >> cobalt/process: remove superfluous check for non-relaxed state >> cobalt/thread: fix scheduler breakage on thread suspension >> drivers/testing: heapcheck: silence UMR warning (false positive) >> cobalt/process: exit_thread handlers should reschedule as needed >> net/proxy: fix non-rt signal overflow >> cobalt/sched: quota: fix use-after-free in quota_remove operation >> net/rtmac: vnic: fix non-rt signal overflow >> net/rtpc: fix non-rt signal overflow >> net/cap: fix non-rt signal overflow >> cobalt/sched: guard against missed rescheduling upon CPU migration >> >> Please test so that we finalize 3.1 soon. > > Running here without issues so far, and I used Phillipe's schedulerfixes > since they appeared. > Looks good to me. > > Norbert Thanks for the feedback (taking it to the ML)! Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
- Ursprüngliche Mail - > Von: "Jan Kiszka" > An: "richard" > CC: "Philippe Gerum" , "Michael Nazzareno Trimarchi" > , "xenomai" > > Gesendet: Mittwoch, 11. Dezember 2019 08:24:41 > Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai) > On 10.12.19 20:52, Richard Weinberger wrote: >> - Ursprüngliche Mail - >>> Von: "Jan Kiszka" >>> That's untested even on x86 - and likely not working, with any kernel. >>> >>> Do you have a use case for kprobe? >> >> Yes. On the old kernel we used to have many hooks (function pointers) >> within kernel to allow installing notification functions by our modules. >> It is basically a hand made tracing/notify framework. >> >> To get rid of the mess we decided to use kprobes instead of our plain >> pointers. So far the probes worked nicely and helped us a lot to cleanup >> the code base. >> >> If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. >> :-( > > CONFIG_KPROBES. We do support tracing (ftrace, down to functions), and > that is what I would recommend to you. > > In general, there are likely more things from the debugging section > unsupported. It's hard to hunt them all down, but CONFIG_KPROBES is > probably worth to add. Let's put it differently. What is missing to have reliable kprobes? Maybe this is a small and nice project to get a better grip on ipipe internals. Thanks, //richard
Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
On 11.12.19 11:17, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >> An: "richard" >> CC: "Philippe Gerum" , "Michael Nazzareno Trimarchi" >> , "xenomai" >> >> Gesendet: Mittwoch, 11. Dezember 2019 08:24:41 >> Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x >> xenomai) > >> On 10.12.19 20:52, Richard Weinberger wrote: >>> - Ursprüngliche Mail - Von: "Jan Kiszka" That's untested even on x86 - and likely not working, with any kernel. Do you have a use case for kprobe? >>> >>> Yes. On the old kernel we used to have many hooks (function pointers) >>> within kernel to allow installing notification functions by our modules. >>> It is basically a hand made tracing/notify framework. >>> >>> To get rid of the mess we decided to use kprobes instead of our plain >>> pointers. So far the probes worked nicely and helped us a lot to cleanup >>> the code base. >>> >>> If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. >>> :-( >> >> CONFIG_KPROBES. We do support tracing (ftrace, down to functions), and >> that is what I would recommend to you. >> >> In general, there are likely more things from the debugging section >> unsupported. It's hard to hunt them all down, but CONFIG_KPROBES is >> probably worth to add. > > Let's put it differently. What is missing to have reliable kprobes? > Maybe this is a small and nice project to get a better grip on ipipe > internals. Probably something similar to what we did for enabling kgdb: Analyze to code path taken on hit, handle it without migrations or worse things - and then make sure this is continuously tested. Due to missing tests of kgdb e.g., I would not assume it still works. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
