[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:                kpfleming
====================================================================== 
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:              01-16-2008 02:30 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 - 01-16-08 02:30  
---------------------------------------------------------------------- 
>>I can't even do an outgoing call anymore [...]
>You are the first one to test them [...]

The problem was on my side : I applied last 3 patches ONLY, while I now
understand I should have also applied all or part (?) of the older patches
before. Anyway, these older patches would need a refresh too (rejects).
Even, a new single patch would be better than a multi-layered patch, imho.

>>Disconnect =>
>> Detected alarm on channel 34: No Alarm
>This looks correct it detected an alarm that's good. However I think it
should
>be 'Red Alarm' rather than 'No Alarm'.

Yes, of course.

>I guess you didn't try it with latest revision from asterisk trunk, did
you?
>What I know is that it is only supposed to work with one of the latest
>revision of asterisk (the one that contains the latest kpfleming's
changes).

I tried with chan_zap.c revision 97448 (quite recent : Jan 14 2008). I
understand that the problem is in chan_zap.c get_alarm() function : it
calls ioctl(ZT_SPANSTAT) that returns span-level information only, while
battery alarms are located at the channel level. At the moment, unless we
change the zaptel API, I suggest that get_alarms calls ioctl(ZT_SPANSTAT)
AND ioctl(ZT_GET_PARAMS) that will return channel-level information. I will
upload a patch for chan_zap.c that implements this fix.

However, regarding our initial problem here, with improper fxo state each
time rxhooksig is set to ZT_RXSIG_INITIAL, I keep thinking that my
approach, although more basic, is safe as well : ensure that all ioctl()
writes to chan->rxhooksig are in irq-locked sections (they already are,
except one, in ZT_STARTUP case, that can easily be moved), and simply
directly check chan->rxhooksig value at the end of irq-driven
wctdm_voicedaa_check_hook() function, in order to determine whether a call
to zt_hooksig() is required or not. I will upload a combined patch that
implements this solution.
[zaptel path] patch -p0 <[path]/zaptel-1.4.8-patch-initial-fxo-state
It will patch :
- zaptel-base.c : move rxhooksig write inside irq-locked section
- wctdm.c and wctdm24xxp/base.c : check chan->rxhooksig and generate
alarms
These patches were compiled, and successfully tested with a TDM400P. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-16-08 02:30  flefoll        Note Added: 0080740                          
======================================================================