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

Matthew Fredrickson creslin at digium.com
Fri Apr 20 09:31:36 MST 2007


You might check the trunk version of wct4xxp driver.  I have started a  
fairly massive and significant overhaul on it that your feedback would  
be useful on.

Matthew Fredrickson

On Apr 20, 2007, at 8:30 AM, Sylvain Boily wrote:

> Hi,
>
> I already open bug on support at digium.com and it was closed because i
> send on bad support. Support says it was better to talking about this  
> on
> mailing developper. So i send you a rapport from my developper  
> Guillaume
> Knispel about some problems on zaptel. If you want access on server for
> testing it was possible. We have creating a small patch just in urgence
> but i was not a solution.
> Unfortunatelly, We have no time now for working on this bug but it was
> an important problem for all peoples who want Digium card TDM2400 and
> TE40XP or B410P.
> We have testing on different server with debian sarge and some other
> kernel.
>
> ----------------
>
>
> Here is a summary of a subset of a number of defaults we encountered in
> Zaptel :
>
> ---
>
> 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.
>
> ---
>
> 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.
>
>
> Sylvain
> --  
> Sylvain BOILY
> Proformatique - 67 rue Voltaire - 92800 Puteaux
> Tel. : 01 41 38 99 64 - Fax. : 01 41 38 99 70
> Email : sboily at proformatique.com - http://proformatique.com/
>
> "Vers un monde plus libre"
> ------------------------------------
> Proformatique est membre de l'ASS2L
> http://www.ass2L.org
> <zaptel-1.2.13-wct4xxp-short- 
> irqsave.patch>_______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list