Jan Kiszka wrote:
Steven Seeger wrote:
Here are the routines in question:
low priority:
for(;;) {
/* regular rf watchdogs */
outb(0x45, 0x);
outb(0x6a, 0x);
outb(0x7e, 0x);
outb(0, 0x); //patient watchdog
outb(0, 0x); //fault led
I didn't get Jan's original response to my messages. I haven't seen what he
wrote until Philippe's response.
To be precise, the Linux kernel as a whole will inherit the RT priority of the
syslog caller until the latter suspends Linux-wise, which is quite possible
due to
the way syslog
Steven Seeger wrote:
There is a awful amount of code in this project, and I should point out that
this same code did not exhibit these problems under a fusion cvs from
You code contains a wrong assumption about the execution context. Older
Xenomai/fusion versions may have concealed this due to
Title: Re: [Xenomai-help] no-brainer issue found, but not solved
There is a awful amount of code in this project, and I should point out that this same code did not exhibit these problems under a fusion cvs from October. I can see about posting the full code, but my supervisors dont want
Steven Seeger wrote:
There is a awful amount of code in this project, and I should point out that
this same code did not exhibit these problems under a fusion cvs from
You code contains a wrong assumption about the execution context. Older
Xenomai/fusion versions may have concealed this due to
I have found what seems to cause my problem.
I have two threads, t1 and t2.
t1 has a priority level of 30, and t2 has a priority level of 5. I am using
the native skin, so t1 has the higher priority.
t2 is flashing an LED on my board every 40 ms, and t1 does nothing until I
hit a key on the
I have found what seems to cause my problem.
I have two threads, t1 and t2.
t1 has a priority level of 30, and t2 has a priority level of 5. I am using
the native skin, so t1 has the higher priority.
t2 is flashing an LED on my board every 40 ms, and t1 does nothing until I
hit a key on the
