From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: "xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Potential problem with rt_eepro100
Date: Wed, 03 Nov 2010 23:03:07 +0100 [thread overview]
Message-ID: <4CD1DC1B.8060407@domain.hid> (raw)
In-Reply-To: <1288816871.1842.84.camel@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 4784 bytes --]
Am 03.11.2010 21:41, Philippe Gerum wrote:
> On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
>> Jan Kiszka wrote:
>>> Am 03.11.2010 17:46, Anders Blomdell wrote:
>>>> Anders Blomdell wrote:
>>>>> Anders Blomdell wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> additional barrier. Can you check this?
>>>>>>>
>>>>>>> diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
>>>>>>> index df56417..66b52ad 100644
>>>>>>> --- a/include/nucleus/sched.h
>>>>>>> +++ b/include/nucleus/sched.h
>>>>>>> @@ -187,6 +187,7 @@ static inline int xnsched_self_resched_p(struct
>>>>>>> xnsched *sched)
>>>>>>> if (current_sched != (__sched__)) { \
>>>>>>> xnarch_cpu_set(xnsched_cpu(__sched__),
>>>>>>> current_sched->resched); \
>>>>>>> setbits((__sched__)->status, XNRESCHED); \
>>>>>>> + xnarch_memory_barrier(); \
>>>>>>> } \
>>>>>>> } while (0)
>>>>>> In progress, if nothing breaks before, I'll report status tomorrow
>>>>>> morning.
>>>>> It still breaks (in approximately the same way). I'm currently putting a
>>>>> barrier in the other macro doing a RESCHED, also adding some tracing to
>>>>> see if a read barrier is needed.
>>>> Nope, no luck there either. Will start interesting tracepoint
>>>> adding/conversion :-(
>>>
>>> Strange. But it was too easy anyway...
>>>
>>>> Any reason why xn_nucleus_sched_remote should ever report status = 0?
>>>
>>> Really don't know yet. You could trigger on this state and call
>>> ftrace_stop() then. Provided you had the functions tracer enabled, that
>>> should give a nice pictures of what happened before.
>>
>> Isn't there a race betweeen these two (still waiting for compilation to
>> be finished)?
>
> We always hold the nklock in both contexts.
>
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix the race:
diff --git a/ksrc/nucleus/intr.c b/ksrc/nucleus/intr.c
index d7a772f..af8ebeb 100644
--- a/ksrc/nucleus/intr.c
+++ b/ksrc/nucleus/intr.c
@@ -85,7 +85,7 @@ static void xnintr_irq_handler(unsigned irq, void *cookie);
void xnintr_host_tick(struct xnsched *sched) /* Interrupts off. */
{
- __clrbits(sched->status, XNHTICK);
+ clrbits(sched->status, XNHTICK);
xnarch_relay_tick();
}
@@ -105,11 +105,13 @@ void xnintr_clock_handler(void)
trace_mark(xn_nucleus, irq_enter, "irq %u", XNARCH_TIMER_IRQ);
trace_mark(xn_nucleus, tbase_tick, "base %s", nktbase.name);
+ xnlock_get(&nklock);
+
++sched->inesting;
__setbits(sched->status, XNINIRQ);
- xnlock_get(&nklock);
xntimer_tick_aperiodic();
+
xnlock_put(&nklock);
xnstat_counter_inc(&nkclock.stat[xnsched_cpu(sched)].hits);
@@ -117,7 +119,7 @@ void xnintr_clock_handler(void)
&nkclock.stat[xnsched_cpu(sched)].account, start);
if (--sched->inesting == 0) {
- __clrbits(sched->status, XNINIRQ);
+ clrbits(sched->status, XNINIRQ);
xnpod_schedule();
}
/*
@@ -178,7 +180,7 @@ static void xnintr_shirq_handler(unsigned irq, void *cookie)
trace_mark(xn_nucleus, irq_enter, "irq %u", irq);
++sched->inesting;
- __setbits(sched->status, XNINIRQ);
+ setbits(sched->status, XNINIRQ);
xnlock_get(&shirq->lock);
intr = shirq->handlers;
@@ -220,7 +222,7 @@ static void xnintr_shirq_handler(unsigned irq, void *cookie)
xnarch_end_irq(irq);
if (--sched->inesting == 0) {
- __clrbits(sched->status, XNINIRQ);
+ clrbits(sched->status, XNINIRQ);
xnpod_schedule();
}
@@ -247,7 +249,7 @@ static void xnintr_edge_shirq_handler(unsigned irq, void *cookie)
trace_mark(xn_nucleus, irq_enter, "irq %u", irq);
++sched->inesting;
- __setbits(sched->status, XNINIRQ);
+ setbits(sched->status, XNINIRQ);
xnlock_get(&shirq->lock);
intr = shirq->handlers;
@@ -303,7 +305,7 @@ static void xnintr_edge_shirq_handler(unsigned irq, void *cookie)
xnarch_end_irq(irq);
if (--sched->inesting == 0) {
- __clrbits(sched->status, XNINIRQ);
+ clrbits(sched->status, XNINIRQ);
xnpod_schedule();
}
trace_mark(xn_nucleus, irq_exit, "irq %u", irq);
@@ -446,7 +448,7 @@ static void xnintr_irq_handler(unsigned irq, void *cookie)
trace_mark(xn_nucleus, irq_enter, "irq %u", irq);
++sched->inesting;
- __setbits(sched->status, XNINIRQ);
+ setbits(sched->status, XNINIRQ);
xnlock_get(&xnirqs[irq].lock);
@@ -493,7 +495,7 @@ static void xnintr_irq_handler(unsigned irq, void *cookie)
xnarch_end_irq(irq);
if (--sched->inesting == 0) {
- __clrbits(sched->status, XNINIRQ);
+ clrbits(sched->status, XNINIRQ);
xnpod_schedule();
}
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2010-11-03 22:03 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4CC82C8D.3080808@domain.hid>
[not found] ` <4CC84327.9070202@domain.hid>
2010-10-28 7:34 ` [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100 Anders Blomdell
2010-10-28 7:40 ` Jan Kiszka
2010-10-28 9:34 ` Anders Blomdell
2010-10-28 10:18 ` Jan Kiszka
2010-10-28 13:02 ` [Xenomai-core] " Anders Blomdell
2010-10-28 15:05 ` Anders Blomdell
2010-10-28 15:09 ` Jan Kiszka
2010-10-28 15:18 ` Anders Blomdell
2010-10-28 15:34 ` Jan Kiszka
2010-10-29 17:42 ` Anders Blomdell
2010-10-29 18:06 ` Jan Kiszka
2010-10-29 19:29 ` Anders Blomdell
2010-11-01 16:55 ` Anders Blomdell
2010-11-03 8:17 ` Jan Kiszka
2010-11-03 10:33 ` Anders Blomdell
2010-11-03 11:44 ` Anders Blomdell
2010-11-03 11:50 ` Jan Kiszka
2010-11-03 11:55 ` Jan Kiszka
2010-11-03 12:07 ` Anders Blomdell
2010-11-03 12:17 ` Jan Kiszka
2010-11-03 13:40 ` Anders Blomdell
2010-11-03 16:02 ` Anders Blomdell
2010-11-03 16:46 ` Anders Blomdell
2010-11-03 16:53 ` Jan Kiszka
2010-11-03 19:38 ` Anders Blomdell
2010-11-03 20:41 ` Philippe Gerum
2010-11-03 22:03 ` Jan Kiszka [this message]
2010-11-03 22:11 ` Jan Kiszka
2010-11-03 22:56 ` Jan Kiszka
2010-11-03 23:11 ` Gilles Chanteperdrix
2010-11-03 23:15 ` Jan Kiszka
2010-11-03 23:18 ` Gilles Chanteperdrix
2010-11-03 23:41 ` Jan Kiszka
2010-11-03 23:44 ` Gilles Chanteperdrix
2010-11-03 23:49 ` Jan Kiszka
2010-11-03 23:56 ` Gilles Chanteperdrix
2010-11-04 0:06 ` Jan Kiszka
2010-11-04 0:13 ` Gilles Chanteperdrix
2010-11-04 7:30 ` Jan Kiszka
2010-11-04 8:45 ` Anders Blomdell
2010-11-04 9:10 ` Jan Kiszka
2010-11-04 9:17 ` Gilles Chanteperdrix
2010-11-04 9:16 ` Gilles Chanteperdrix
2010-11-04 9:18 ` Gilles Chanteperdrix
2010-11-04 9:26 ` Jan Kiszka
2010-11-04 9:32 ` Jan Kiszka
2010-11-04 10:42 ` Anders Blomdell
2010-11-04 12:39 ` Gilles Chanteperdrix
2010-11-04 13:18 ` Anders Blomdell
2010-11-04 14:37 ` Jan Kiszka
2010-11-04 14:53 ` Anders Blomdell
2010-11-04 15:33 ` Jan Kiszka
2010-11-04 22:08 ` Gilles Chanteperdrix
2010-11-04 23:10 ` Jan Kiszka
2010-11-04 23:25 ` Gilles Chanteperdrix
2010-11-04 23:32 ` Jan Kiszka
2010-11-04 23:46 ` Gilles Chanteperdrix
2010-11-05 0:09 ` Jan Kiszka
2010-11-05 0:11 ` Gilles Chanteperdrix
2010-11-05 1:35 ` Gilles Chanteperdrix
2010-11-05 9:59 ` Anders Blomdell
2010-11-04 22:06 ` Gilles Chanteperdrix
2010-11-04 23:17 ` Jan Kiszka
2010-11-04 23:24 ` Gilles Chanteperdrix
2010-11-04 23:35 ` Jan Kiszka
2010-11-05 1:28 ` Gilles Chanteperdrix
2010-11-05 10:21 ` Anders Blomdell
2010-11-06 0:27 ` Gilles Chanteperdrix
2010-11-06 20:26 ` Anders Blomdell
2010-11-06 20:37 ` Gilles Chanteperdrix
2010-11-06 22:49 ` Philippe Gerum
2010-11-07 1:00 ` Jan Kiszka
2010-11-07 8:31 ` Gilles Chanteperdrix
2010-11-07 9:46 ` Jan Kiszka
2010-11-07 9:57 ` Gilles Chanteperdrix
2010-11-07 10:00 ` Jan Kiszka
2010-11-07 10:03 ` Philippe Gerum
2010-11-07 10:08 ` Jan Kiszka
2010-11-07 10:12 ` Gilles Chanteperdrix
2010-11-07 10:14 ` Jan Kiszka
2010-11-07 10:49 ` Philippe Gerum
2010-11-07 9:46 ` Philippe Gerum
2010-11-11 15:46 ` Gilles Chanteperdrix
2010-11-12 15:36 ` Jan Kiszka
2010-11-13 18:31 ` Gilles Chanteperdrix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD1DC1B.8060407@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.