On 21 July 2010 14:06, Gilles Chanteperdrix < [email protected]> wrote:
> Stephen Bryant wrote: > > On 21 July 2010 12:06, Gilles Chanteperdrix > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > Stephen Bryant wrote: > > > Hi, > > > > > > I have some code (simplified example below) which uses > > > 'pthread_wait_np(&Overrun)' within a while loop, using a period of > > > 1,000,000ns (1ms) which has been set using > > 'pthread_make_periodic_np()'. > > > This wakes the thread up less than 2,000ns late in general, > sometimes > > > 20,000ns late, and at most less than 45,000ns late. > > > > Since you do not tell us, I guess you are running on x86. Depending > on > > the x86 you are running, 45 us may be high. > > > > > > Yes, it is x86, sorry for the omission. What sort of latencies would you > > expect me to see? > > If it is for instance, a core 2 duo, it should be around, say, 10 or > 20us. If on the other hand, it is a geode, then 45us may be OK. The > actual results also depend on the system load, an unloaded core 2 will > have average latencies under 10us. > > > This reasoning is flawed: you may be preempted by interrupts any > time. > > Including just about at the time where you were going to exit the > busy > > loop. Unless you spin irqs off, and only reenable irqs when the job > the > > thread is supposed to be doing is done. And if you have an SMI issue, > > even turning off the interrupts will not help. > > > > > > I was under the (apparently flawed) impression that Adeos was used to > > prevent interrupts preempting a running high priority task in primary > > mode, only forwarding the interrupts to Linux once the task was waiting > > / finished. I guess that it only prevents a subset of all interrupts, > > and the rest must be specifically disabled then re-enabled by the > > program, or maybe it does not intercept any interrupts? > > It prevents secondary domain interrupts from being executed, but the > primary domain interrupt such as the timer interrupt are still executed, > and the secondary domain interrupts are still ticking and cause a > context switch, even if masked immediately. > > > The question is: is the SMI workaround working for your chipset? If > that > > is the case, you should get messages in the kernel logs. > > > > > > I've had a look at dmesg, but cannot find any references to SMI - what > > should I be looking for? > > What is described in the TROUBLESHOOTING file. > > I have tried disabling the SMI workaround, ensuring that SMI detection is not disabled, and logging the kernel output (setting the kernel log level to 8 in grub and sending the output to the serial port to be picked up by another machine). The troubleshooting file states that I should see "Xenomai: Intel chipset found and SMI workaround not enabled, you may encounter high interrupt latencies." in this output, however this does not occur - I am using an Intel Core 2 Duo but with SMP disabled, if this has any relevance. Steve
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
