Topic: [Announce]... Er... Loads of Asterisk/SAIL stuff

[rcasado]

Hello Selintra,

The Zaptel / Kernel issue has been a problem for a long time.    SME Server isn't a dev platform (and rightfully so) but perhaps building an install script for Asterisk / Zaptel might be an option instead of maintaining RPM's?

I know... I know... this is a crude example and pardon my lack of knowledge on the SME Server platform; but bear with me.

Temporarily install the packages needed to compile Asterisk and Zap:

Code: [Select]

yum –y update
yum --enablerepo=* install gcc gcc-c++ kernel-devel kernel-smp-devel bison ncurses-devel audiofile-devel subversion libogg-devel tftp-server ntp doxygen

Code: [Select]

signal-event post-upgrade; signal-event reboot

Code: [Select]

ln -s /usr/src/kernels/2.6.9-55.plus.c4-smp-i686 /usr/src/linux-2.6
ln -s /usr/src/kernels/2.6.9-55.plus.c4-smp-i686 /usr/src/linux

Code: [Select]

cd /usr/src
svn checkout http://svn.digium.com/svn/asterisk/trunk asterisk
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
svn checkout http://svn.digium.com/svn/libpri/trunk libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/trunk asterisk-addons

Code: [Select]

cd /usr/src/zaptel
./configure; make menuselect
# "X" out
make clean; make linux26; make install

Code: [Select]

cd /usr/src/libpri
make install

Code: [Select]

cd /usr/src/asterisk
./configure
make install
make progdocs
make config

Load everything up properly then CLEAN UP!!!

Code: [Select]

yum remove gcc gcc-c++ kernel-devel kernel-smp-devel ncurses-devel audiofile-devel doxygen

Just a thought,
R

[SARK devs]

Hi R

Just a thought

...and a good one.  We've discussed this many times.  As you may know, A@H/Trixbox/ whatever it's called nowadays, installs asterisk in the way you describe and it has some advantages from a kernel-release point of view but, of course, once its in, they have the same problem to keep up with the Kernel releases that we have.  The great beauty of rpm is that it can be regressed if you get it wrong and this is incredibly important for our paying customers.  They won't allow us to take their phones away from them while we rebuild the system if we get a release wrong.  With rpm, we can be back to the previous release in less than a couple of minutes if we screw up (and we do screw up - ).    

In truth, we only maintain asterisk to maintain SARK/SAIL, it's a job we would rather not have to do...  

SARK/SAIL, doesn't much care which asterisk release it's running against (well, 2.1.15 needs 1.4,  but 2.1.14 will run with pretty much any earlier release)  and furthermore, doesn't care how the asterisk image was built so we would be happy to encourage/help anyone who has a better/different idea when it comes to building asterisk on SME Server, and we do like your idea.





Thanks for the good input.

Best

S

[llandry]

OK..

Being adventurous, I followed rcasado's lead and created and compiled the zaptel module myself.. I went so far as to update the kernel using the centosplus repository.

