On Mon, 2006-07-31 at 00:00 +0200, Jan Kiszka wrote: <snip>
> > I'd like to explain why we don't we see any other routines than > > xnthread_aperiodic_handler called from xntimer_do_tick_aperiodic in the > > call frame? Even in case of massive jittery (e.g. > 300 us late) in one > > shot, we should not spin in this code, due to the resync done in > > xnpod_wait_thread_timeout - assuming we only have a single outstanding > > timer (+ the host tick, but this should not be an issue). > > xnpod_wait_thread_timeout? Do you mean xnpod_wait_thread_period? How > should it help us as long as we are in the tick handler? > Yes, I meant xnpod_wait_thread_period; forget about this, brain is missing ECC feature. I misread the tracer output. > > > >> I rather think, also when looking at Julien's second trace, that we have > >> some issue with X in user-space here, probably in combination with weird > >> VIA hardware stalling IRQ delivery for a "few" microseconds. Let's see > >> if the irqbench gives similar results. > >> > > > > The problem is that I can reproduce X-related jittery (> 2 ms in a row) > > on one of my test boxen when dragging windows over the screen, without > > triggering the NMI watchdog set to 100 us (and guess what, the chipset > > in question is from VIA). > > Does NMI management happen in the CPU or has the chipset any influence > as well? I was referring to something like SMI# -> SMM which disables IRQs _and_ the NMI# and INIT# lines, in which case, the chipset would be at the root of the problem. Since we cannot guarantee that our existing SMI work-around blocks all potential SMI sources/events (hence the name), we cannot exclude such possibility. > If yes, I could imagine what VIA does here... Have you already > checked what irqbench records? > Not yet. > Jan > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
