Re: [Xenomai-core] Error propagating ISR to Linux domain
On Wed, Jul 30, 2008 at 10:31 AM, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote: > ... you loose the RT response, as was (correctly) said in my first answer. You are right, of course. It was my error not to mention this in the original post. For me this is just the solution to avoid the infinte loop when irqs are shared. Until now it was always possible to avoid shared irqs (between RT and non-RT) by changing the position of the PCI card. Ulrich ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error propagating ISR to Linux domain
On Tue, Jul 29, 2008 at 4:20 PM, Gilles Chanteperdrix
<[EMAIL PROTECTED]> wrote:
> Gilles Chanteperdrix wrote:
>> Ulrich Schwab wrote:
>>> why not checking for irq origin like this:
>>> int my_isr_handler (xnintr_t *irq)
>>> {
>>> if ( ! test_my_card_for_irq_origin )
>>> return XN_ISR_NONE | XN_ISR_PROPAGATE;
>>> ... /* handling */
>>> return XN_ISR_HANDLED;
>>> }
>>>
>>> this way XN_ISR_PROPAGATE is never returned in the not-shared case.
>>
>> I think this idea needs an answer; the answer is no: it will not work.
>> Because the IRQ will remain masked until Linux handles it, which
>> basically means that the RT irq will wait for non-RT activity, you loose
>> real-time response.
>
> It will not work, but not for the reason I mention: Adeos WILL re-enable
> the IRQ at interrupt controller level after the end of this handler,
> however, since the interrupt was not cleared on the peripheral side, the
> peripheral will reassert the interrupt when the interrupt is unmasked at
> interrupt controller level, so the CPU will enter an infinite loop
> invoking the ISR.
>
> --
> Gilles.
>
Are You sure?
IIRC the infinte loop You describe occurs when XN_ISR_PROPAGATE is
removed from the code above.
Ulrich
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error propagating ISR to Linux domain
why not checking for irq origin like this:
int my_isr_handler (xnintr_t *irq)
{
if ( ! test_my_card_for_irq_origin )
return XN_ISR_NONE | XN_ISR_PROPAGATE;
... /* handling */
return XN_ISR_HANDLED;
}
this way XN_ISR_PROPAGATE is never returned in the not-shared case.
On Wed, Jul 16, 2008 at 6:03 PM, Benjamin ZORES
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've encountered a little problem when trying to propagate an ISR from
> Xenomai to Linux context.
>
> To sum up clearly, I'm writing an RT kernel module that drives a PCI card.
> I've registered a nucleus ISR handler on the IRQ attributed to this card.
>
> On some systems, this IRQ is dedicated to this PCI card only.
> Though, on others, it is shared with other peripherals.
> Hence, I need to forward/propagate this IRQ to Linux domain for other
> drivers to handle it
> when the IRQ has not been initiated by my PCI card.
>
> My RT ISR code looks like the following:
>
> int my_isr_handler (xnintr_t *irq)
> {
>... /* handling */
> return XN_ISR_HANDLED | XN_ISR_PROPAGATE;
> }
>
> While this code works perfectly when the IRQ number is really shared
> among peripherals,
> when I use it on system where this IRQ is dedicated to RT only (i.e. not
> used by Linux),
> then, the IRQ is never acknowledged.
>
> In other words, I see a bug when returning XN_ISR_PROPAGATE on a system
> where
> no Linux driver has registered a handler for this IRQ.
> Is this something known and is there some workaround (I'm using 2.6.23 +
> lastest Adeos + Xenomai 2.4.4 on x86_32) ???
>
> A quick and dirty workaround is to create a dummy Linux IRQ handler
> (doing so acknowledge my propagated IRQ) but:
> - if it returns IRQ_NONE, then Linux discard the IRQ line after having
> missed 10 of them (on system where the IRQ is dedicated)
> - if it returns IRQ_HANDLED, then I have no guarantee that this dumym
> handler won't get called before the legacy drivers that need it.
>
> Or maybe there is a way in Xenomai to know that any subdomain (like
> Linux) has registered a handler for this given IRQ ??
>
> Any help would be appreciated,
>
> Ben
>
> ___
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core
>
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] SMI update
On Thursday 10 August 2006 10:27, Jan Kiszka wrote:
> Ulrich Schwab wrote:
> > On Thursday 10 August 2006 00:44, Jan Kiszka wrote:
> >> Thanks for the patch, we just need some additional define of
> >> PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you
> >> additionally provide a ChangeLog fragment, your patch would be perfect!
> >> (I tend to forget the last part often too... :) )
> >
> > Where to add the new define for kernel 2.4 ?
>
> I would say to smi.c directly as there are no other users in sight.
> Otherwise, wrapping code goes to include/asm-{generic|}/wrapper.h.
I did add the new Id to smi.c directly now.
Ulrich
--
inmess GmbH
Frankfurter Str. 74
D - 64521 Gross-Gerau
Phone: +49 6152 97790
Fax : +49 6152 977920
mail : [EMAIL PROTECTED]
web: www.inmess.de
diff -urp xenomai-2.2.0-org/ChangeLog xenomai-2.2.0-patched/ChangeLog
--- xenomai-2.2.0-org/ChangeLog 2006-07-17 18:50:17.0 +0200
+++ xenomai-2.2.0-patched/ChangeLog 2006-08-10 14:51:28.0 +0200
@@ -1,3 +1,7 @@
+2006-08-10 Ulrich Schwab <[EMAIL PROTECTED]>
+
+ * ksrc/arch/i386/smi.c added id of Intel ICH7 to list of SMI chipsets
+
2006-07-17 Philippe Gerum <[EMAIL PROTECTED]>
* RELEASE: Xenomai 2.2 (Engines Of Creation)
diff -urp xenomai-2.2.0-org/ksrc/arch/i386/smi.c xenomai-2.2.0-patched/ksrc/arch/i386/smi.c
--- xenomai-2.2.0-org/ksrc/arch/i386/smi.c 2006-07-03 08:44:33.0 +0200
+++ xenomai-2.2.0-patched/ksrc/arch/i386/smi.c 2006-08-10 14:50:37.0 +0200
@@ -31,6 +31,13 @@
#include
#include
+/* DEVICE_IDs needed for 2.4 support */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
+#ifndef PCI_DEVICE_ID_INTEL_ICH7_0
+#define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8
+#endif
+#endif
+
static struct pci_device_id rthal_smi_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0) },
@@ -45,6 +52,7 @@ static struct pci_device_id rthal_smi_pc
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2) },
+{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0) },
{ 0, },
};
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] SMI update
On Thursday 10 August 2006 00:44, Jan Kiszka wrote: > Thanks for the patch, we just need some additional define of > PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you > additionally provide a ChangeLog fragment, your patch would be perfect! > (I tend to forget the last part often too... :) ) Where to add the new define for kernel 2.4 ? Ulrich -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] SMI update
I saw some bad latency behaviour on a new system, it is a
P4 with ICH7 chipset. It showed more than 300 us max. latency without any
load.
This chipset was not detected as SMI generating and SMI disable was not done.
Finally I figured out where to add this DEVICE_ID
to the SMI detection in smi.c
It is done in the attached patch.
Now, the max. latency values on this new system are below 10 us.
Although, not tested very long.
Regards,
Ulrich Schwab
--
inmess GmbH
Frankfurter Str. 74
D - 64521 Gross-Gerau
Phone: +49 6152 97790
Fax : +49 6152 977920
mail : [EMAIL PROTECTED]
web: www.inmess.de
diff -urp xenomai-2.2.0/ksrc/arch/i386/smi.c xenomai-2.2-patched/ksrc/arch/i386/smi.c
--- xenomai-2.2.0/ksrc/arch/i386/smi.c 2006-07-03 08:44:33.0 +0200
+++ xenomai-2.2-patched/ksrc/arch/i386/smi.c 2006-08-09 18:20:57.0 +0200
@@ -45,6 +45,7 @@ static struct pci_device_id rthal_smi_pc
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2) },
+{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0) },
{ 0, },
};
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
On Wednesday 09 August 2006 13:42, Dmitry Adamushko wrote:
> So could anyone test this patch and let me know if it works?
>
> Note : I haven't compiled it even as I don't have a proper environment. But
> the changes are pretty simple so it should be ok.
I just did run the test program supplied by Vincent after applying Your patch
(against 2.2.0)
It did work !
Only one small typo was in the patch, it is fixed in the attached patch
version.
>
> There was actually yet another problem mmm... who cares to delete a sender
> from the msendq?
>
> Now should be ok or maybe I'm completely wrong and see the things which do
> not exist at all :)
>
> p.s. I cc'ed "xenomai-core" as it may involve further discussions and it's
> the right place indeed.
--
inmess GmbH
Frankfurter Str. 74
D - 64521 Gross-Gerau
Phone: +49 6152 97790
Fax : +49 6152 977920
mail : [EMAIL PROTECTED]
web: www.inmess.de
diff -urp xenomai-a/include/nucleus/synch.h xenomai-b/include/nucleus/synch.h
--- xenomai-a/include/nucleus/synch.h 2006-07-20 11:09:01.0 +0200
+++ xenomai-b/include/nucleus/synch.h 2006-08-09 12:53:37.044217000 +0200
@@ -28,6 +28,7 @@
#define XNSYNCH_NOPIP 0x0
#define XNSYNCH_PIP 0x2
#define XNSYNCH_DREORD 0x4
+#define XNSYNCH_FOWNER 0x20 /* Fixed owner */
#if defined(__KERNEL__) || defined(__XENO_SIM__)
diff -urp xenomai-a/ksrc/nucleus/synch.c xenomai-b/ksrc/nucleus/synch.c
--- xenomai-a/ksrc/nucleus/synch.c 2006-06-15 14:15:25.0 +0200
+++ xenomai-b/ksrc/nucleus/synch.c 2006-08-09 13:28:55.199081000 +0200
@@ -37,6 +37,14 @@
#include
#include
+/* temporarily here */
+static inline void xnsynch_set_owner_internal(xnsynch_t *synch, xnthread_t *thread)
+{
+ if (!testbits(synch->status, XNSYNCH_FOWNER))
+ synch->owner = thread;
+}
+
+
/*!
* \fn void xnsynch_init(xnsynch_t *synch, xnflags_t flags);
* \brief Initialize a synchronization object.
@@ -181,7 +189,7 @@ void xnsynch_sleep_on(xnsynch_t *synch,
if (testbits(synch->status, XNSYNCH_PENDING)) {
/* Ownership is still pending, steal the resource. */
- synch->owner = thread;
+ xnsynch_set_owner_internal(synch, thread);
__clrbits(thread->status,
XNRMID | XNTIMEO | XNBREAK);
goto grab_ownership;
@@ -209,7 +217,7 @@ void xnsynch_sleep_on(xnsynch_t *synch,
xnpod_suspend_thread(thread, XNPEND, timeout, synch);
- if (unlikely(synch->owner != thread)) {
+ if (!testbits(synch->status, XNSYNCH_FOWNER) && unlikely(synch->owner != thread)) {
/* Somebody stole us the ownership while we were ready to
run, waiting for the CPU: we need to wait again for the
resource. */
@@ -362,12 +370,12 @@ xnthread_t *xnsynch_wakeup_one_sleeper(x
if (holder) {
thread = link2thread(holder, plink);
thread->wchan = NULL;
- synch->owner = thread;
+ xnsynch_set_owner_internal(synch, thread);
__setbits(synch->status, XNSYNCH_PENDING);
xnltt_log_event(xeno_ev_wakeup1, thread->name, synch);
xnpod_resume_thread(thread, XNPEND);
} else {
- synch->owner = NULL;
+ xnsynch_set_owner_internal(synch, thread);
__clrbits(synch->status, XNSYNCH_PENDING);
}
@@ -435,7 +443,7 @@ xnpholder_t *xnsynch_wakeup_this_sleeper
nholder = poppq(&synch->pendq, holder);
thread = link2thread(holder, plink);
thread->wchan = NULL;
- synch->owner = thread;
+ xnsynch_set_owner_internal(synch, thread);
__setbits(synch->status, XNSYNCH_PENDING);
xnltt_log_event(xeno_ev_wakeupx, thread->name, synch);
xnpod_resume_thread(thread, XNPEND);
@@ -523,7 +531,7 @@ int xnsynch_flush(xnsynch_t *synch, xnfl
status = XNSYNCH_RESCHED;
}
- synch->owner = NULL;
+ xnsynch_set_owner_internal(synch, NULL);
__clrbits(synch->status, XNSYNCH_PENDING);
xnlock_put_irqrestore(&nklock, s);
diff -urp xenomai-a/ksrc/skins/native/task.c xenomai-b/ksrc/skins/native/task.c
--- xenomai-a/ksrc/skins/native/task.c 2006-07-30 10:50:49.0 +0200
+++ xenomai-b/ksrc/skins/native/task.c 2006-08-09 13:32:21.91777 +0200
@@ -262,7 +262,7 @@ int rt_task_create(RT_TASK *task,
#ifdef CONFIG_XENO_OPT_NATIVE_MPS
xnsynch_init(&task->mrecv, XNSYNCH_FIFO);
- xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP);
+ xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP | XNSYNCH_FOWNER);
xnsynch_set_owner(&task->msendq, &task->thread_base);
task->flowgen = 0;
#endif /* CONFIG_XENO_OPT_NATIVE_MPS */
@@ -2057,10 +2057,7 @@ int rt_task_reply(int flowid, RT_TASK_MC
identifier from other senders wrt to a given receiver. */
if (receiver->wait_args.mps.mcb_s.flowid == flowid) {
- /* Note that the following will cause the receiver to be
- unblocked without transferring the ownership of the
- msendq object, since we want the sender to keep it. */
- xnpod_resume_thread(&receiver->thread_base, XNPEND);
+ xnsynch_wakeup_this_sleeper(&sender->msendq, holder);
break;
[Xenomai-core] rt_task_receive DOKU
Hello, here is a patch, making the doku of rt_task_receive() more complete. diff -Nru xenomai-2.0-orig/skins/native/task.c xenomai-2.0-devel/skins/native/task.c --- xenomai-2.0-orig/skins/native/task.c2005-10-08 16:26:07.0 +0200 +++ xenomai-2.0-devel/skins/native/task.c 2005-11-08 11:00:27.0 +0100 @@ -1788,6 +1788,8 @@ * and no remote task is currently waiting for sending a message to * the caller. * + * - -ETIMEDOUT is returned if no message was received within the @a timeout. + * * - -EINTR is returned if rt_task_unblock() has been called for the * caller before any message was available. * -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de
[Xenomai-core] rt_task_receive DOKU
Hello, here is a patch, making the doku of rt_task_receive() more complete. diff -Nru xenomai-2.0-orig/skins/native/task.c xenomai-2.0-devel/skins/native/task.c --- xenomai-2.0-orig/skins/native/task.c2005-10-08 16:26:07.0 +0200 +++ xenomai-2.0-devel/skins/native/task.c 2005-11-08 11:00:27.0 +0100 @@ -1788,6 +1788,8 @@ * and no remote task is currently waiting for sending a message to * the caller. * + * - -ETIMEDOUT is returned if no message was received within the @a timeout. + * * - -EINTR is returned if rt_task_unblock() has been called for the * caller before any message was available. * -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
