[Oslib-devel] Re: OSlib ABORT 64

[Paolo G. <pao...@ti...>]

(I reply to this thread on shark-devel and to oslib-devel because I
think it may be of interest of all the subscribers...)

where it is printed:
--
ABORT 64 is written by abort_tail() (oslib/kl/init.c), 
that is called from ll_abort() (oslib/kl/abort.s),
that is called from the timer interrupt handler called ll_timer
(oslib/kl/timeint.s)

why?
--
It happens when a timer interrupt arrived before the previous timer
interrupt finished.
That situation is quite bad, becaude it means that something strange is
happening, and that (probably) the timer reference has been lost (the
timer interrupts are used to take track of the system time). (Note that
the timer interrupt have anyway a robustness of 55ms)

We have to distinguish 2 cases:

- periodic timer: In this case, the real-time clock raises an interrupt
every XXX ticks. This is the real problem... because we do not know how
many interrupts have been raised since the last timer handler.

- oneshot timer: This case is more strange, because the one-shot timer
reprograms the timer everytime it exits from a timer interrupt; to avoid
that, Luca set a minimum interarrival time between two interrupts (in
oslib/include/i386/pit.h), so -it should be- that the abort 64 with the
one-shot timer never happens... but (I do not know why), sometimes it
happens :-(

... anyway, I guess that the overrun check for the oslib events should
be done only in the periodic case, not in the one shot case.



Typical situations:
--
The ABORT 64 typically happens if someone puts some cprintf inside the
interrupt handler, and these printfs have to scroll the screen, that
usually takes around 1ms per scroll...

In the shark case, it may happen that the linux timer raised by the
network driver is quite long, and so it maybe should be run inside a
thread. I think Michael is working on a solution like that.

Other notes can be found in the FAQ 1.1 on the shark website.

That's all for now...

bye

PJ

On Fri, 2003-09-05 at 18:12, Giacomo Guidi wrote: 
> Hi all
> 
> I'm studing the "ABORT 64" error... it's one of the most strange things 
> of SHARK. It should happen if the ll_timer function inside OSLib, called
> by the the PIC timer, isn't ended before another PIC interrupt is 
> posted. This mean that if an event of the shark kernel (like a scheduler 
> decision) is longer than the system tick... you got an ABORT 64.
> 
> I measured with TSC how long are these events. In the worst case, when 
> all debug stuff are activated, on my slow PENTIUM 200, i got around 10 
> us. It's much less than the 1000 us of the system tick... but I got
> anyway ABORT 64.
> 
> So, what's the problem ? Maybe a routine that reactivate the interrupt
> in the middle of a system event (that should have interrupt disable) can
> cause this behaviour ?
> 
> Regards
> 
> Giacomo