[Xenomai-core] PATCH: GCC4 build on Xenomai Simulator
Hello list,
Recently, I am building Xenomai Simulator on Ubuntu feisty, and
encounter the following compilation errors:
%
make[1]: Entering directory `/home/jserv/realtime/xenomai/build-sim/vm'
if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../sim/vm -I../include -fno-exceptions -D__XENO_SIM__
-I../../sim/vm/.. -g -MT libmvm_la-thread.lo -MD -MP -MF
.deps/libmvm_la-thread.Tpo -c -o libmvm_la-thread.lo `test -f
'thread.cc' || echo '../../sim/vm/'`thread.cc; \
then mv -f .deps/libmvm_la-thread.Tpo
.deps/libmvm_la-thread.Plo; else rm -f .deps/libmvm_la-thread.Tpo;
exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I../../sim/vm -I../include -fno-exceptions
-D__XENO_SIM__ -I../../sim/vm/.. -g -MT libmvm_la-thread.lo -MD -MP -MF
.deps/libmvm_la-thread.Tpo -c ../../sim/vm/thread.cc -fPIC -DPIC -o
.libs/libmvm_la-thread.o
../../sim/vm/thread.cc: In member function 'virtual void
XenoThread::resume()':
../../sim/vm/thread.cc:66: error: 'int MvmThread::globalTrace' is
private
../../sim/vm/thread.cc:1184: error: within this context
../../sim/vm/thread.cc:66: error: 'int MvmThread::globalTrace' is
private
...
%
$ gcc --version
gcc (GCC) 4.1.2 20070106 (prerelease) (Ubuntu 4.1.1-21ubuntu7)
The patch to fix the above issue is attached. Please take a look at
that. Thanks!
Best Regards,
Jim Huang (jserv)
http://jserv.sayya.org/
Index: sim/vm/thread.cc
===
--- sim/vm/thread.cc(revision 2087)
+++ sim/vm/thread.cc(working copy)
@@ -794,10 +794,12 @@ void MvmThread::bumpInto ()
do_restore(context);
}
+#ifdef CONFIG_XENO_MVM_DEBUG
void MvmThread::setGlobalTrace (int traceLevel) {
globalTrace = traceLevel;
}
+#endif // CONFIG_XENO_MVM_DEBUG
extern int _etext, _edata, _end;
Index: sim/vm/thread.h
===
--- sim/vm/thread.h (revision 2087)
+++ sim/vm/thread.h (working copy)
@@ -120,7 +120,11 @@ private:
virtual void body();
+#ifdef CONFIG_XENO_MVM_DEBUG
+public:
static int globalTrace;
+static void setGlobalTrace(int traceLevel);
+#endif // CONFIG_XENO_MVM_DEBUG
protected:
@@ -138,8 +142,6 @@ public :
static MvmScheduler runChain;
-static void setGlobalTrace(int traceLevel);
-
MvmThread(const char *name,
int pflags =0,
unsigned stackSize =32768);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai Bits on MIPS
somshekar kadam wrote: Hi All, I am porting Xenomai on MIPS, I am beginner o Xenomai, please help me in understanding this point. whats the purpose of bits directory in include directory, please throw some light on this, I see it for 64 bit adoption , correct me if am wrong, what are the depedency of it on xenomai. Please comment. Yes, but first on the netiquette: o Please don't reply to arbitrary threads when starting a new one, it confuses people's mail clients. o Please don't put arbitrary people in CC when starting a new thread. Now on the bits directory: It contains arch-dependent internal helper functions of the related nucleus core modules. Check them carefully for potential adoptions that might be required on MIPS. 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] I-pipe patch for linux 2.6.19 on ARM.
Gilles Chanteperdrix wrote: Hi, here comes the I-pipe patch for linux 2.6.19 on ARM. In addition to the upgrade to linux 2.6.19, the AT91 port is improved: - it waits for the console to be enabled or about 2 minutes before panicing if the configured frequency is wrong; - the timer counter used as time source is chosen when configuring the kernel; - it uses the kernel clock interface in order to enable the timer counter clock instead of tweaking directly the registers. A few more words about this patch; I had to reduce the list of files included in asm-arm/ipipe.h and include linux/irq.h in kernel/ipipe/core.c otherwise the kernel did not compile with CONFIG_PREEMPT enabled. There are a few new enable_irq in entry-armv.S and I was not sure what to do about them, so I simply leaved them. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_task_create() hangs ?
Steven Scholz wrote: We noticed that on the AT91RM9200 we don't see the Xenomai: POSIX: destroyed thread c14a0320 message. Not even when running (and stopping) cyclictest. I suspect that this is leading to our problems. This message only appears if CONFIG_XENO_OPT_DEBUG_POSIX is enabled, are you sure it is enabled in the AT91 kernel configuration ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority
On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
So it clearly states that a non-preemtible task may block (and
rescheduling occurs in
this case).
Ok, so this is a must fix. Will do. Thanks for reporting.
I had a look at the OSEK specification, it also has non-preemptible
tasks. So, I guess we should add an xnpod_locked_schedule that simply does
if (xnthread_test_state(xnpod_current_sched()-runthread, XNLOCK)) {
xnpod_unlock_sched();
xnpod_lock_sched();
} else
xnpod_schedule();
and call this xnpod_locked_schedule() instead of xnpod_schedule() in
these skins.
The more I think of it, the more it becomes obvious that the current
implementation of the scheduler locks is uselessly restrictive.
Actually, the only thing we gain from not allowing threads to block
while holding such kind of lock is the opportunity to panic at best if
the debug switch is on, or to go south badly if not.
Even the pattern above would not solve the issue in fact, because things
like xnsynch_sleep_on() which fire a rescheduling call would have to
either get a special argument telling us about the policy in this
matter, or forcibly unlock the scheduler behind the curtains before
calling xnpod_suspend() internally. While we are at it, we would be
better off incorporating the latter at the core, and assume that
callers/skins that do _not_ want to allow sleeping schedlocks did the
proper sanity checks to prevent this before running the rescheduling
procedure. Other would just benefit from the feature.
In short, the following patch against 2.3.0 stock fixes the issue,
allowing threads to block while holding the scheduler lock.
--
Philippe.
Index: include/nucleus/thread.h
===
--- include/nucleus/thread.h (revision 2090)
+++ include/nucleus/thread.h (working copy)
@@ -152,6 +152,8 @@
int cprio; /* Current priority */
+u_long schedlck; /*! Scheduler lock count. */
+
xnpholder_t rlink; /* Thread holder in ready queue */
xnpholder_t plink; /* Thread holder in synchronization queue(s) */
@@ -248,6 +250,7 @@
#define xnthread_test_info(thread,flags) testbits((thread)-info,flags)
#define xnthread_set_info(thread,flags)__setbits((thread)-info,flags)
#define xnthread_clear_info(thread,flags) __clrbits((thread)-info,flags)
+#define xnthread_lock_count(thread)((thread)-schedlck)
#define xnthread_initial_priority(thread) ((thread)-iprio)
#define xnthread_base_priority(thread) ((thread)-bprio)
#define xnthread_current_priority(thread) ((thread)-cprio)
Index: include/nucleus/pod.h
===
--- include/nucleus/pod.h (revision 2090)
+++ include/nucleus/pod.h (working copy)
@@ -203,8 +203,6 @@
xnqueue_t threadq; /*! All existing threads. */
int threadq_rev; /*! Modification counter of threadq. */
- volatile u_long schedlck; /*! Scheduler lock count. */
-
xnqueue_t tstartq, /*! Thread start hook queue. */
tswitchq, /*! Thread switch hook queue. */
tdeleteq; /*! Thread delete hook queue. */
@@ -348,7 +346,7 @@
(!!xnthread_test_state(xnpod_current_thread(),XNLOCK))
#define xnpod_unblockable_p() \
-(xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),XNLOCK|XNROOT))
+(xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),XNROOT))
#define xnpod_root_p() \
(!!xnthread_test_state(xnpod_current_thread(),XNROOT))
@@ -445,24 +443,26 @@
static inline void xnpod_lock_sched(void)
{
+ xnthread_t *runthread = xnpod_current_sched()-runthread;
spl_t s;
xnlock_get_irqsave(nklock, s);
- if (nkpod-schedlck++ == 0)
- xnthread_set_state(xnpod_current_sched()-runthread, XNLOCK);
+ if (xnthread_lock_count(runthread)++ == 0)
+ xnthread_set_state(runthread, XNLOCK);
xnlock_put_irqrestore(nklock, s);
}
static inline void xnpod_unlock_sched(void)
{
+ xnthread_t *runthread = xnpod_current_sched()-runthread;
spl_t s;
xnlock_get_irqsave(nklock, s);
- if (--nkpod-schedlck == 0) {
- xnthread_clear_state(xnpod_current_sched()-runthread, XNLOCK);
+ if (--xnthread_lock_count(runthread) == 0) {
+ xnthread_clear_state(runthread, XNLOCK);
xnpod_schedule();
}
Index: ChangeLog
===
--- ChangeLog (revision 2091)
+++ ChangeLog (working copy)
@@ -1,5 +1,9 @@
2007-01-30 Philippe Gerum [EMAIL PROTECTED]
+ * ksrc/nucleus/pod.c (xnpod_schedule): Allow threads to block
+ while holding the scheduler lock. Move the lock nesting count as a
+ per-thread data (instead of the former global pod attribute).
+
* sim/include/Makefile.am: Fix destination directory for
xeno_config.h to $(prefix)/asm-sim.
Index: ksrc/nucleus/thread.c
===
--- ksrc/nucleus/thread.c
