|
| From: | Gilmore, Gerry |
| Subject: | RE: [Bayonne-devel] ERROR:4111 & Failed open in sctsdtdxag.c |
| Date: | Sat, 29 Jan 2005 09:35:27 -0800 |
Usually, these messages mean one of several things: LiS was compiled with kgcc or egcs instead of gcc. If you're using FP1, and didn't modify the configure script, this is likely. The wrong answers were given to one or more of the config.sh questions, see the attached HOWTOs for more detail. The wrong (or no) interrupt was given during install. Because you've (apparently) got an ISA board, you need to verify that several things are correct in the /usr/dialogic/cfg directory: the entry in .bltirq should be the IRQ for the boards; the entry in .veclist for SRAM matches the IRQ; any entry in dialogic.cfg that references the Interrupt/IRQ level matches as well; make *darned* sure that the IRQ is reserved for ISA in the BIOS setup. Reference the attached HOWTOs, based on your System Release for the best install methods, IMHO. :-) Gerry There are 10 kinds of people in the world, those who understand binary and those who don't. Gerry Gilmore Field Applications Engineer Intel Corporation (http://www.intel.com) -----Original Message----- From: address@hidden [mailto:address@hidden On Behalf Of Raymond Gibson Sent: Friday, January 28, 2005 6:56 PM To: Bayonne Subject: [Bayonne-devel] ERROR:4111 & Failed open in sctsdtdxag.c Hello, i need a little help interpreting this output. Did the software load? the output shows an ERROR:4111. However, it looks like it may have loaded, but i'm not sure. How do i fix this? dxxxB1 : Failed open in sctsdtdxag.c: No such file or directory dxxxB1 : Failed open in sctsdtdxag.c: Illegal seek <snip> address@hidden root]# /etc/init.d/orbacus start Starting ORB Event Server: [ OK ] Starting Orbacus4 nameserv: [ OK ] address@hidden root]# /usr/dialogic/bin/dlstart Dialogic Generic Downloader Version 5.10 (Build 12) Copyright (c) 1992-2000 by Dialogic Corp. Using /usr/dialogic/cfg/dialogic.cfg to configure Dialogic Boards System Download ............................................ D/41ESC (ID 1) Download .. d4x Firmware Version 6.53 Build 0028.0002 1 Dialogic Board Successfully Installed /usr/dialogic/bin/genstart: ERROR:4111: cannot start Generic Driver Add SW Devices .... REGVOX: # REGVOX: # Dialogic Generic Configuration File REGVOX: # REGVOX: # REGVOX: # Total number of virtual boards - 1 REGVOX: # REGVOX: REGVOX: # REGVOX: # Board Type - D/41ESC REGVOX: # REGVOX: dxxxB1 4 1 C D0000 2000 1 D4XE 3 Add SW Devices Done Dialogic SCSA Transmit Timeslot Assignment Program Version 2.0 Linux 2.x.x Copyright (C) 1997-2000 Dialogic Corp. ALL RIGHTS RESERVED Using default base timeslot 0; none other specified. dxxxB1 : Failed open in sctsdtdxag.c: No such file or directory dxxxB1 : Failed open in sctsdtdxag.c: Illegal seek <snip> -- Raymond Gibson address@hidden _______________________________________________ Bayonne-devel mailing list address@hidden http://lists.gnu.org/mailman/listinfo/bayonne-devel
|
SR 5.1 FP1 for
Linux Installation HOWTO This document is meant to simplify the installation process for System Release 5.1 with Feature Pack 1 (FP1) for Linux, with a separate section on DM3-based hardware. DM3-based hardware is newly supported under Linux and represents a whole new series of Dialogic brand telephony boards.
Basically, we have 2 different hardware families - Springware and DM3. The Springware family has been around for a long time and includes everything from 2-port analog cards up through dual-span cards with 48 ports. The DM3 family begins at 48 ports per board and goes up from there. The easiest way to tell the difference is to look at the model name on the card bracket sticker. All DM3 hardware will have a model name that starts with: DM/ while Springware model names will start with plain D/ (or MSI/ for the MSI cards). For instance, a Springware card might have a model name of D/480JCT-2T1 while a DM3 card might have a model name like DM/V480A-2T1. You get the drift. But first, a word about Global Call.......... Global Call Global Call is our call control API of choice. While we still support the older, low-level API for Springware hardware, we're (I'm) strongly encouraging everyone to migrate away from the lower-level APIs and embrace GC. Why? Several reasons: 1) It's a common API that spans technologies and protocols. It supports DM3 and Springware, T1/E1 and analog with the same code base. That's pretty compelling to me. 2) Along with the basic technologies above, it also supports VoIP and SS7(!). Again, all with the same code base. 3) GC is going to be the focus of future call control efforts by us. There's not going to be any enhancements to, say, the dt_settssig() (raise the A bits!) call. 4) GC is the only call control API supported for DM3 hardware. In order to fully utilize all of GC, you'll need to download the latest protocol package from http://support.dialogic.com/releases/protocols/GCProtocols30/index.htm so you may as well get that now. And a word about device names and protocols Device Names and Protocols If you’re already familiar with Dialogic device names and protocols and such, you can skip this section. Otherwise, it’s very useful to understand it. Basically, Dialogic devices are divided into several groups: voice and other media resource devices; analog phone lines and digital (T1 or E1) lines. (If you’re confused at this point, please stop now and find someone who understands what I just said before trying to go on.) Each of these types of devices has their own device naming convention, some of which unfortunately overlap. Also, for each kind of device, you’ve got the individual channels as well as a logical “board” device which contains some number of individual channels. Let’s look at this in more detail, starting with the media devices. The media channels (aka “ports”) are named along the lines of: dxxxB1C1 (case is very important!!) where the “B” is the logical, ones-based board number and the “C” is the logical, ones-based channel number. For the voice devices, the channels are numbered 1 through 4. So, dxxxB1C1 is a valid device name while dxxxB1C9 is not. Why? Remember that the channels only number 1 – 4. Usually, the physical boards have a greater number of channels than 4, so these are assigned progressively higher numbered logical board numbers. For instance, on a 24-port board, you’d have: dxxxB1C1 – dxxxB1C4 dxxxB2C1 – dxxxB2C4 …….. dxxxB6C1 – dxxxB6C4 See? Six logical boards, each with 4 logical channels gives you all 24 channels. As an aside each of the logical board devices (dxxxB1; dxxxB2; etc.) can also be opened for manipulating certain settings. Now, let’s skip to the section for digital boards. The same general concept of logical boards and logical channels applies here as well, though the names are different. For digital boards, the devices are named along the lines of: dtiB1T1 where, again, the “B” is the logical, ones-based board number and the “T” is the logical, ones-based channel number in the range of 1 – 24 (for T1 CAS; 23 for PRI ISDN) or 1 – 30 (for E1). By the way, the “T” stands for “timeslot” because in T1/E1 framing, the individual channels are referred to as timeslots – not to be confused with SC/CTBus timeslots. Now that I’ve cleared everything up, it’s time to confuse you. For analog line devices, each line is directly associated with it’s respective voice resource and, indeed, uses the exact same device name. So, if you’ve got a single 4-port analog card, you’ll have devices dxxxB1C1 – dxxxB1C4 referring to the voice resources and the actual analog line so that you’d use the same device name for going off-hook and for playing a prompt! Don’t worry, after a while, it all starts making sense. The good news about analog lines is that your don’t have to determine any of the other stuff involved in setting up digital lines, such as line coding and framing, CAS, and PRI protocols, etc. Again, if your eyes glazed over while reading this part, get help now! Pre-requisites Before beginning, you'll need to have the right information and equipment at hand. Specifically, you'll need: Red Hat 7.3 with the 2.4.18-5 (or greater) kernel update
RPM from Red Hat (Recommended) The System Release 5.1 for Linux CD (or download image) The System Release 5.1 for Linux Feature Pack 1 CD (or
download image) LiS Version 2.15.2 One or more supported DM3 or Springware boards in the system, cabled together with their rotary switches set at sequential, unique, non-zero values.
To be logged in as "root". You'll be doing a lot of stuff that requires root-level access. RH Install We'll begin by installing Red Hat 7.3. This should be straightforward and, if you have problems installing 7.3, then keep working on it until you get it right. You must start with a good, clean, 7.3 install. First, during the initial startup of the installation, select a Custom install. Each of the other pre-packaged options (workstation, server, etc.) has certain pieces missing that we'll need. However, you can select whatever you want so long as the following packages are installed as a minimum. This is like the hardware - if you don't get this part right, expect no sympathy. kernel kernel-headers kernel-source devel kernel-devel compat-libstdc++ (if you've got DM3 hardware) Also, make sure during the GUI configuration process to select a Text login. It's much safer to do that and tweak the GUI configuration after installation. Once you've gotten it setup correctly, you can go back and make the GUI login the default. Next, take the CD with SR5.1 and FP1 and put it in the CD-ROM drive and mount it on /mnt/cdrom. All of the following instructions will presume that this has been done correctly. # mount /dev/<cdrom-dev-name> /mnt/cdrom RH Upgrade After Red Hat 7.3 is installed and working correctly, it's time to upgrade the kernel. Before doing so, let's verify that the required kernel packages were installed. To do this, run: # rpm -qa
| grep kernel What you should see is something like: kernel-source-2.4.18-3 kernel-2.4.18-3 (or, if you've loaded on an SMP system) kernel-smp-2.4.18-3 ..... and possibly more If you don't have the ones listed above, then you'll need to redo the installation and make sure to select the "Kernel Development" package set. If you do, we'll move on. Now, we'll install the updated kernel and associated packages by running the following commands: # cd
/mnt/cdrom/FP1/2.4.20* # rpm -ivh
kernel-2.4.20-18.7.i686.rpm (or) # rpm -ivh kernel-smp-2.4.20-18.7.i686.rpm # rpm -Uvh
kernel-source-2.4.20-18.7.i386.rpm Note the use of the "-ivh"
for the kernel and the "-Uvh" for the
kernel-sources packages. Also, please note
that you may need to upgrade the dev package in order to upgrade the kernel.
This package is included in the same directory. Presuming that you didn't see any dastardly errors during these steps, we'll activate the new kernel and reboot by the following steps. (If you’re using GRUB as your boot loader, this step is not necessary) # vi /etc/lilo.conf Within this file are various entries corresponding to different kernel configurations, specifically related to SMP vs. non-SMP. There will be a section for each type. What you'll want to do is to duplicate the relevant section and change the 2.4.18-3 strings to 2.4.20-18.7. Within that new section, you should also change the label field to a new, unique name such as linuxnew. There cannot be 2 entries in here with the same label!!! Finally, change the default label in the beginning of the file to reflect the new name (linuxnew). Save that file and run: # lilo This will update some system files to reflect the changes and prepare for the next reboot. So, let's reboot using your favorite method. Once the system reboots, if all went correctly, you should now be looking at the login prompt displaying your new kernel version. If not, it's time to backtrack and discover what you did wrong. I'll wait...................... OK. Now it's time to move on to the Linux STREAMS (LiS) installation. LiS Install First, remount the CD as earlier. Then, run the commands: # cd /mnt/cdrom/FP1/LiS # cp LiS-2.15.2.tgz /usr/src # cd /usr/src # tar –xzvf
LiS-2.15.2.tgz # cd /usr/src # vi Configure …. Here, you should go to line 1634 and copy it and the
next line to insert below line 1636. At the end, this section should look like
this: ….. else CC_NAME=gcc CC_OPTIMIZE=-O2 fi # 2 New lines below here.... CC_NAME=gcc CC_OPTIMIZE=-O2 GCC_VERS=`$CC_NAME -v 2>&1 |tail -1` # make This will begin the process of building and installing the LiS system. You'll be asked a series of configuration questions, which should all be answerable just by hitting Enter to take the default. Then the compiling of LiS will begin. Note that you may see a lot of warnings about malloc.h being deprecated and to use slab.h instead. These can be safely ignored. # make install This copies the LiS utilities and libraries around to their proper places. If there are any horrible problems noted, fix these before trying to proceed. Dialogic Installation Now, we're ready for the Dialogic 5.1 install (Finally!! :-). The CD should still be mounted from the earlier steps. Run: # cd /mnt/cdrom # ./install.sh This begins the install process. Basically, you'll be presented with a menu of choices for packages. Items 1 and 2 are for Springware support and items 3 - 6 are for DM3. Here's where the homework that you did earlier in verifying the type of hardware that you have pays off. A word to the wise, unless you know specifically that you have Antares hardware, make sure to not select option 2. It creates some config file entries that will clutter your screen with all kinds of mean, nasty, ugly messages during initialization. Also, sadly, selecting All has the same effect. Normally, this would be the point where you would run config.sh as the screen instructs you to do. However, don’t! First, we need to install the FP1 package which includes updated drivers for Rd Hat 7.3. Basically, cd into the directory on your custom CD (or whatever) where you’ve got the FP1 packages and duplicate what you just finished above. That is, run install.sh (again) and after that finishes successfully you can then run: # ./config.sh You'll be asked if you've got any DM3 boards, then if you've got any Springware boards and finally whether you want to configure SNMP on the system. We're not going to discuss SNMP configuration in this HOWTO. If you selected that you have Springware boards, you’ll get an additional prompt: Will this system use ISA / board locator technology boards e.g., D/XXE, D/240SC-T1 boards? This question is a tad misleading in that what it’s really asking is if you’ve got SCBus-type cards. If your Springware cards have the SCBus/CTBus connectors on the back spline edge of the card, then answer “Yes” – otherwise answer “No”. For cards such as the D/4PCI; the D/21H; D/41H; etc., answer “No”. Now, the system will begin rebuilding the LiS system with the Dialogic drivers hooked in. After that is finished, you'll be brought into one or more configuration tools, depending on the type of hardware that you've installed. We'll take them separately below. DM3 Configuration The configuration of DM3 boards under Linux revolves around correct configuration of the /usr/dialogic/cfg/pyramid.scd file. This is the DM3 equivalent of /usr/dialogic/cfg/dialogic.cfg for Springware boards.
Here, you're presented with a list of DM3 boards that the system has detected. NOTE: If you know for a fact that you've got DM3 hardware installed, but the config program shows you an empty list, then you most likely did not install the compat-libstdc++ package during installation. To verify that this is the case, switch to an alternate screen and run: /usr/dialogic/bin/listboards If you get an error about libstdc++, then you need to install that package from the Red Hat CD. In the DM3_cfg.sh script, basically just sequence through the different fields getting everything setup correctly. I know that's thin guidance, but configuring DM3 boards isn't easy and I encourage you to experiment (and RTFM, of course) with different configs until you get good and comfortable. To try your new configuration setup, run these commands in order. # /usr/dialogic/bin/dlstop # /usr/dialogic/bin/dlstart While dlstart is running, you'll see voluminous information scrolling across the screen. You'll have to watch it closely as it scrolls by to make sure that parts didn't fail. Once you've run it a few times with good and bad info, you'll be able to notice the differences between success and failure easily. Also, you can redirect the output of dlstart to a log file. DM3 Testing The best/only way to test DM3 hardware is via the few demo programs included that are DM3-capable. That is, essentially, /usr/dialogic/demos/gc_demos/gc_basic_call_model. (Named by the Ridiculously_long_and_complicated_program_naming group within Dialogic). To run that, run: # cd /usr/dialogic/demos/gc_demos # vi gc_basic_call_model.cfg # Edit this file to reflect the boards/channels/protocols to test. If you don’t get this setup right, it won’t work!! # ./gc_basic_call_model If you get an error from gc_Start(), reboot the system. There are some library dependencies that get resolved at boot time.
And we should be off to the races!!!!!!!!!!!!!!!! Springware
Configuration Configuring Springware hardware can be done one of two ways: either through the mkcfg program, automatically invoked by the installation process if you selected Springware hardware, or by manually editing the /usr/dialogic/cfg/dialogic.cfg file. This file is created by running /usr/dialogic/bin/mkcfg if you want to invoke it later. Here again, the key is knowing your hardware and knowing how you want it configured. This is where the RTFM comes into play again. While you can configure the boards themselves, configuring specific protocols (like ISDN) requires manually editing the dialogic.cfg file mentioned above. The details on the format of the dialogic.cfg file are in the Software Installation Guide noted below. Springware
Testing The software furnished for testing Springware hardware is much broader and is really dependent on your hardware. Specifically, analog vs digital; ISDN vs robbed-bit, etc. However, you *can* (and should, actually) use the afore-mentioned gc_basic_call_model program which has the advantages of working with all hardware and all protocols. However there is also available: pansr - which works with analog and robbed-bit T1 with immediate start protocol. It’s located in /usr/dialogic/demos/dx_demos. The source code is there and you should take a look at the command-line options as they need to be set right or, surprise!, it won’t work. isdiag - a great PRI ISDN testing program in /usr/dialogic/bin sampletest - a stripped-down isdiag, but with source code in /usr/dialogic/demos/cc_demos Basically, you really should get your system working with a canned demo before jumping into your new, super-threaded, etc. custom program. It really helps to have a good baseline to start from. Further Reading (Trust me on this - it's well worth
the time to read this stuff) Root link for all Linux SR 5.1 Documentation http://support.dialogic.com/releases/unix51/linux51/SR5.1_Linux/Onldoc/html_files/index.html Release Guide http://support.dialogic.com/releases/unix51/linux51/release_guide/release_guide.html - P1426_77937 Software Installation Guide |
|
SR 5.1 SP1 for
Linux Installation HOWTO This document is meant to simplify the installation process for System Release 5.1 with Service Pack 1 (SP1) for Linux, with a separate section on DM3-based hardware. DM3-based hardware is newly supported under Linux and represents a whole new series of Dialogic brand telephony boards.
Basically, we have 2 different hardware families - Springware and DM3. The Springware family has been around for a long time and includes everything from 2-port analog cards up through dual-span cards with 48 ports. The DM3 family begins at 48 ports per board and goes up from there. The easiest way to tell the difference is to look at the model name on the card bracket sticker. All DM3 hardware will have a model name that starts with: DM/ while Springware model names will start with plain D/ (or MSI/ for the MSI cards). For instance, a Springware card might have a model name of D/480JCT-2T1 while a DM3 card might have a model name like DM/V480A-2T1. You get the drift. But first, a word about Global Call.......... Global Call Global Call is our call control API of choice. While we still support the older, low-level API for Springware hardware, we're (I'm) strongly encouraging everyone to migrate away from the lower-level APIs and embrace GC. Why? Several reasons: 1) It's a common API that spans technologies and protocols. It supports DM3 and Springware, T1/E1 and analog with the same code base. That's pretty compelling to me. 2) Along with the basic technologies above, it also supports VoIP and, soon, SS7. Again, all with the same code base. 3) GC is going to be the focus of future call control efforts by us. There's not going to be any enhancements to, say, the dt_settssig() (raise the A bits!) call. 4) GC is the only call control API supported for DM3 hardware. In order to fully utilize all of GC, you'll need to download the latest protocol package from http://support.dialogic.com/releases/protocols/GCProtocols20/index.htm so you may as well get that now. And a word about device names and protocols Device Names and Protocols If you’re already familiar with Dialogic device names and protocols and such, you can skip this section. Otherwise, it’s very useful to understand it. Basically, Dialogic devices are divided into several groups: voice and other media resource devices; analog phone lines and digital (T1 or E1) lines. (If you’re confused at this point, please stop now and find someone who understands what I just said before trying to go on.) Each of these types of devices has their own device naming convention, some of which unfortunately overlap. Also, for each kind of device, you’ve got the individual channels as well as a logical “board” device which contains some number of individual channels. Let’s look at this in more detail, starting with the media devices. The media channels (aka “ports”) are named along the lines of: dxxxB1C1 (case is very important!!) where the “B” is the logical, ones-based board number and the “C” is the logical, ones-based channel number. For the voice devices, the channels are numbered 1 through 4. So, dxxxB1C1 is a valid device name while dxxxB1C9 is not. Why? Remember that the channels only number 1 – 4. Usually, the physical boards have a greater number of channels than 4, so these are assigned progressively higher numbered logical board numbers. For instance, on a 24-port board, you’d have: dxxxB1C1 – dxxxB1C4 dxxxB2C1 – dxxxB2C4 …….. dxxxB6C1 – dxxxB6C4 See? Six logical boards, each with 4 logical channels gives you all 24 channels. As an aside each of the logical board devices (dxxxB1; dxxxB2; etc.) can also be opened for manipulating certain settings. Now, let’s skip to the section for digital boards. The same general concept of logical boards and logical channels applies here as well, though the names are different. For digital boards, the devices are named along the lines of: dtiB1T1 where, again, the “B” is the logical, ones-based board number and the “T” is the logical, ones-based channel number in the range of 1 – 24 (for T1 CAS; 23 for PRI ISDN) or 1 – 30 (for E1). By the way, the “T” stands for “timeslot” because in T1/E1 framing, the individual channels are referred to as timeslots – not to be confused with SC/CTBus timeslots. Now that I’ve cleared everything up, it’s time to confuse you. For analog line devices, each line is directly associated with it’s respective voice resource and, indeed, uses the exact same device name. So, if you’ve got a single 4-port analog card, you’ll have devices dxxxB1C1 – dxxxB1C4 referring to the voice resources and the actual analog line so that you’d use the same device name for going off-hook and for playing a prompt! Don’t worry, after a while, it all starts making sense. The good news about analog lines is that your don’t have to determine any of the other stuff involved in setting up digital lines, such as line coding and framing, CAS, and PRI protocols, etc. Again, if your eyes glazed over while reading this part, get help now! Pre-requisites Before beginning, you'll need to have the right information and equipment at hand. Specifically, you'll need: Red Hat 7.2 with the 2.4.9-13 (or greater) kernel update
RPM from Red Hat OR Red Hat 7.3 with the 2.4.18-5 (or greater) kernel update
RPM from Red Hat (Recommended) The System Release 5.1 for Linux CD (or download
image) The System Release 5.1 for Linux Service Pack 1 CD (or
download image) LiS Version
2.13.16 One or more supported DM3 or Springware boards in the system, cabled together with their rotary switches set at sequential, unique, non-zero values.
To be logged in as "root". You'll be doing a lot of stuff that requires root-level access. RH Install Since I’m a big fan of Red Hat 7.3, we’ll focus on that one. If you insist on using Red Hat 7.2, that’s OK, you’ll just have to modify a few steps along the way. We'll begin by installing Red Hat 7.3. This should be straightforward and, if you have problems installing 7.3, then keep working on it until you get it right. You must start with a good, clean, 7.3 install. First, during the initial startup of the installation, select a Custom install. Each of the other pre-packaged options (workstation, server, etc.) has certain pieces missing that we'll need. However, you can select whatever you want so long as the following packages are installed as a minimum. This is like the hardware - if you don't get this part right, expect no sympathy. kernel kernel-headers kernel-source devel kernel-devel compat-libstdc++ (if you've got DM3 hardware) Also, make sure during the GUI configuration process to select a Text login. It's much safer to do that and tweak the GUI configuration after installation. Once you've gotten it setup correctly, you can go back and make the GUI login the default. Next, take the CD with SR5.1 and SP1 and put it in the CD-ROM drive and mount it on /mnt/cdrom. All of the following instructions will presume that this has been done correctly. NOTE: If you've downloaded the release from the web site and you're going to be doing multiple installations, I highly recommend that you build a custom CD with the SR 5.1 stuff, SP1, the Global Call Protocols Package Version 3.0, the kernel update RPMS, LiS, etc. # mount /dev/<cdrom-dev-name> /mnt/cdrom RH Upgrade After Red Hat 7.3 is installed and working correctly, it's time to upgrade the kernel. Before doing so, let's verify that the required kernel packages were installed. To do this, run: # rpm -qa | grep
kernel What you should see is something like: kernel-source-2.4.18-3 kernel-2.4.18-3 (or, if you've loaded on an SMP
system) kernel-smp-2.4.18-3 ..... and possibly more If you don't have the ones listed above, then you'll need to redo the installation and make sure to select the "Kernel Development" package set. If you do, we'll move on. Now, we'll install the updated kernel and associated packages by running the following commands: # rpm -ivh kernel-2.4.18-10.i686.rpm (or) # rpm -ivh
kernel-smp-2.4.18-10.i686.rpm # rpm -Uvh kernel-source-2.418-10.i386.rpm Note the use of the "-ivh" for
the kernel and the "-Uvh" for the kernel-sources
packages. Presuming that you didn't see any dastardly errors during these steps, we'll activate the new kernel and reboot by the following steps. # vi /etc/lilo.conf Within this file are various entries corresponding to different kernel configurations, specifically related to SMP vs. non-SMP. There will be a section for each type. What you'll want to do is to duplicate the relevant section and change the 2.4.18-3 strings to 2.4.18-10. Within that new section, you should also change the label field to a new, unique name such as linuxnew. There cannot be 2 entries in here with the same label!!! Finally, change the default label in the beginning of the file to reflect the new name (linuxnew). Save that file and run: # lilo This will update some system files to reflect the changes and prepare for the next reboot. So, let's reboot using your favorite method. Once the system reboots, if all went correctly, you should now be looking at the login prompt displaying your new kernel version. If not, it's time to backtrack and discover what you did wrong. I'll wait...................... OK. Now it's time to move on to the Linux STREAMS (LiS) installation. LiS
Install First, remount the CD as earlier. Then, run the commands: # cd
/usr/src # tar -xzvf /mnt/cdrom/LiS-2.13.16.tgz # cd
LiS-2.13 # make This will begin the process of building and installing the LiS system. You'll be asked a series of configuration questions, which should all be answerable just by hitting Enter to take the default, except for the kernel source directory, which should be: /usr/src/linux-2.4 . Then the compiling of LiS will begin. Note that you'll see a lot of warnings about malloc.h being deprecated and to use slab.h instead. These can be safely ignored. # make install This copies the LiS utilities and libraries around to their proper places. Dialogic Installation Now, we're ready for the Dialogic 5.1 install (Finally!! :-). The CD should still be mounted from the earlier steps. Run: # cd
/mnt/cdrom # ./install.sh This begins the install process. Basically, you'll be presented with a menu of choices for packages. Items 1 and 2 are for Springware support and items 3 - 6 are for DM3. Here's where the homework that you did earlier in verifying the type of hardware that you have pays off. A word to the wise, unless you know specifically that you have Antares hardware, make sure to not select option 2. It creates some config file entries that will clutter your screen with all kinds of mean, nasty, ugly messages during initialization. Also, sadly, selecting All has the same effect. Normally, this would be the point where you would run config.sh as the screen instructs you to do. However, don’t! First, we need to install the SP1 package which includes updated drivers for Rd Hat 7.3. Basically, cd into the directory on your custom CD (or whatever) where you’ve got the SP1 packages and duplicate what you just finished above. That is, run install.sh (again) and after that finishes successfully you can then run: # ./config.sh You'll be asked if you've got any DM3 boards, then if you've got any Springware boards and finally whether you want to configure SNMP on the system. We're not going to discuss SNMP configuration in this HOWTO. If you selected that you have Springware boards, you’ll get an additional prompt: Will this system use ISA / board locator technology boards e.g., D/XXE, D/240SC-T1 boards? This question is a tad misleading in that what it’s really
asking is if you’ve got SCBus-type cards. If your
Springware cards have the SCBus/CTBus connectors on the back spline edge of the card, then answer “Yes” – otherwise
answer “No”. For cards such as the D/4PCI; the D/21H; D/41H; etc., answer “No”. Now, the system will begin rebuilding the LiS system with the Dialogic drivers hooked in. After that is finished, you'll be brought into one or more configuration tools, depending on the type of hardware that you've installed. We'll take them separately below. DM3 Configuration The configuration of DM3 boards under Linux revolves around correct configuration of the /usr/dialogic/cfg/pyramid.scd file. This is the DM3 equivalent of /usr/dialogic/cfg/dialogic.cfg for Springware boards.
Here, you're presented with a list of DM3 boards that the system has detected. NOTE: If you know for a fact that you've got DM3 hardware installed, but the config program shows you an empty list, then you most likely did not install the compat-libstdc++ package during installation. To verify that this is the case, switch to an alternate screen and run: /usr/dialogic/bin/listboards If you get an error about libstdc++, then you need to install that package from the Red Hat CD. In the DM3_cfg.sh script, basically just sequence through the different fields getting everything setup correctly. I know that's thin guidance, but configuring DM3 boards isn't easy and I encourage you to experiment (and RTFM, of course) with different configs until you get good and comfortable. To try your new configuration setup, run these commands in order. # /usr/dialogic/bin/dlstop # /usr/dialogic/bin/dlstart While dlstart is running, you'll see voluminous information scrolling across the screen. You'll have to watch it closely as it scrolls by to make sure that parts didn't fail. Once you've run it a few times with good and bad info, you'll be able to notice the differences between success and failure easily. Also, you can redirect the output of dlstart to a log file. DM3 Testing The best/only way to test DM3 hardware is via the few demo programs included that are DM3-capable. That is, essentially, /usr/dialogic/demos/gc_demos/gc_basic_call_model. (Named by the Ridiculously_long_and_complicated_program_naming group within Dialogic). To run that, run: # cd
/usr/dialogic/demos/gc_demos # vi gc_basic_call_model.cfg # Edit this file to reflect the boards/channels/protocols to test. If you don’t get this setup right, it won’t work!! # ./gc_basic_call_model If you get an error from gc_Start(), reboot the system. There are some library dependencies that get resolved at boot time.
And we should be off to the races!!!!!!!!!!!!!!!! Springware
Configuration Configuring Springware hardware can be done one of two ways: either through the mkcfg program, automatically invoked by the installation process if you selected Springware hardware, or by manually editing the /usr/dialogic/cfg/dialogic.cfg file. This file is created by running /usr/dialogic/bin/mkcfg if you want to invoke it later. Here again, the key is knowing your hardware and knowing how you want it configured. This is where the RTFM comes into play again. While you can configure the boards themselves, configuring specific protocols (like ISDN) requires manually editing the dialogic.cfg file mentioned above. The details on the format of the dialogic.cfg file are in the Software Installation Guide noted below. Springware
Testing The software furnished for testing Springware hardware is much broader and is really dependent on your hardware. Specifically, analog vs digital; ISDN vs robbed-bit, etc. However, you *can* (and should, actually) use the afore-mentioned gc_basic_call_model program which has the advantages of working with all hardware and all protocols. However there is also available: pansr - which works with analog and robbed-bit T1 with immediate start protocol. It’s located in /usr/dialogic/demos/dx_demos. The source code is there and you should take a look at the command-line options as they need to be set right or, surprise!, it won’t work. isdiag - a great PRI ISDN testing program in /usr/dialogic/bin sampletest - a stripped-down isdiag, but with source code in /usr/dialogic/demos/cc_demos Basically, you really should get your system working with a canned demo before jumping into your new, super-threaded, etc. custom program. It really helps to have a good baseline to start from. Further Reading (Trust me on this - it's well worth the
time to read this stuff) Root link for all Linux SR 5.1 Documentation http://support.dialogic.com/releases/unix51/linux51/SR5.1_Linux/Onldoc/html_files/index.html Release Guide http://support.dialogic.com/releases/unix51/linux51/release_guide/release_guide.html#P1426_77937 Software Installation Guide |
| [Prev in Thread] | Current Thread | [Next in Thread] |