[asterisk-dev] Digium card TD2400/TE40XP irq problem

[Matthew Fredrickson]

On Apr 20, 2007, at 8:30 AM, Sylvain Boily wrote:
> First Zaptel is SMP and PREEMPT unsafe for various reasons, including
> * http://bugs.digium.com/view.php?id=8422
> but not only: the try_module_get mechanism is not used correctly for
> driver modules, and there also are various locking and context issues
> in the driver API that are not documented and really error prone (and
> there are indeed errors in the way the API is used by official Zaptel
> drivers themselves)
>
> ---
>
> This issue is even worse :
> * http://bugs.digium.com/view.php?id=8404
> It's absolutely bad and broken design. There is no good reason on earth
> to
>  unconditionally busy loop for several jiffies (the way it's used in
> combination with register polling for timeouting can be OK depending
> upon
> statistical repartition of the wait time). Maybe there was one some 
> time
> ago but anyway this is not the case anymore if it was.

Yes, this could be done better.  It has not been a big concern since 
it's only in an initialization routing and not during operational 
runtime.

> The last big issue we encountered is spin_lock_irqsave being hold for 
> an
> enormous period of time for example in wct4xxp, but as usual this kind
> of
> issue (holding spin_lock_irqsave for years) is spread all over the
> Zaptel
> tree. This just caused interrupt misses on other (including Zaptel !)
> devices, resulting in a misfunction of the latter. As we needed a
> working
> setup within few minutes but the robustness, stability and 
> functionality
> were not important on this setup, I wrote a quick hack in wct4xxp which
> reenabled interruptions at fixed points (patch attached), but this is
> really just a hack and this approach must not be taken for a real fix.

Most of the sections that hold locks for extended periods of time are 
those used in initialization routines (wctdm24xxp.c and 
wct4xxp/base.c).   While this is not a particularly great idea, 
generally speaking, it's not quite as big of a red flag as doing it in 
something like an interrupt handler.  The only time it might cause 
significant interrupt latency is during driver load.  Most of that code 
is not called very often.

On a side note, as I mentioned earlier, I'm starting to go through some 
of the drivers to improve their performance.  Part of that is fixing 
some of the locking as well.

Matthew Fredrickson