[Asterisk-Users] ZT_CHANCONFIG failed on channel 1 - WAS WORKING!!

[Scott Brown]

Hi Everyone:

Problem Solved.  Thanks to Matt, Paul and Rich for their excellent help!   
It is always appreciated.

Here's the solution, for thsoe interested:

SuSE distributes zaptel drivers and the auto update referenced puts  
drivers that may not be compatible with the current release on CVS (head  
or stable) or whateve version you may have compiled and installed apart  
 from the disto.

Thus the incompatible symbols in loadable modules with no compile errors.   
One set from the disto in the "extra" directory and the compiled set in  
the "misc" directory under /lib/modules/{kernelname-version}/

It seems to me that this could conceivably cause Zaptel drivers to be  
"flaky" as reported by Paul, when they aren't sufficiently out of sync  
with symbol version error to fail in loading.  For the complete story on  
SuSE-Zaptel issues, please see:

http://www.voip-info.org/wiki-Asterisk+Linux+SuSE

Scott

On Sun, 21 Aug 2005 08:51:19 -0600, Scott Brown <sbrown at andersonis.com>  
wrote:

> Hi Paul:
>
> Thanks very much for the suggestion.  I don't understand why this just  
> began to happnen.  I never
> had problems before.  Your suggestion has shed a lot of light on the  
> problem.  Because wcfxs "disagrees" about the version of the symbols  
> listed below, I get the following unknown symbol problems for:
>
> zt_receive
> zt_qevent_lock
> zt_ec_chunk
> zt_transmit
> zt_unregister
> zt_hooksig
> zt_register
>
> With: "wcfxs: disagrees about version of symbol..."
>
> BTW, I also did a full checkout (v1-0) and rebuild (deleting modules and  
> includes beforehand) of
> astrisk zaptel and libpri.  That didn't change anything.
>
> Below is the resultant output from the -v modprobe and dmesg output.  If  
> you or anyone else can help with this it would really be appreciated,  
> thanks:
>
> # modprobe -v -n wctdm
> insmod /lib/modules/2.6.11.4-21.8-default/kernel/lib/crc-ccitt.ko
> insmod /lib/modules/2.6.11.4-21.8-default/misc/zaptel.ko
> install /sbin/modprobe --ignore-install wcfxs && /sbin/ztcfg
> # modprobe -v wctdm
> insmod /lib/modules/2.6.11.4-21.8-default/kernel/lib/crc-ccitt.ko
> insmod /lib/modules/2.6.11.4-21.8-default/misc/zaptel.ko
> install /sbin/modprobe --ignore-install wcfxs && /sbin/ztcfg
> insmod /lib/modules/2.6.11.4-21.8-default/extra/wcfxs.ko
> FATAL: Error inserting wcfxs  
> (/lib/modules/2.6.11.4-21.8-default/extra/wcfxs.ko): Unknown symbol
> in module, or unknown parameter (see dmesg)
> FATAL: Error running install command for wcfxs
>
> pertinent dmesg output:
> zaptel: module not supported by Novell, setting U taint flag.
> Zapata Telephony Interface Registered on major 196
> wcfxs: module not supported by Novell, setting U taint flag.
> Zapata Telephony Interface Unloaded
> zaptel: module not supported by Novell, setting U taint flag.
> Zapata Telephony Interface Registered on major 196
> wcfxs: module not supported by Novell, setting U taint flag.
> wcfxs: disagrees about version of symbol zt_receive
> wcfxs: Unknown symbol zt_receive, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_qevent_lock
> wcfxs: Unknown symbol zt_qevent_lock, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_ec_chunk
> wcfxs: Unknown symbol zt_ec_chunk, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_transmit
> wcfxs: Unknown symbol zt_transmit, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_unregister
> wcfxs: Unknown symbol zt_unregister, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_hooksig
> wcfxs: Unknown symbol zt_hooksig, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_register
> wcfxs: Unknown symbol zt_register, st_info == 0x1
> load_module: err 0xfffffffffffffffe (dont worry)
> wcfxs: module not supported by Novell, setting U taint flag.
> wcfxs: disagrees about version of symbol zt_receive
> wcfxs: Unknown symbol zt_receive, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_qevent_lock
> wcfxs: Unknown symbol zt_qevent_lock, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_ec_chunk
> wcfxs: Unknown symbol zt_ec_chunk, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_transmit
> wcfxs: Unknown symbol zt_transmit, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_unregister
> wcfxs: Unknown symbol zt_unregister, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_hooksig
> wcfxs: Unknown symbol zt_hooksig, st_info == 0x1
> wcfxs: disagrees about version of symbol zt_register
> wcfxs: Unknown symbol zt_register, st_info == 0x1
> load_module: err 0xfffffffffffffffe (dont worry)
>
> Thanks for the help.
>
> Scott
>   On Sat, 20 Aug 2005 03:58:18 -0600, Paul Hewlett  
> <paul at cottonpickinminds.co.za> wrote:
>
>> On Saturday 20 August 2005 09:58, Scott Brown wrote:
>>> Hi Matt:
>>>
>>> That suggestion is possibly on the right track.  It made me remember  
>>> that -
>>> although I'm not using Fedora, but SuSE 9.3, that it went through an
>>> automatic network update just recently.  After that, I tried updating  
>>> the
>>> Zaptel files from CVS and recompiling everything, but to no avail.  The
>>> same error still occured.  I eliminated hardware by swapping out a  
>>> working
>>> TDM400 with the same FXS/FXO configuration.  The same error occurs.   
>>> The
>>> SuSE update may have moved some of the required files, although there  
>>> are
>>> no complaints during the build and I can't determine what may have  
>>> moved.
>>
>>    Currently I am doing the following on SuSE :
>>
>>    First reboot the PC with asterisk disabled. This will force the  
>> creation of
>> the devices during boot from the /etc/udev/rules.d files.
>>
>>    Try modprobing :
>>
>>         modprobe -v -n wctdm
>>
>>    This does nothing but tells you what would happen. If your
>> modprobe.d/zaptel file is correct the the output from this command will  
>> be
>> loading of zaptel,wcfxs and an execution of ztcfg. In other words you  
>> do not
>> have to modprobe more than one module - dependencies are sorted by the
>> modprobe.d/zaptel file. If you want -vv on the ztcfg file edit
>> modprobe.d/zaptel. I remember from the wiki somewhere that one must not
>> execute ztcfg more than once and this will happen if you modprobe  
>> zaptel and
>> then wctdm and then execute ztcfg manually. So to load
>>
>>         modprobe -v wctdm
>>
>> and to unload
>>
>>         modprobe -v -r wctdm
>>
>> Add these commands to your asterisk startup script
>>
>> This does not seem to work on Fedora - SuSE has a section on bootup  
>> 'Creating
>> devices' that seems to pre-initialise everything - Fedora seems not to  
>> have
>> this so one has to resort to insmodding and sleeping viz:
>>
>>         insmod zaptel
>>         sleep 3
>>         insmod wcfxs
>>         sleep 3
>>         ztcfg -vv
>>
>> The above has been learned from experience - the loading of the driver  
>> modules
>> for asterisk/zap seems fraught with reliability issues - in some cases  
>> the
>> drivers load without error - at other times various errors occur - I  
>> have not
>> yet figured out the cause of failures
>>
>> Paul
>>>
>>
>
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/