[Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)
Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the "name" field to the interrupt object of the nucleus layer. Reworks the related bits of the native skin (+ a few minor changes for posix and rtdm) to support the named interrupt objects. 2) shirq-v7.patch Generic support for shared interrupts. 3) shirq-proc.patch /proc support. Now /proc/xenomai/irq shows the names of handlers. The related code have been removed from the hal layer to nucleus. - 4) shirq-isa.patch Trying to handle the edge-triggered stuff. This is a very preliminary version so the only thing I promise so far is that it compiles successfully. The functionality added by first 3 patches seem to be working.-- Best regards,Dmitry Adamushko shirq-base.patch Description: Binary data shirq-v7.patch Description: Binary data shirq-proc.patch Description: Binary data shirq-isa.patch Description: Binary data
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus
suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute
shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
> > So, the only case when we are sure that a user-space thread can
not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
Almost ok, but XNDELAY might also be set alone, indicating a purely
timed wait state (i.e. without sync object to pend on, so XNPEND is off).
Forget about this: XNDELAY might also be a transient bit like XNSUSP, so you are
right, we cannot test it there.
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c(revision 507)
+++ ksrc/nucleus/shadow.c(working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
-xnflags_t status = threadin->status & ~XNRELAX;
+xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux
domain?! (status=0x%lx, sig=%d, prev=%s[%d])",
+threadin->name,
+next->pid,
+status,
+sigpending,
+prev->comm,
+prev->pid);
+}
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
-testbits(status,XNTHREAD_BLOCK_BITS))
+testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?!
(status=0x%lx, sig=%d, prev=%s[%d])",
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
>
> So, the only case when we are sure that a user-space thread can not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
Almost ok, but XNDELAY might also be set alone, indicating a purely timed wait
state (i.e. without sync object to pend on, so XNPEND is off).
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 507)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
- xnflags_t status = threadin->status & ~XNRELAX;
+ xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux domain?!
(status=0x%lx, sig=%d, prev=%s[%d])",
+ threadin->name,
+ next->pid,
+ status,
+ sigpending,
+ prev->comm,
+ prev->pid);
+ }
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
- testbits(status,XNTHREAD_BLOCK_BITS))
+ testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx, sig=%d,
prev=%s[%d])",
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
Re: [Xenomai-core] [BUG] version mismatch
Anders Blomdell wrote: in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch: #define IPIPE_ARCH_STRING"1.1-02" shouldn't this be #define IPIPE_ARCH_STRING"1.2-00" Yes it should. Fixed, thanks. -- Philippe.
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Anders Blomdell wrote: Jan Kiszka wrote: Anders Blomdell wrote: While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. My impression as well, but it's nowhere documented, nor enforced in the code. In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? Yes. desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. If the non-RT driver sets that bit in its ISR routine, yes. I have the (overly optimistic?) view that the non-RT ISR only does whatever is necessary to clear the interrupt and leaves the enable/disable bits untouched. Or perhaps the whole conceptis of no interest to others, and I should put this arbitration in the platform specific part (arch/ppc/platform/prpmc800.c) and consider the harrier chip as a cascaded interrupt controller, and handle it as such? -- Anders Blomdell
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Jan Kiszka wrote: Anders Blomdell wrote: While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. My impression as well, but it's nowhere documented, nor enforced in the code. In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? Yes. desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. If the non-RT driver sets that bit in its ISR routine, yes. I have the (overly optimistic?) view that the non-RT ISR only does whatever is necessary to clear the interrupt and leaves the enable/disable bits untouched. Meanwhile I recalled that my hack to realise IRQ sharing between a RT device and a non-RT eepro100 is filed on a public archive: https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html Thanks, I'll take a look at it. -- Anders Blomdell
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Anders Blomdell wrote: > While looking into how to implement sharing of interrupts between > realtime and non-realtime domains (and applying Wolfgang Grandegger's > patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], > which is necessary to make XN_ISR_ENABLE work at all on the PowerPC > platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE > are mutually exclusive, since if both are set, desc->handler->end will > be called twice: > > 1. When the realtime isr handler returns > 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. > > In the solution I have in mind at the moment, I will: > > 1. Add an extra iend handler argument to xnintr_init > 2. If XN_ISR_ENABLE is returned from the isr handler, > replace desc->handler->end with the user supplied > iend handler. > > Hereby I hope to be able to handle interrupts shared between realtime > and non-realtime domain, without having the realtime domain wait for all > non-realtime interrupts to finish. This is the scenario I'm thinking of: > > 1. A non-RT interrupt occurs > 2. The (RT) isr handler detects the non-RT interrupt, > disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? > desc->handler->end with the user supplied iend handler, > returns XN_ISR_CHAINED | XN_ISR_ENABLE. > 3. RT interrupts are serviced by the (RT) isr handler, > returns XN_ISR_ENABLE > 4. The Linux domain get a chance to run the chained interrupt, > and eventually calls desc->handler->end (supplied iend handler) > 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. Meanwhile I recalled that my hack to realise IRQ sharing between a RT device and a non-RT eepro100 is filed on a public archive: https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html > > Comments on the above are most welcome! > Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Comments on the above are most welcome! -- Anders Blomdell
[Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)
Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the "name" field to the interrupt object of the nucleus layer. Reworks the related bits of the native skin (+ a few minor changes for posix and rtdm) to support the named interrupt objects. 2) shirq-v7.patch Generic support for shared interrupts. 3) shirq-proc.patch /proc support. Now /proc/xenomai/irq shows the names of handlers. The related code have been removed from the hal layer to nucleus. - 4) shirq-isa.patch Trying to handle the edge-triggered stuff. This is a very preliminary version so the only thing I promise so far is that it compiles successfully. The functionality added by first 3 patches seem to be working.-- Best regards,Dmitry Adamushko shirq-base.patch Description: Binary data shirq-v7.patch Description: Binary data shirq-proc.patch Description: Binary data shirq-isa.patch Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jeroen Van den Keybus wrote: >> Revision 466 contains the mutex-info fix, but that is post -rc2. Why not >> switching to SVN head? > > > Philippe asked to apply the patch against Xenomai 2.1-rc2. Can I safely > patch it against the SVN tree ? After that, what will 'svn up' do to the > patched tree ? The CONFIG_PREEMPT fix is already contained in the latest SVN revision, no need to patch anymore. When unsure if a patch will cleanly apply, try "patch --dry-run" first. (Virtually) rejected hunks can then be used to asses if the patch fits - without messing up the code base immediately. > > Remember I'm quite new to Linux. Actually, I spent half an hour finding out > how that patch stuff (especially the -p option) works. > :) (it's no problem to ask even these kind of "stupid" questions to the list or us directly - no one will bite you!) Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
>
> So, the only case when we are sure that a user-space thread can not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
--
Gilles Chanteperdrix.
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 507)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
- xnflags_t status = threadin->status & ~XNRELAX;
+ xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux domain?!
(status=0x%lx, sig=%d, prev=%s[%d])",
+ threadin->name,
+ next->pid,
+ status,
+ sigpending,
+ prev->comm,
+ prev->pid);
+ }
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
- testbits(status,XNTHREAD_BLOCK_BITS))
+ testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx,
sig=%d, prev=%s[%d])",
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head? Philippe asked to apply the patch against Xenomai 2.1-rc2. Can I safely patch it against the SVN tree ? After that, what will 'svn up' do to the patched tree ? Remember I'm quite new to Linux. Actually, I spent half an hour finding out how that patch stuff (especially the -p option) works. Jeroen.
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus
suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute
shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
> > So, the only case when we are sure that a user-space thread can
not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
Almost ok, but XNDELAY might also be set alone, indicating a purely
timed wait state (i.e. without sync object to pend on, so XNPEND is off).
Forget about this: XNDELAY might also be a transient bit like XNSUSP, so you are
right, we cannot test it there.
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c(revision 507)
+++ ksrc/nucleus/shadow.c(working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
-xnflags_t status = threadin->status & ~XNRELAX;
+xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux
domain?! (status=0x%lx, sig=%d, prev=%s[%d])",
+threadin->name,
+next->pid,
+status,
+sigpending,
+prev->comm,
+prev->pid);
+}
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
-testbits(status,XNTHREAD_BLOCK_BITS))
+testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?!
(status=0x%lx, sig=%d, prev=%s[%d])",
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jeroen Van den Keybus wrote: >>> I've installed both patches and the problem seems to have disappeared. >>> I'll try it on another machine tomorrow, too. Meanwhile: thanks very >>> much for the assistance ! > > > While testing more thoroughly, my triggers for zero mutex values after > acquiring the lock are going off again. I was using the SVN xenomai > development tree, but I've now switched to the (fixed) 2.1-rc2 in order to > apply the patches. Is Jan's bugfix included in that one ? Revision 466 contains the mutex-info fix, but that is post -rc2. Why not switching to SVN head? Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
> I've installed both patches and the problem seems to have disappeared.> I'll try it on another machine tomorrow, too. Meanwhile: thanks very > much for the assistance ! While testing more thoroughly, my triggers for zero mutex values after acquiring the lock are going off again. I was using the SVN xenomai development tree, but I've now switched to the (fixed) 2.1-rc2 in order to apply the patches. Is Jan's bugfix included in that one ? Jeroen.
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
>
> So, the only case when we are sure that a user-space thread can not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
Almost ok, but XNDELAY might also be set alone, indicating a purely timed wait
state (i.e. without sync object to pend on, so XNPEND is off).
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 507)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
- xnflags_t status = threadin->status & ~XNRELAX;
+ xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux domain?!
(status=0x%lx, sig=%d, prev=%s[%d])",
+ threadin->name,
+ next->pid,
+ status,
+ sigpending,
+ prev->comm,
+ prev->pid);
+ }
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
- testbits(status,XNTHREAD_BLOCK_BITS))
+ testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx, sig=%d,
prev=%s[%d])",
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] version mismatch
Anders Blomdell wrote: in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch: #define IPIPE_ARCH_STRING"1.1-02" shouldn't this be #define IPIPE_ARCH_STRING"1.2-00" Yes it should. Fixed, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] version mismatch
in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch: #define IPIPE_ARCH_STRING"1.1-02" shouldn't this be #define IPIPE_ARCH_STRING"1.2-00" -- Anders Blomdell
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Jeroen Van den Keybus wrote:
>>> I mean that the support of shared interrupts for ISA boards
>> (edge-triggered
>>> stuff) is a kind of emulation to overcome the shortcommings of the
>> initial
>>> design on the hardware level. The hardware was just not supposed to
>> support
>>> shared interrupt channels. So, let's keep it a bit aside from another
>> code
>>> :o)
>> Unfortunately, this crappy hardware is still quite common in the
>> embedded domain.
>
>
> If I've understood correctly, the only reason for having this support is to
> avoid - after discovering an interrupting UART - that the IRQ line remains
> high upon exit, which would cause the 8259 not to issue the CPU IRQ for that
> line anymore ?
Yep.
>
> The proposed solution is therefore to traverse the entire list of
> UARTs connected to that IRQ line and make sure none of them was interrupting
> in two consecutive passes (by checking their status registers). That would
> mean the IRQ line must be deasserted and the 8259 will properly detect any
> newly arriving interrupts, since the 8259 has been acknowledged before
> handling the interrupt.
Yep.
>
> 1. Wouldn't it be more efficient to make this a compile-time option, instead
> of burdening the nucleus with it ?
You need this feature per-IRQ as there will always be also usual
level-triggered IRQs on your system. What Dmitry is now heading for is a
runtime selection of the fitting IRQ trampoline at nucleus level.
> 2. Would it be an option, in the embedded boards Jan is speaking of, to put
> the 8259 in level sensitive mode ? Some of the boards I know don't actually
> have this selection logic for the built-in interrupt sources such as the
> timer and the IDE I/F and it therefore only applies to the ISA bus.
Might be an option, but I'm not THAT deep into it to asses all possible
pitfalls of such an approach. Has anyone ever tried this in reality?
> 3. Beware of UARTs that cause interrupts and have a problem that causes them
> to spuriously return 'all green' upon reading of the IIR register. I have
> dealt with an integrated ('Super I/O') card with that problem before. The
> only solution was to look at LSR and check THRE as well, even when no TX
> interrupt was seemingly present. Must be a logic race.
Yes, there is always the risk of running onto such hardware. Luckily, we
haven't "found" any of it on our systems so far (once you picked
reasonable hardware, you should stay with it - just like we do :) ).
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Shared irqs v.6
> I mean that the support of shared interrupts for ISA boards (edge-triggered> stuff) is a kind of emulation to overcome the shortcommings of the initial
> design on the hardware level. The hardware was just not supposed to support> shared interrupt channels. So, let's keep it a bit aside from another code> :o)Unfortunately, this crappy hardware is still quite common in the
embedded domain.
If I've understood correctly, the only reason for having this support is to avoid - after discovering an interrupting UART - that the IRQ line remains high upon exit, which would cause the 8259 not to issue the CPU IRQ for that line anymore ?
The proposed solution is therefore to traverse the entire list of UARTs connected to that IRQ line and make sure none of them was interrupting in two consecutive passes (by checking their status registers). That would mean the IRQ line must be deasserted and the 8259 will properly detect any newly arriving interrupts, since the 8259 has been acknowledged before handling the interrupt.
1. Wouldn't it be more efficient to make this a compile-time option, instead of burdening the nucleus with it ?
2. Would it be an option, in the embedded boards Jan is speaking of, to put the 8259 in level sensitive mode ? Some of the boards I know don't actually have this selection logic for the built-in interrupt sources such as the timer and the IDE I/F and it therefore only applies to the ISA bus.
3. Beware of UARTs that cause interrupts and have a problem that causes them to spuriously return 'all green' upon reading of the IIR register. I have dealt with an integrated ('Super I/O') card with that problem before. The only solution was to look at LSR and check THRE as well, even when no TX interrupt was seemingly present. Must be a logic race.
Jeroen.
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Anders Blomdell wrote: Jan Kiszka wrote: Anders Blomdell wrote: While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. My impression as well, but it's nowhere documented, nor enforced in the code. In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? Yes. desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. If the non-RT driver sets that bit in its ISR routine, yes. I have the (overly optimistic?) view that the non-RT ISR only does whatever is necessary to clear the interrupt and leaves the enable/disable bits untouched. Or perhaps the whole conceptis of no interest to others, and I should put this arbitration in the platform specific part (arch/ppc/platform/prpmc800.c) and consider the harrier chip as a cascaded interrupt controller, and handle it as such? -- Anders Blomdell ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Jan Kiszka wrote: Anders Blomdell wrote: While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. My impression as well, but it's nowhere documented, nor enforced in the code. In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? Yes. desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. If the non-RT driver sets that bit in its ISR routine, yes. I have the (overly optimistic?) view that the non-RT ISR only does whatever is necessary to clear the interrupt and leaves the enable/disable bits untouched. Meanwhile I recalled that my hack to realise IRQ sharing between a RT device and a non-RT eepro100 is filed on a public archive: https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html Thanks, I'll take a look at it. -- Anders Blomdell ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
Anders Blomdell wrote: > While looking into how to implement sharing of interrupts between > realtime and non-realtime domains (and applying Wolfgang Grandegger's > patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], > which is necessary to make XN_ISR_ENABLE work at all on the PowerPC > platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE > are mutually exclusive, since if both are set, desc->handler->end will > be called twice: > > 1. When the realtime isr handler returns > 2. When the Linux domain calls it in __do_IRQ Yes, those bits are semantically exclusive. Actually, I think passing both bits could even cause deadlocks if the RT-IRQ is raised again before the non-RT handler got a chance to clear the IRQ source in hardware. > > In the solution I have in mind at the moment, I will: > > 1. Add an extra iend handler argument to xnintr_init > 2. If XN_ISR_ENABLE is returned from the isr handler, > replace desc->handler->end with the user supplied > iend handler. > > Hereby I hope to be able to handle interrupts shared between realtime > and non-realtime domain, without having the realtime domain wait for all > non-realtime interrupts to finish. This is the scenario I'm thinking of: > > 1. A non-RT interrupt occurs > 2. The (RT) isr handler detects the non-RT interrupt, > disables further non-RT interrupts on that irq-vector, replaces This remains vague to me. How precisely will you disable? I guess at hardware level, i.e. in a (non-RT) device-specific way: switch off the bit in some hardware register that says "this device can produce IRQs", right? > desc->handler->end with the user supplied iend handler, > returns XN_ISR_CHAINED | XN_ISR_ENABLE. > 3. RT interrupts are serviced by the (RT) isr handler, > returns XN_ISR_ENABLE > 4. The Linux domain get a chance to run the chained interrupt, > and eventually calls desc->handler->end (supplied iend handler) > 5. The iend handler reenables non-RT interrupts. Then this would switch on that bit again? Note that this may require to synchronise the hardware access with parts of the non-RT driver. Meanwhile I recalled that my hack to realise IRQ sharing between a RT device and a non-RT eepro100 is filed on a public archive: https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html > > Comments on the above are most welcome! > Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?
While looking into how to implement sharing of interrupts between realtime and non-realtime domains (and applying Wolfgang Grandegger's patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html], which is necessary to make XN_ISR_ENABLE work at all on the PowerPC platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE are mutually exclusive, since if both are set, desc->handler->end will be called twice: 1. When the realtime isr handler returns 2. When the Linux domain calls it in __do_IRQ In the solution I have in mind at the moment, I will: 1. Add an extra iend handler argument to xnintr_init 2. If XN_ISR_ENABLE is returned from the isr handler, replace desc->handler->end with the user supplied iend handler. Hereby I hope to be able to handle interrupts shared between realtime and non-realtime domain, without having the realtime domain wait for all non-realtime interrupts to finish. This is the scenario I'm thinking of: 1. A non-RT interrupt occurs 2. The (RT) isr handler detects the non-RT interrupt, disables further non-RT interrupts on that irq-vector, replaces desc->handler->end with the user supplied iend handler, returns XN_ISR_CHAINED | XN_ISR_ENABLE. 3. RT interrupts are serviced by the (RT) isr handler, returns XN_ISR_ENABLE 4. The Linux domain get a chance to run the chained interrupt, and eventually calls desc->handler->end (supplied iend handler) 5. The iend handler reenables non-RT interrupts. Comments on the above are most welcome! -- Anders Blomdell ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jeroen Van den Keybus wrote: >> Revision 466 contains the mutex-info fix, but that is post -rc2. Why not >> switching to SVN head? > > > Philippe asked to apply the patch against Xenomai 2.1-rc2. Can I safely > patch it against the SVN tree ? After that, what will 'svn up' do to the > patched tree ? The CONFIG_PREEMPT fix is already contained in the latest SVN revision, no need to patch anymore. When unsure if a patch will cleanly apply, try "patch --dry-run" first. (Virtually) rejected hunks can then be used to asses if the patch fits - without messing up the code base immediately. > > Remember I'm quite new to Linux. Actually, I spent half an hour finding out > how that patch stuff (especially the -p option) works. > :) (it's no problem to ask even these kind of "stupid" questions to the list or us directly - no one will bite you!) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Gilles Chanteperdrix wrote:
> This is not the only situation where a thread with a nucleus suspension
> bit need to run shortly in secondary mode: it also occurs when
> suspending with xnpod_suspend_thread() a thread running in secondary
> mode; the thread receives the SIGCHLD signal and need to execute shortly
> with the suspension bit set in order to cause a migration to primary
> mode.
>
> So, the only case when we are sure that a user-space thread can not be
> scheduled by Linux seems to be when this thread does not have the
> XNRELAX bit.
From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed
patch.
--
Gilles Chanteperdrix.
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 507)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
- xnflags_t status = threadin->status & ~XNRELAX;
+ xnflags_t status = threadin->status;
int sigpending = signal_pending(next);
-if (!(next->ptrace & PT_PTRACED) &&
+if (!testbits(status, XNRELAX))
+{
+show_stack(xnthread_user_task(threadin),NULL);
+xnpod_fatal("Hardened thread %s[%d] running in Linux domain?!
(status=0x%lx, sig=%d, prev=%s[%d])",
+ threadin->name,
+ next->pid,
+ status,
+ sigpending,
+ prev->comm,
+ prev->pid);
+ }
+else if (!(next->ptrace & PT_PTRACED) &&
/* Allow ptraced threads to run shortly in order to
properly recover from a stopped state. */
testbits(status,XNSTARTED) &&
- testbits(status,XNTHREAD_BLOCK_BITS))
+ testbits(status,XNPEND))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx,
sig=%d, prev=%s[%d])",
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head? Philippe asked to apply the patch against Xenomai 2.1-rc2. Can I safely patch it against the SVN tree ? After that, what will 'svn up' do to the patched tree ? Remember I'm quite new to Linux. Actually, I spent half an hour finding out how that patch stuff (especially the -p option) works. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jeroen Van den Keybus wrote: >>> I've installed both patches and the problem seems to have disappeared. >>> I'll try it on another machine tomorrow, too. Meanwhile: thanks very >>> much for the assistance ! > > > While testing more thoroughly, my triggers for zero mutex values after > acquiring the lock are going off again. I was using the SVN xenomai > development tree, but I've now switched to the (fixed) 2.1-rc2 in order to > apply the patches. Is Jan's bugfix included in that one ? Revision 466 contains the mutex-info fix, but that is post -rc2. Why not switching to SVN head? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
> I've installed both patches and the problem seems to have disappeared.> I'll try it on another machine tomorrow, too. Meanwhile: thanks very > much for the assistance ! While testing more thoroughly, my triggers for zero mutex values after acquiring the lock are going off again. I was using the SVN xenomai development tree, but I've now switched to the (fixed) 2.1-rc2 in order to apply the patches. Is Jan's bugfix included in that one ? Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] version mismatch
in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch: #define IPIPE_ARCH_STRING"1.1-02" shouldn't this be #define IPIPE_ARCH_STRING"1.2-00" -- Anders Blomdell ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Jeroen Van den Keybus wrote:
>>> I mean that the support of shared interrupts for ISA boards
>> (edge-triggered
>>> stuff) is a kind of emulation to overcome the shortcommings of the
>> initial
>>> design on the hardware level. The hardware was just not supposed to
>> support
>>> shared interrupt channels. So, let's keep it a bit aside from another
>> code
>>> :o)
>> Unfortunately, this crappy hardware is still quite common in the
>> embedded domain.
>
>
> If I've understood correctly, the only reason for having this support is to
> avoid - after discovering an interrupting UART - that the IRQ line remains
> high upon exit, which would cause the 8259 not to issue the CPU IRQ for that
> line anymore ?
Yep.
>
> The proposed solution is therefore to traverse the entire list of
> UARTs connected to that IRQ line and make sure none of them was interrupting
> in two consecutive passes (by checking their status registers). That would
> mean the IRQ line must be deasserted and the 8259 will properly detect any
> newly arriving interrupts, since the 8259 has been acknowledged before
> handling the interrupt.
Yep.
>
> 1. Wouldn't it be more efficient to make this a compile-time option, instead
> of burdening the nucleus with it ?
You need this feature per-IRQ as there will always be also usual
level-triggered IRQs on your system. What Dmitry is now heading for is a
runtime selection of the fitting IRQ trampoline at nucleus level.
> 2. Would it be an option, in the embedded boards Jan is speaking of, to put
> the 8259 in level sensitive mode ? Some of the boards I know don't actually
> have this selection logic for the built-in interrupt sources such as the
> timer and the IDE I/F and it therefore only applies to the ISA bus.
Might be an option, but I'm not THAT deep into it to asses all possible
pitfalls of such an approach. Has anyone ever tried this in reality?
> 3. Beware of UARTs that cause interrupts and have a problem that causes them
> to spuriously return 'all green' upon reading of the IIR register. I have
> dealt with an integrated ('Super I/O') card with that problem before. The
> only solution was to look at LSR and check THRE as well, even when no TX
> interrupt was seemingly present. Must be a logic race.
Yes, there is always the risk of running onto such hardware. Luckily, we
haven't "found" any of it on our systems so far (once you picked
reasonable hardware, you should stay with it - just like we do :) ).
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
> I mean that the support of shared interrupts for ISA boards (edge-triggered> stuff) is a kind of emulation to overcome the shortcommings of the initial
> design on the hardware level. The hardware was just not supposed to support> shared interrupt channels. So, let's keep it a bit aside from another code> :o)Unfortunately, this crappy hardware is still quite common in the
embedded domain.
If I've understood correctly, the only reason for having this support is to avoid - after discovering an interrupting UART - that the IRQ line remains high upon exit, which would cause the 8259 not to issue the CPU IRQ for that line anymore ?
The proposed solution is therefore to traverse the entire list of UARTs connected to that IRQ line and make sure none of them was interrupting in two consecutive passes (by checking their status registers). That would mean the IRQ line must be deasserted and the 8259 will properly detect any newly arriving interrupts, since the 8259 has been acknowledged before handling the interrupt.
1. Wouldn't it be more efficient to make this a compile-time option, instead of burdening the nucleus with it ?
2. Would it be an option, in the embedded boards Jan is speaking of, to put the 8259 in level sensitive mode ? Some of the boards I know don't actually have this selection logic for the built-in interrupt sources such as the timer and the IDE I/F and it therefore only applies to the ISA bus.
3. Beware of UARTs that cause interrupts and have a problem that causes them to spuriously return 'all green' upon reading of the IIR register. I have dealt with an integrated ('Super I/O') card with that problem before. The only solution was to look at LSR and check THRE as well, even when no TX interrupt was seemingly present. Must be a logic race.
Jeroen.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
