[asterisk-bugs] [Zaptel 0008290]: [patch] zap hookstate is never set offhook if wctdm module is loaded with an active fxo line

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8290 
====================================================================== 
Reported By:                tmarkov
Assigned To:                mattf
====================================================================== 
Project:                    Zaptel
Issue ID:                   8290
Category:                   wctdm
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Zaptel Version:              1.2.10 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             11-03-2006 17:28 CST
Last Modified:              12-04-2007 06:05 CST
====================================================================== 
Summary:                    [patch] zap hookstate is never set offhook if wctdm
module is loaded with an active fxo line
Description: 
If #define ZAP_CHECK_HOOKSTATE is uncommented in chan_zap.c, then the
hookstate stays onhook if the wctdm module is loaded with an active line. 
Removing line and reinserting will cause the hookstate to initialize
properly.  The problem appears to be that wc->mod[card].fxo.battery never
gets initialized to 0, so in wctdm_voicedaa_check_hook() the test "if
(!wc->mod[card].fxo.battery && !wc->mod[card].fxo.battdebounce)" is never
entered, and the hookstate remains onhook upon module startup.  Only a
cycling of line voltage will correct the problem.  I have attached a patch
which initializes the battery variable and fixes the problem for me.
====================================================================== 

---------------------------------------------------------------------- 
 flefoll - 12-04-07 06:05  
---------------------------------------------------------------------- 
To complete menault's last note, a few more words about checking in wctdm.c
or wctdm24xxp/base.c, if wc->chans[card].rxhooksig is equal to
ZT_RXSIG_INITIAL, in order to trigger an information update with
zt_hooksig().

I'd rather let mattf confirm whether the method I suggest is compliant
with Zaptel software architecture or not, but here is my understanding :
- chan->rxhooksig is "read-only" in zaptel-base.c, except for its
initialization as ZT_RXSIG_INITIAL by zt_ctl_ioctl(ZT_STARTUP or
ZT_CHANCONFIG).
- chan->rxhooksig is written only from outside zaptel-base.c, through hook
functions zt_hooksig() and zt_rbsbits().
Consequently, EXCEPT for the init sequence, it is the job of "sub-drivers"
(wctdm.c or others) to update chan->rxhooksig.

As far as locking is concerned :
zt_hooksig() and zt_rbsbits() use spin_lock_irqsave() and
spin_unlock_irqrestore() before/after performing write operations. It may
make sense to do the same in zt_ctl_ioctl(ZT_STARTUP or ZT_CHANCONFIG) : we
can notice that rxhooksig init is already inside a spin_lock/unlock in case
of ZT_CHANCONFIG :-), while it is just after spin_unlock_irqrestore() in
case of ZT_STARTUP :-(

The main interest of this approach is to avoid calling zt_hooksig()
periodically just because of this oneshot problem with the init sequence. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-04-07 06:05  flefoll        Note Added: 0074733                          
======================================================================