From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: "xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Potential problem with rt_eepro100
Date: Fri, 05 Nov 2010 00:46:56 +0100 [thread overview]
Message-ID: <4CD345F0.3040509@domain.hid> (raw)
In-Reply-To: <4CD34293.7040802@domain.hid>
Jan Kiszka wrote:
> Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
>>>>> debugging off.
>>>> That is not enough.
>>> It is, I've reviewed the code today.
>> The fallouts I am talking about are:
>> 47dac49c71e89b684203e854d1b0172ecacbc555
>
> Not related.
>
>> 38f2ca83a8e63cc94eaa911ff1c0940c884b5078
>
> An optimization.
>
>> 5e7cfa5c25672e4478a721eadbd6f6c5b4f88a2f
>
> That fall out of that commit is fixed in my series.
>
>>>> This commit was followed by several others to "fix
>>>> the fix". You know how things are, someone proposes a fix, which fixes
>>>> things for him, but it breaks in the other people configurations (one of
>>>> the fallouts was a complete revamp of include/asm-arm/atomic.h for
>>>> instance).
>>>>
>>> I've pushed a series that reverts that commit, then fixes and cleans up
>>> on top of it. Just pushed if you want to take a look. We can find some
>>> alternative debugging mechanism independently (though I'm curious to see
>>> it - it still makes no sense to me).
>> Since the fix is simply a modification to what we have currently. I
>> would prefer if we did not remove it. In fact, I think it would be
>> simpler if we started from what we currently have than reverting past
>> patches.
>
> Look at the series, it goes step by step to an IMHO clean state. We can
> pull out the debugging check removal, though, if you prefer to work on
> top of the existing code.
>From my point of view, Anders looks for something that works, so
following the rules that the minimal set of changes minimize the chances
of introducing new bugs while cleaning, I would go for the minimal set
of changes, such as:
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..8150510 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -165,28 +165,27 @@ struct xnsched_class {
#endif /* CONFIG_SMP */
/* Test all resched flags from the given scheduler mask. */
-static inline int xnsched_resched_p(struct xnsched *sched)
+static inline int xnsched_remote_resched_p(struct xnsched *sched)
{
- return testbits(sched->status, XNRESCHED);
+ return !xnarch_cpus_empty(current_sched->resched);
}
-static inline int xnsched_self_resched_p(struct xnsched *sched)
+static inline int xnsched_resched_p(struct xnsched *sched)
{
return testbits(sched->status, XNRESCHED);
}
/* Set self resched flag for the given scheduler. */
#define xnsched_set_self_resched(__sched__) do { \
- setbits((__sched__)->status, XNRESCHED); \
+ __setbits((__sched__)->status, XNRESCHED); \
} while (0)
/* Set specific resched flag into the local scheduler mask. */
#define xnsched_set_resched(__sched__) do { \
xnsched_t *current_sched = xnpod_current_sched(); \
- setbits(current_sched->status, XNRESCHED); \
+ __setbits(current_sched->status, XNRESCHED); \
if (current_sched != (__sched__)) { \
xnarch_cpu_set(xnsched_cpu(__sched__), current_sched->resched); \
- setbits((__sched__)->status, XNRESCHED); \
} \
} while (0)
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 862838c..4cb707a 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -276,18 +276,16 @@ EXPORT_SYMBOL_GPL(xnpod_fatal_helper);
void xnpod_schedule_handler(void) /* Called with hw interrupts off. */
{
- xnsched_t *sched;
+ xnsched_t *sched = xnpod_current_sched();
trace_mark(xn_nucleus, sched_remote, MARK_NOARGS);
#if defined(CONFIG_SMP) && defined(CONFIG_XENO_OPT_PRIOCPL)
- sched = xnpod_current_sched();
if (testbits(sched->status, XNRPICK)) {
clrbits(sched->status, XNRPICK);
xnshadow_rpi_check();
}
-#else
- (void)sched;
#endif /* CONFIG_SMP && CONFIG_XENO_OPT_PRIOCPL */
+ xnsched_set_self_resched(sched);
xnpod_schedule();
}
@@ -2174,7 +2172,7 @@ static inline int __xnpod_test_resched(struct xnsched *sched)
int resched = testbits(sched->status, XNRESCHED);
#ifdef CONFIG_SMP
/* Send resched IPI to remote CPU(s). */
- if (unlikely(xnsched_resched_p(sched))) {
+ if (unlikely(xnsched_remote_resched_p(sched))) {
xnarch_send_ipi(sched->resched);
xnarch_cpus_clear(sched->resched);
}
diff --git a/ksrc/nucleus/timer.c b/ksrc/nucleus/timer.c
index 1fe3331..a0ac627 100644
--- a/ksrc/nucleus/timer.c
+++ b/ksrc/nucleus/timer.c
@@ -97,7 +97,7 @@ void xntimer_next_local_shot(xnsched_t *sched)
__clrbits(sched->status, XNHDEFER);
timer = aplink2timer(h);
if (unlikely(timer == &sched->htimer)) {
- if (xnsched_self_resched_p(sched) ||
+ if (xnsched_resched_p(sched) ||
!xnthread_test_state(sched->curr, XNROOT)) {
h = xntimerq_it_next(&sched->timerqueue, &it, h);
if (h) {
--
Gilles.
next prev parent reply other threads:[~2010-11-04 23:46 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
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 [this message]
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=4CD345F0.3040509@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=jan.kiszka@domain.hid \
--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.