[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-14-2007 04:40 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.
====================================================================== 

---------------------------------------------------------------------- 
 meneault - 12-14-07 04:40  
---------------------------------------------------------------------- 
Hi,

I just uploaded some new patches updated to latest version available from
trunk (revision 3474).

8290-race-wctdm-c_1_4_rev3474 => the initial race condition
8290-msg-wctdm-c_1_4_rev3474 => the message printing problem "BATTERY"
8290-hooksig-*_1_4_rev3474 => the problem of RXSIG_INITIAL

(8290-hooksig-wctdm-c_1_4_rev3474 needs
8290-hooksig-msg-wctdm-c_1_4_rev3474 applied)

This time I made the hooksig (RXSIG_INITIAL issue) patch the cleanest way
but as I said in the previous message zaptel-base.c and zaptel.h needed
some modifications. I made the things safely so everything is correctly
locked.
The issue is solved for both FXO and FXS ports (even if FXS wouldn't be an
issue for what is expected from this bug patch, anyway for future safety is
good to have this fixed too).

In the common case the cost of this patch is near 0, because we lock on
wc->lock from interrupt context which won't collide with any other accesses
except with wctdm specific ioctls and transmit hook state changes which are
really rare.

This is a neat gain from the previous patch that locked on chan->lock and
thus would collide with almost all ioctls and with the read method which is
called often in the common case (anyway I didn't notice any performance
loss because lock times are usually short).

For a more detailed description:
When rxhooksig is reset by zaptel-base.c to RXSIG_INITIAL (currently on
ZT_CHANCONFIG and ZT_STARTUP ioctls) then zaptel-base triggers this change
to subdrivers by calling the span specific rxhookreset callback function
for a specific channel. This tell subdrivers that zt_hooksig should be
called soon for that channel.

For wctdm.c this callback only changes the state of rxhookupdate variable
to 1 for the matching card.

For the FXO case in voicedaa_check_hook:
if rxhookupdate is set to 1 then
battery state is set to -1 
which would cause a call to zt_hooksig in less than battdebounce ms.

For the FXS case in proslic_check_hook:
if rxhookupdate is set to 1 then
the state is changed so that zt_hooksig is called with current hook
state.

I am now testing this patch....
When looking at my traces this appears to work:

- when loading the driver you should have 
BATTERY ON ... printed when loading driver
(or NO BATTERY ON ... if you don't have any line connected)

- then after executing ztcfg you should have:
(NO) BATTERY ON ... printed again for FXO cards
and Card X Going ... for FXS cards.

I have a FXS card on slot 1 and FXO card on slot 0, for each new
reconfiguration of channels I have this printed which indicates that the
patch runs correctly
(I simply run ztcfg -f to force reconfiguring channels)

Dec 14 11:33:15 dialplan kernel: wctdm: Card 0 Going on hook
Dec 14 11:33:15 dialplan kernel: BATTERY on 1/4 (+)! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-14-07 04:40  meneault       Note Added: 0075378                          
======================================================================