Re: [Oslib-devel] ABORT 64 and time

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

> I am willing to do this change, however... In this particular situation,
> the abort 64 is more than motivated even in the oneshot case. Guys, we
> are spending more than 1ms in the int handler!!! The kernel must
> complain, otherwise we are going to have a lot of funny bugs in the
> future...
> Maybe I can just change the overrun test (converting it in a test on the
> amount of time spent in the handler) and print a warning if things are
> going bad...

My opinion is that the action that have to be carried when a timer
overrun is detected should be left to the kernel layer. In my opinion,
printing a message or exiting with ll_abort is not a good idea, because
ll_abort -just exits without saying a word- in general the kernel should
have the possibility to do at least something like:
- clean up all its things before exiting
- sending a signal to some process saying "hey! something strange
happened!", leaving to the application the possibility to ignore that or
to exit properly.
- adjust the timer period adaptively ;-)

Also note that a clock overrun is -really- critical if it lets you loose
the time reference...but not so critical if it happen when using the TSC
(that has a longer lifetime).

(Btw, Giacomo sent you a patch about TSC/APIC support in the event
mechanism of oslib... I've not checked if it has been rejected or
included in the CVS tree... if you want we can post it again in the
patch part of the sourceforge website...)

Also note that the clock overrun problem happens often at initialization
time, so since things have not yet started properly, we should allow
some flexibility.

I would propose some kind of hook that is by default set to ll_abort,
but that it can be redefined by the user, in a similar way to what
happens to the irqs/exceptions/...

bye

PJ

-- 
Paolo Gai <pao...@ti...>
Scuola S. Anna