Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 28.11.18 09:58, Philippe Gerum wrote: On 11/28/18 7:56 AM, Jan Kiszka wrote: On 27.11.18 19:54, Philippe Gerum wrote: On 11/27/18 6:44 PM, Jan Kiszka wrote: On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:14 PM, Jan Kiszka wrote: On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. That would be a change compared to my past ARM experiments (4.x, if not 3.x based). Can you point me to the problem in more details? Calling __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs) may result in re-enabling IRQs unexpectedly for the caller, due to the callee relaxing. AFAIR, a core debug level assertion should trip when that happens. Coming back to that topic: Just tested ARM on 4.4 with all debug switches of core and ipipe enabled but nothing triggered. So, either the issue is more subtle, or it not really an issue. xnthread_relax() forces hard irqs on: __ipipe_exit_irq -> back from irq_handler (entry-armv.S), so you end up running the interrupt return path with irqs on both for svc or usr modes, including the regular preemption management stuff which assumes the opposite. WARN_ON_ONCE(!hard_irqs_disabled()) should trigger from __ipipe_check_root_interruptible() if added there. Ah! Now we are on the same page. But this does not trigger anymore, and that's because of these two: - https://gitlab.denx.de/Xenomai/ipipe/commit/b2bb695a1ece2320ab04cba9aa359bed8953baf7 - https://gitlab.denx.de/Xenomai/ipipe/commit/da42030eb2e1afc6f3f8f4f6d40ae9b336e3d635 I've noticed that issue back then and urged on addressing it. So we are already safe on ARM as well. That's good. ipipe-core-4.4.71-arm-9 is not safe, and that one is the latest patch I pushed for the 4.4 series over ARM, back in 2015. At the very least, a new 4.4 patch which includes the commit you refer to should be issued (which I'm going to do since the patch maker bot is not fixed yet), but that also means that any version prior to the upcoming ipipe-core-4.4.71-arm-10 would break with these mayday changes. Yes, I meanwhile also realized that we currently lack a recent 4.4-arm release. I'm planning to issue one anyway, plus I have some small build fixes in that tree (backports). We also miss that on 4.9 side, unfortunately, but there are no plans on that end anymore. This mayday cleanup will only affect 3.1. So I think it would be reasonable to request users to use latest maintained I-pipe releases with that upcoming Xenomai line. Just like I started to discuss regarding ARM64, we could add minimum version checks to Xenomai that filter out older patches. That would also simplify other feature checks we currently carry or which I plan to add for the gdb improvements (two new small IPIPE_KEVT hooks will be needed). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/28/18 7:56 AM, Jan Kiszka wrote: > On 27.11.18 19:54, Philippe Gerum wrote: >> On 11/27/18 6:44 PM, Jan Kiszka wrote: >>> On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:14 PM, Jan Kiszka wrote: > On 08.11.18 14:05, Philippe Gerum wrote: >> On 11/5/18 1:20 PM, Jan Kiszka wrote: >>> The mayday mechanism exists in order to kick a xenomai userspace >>> task >>> into secondary mode while it is running userspace code. For that, >>> we ask >>> I-pipe to call us back when the task was interrupted and is about to >>> return to userspace. >>> >>> So far we defer the relaxation from that callback via a VDSO-like >>> mechanism that triggers a special syscall to the return path of that >>> very same syscall. However, that is not desirable because it is a >>> complex, arch-specific mechanism that can easily break and, >>> specifically, that destroys the backtrace of ptraced tasks. >>> >>> Fortunately, we can fulfill the needs of mayday also by relaxing >>> the task directly from the mayday callback. Tested successfully on >>> x86-64 and ARM. >> >> ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to >> work >> properly. This method would cause an interrupt state breakage with >> any >> older ARM patch. > > That would be a change compared to my past ARM experiments (4.x, if > not > 3.x based). Can you point me to the problem in more details? > Calling __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs) may result in re-enabling IRQs unexpectedly for the caller, due to the callee relaxing. AFAIR, a core debug level assertion should trip when that happens. >>> >>> Coming back to that topic: Just tested ARM on 4.4 with all debug >>> switches of core and ipipe enabled but nothing triggered. So, either the >>> issue is more subtle, or it not really an issue. >> >> xnthread_relax() forces hard irqs on: >> >> __ipipe_exit_irq -> back from irq_handler (entry-armv.S), so you end up >> running the interrupt return path with irqs on both for svc or usr >> modes, including the regular preemption management stuff which assumes >> the opposite. >> >> WARN_ON_ONCE(!hard_irqs_disabled()) should trigger from >> __ipipe_check_root_interruptible() if added there. >> > > Ah! Now we are on the same page. But this does not trigger anymore, and > that's because of these two: > > - > https://gitlab.denx.de/Xenomai/ipipe/commit/b2bb695a1ece2320ab04cba9aa359bed8953baf7 > > - > https://gitlab.denx.de/Xenomai/ipipe/commit/da42030eb2e1afc6f3f8f4f6d40ae9b336e3d635 > > > I've noticed that issue back then and urged on addressing it. So we are > already safe on ARM as well. That's good. ipipe-core-4.4.71-arm-9 is not safe, and that one is the latest patch I pushed for the 4.4 series over ARM, back in 2015. At the very least, a new 4.4 patch which includes the commit you refer to should be issued (which I'm going to do since the patch maker bot is not fixed yet), but that also means that any version prior to the upcoming ipipe-core-4.4.71-arm-10 would break with these mayday changes. -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 27.11.18 19:57, Philippe Gerum wrote: On 11/27/18 7:15 PM, Jan Kiszka wrote: On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:15 PM, Jan Kiszka wrote: On 08.11.18 14:09, Philippe Gerum wrote: On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. ppc32 is fine back to kernel 4.1 regarding this (did not check earlier stuff), and arm64 needs the 4.14-based split series to work properly (4.9 is wrong). Is the reason for arm64 on 4.9 the same as for arm? Yes, same pattern. Is ARM64 on 4.9 considered stable? I don't think so. I would recommend 4.14 as a stable starting point for Xenomai/arm64. Should we add a warning to the nucleus that triggers when ARM64 is built against <4.14? The mayday issue would also be trivial to address in 4.9, 100% analogously to the ARM patches, but that would be pointless if no one should use that kernel for ARM64. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 27.11.18 19:54, Philippe Gerum wrote: On 11/27/18 6:44 PM, Jan Kiszka wrote: On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:14 PM, Jan Kiszka wrote: On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. That would be a change compared to my past ARM experiments (4.x, if not 3.x based). Can you point me to the problem in more details? Calling __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs) may result in re-enabling IRQs unexpectedly for the caller, due to the callee relaxing. AFAIR, a core debug level assertion should trip when that happens. Coming back to that topic: Just tested ARM on 4.4 with all debug switches of core and ipipe enabled but nothing triggered. So, either the issue is more subtle, or it not really an issue. xnthread_relax() forces hard irqs on: __ipipe_exit_irq -> back from irq_handler (entry-armv.S), so you end up running the interrupt return path with irqs on both for svc or usr modes, including the regular preemption management stuff which assumes the opposite. WARN_ON_ONCE(!hard_irqs_disabled()) should trigger from __ipipe_check_root_interruptible() if added there. Ah! Now we are on the same page. But this does not trigger anymore, and that's because of these two: - https://gitlab.denx.de/Xenomai/ipipe/commit/b2bb695a1ece2320ab04cba9aa359bed8953baf7 - https://gitlab.denx.de/Xenomai/ipipe/commit/da42030eb2e1afc6f3f8f4f6d40ae9b336e3d635 I've noticed that issue back then and urged on addressing it. So we are already safe on ARM as well. That's good. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/27/18 7:15 PM, Jan Kiszka wrote: > On 08.11.18 14:24, Philippe Gerum wrote: >> On 11/8/18 2:15 PM, Jan Kiszka wrote: >>> On 08.11.18 14:09, Philippe Gerum wrote: On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: > On 11/5/18 1:20 PM, Jan Kiszka wrote: >> The mayday mechanism exists in order to kick a xenomai userspace task >> into secondary mode while it is running userspace code. For that, we >> ask >> I-pipe to call us back when the task was interrupted and is about to >> return to userspace. >> >> So far we defer the relaxation from that callback via a VDSO-like >> mechanism that triggers a special syscall to the return path of that >> very same syscall. However, that is not desirable because it is a >> complex, arch-specific mechanism that can easily break and, >> specifically, that destroys the backtrace of ptraced tasks. >> >> Fortunately, we can fulfill the needs of mayday also by relaxing >> the task directly from the mayday callback. Tested successfully on >> x86-64 and ARM. > > ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to > work > properly. This method would cause an interrupt state breakage with any > older ARM patch. > ppc32 is fine back to kernel 4.1 regarding this (did not check earlier stuff), and arm64 needs the 4.14-based split series to work properly (4.9 is wrong). >>> >>> Is the reason for arm64 on 4.9 the same as for arm? >>> >> >> Yes, same pattern. >> > > Is ARM64 on 4.9 considered stable? I don't think so. I would recommend 4.14 as a stable starting point for Xenomai/arm64. Then I would look into that path as > well. > > But given that ARM64 will be newly introduced with 3.1 only and that 4.9 > will likely be out of our legacy maintenance by then, the simpler > solution for mayday topic could just be raising the minimum supported > version to 4.14 for that arch (if there is a real issue). > > Jan > -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/27/18 6:44 PM, Jan Kiszka wrote: > On 08.11.18 14:24, Philippe Gerum wrote: >> On 11/8/18 2:14 PM, Jan Kiszka wrote: >>> On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: > The mayday mechanism exists in order to kick a xenomai userspace task > into secondary mode while it is running userspace code. For that, > we ask > I-pipe to call us back when the task was interrupted and is about to > return to userspace. > > So far we defer the relaxation from that callback via a VDSO-like > mechanism that triggers a special syscall to the return path of that > very same syscall. However, that is not desirable because it is a > complex, arch-specific mechanism that can easily break and, > specifically, that destroys the backtrace of ptraced tasks. > > Fortunately, we can fulfill the needs of mayday also by relaxing > the task directly from the mayday callback. Tested successfully on > x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. >>> >>> That would be a change compared to my past ARM experiments (4.x, if not >>> 3.x based). Can you point me to the problem in more details? >>> >> >> Calling __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs) may result in >> re-enabling IRQs unexpectedly for the caller, due to the callee >> relaxing. AFAIR, a core debug level assertion should trip when that >> happens. >> > > Coming back to that topic: Just tested ARM on 4.4 with all debug > switches of core and ipipe enabled but nothing triggered. So, either the > issue is more subtle, or it not really an issue. xnthread_relax() forces hard irqs on: __ipipe_exit_irq -> back from irq_handler (entry-armv.S), so you end up running the interrupt return path with irqs on both for svc or usr modes, including the regular preemption management stuff which assumes the opposite. WARN_ON_ONCE(!hard_irqs_disabled()) should trigger from __ipipe_check_root_interruptible() if added there. > > I suppose I need more background here to understand the risk you see. If > there is a problem, I'd either like to backport a solution from 4.14 or > detect what the kernel supports and scale down mayday depending on that, > at least on ARM. > > BTW, this is the call path we are talking about: > > #0 handle_mayday_event (regs=) at > ../kernel/xenomai/posix/process.c:1028 > #1 0xc02c3c70 in __ipipe_notify_trap (exception=9, regs=0xece07fb0) at > ../kernel/ipipe/core.c:1065 > #2 0xc02c52a8 in __ipipe_call_mayday (regs=0xece07fb0) at > ../kernel/ipipe/core.c:1610 > #3 0xc021e448 in __ipipe_exit_irq (regs=) at > ../arch/arm/kernel/ipipe.c:357 > #4 0xc020a57c in __ipipe_exit_irq (regs=) at > ../arch/arm/kernel/ipipe.c:396 > #5 __ipipe_grab_irq (irq=, regs=) at > ../arch/arm/kernel/ipipe.c:395 > #6 0xc020ac0c in ipipe_handle_multi_irq (regs=, > irq=) at ../arch/arm/include/asm/ipipe.h:232 > #7 ipipe_handle_domain_irq (regs=, hwirq= out>, domain=) at ../arch/arm/include/asm/ipipe.h:249 > #8 gic_handle_irq (regs=0xece07fb0) at ../drivers/irqchip/irq-gic.c:367 > > I wonder what the difference is to a normal Xenomai reschedules at the > end of an interrupt. > The rescheduling bits for xnthread_relax() are very specific, so that we can transfer control of the current context to another scheduler logic in a safe way. Looking at the way XNRELAX is dealt with by xnthread_suspend() may help. -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:15 PM, Jan Kiszka wrote: On 08.11.18 14:09, Philippe Gerum wrote: On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. ppc32 is fine back to kernel 4.1 regarding this (did not check earlier stuff), and arm64 needs the 4.14-based split series to work properly (4.9 is wrong). Is the reason for arm64 on 4.9 the same as for arm? Yes, same pattern. Is ARM64 on 4.9 considered stable? Then I would look into that path as well. But given that ARM64 will be newly introduced with 3.1 only and that 4.9 will likely be out of our legacy maintenance by then, the simpler solution for mayday topic could just be raising the minimum supported version to 4.14 for that arch (if there is a real issue). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 08.11.18 14:24, Philippe Gerum wrote: On 11/8/18 2:14 PM, Jan Kiszka wrote: On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. That would be a change compared to my past ARM experiments (4.x, if not 3.x based). Can you point me to the problem in more details? Calling __ipipe_notify_trap(IPIPE_TRAP_MAYDAY, regs) may result in re-enabling IRQs unexpectedly for the caller, due to the callee relaxing. AFAIR, a core debug level assertion should trip when that happens. Coming back to that topic: Just tested ARM on 4.4 with all debug switches of core and ipipe enabled but nothing triggered. So, either the issue is more subtle, or it not really an issue. I suppose I need more background here to understand the risk you see. If there is a problem, I'd either like to backport a solution from 4.14 or detect what the kernel supports and scale down mayday depending on that, at least on ARM. BTW, this is the call path we are talking about: #0 handle_mayday_event (regs=) at ../kernel/xenomai/posix/process.c:1028 #1 0xc02c3c70 in __ipipe_notify_trap (exception=9, regs=0xece07fb0) at ../kernel/ipipe/core.c:1065 #2 0xc02c52a8 in __ipipe_call_mayday (regs=0xece07fb0) at ../kernel/ipipe/core.c:1610 #3 0xc021e448 in __ipipe_exit_irq (regs=) at ../arch/arm/kernel/ipipe.c:357 #4 0xc020a57c in __ipipe_exit_irq (regs=) at ../arch/arm/kernel/ipipe.c:396 #5 __ipipe_grab_irq (irq=, regs=) at ../arch/arm/kernel/ipipe.c:395 #6 0xc020ac0c in ipipe_handle_multi_irq (regs=, irq=out>) at ../arch/arm/include/asm/ipipe.h:232 #7 ipipe_handle_domain_irq (regs=, hwirq=, domain=) at ../arch/arm/include/asm/ipipe.h:249 #8 gic_handle_irq (regs=0xece07fb0) at ../drivers/irqchip/irq-gic.c:367 I wonder what the difference is to a normal Xenomai reschedules at the end of an interrupt. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/8/18 2:15 PM, Jan Kiszka wrote: > On 08.11.18 14:09, Philippe Gerum wrote: >> On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: >>> On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. >>> >>> ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work >>> properly. This method would cause an interrupt state breakage with any >>> older ARM patch. >>> >> >> ppc32 is fine back to kernel 4.1 regarding this (did not check earlier >> stuff), and arm64 needs the 4.14-based split series to work properly >> (4.9 is wrong). > > Is the reason for arm64 on 4.9 the same as for arm? > Yes, same pattern. -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. That would be a change compared to my past ARM experiments (4.x, if not 3.x based). Can you point me to the problem in more details? Thanks, Jan
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: > On 11/5/18 1:20 PM, Jan Kiszka wrote: >> The mayday mechanism exists in order to kick a xenomai userspace task >> into secondary mode while it is running userspace code. For that, we ask >> I-pipe to call us back when the task was interrupted and is about to >> return to userspace. >> >> So far we defer the relaxation from that callback via a VDSO-like >> mechanism that triggers a special syscall to the return path of that >> very same syscall. However, that is not desirable because it is a >> complex, arch-specific mechanism that can easily break and, >> specifically, that destroys the backtrace of ptraced tasks. >> >> Fortunately, we can fulfill the needs of mayday also by relaxing >> the task directly from the mayday callback. Tested successfully on >> x86-64 and ARM. > > ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work > properly. This method would cause an interrupt state breakage with any > older ARM patch. > ppc32 is fine back to kernel 4.1 regarding this (did not check earlier stuff), and arm64 needs the 4.14-based split series to work properly (4.9 is wrong). -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 05.11.18 14:48, Steven Seeger wrote: > On Monday, November 5, 2018 7:20:33 AM EST Jan Kiszka wrote: >> >> I would appreciate if you could test ARM64 and PowerPC for me. Until we >> have QEMU test images for both, it's still tricky for me to do that. > > I have something I've got to get done before I can do anything else, but once > that's done I can take a look a this on a PowerPC board. > Great, TIA! The key test is likely sigdebug from smokey. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On Monday, November 5, 2018 7:20:33 AM EST Jan Kiszka wrote: > > I would appreciate if you could test ARM64 and PowerPC for me. Until we > have QEMU test images for both, it's still tricky for me to do that. I have something I've got to get done before I can do anything else, but once that's done I can take a look a this on a PowerPC board. Steven