I now have a zaptel module that installs nicely... ( at least, modprobe zaptel, doesn't complain )

But, sail still doesn't see the card..

lspci -vv yeilds:

Code: [Select]

01:03.0 Communication controller: Motorola Wildcard X100P
        Subsystem: Efar Microsystems: Unknown device 0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 96 (250ns min, 32000ns max)
        Interrupt: pin A routed to IRQ 185
        Region 0: I/O ports at 2100 [size=256]
        Region 1: Memory at effff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Don't know where to go from here.

Thanks

L2
[/code]

[llandry]

More info to fuel the fire..

On a hunch, I added my card to the  database and got a little further ( I think )

Now when I probe for the card I get the following:

Code: [Select]


Found following card...

01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Requesting Load of wctdm ...


Loading zaptel...
Loading wctdm...
Loading ztdummy...

Zaptel view of card in /proc/zaptel/1
 Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
 
 


It finds the card this time, but after a commit, I still get:

Code: [Select]


PCI Telephony Cards

There are currently no PCI Telephony cards registered on the system.


 
In the UI..

Thanks

L2

[hervep]

More info to fuel the fire..

On a hunch, I added my card to the  database and got a little further ( I think )

Now when I probe for the card I get the following:

Code: [Select]


Found following card...

01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Requesting Load of wctdm ...


Loading zaptel...
Loading wctdm...
Loading ztdummy...

Zaptel view of card in /proc/zaptel/1
 Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
 
 


It finds the card this time, but after a commit, I still get:

Code: [Select]


PCI Telephony Cards

There are currently no PCI Telephony cards registered on the system.


 
In the UI..

Thanks

L2

Hi llandry,

Think you just selected the wrong driver in your database :

Loading zaptel...
Loading wctdm...
Loading ztdummy...

Most probably you did something like

Code: [Select]

/sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wctdm zzeor EOR

Try with 'wcfxo' instead of 'wctdm'

Code: [Select]

/sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wcfxo zzeor EOR


Best,

Hervé

[llandry]

Yes indeed Hervé,

After staring at it for awhile I noticed that and changed it...

so now I have the following in the db:

Code: [Select]


[root@master ~]# db selintra-work show pci:1057:5608:1055:0001
pci:1057:5608:1055:0001=sysdev
    probe=wcfxo
    zzeor=EOR
[root@master ~]#


and this when I probe...

Code: [Select]


Found following card...

01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Requesting Load of wcfxo ...


Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...

Zaptel view of card in /proc/zaptel/1
 Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
 
 

and the following after the commit:

Code: [Select]


PCI Telephony Cards

There are currently no PCI Telephony cards registered on the system.




So, still no luck...

I do thank  you for your patience.

L2

[hervep]

Hi R

Just a thought

...and a good one.  We've discussed this many times.  As you may know, A@H/Trixbox/ whatever it's called nowadays, installs asterisk in the way you describe and it has some advantages from a kernel-release point of view but, of course, once its in, they have the same problem to keep up with the Kernel releases that we have.  The great beauty of rpm is that it can be regressed if you get it wrong and this is incredibly important for our paying customers.  They won't allow us to take their phones away from them while we rebuild the system if we get a release wrong.  With rpm, we can be back to the previous release in less than a couple of minutes if we screw up (and we do screw up - ).    

In truth, we only maintain asterisk to maintain SARK/SAIL, it's a job we would rather not have to do...  

SARK/SAIL, doesn't much care which asterisk release it's running against (well, 2.1.15 needs 1.4,  but 2.1.14 will run with pretty much any earlier release)  and furthermore, doesn't care how the asterisk image was built so we would be happy to encourage/help anyone who has a better/different idea when it comes to building asterisk on SME Server, and we do like your idea.





Thanks for the good input.

Best

S

Maybe just need to add a 'sail panel entry' called 'Update asterisk modules' that launches the script, and make copies of the right files at the right place if new kernel detected ... ?

Just a though

Best,

Hervé

[hervep]

Yes indeed Hervé,

After staring at it for awhile I noticed that and changed it...

so now I have the following in the db:

Code: [Select]


[root@master ~]# db selintra-work show pci:1057:5608:1055:0001
pci:1057:5608:1055:0001=sysdev
    probe=wcfxo
    zzeor=EOR
[root@master ~]#


and this when I probe...

Code: [Select]


Found following card...

01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Requesting Load of wcfxo ...


Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...

Zaptel view of card in /proc/zaptel/1
 Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
 
 

and the following after the commit:

Code: [Select]


PCI Telephony Cards

There are currently no PCI Telephony cards registered on the system.




So, still no luck...

I do thank  you for your patience.

L2

No problem

Now you got both drivers loaded :

Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...

You should only have 'zaptel' and 'wcfxo'.
Did you rebooted your system ?
Did you erased the previous 'PCI' entry (wctdm) in database ?

Think you are very close to the solution

Herve

[llandry]

Hervé,

I thought I deleted the entry before... I just need to supply the key correct?

db selintra-work -delete key

Although I'm getting close, I'm packing it in for the night.  

Again, merci for all your help.

L2

[hervep]

Hervé,

I thought I deleted the entry before... I just need to supply the key correct?

db selintra-work -delete key

Although I'm getting close, I'm packing it in for the night.  

Again, merci for all your help.

L2

Yep, but in fact they are two databases ( selintra & selintra-work ... ), need to commit to 'copy' selintra work onto selintra.

Would suggest the following ( I have to go to work now ) :

- Check again the PCI id to be 100% sure it meets your card ( XP100 clone ? ) using lspci commands as described in the 'sail documentation'.
... Subsystem is currently maybe not correct :

01:03.0 Communication controller: Motorola Wildcard X100P
   Subsystem: Efar Microsystems: Unknown device 0001
   Flags: bus master, medium devsel, latency 96, IRQ 185
   I/O ports at 2100 [size=256]
   Memory at effff000 (32-bit, non-prefetchable) [size=4K]
   Capabilities: [40] Power Management version 2

- do again ' /sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wcfxo zzeor EOR ' using the right PCI ID

- do a 'commit' in sail panel

- reboot

- initialize and probe + commit

- reboot again

... Not the shortest way, but since I have to go ... .

Best,

Hervé

[SARK devs]

Hi Llandry,

Sorry you're having bother with PCI mate.

The PCI detection stuff is, outside of the AGI itself, the most complex code in the system (ask Herve - he's just added the mISDN support in 1.4 and it gave him grey hair! - only joking Herve ).

There are a few bugs in there, but the routine will usually work very well first pass.  It's when you change things that it starts to get a little pernickety.  

It's not even as if I can blame anyone else because I personally wrote the PCI code so I stand guilty as charged.

In particular ZTDUMMY is a pain. because once PCI has decided it needs to load it, that's it, it will not release the damned thing.

Anyhoo, all this doesn't help you except to say that I am just finishing up automated PRI recognition & support for Digium cards.  Two promises....

I will  fix as many bugs as I can find and I will get 'round to opening up the card recognition database with a GUI component.

Best

Jeff@selintra

[llandry]

Thank you both for your help...

I can't get help like this from a commercial product


Hervé, I followed you advice and still no go.... It still loads the wcfxo, wctdm and ztdummy drivers...

Jeff,  I removed the selintra-sail rpm, dropped the asterisk database, rebooted and re-installed the rpm and it sill picks up the wctdm driver that I had set in error previously.  Is there some other file that may not be removed when I un-install?

Thanks a bunch guys...

L2

[llandry]

We're getting closer..

I've done a bunch of clean up in the selintra-work database and removed erroneous references to the ztdummy and wctdm drivers..

I unloaded the wctdm, ztdummy, wcfxo and zaptel drivers from memory.

I then probed for the card again and go this:

Code: [Select]


Found following card...

01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Requesting Load of wcfxo ...


Loading zaptel...
Loading wcfxo...

No Zaptel Telephony Boards found - check admin-error log for probe failures...

Signalling asterisk daemon to load ZTDUMMY for timing purposes



And this is what is on the logs:

Code: [Select]


Jun 13 09:41:16 master kernel: Zapata Telephony Interface Registered on major 196
Jun 13 09:41:16 master kernel: Zaptel Version: SVN-branch-1.4-r2645
Jun 13 09:41:16 master kernel: Zaptel Echo Canceller: MG2
Jun 13 09:41:22 master kernel: ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 20 (level, low) -> IRQ 185
Jun 13 09:41:22 master kernel: Failed to initailize DAA, giving up...
Jun 13 09:41:22 master kernel: wcfxo: probe of 0000:01:03.0 failed with error -5
Jun 13 09:41:22 master kernel: Registered tone zone 0 (United States / North America)


I've double check the signature of the card and:

   pci:1057:5608:1055:0001

is indeed the correct string.

So.... Is my card bad maybe? or, have I made such a mess that maybe I should start from scratch

Thanks

L2

[matsk]

A bit late but just to confuse stuff.

To use trunk is NOT recommended in a production environment, here are new functions being tested and features can go from stable to totaly unstable from one minute to another.

svn checkout http://svn.digium.com/svn/asterisk/trunk asterisk
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
svn checkout http://svn.digium.com/svn/libpri/trunk libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/trunk asterisk-addons

svn checkout http://svn.digium.com/svn/asterisk/branches//x.x asterisk
svn checkout http://svn.digium.com/svn/zaptel/branches/x.x zaptel
svn checkout http://svn.digium.com/svn/libpri/branches/x.x libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/branches/x.x asterisk-addons

Branches is the part that are released as stable releases and is the same as the one that can be downloaded as tar packages. x.x is the version of asterisk example 1.2, 1.4 and so on.

[SARK devs]

Hi Llandry

I've had a quick look at the code and this may be a timing problem.

Do this...

stop zaptel with zaptel -s

Then...

lsmod

make a note of any digium drivers loaded...

unload them with rmmod driver name...

e.g. rmmod ztdummy

finally unload zaptel itself with...

rmmod zaptel

check that they've all gone with...

ls /proc/zaptel

/proc/zaptel  should not exist at this point because udev should have deleted it.

OK, load wcfxo...

modprobe wcfxo

then do...

cat /proc/zaptel/1

Tell me what you get....



best

j@selintra