Moving README.Astribank to dahdi-tools .

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@5402 a0bf4364-ded3-4de4-8d8a-66a801d63aff

1 files changed, 0 insertions, 1362 deletions

diff --git a/drivers/dahdi/xpp/README.Astribank b/drivers/dahdi/xpp/README.Astribank
deleted file mode 100644
index 1918268..0000000
--- a/drivers/dahdi/xpp/README.Astribank
+++ /dev/null
@@ -1,1362 +0,0 @@
-Xorcom Astribank Documentation
-==============================
-Xorcom Team <support@xorcom.com>
-$Revision$, $Date$
-
-This file documents the Dahdi drivers for the Xorcom Channel Bank.
-The drivers reside in a separate subdirectory, kernel/xpp/ .
-
-It is generally a more technical document than the 
-http://www.xorcom.com/documentation/manuals/[Astribank User Manual]
-
-An HTML version of the latest version of this document could be found at 
-http://docs.tzafrir.org.il/dahdi-linux/README.Astribank.html[]
-
-Building and Installation
--------------------------
-Building and installation is basically like the normal procedure of 
-installing Dahdi with some additions.
-
-Building drivers
-~~~~~~~~~~~~~~~~
-Apart from the standard Dahdi build requirements, you also need libusb
-development headers to build the fpga_load firmware loader. This is
-typically the package libusb-dev on Debian (and derivatives like Ubuntu)
-or libusb-devel on RedHat (and derivatives like CentOS/Trixbox).
-
-Sample Configurations
----------------------
-We generally recommend to generate the configuration by using utility
-genzaptelconf or zapconf which are included with Dahdi. Nevertheless,
-the following can serve as reference configurations for a system where 
-Astribank devices are used.
-
-
-xpp.conf: Astribank Initialization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/etc/dahdi/xpp.conf is read by the initialization modules of dahdi
-scripts.
------------------------------------------------------------
-# /etc/dahdi/xpp.conf
-#
-# This file is used to configure the operation
-# of init_card_* initialization scripts.
-#
-
-# Adds many more tracing messages that are sent to syslog:
-#debug		1
-
-# xpd_pri: E1 or T1. The default is E1 for all the ports.
-#   Setting T1 instead:
-#pri_protocol	T1
-#
-#  Or if you actually want to mix E1 and T1:
-#pri_protocol/xbus-00/xpd-02	T1
-#pri_protocol/connector:usb-0000:00:1d.7-7/xpd-03	T1
-#pri_protocol/label:usb:0000183/xpd-03	T1
-# If several definitions can refer to a port, the last wins. 
-# If none applies, the default of E1 holds.
-
-#  Don't run power calibration on the FXS units. This can save time
-#  but can also get you unit randomly disconnect, if badly used:
-#fxs_skip_calib	1
-
-#  FXO: country to adjust settings to:
-#opermode	ISRAEL
------------------------------------------------------------
-
-/////////////////////////////////////////////
-TODO: genconf_parameters, init.conf: need documentation?
-/////////////////////////////////////////////
-
-/etc/dahdi/system.conf
-~~~~~~~~~~~~~~~~~~~~~~
-
-Astribank 8
-^^^^^^^^^^^
-    fxoks=1-14
-
-Astribank 6FXS/2FXO
-^^^^^^^^^^^^^^^^^^^
-    fxoks=1-12
-    fxsks=13-14
-
-Astribank 16: 8FXS/8FXO
-^^^^^^^^^^^^^^^^^^^^^^^
-    fxoks=1-14
-    fxsks=15-22
-
-Astribank 4 BRI
-^^^^^^^^^^^^^^^
-    # Assumed ports settings:
-    # Ports 1,3: TE
-    # Ports 2,4: NT
-    span=1,1,1,ccs,ami
-    span=2,0,1,ccs,ami
-    span=3,2,1,ccs,ami
-    span=4,0,1,ccs,ami
-    bchan=1-2,4-5,7-8,10-11
-    dchan=3,6,9,12
-
-Astribank 4 PRI E1
-^^^^^^^^^^^^^^^^^^
-    # Assumed ports settings:
-    # Ports 1,3: TE (CPE)
-    # Ports 2,4: NT (Net)
-    span=1,1,1,ccs,hdb3,crc4
-    span=2,0,1,ccs,hdb3,crc4
-    span=3,2,1,ccs,hdb3,crc4
-    span=4,0,1,ccs,hdb3,crc4
-    bchan=1-15,17-30,31-45,47-60,61-75,77-90,91-105,107-120
-    dchan=16,46,76,106
-
-Astribank 4 PRI T1
-^^^^^^^^^^^^^^^^^^
-    # Assumed ports settings:
-    # Ports 1,3: TE (CPE)
-    # Ports 2,4: NT (Net)
-    span=1,1,1,esf,b8zs
-    span=2,0,1,esf,b8zs
-    span=3,2,1,esf,b8zs
-    span=4,0,1,esf,b8zs
-    bchan=1-23,25-47,49-71,73-95
-    dchan=24,48,72,96
-  
-
-/etc/asterisk/chan_dahdi.conf
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Astribank 8
-^^^^^^^^^^^   
-    [channels]
-    signalling=fxo_ks
-    ; The real analog ports:
-    context=from-internal
-    echocancel=yes
-    ; echocancelwhenbriged=yes
-    ; echotraining=no
-    channel => 1-8
-
-    ; output ports:
-    context=astbank-output
-    channel => 9-10
-    ; input ports:
-    immediate=yes
-    context=astbank-input
-    channel => 11-14
-    immediate=no
-
-Astribank 6FXS/2FXO
-^^^^^^^^^^^^^^^^^^^   
-    [channels]
-    signalling=fxo_ks
-    ; The real analog ports:
-    context=from-internal
-    echocancel=yes
-    ; echocancelwhenbriged=yes
-    ; echotraining=no
-    channel => 1-6
-
-    ; output ports:
-    context=astbank-output
-    channel => 7-8
-    ; input ports:
-    immediate=yes
-    context=astbank-input
-    channel => 9-12
-    immediate=no
-
-    ; FXO ports
-    signalling=fxs_ks
-    context=from-pstn
-    callerid=asreceived
-    channel => 13-14
-
-Astribank 16: 8FXS/8FXO
-^^^^^^^^^^^^^^^^^^^^^^^   
-    [channels]
-    signalling=fxo_ks
-    ; The real analog ports:
-    context=from-internal
-    echocancel=yes
-    ; echocancelwhenbriged=yes
-    ; echotraining=no
-    channel => 1-8
-
-    ; output ports:
-    context=astbank-output
-    channel => 9-10
-    ; input ports:
-    immediate=yes
-    context=astbank-input
-    channel => 11-14
-    immediate=no
-
-    ; FXO ports
-    signalling=fxs_ks
-    context=from-pstn
-    callerid=asreceived
-    channel => 15-22
-
-Astribank 4 BRI
-^^^^^^^^^^^^^^^    
-    ; Assumed ports settings:
-    ; Ports 1,3: TE
-    ; Ports 2,4: NT
-    [channels]
-    switchtype = euroisdn
-    callerid = asreceived
-    
-    ; TE ports:
-    signalling = bri_cpe_ptmp
-    ;signalling = bri_cpe
-    context = from-pstn
-    group = 1,11
-    channel => 1,2
-    
-    group = 1,13
-    channel => 7,8
-    
-    ; NT ports:
-    signalling = bri_net_ptmp
-    ;signalling = bri_net
-    context = from-internal
-    group = 2,12
-    channel => 4,5
-    
-    group = 2,14
-    channel => 10,11
-
-Astribank 4 PRI E1
-^^^^^^^^^^^^^^^^^^ 
-    ; Assumed ports settings:
-    ; Ports 1,3: TE
-    ; Ports 2,4: NT
-    [channels]
-    switchtype = euroisdn
-    callerid = asreceived
-    
-    ; TE ports:
-    signalling = pri_cpe
-    context = from-pstn
-    group = 1,11
-    channel => 1-15,17-30
-    
-    group = 1,13
-    channel => 61-75,77-90
-    
-    ; NT ports:
-    signalling = pri_net
-    ;signalling = pri_net
-    context = from-internal
-    group = 2,12
-    channel => 31-45,47-60
-    
-    group = 2,14
-    channel => 91-105,107-120
-
-Astribank 4 PRI T1
-^^^^^^^^^^^^^^^^^^ 
-    ; Assumed ports settings:
-    ; Ports 1,3: TE
-    ; Ports 2,4: NT
-    [channels]
-    switchtype = national
-    callerid = asreceived
-    
-    ; TE ports:
-    signalling = pri_cpe
-    context = from-pstn
-    group = 1,11
-    channel => 1-23
-    
-    group = 1,13
-    channel => 49-71
-    
-    ; NT ports:
-    signalling = pri_cpe
-    ;signalling = pri_net
-    context = from-internal
-    group = 2,12
-    channel => 25-47
-    
-    group = 2,14
-    channel => 73-95
-
-
-/etc/asterisk/extensions.conf
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sample dialplan (extensions.conf) for all the above:
-
------------------------------------------------------------
-[phones-dahdi]
-; With Asterisk 1.4 you will may need to use here 'Zap' instead of
-; DAHDI. See Zaptel-to-DAHDI.txt .
-;
-; 6001 will dial to channel 1, 6020, to Dahdi channel 20, etc.
-exten => _6XXX,1,Dial(DAHDI/${EXTEN:1})
-; Useful for debugging trunks. Will potentially allow users to
-; bypass context limitations.
-;exten => _6XXX.,1,Dial(DAHDI/${EXTEN:1:3}/${EXTEN:4})
-
-[trunk]
-; A number that begins with 9: dial it through a trunk
-; (we put FXO channels and TE channels in group 0).
-; The leading 9 is stripped.
-exten => _9.,1,Dial(DAHDI/g0/${EXTEN:1})
-; dialing a number that begins with 83 will dial it through
-; span 3, and so forth. The two leading digits are stripped.
-; (Each digital span is also added to group 10+span number).
-exten => _8X.,1,Dial(DAHDI/g1${EXTEN:1:1}/${EXTEN:2})
-
-[from-internal] 
-; The context of FXS ports: analog phones.
-; They are allowed to dial to all other phones 
-include => phones-zap 
-; They are also allowed to call through the trunk: 
-include => trunk
-; some simple tests:
-include => astbank-test
-
-[from-pstn] 
-; Calls from the PSTN enter here. Redirect calls to an IVR 
-; or a default extension in the s context here. In this case we  
-; redirect calls to Dahdi channel 1: 
-exten => s,1,Dial(DAHDI/1) 
-
-; Alternatively, the following will redirect you to the demo IVR 
-; from the sample extensions.conf of Asterisk:
-include => demo
-
-; An extra context with some simple tests
-[astbank-test]
-; 200: echo test
-exten => 200,1,Answer
-exten => 200,n,Wait(1)
-exten => 200,n,Echo()
-exten => 200,n,Hangup
-
-; 203: say extension number. Will only work if caller ID 
-; is properly set in zapata.conf / zapata-channels.conf
-exten => 203,1,Answer
-exten => 203,n,Wait(1)
-exten => 203,n,SayNumber(${CALLERID(num)})
-exten => 203,n,Hangup
-
-[astbank-input] 
-exten => s,1,Set(DAHDI_CHAN=${CUT(CHANNEL,-,1)}) 
-exten => s,n,Set(DAHDI_CHAN=${CUT(DAHDI_CHAN,/,2)}) 
-; 11 is the number of the first input port. At least in the sample 
-; configuration below. 
-;exten => s,n,Set(INPUT_NUM=$[${DAHDI_CHAN}-11)]) 
-; The sample below just logs the signal.  
-exten => s,n,NoOp(Got signal from Dahdi Channel ${DAHDI_CHAN}) 
-; Alternatively: 
-;exten => s,n,System(run something) 
-
-; No. We did not forget the context astbank-outputs. Output 
-; ports only get calls from the PBX. Thus they don't need a context 
-; of their own. Sending them to a context of their on makes 
-; 'zap show channels' in the CLI provide useful display, though.
------------------------------------------------------------
-
-
-
-
-Troubleshooting
----------------
-The following commands provide useful information for debugging:
-
-lsusb Test
-~~~~~~~~~~
-Check USB level status. You can use one of the following utilities for it:
-
-  dahdi_hardware -v
-       or
-  lsusb | grep e4e4
-
-- Look for the USB Product ID (the second number after e4e4).
-- If you see *11x2* (e.g: 1152)- the FPGA firmware has been loaded.
-  Move on.
-  dahdi_hardware will also show you some more details if the driver
-  is loaded while the lsusb will just list the device.
-- If it shows something as product ID *11x0* - the USB firmware is not
-  loaded. Maybe you need to run fxload. Or maybe just unplug and plug again
-  the device. Also make sure that you have fxload installed.
-- If lsusb shows the Product ID as *11x1* - only the USB firmware is loaded 
-  and not the FPGA firmware is loaded. If this is still the case after 
-  a while - either the firmware loading has failed or you don't have
-  fpga_load. Make sure you have libusb-dev(el) installed when
-  building Dahdi. After you have installed it, you may need to re-run
-  ./configure .
-- It should list all of your Astribank devices. If it doesn't (for
-  more than period of time needed for the initial firmware
-  loading) - Check that the Astribank is connected indeed.
-
-
-DAHDI Registration
-~~~~~~~~~~~~~~~~~~
-Check if the Astribank spans are registered in DAHDI:
-
-  dahdi_registration
-
-- This should give useful results after the drivers have identified
-  and your devices are initialized.
-- It should list all Astribank XPDs. For each of them it should write
-  "on" or "off". If the registration status is "off", then it means that
-  the span has not been registered in Dahdi and therefore can not be used
-  yet.
-- Registration is normally done as part of `/etc/init.d/dahdi start`.
-  If you want to register the spans manually, then run command:
-  `dahdi_registration on` .
-- Disabling of the automatic Astribank spans registration give you full
-  control on the order of Dahdi spans. See the module parameter
-  **zap_autoreg** for the further details.
-
-
-DAHDI Level Information
-~~~~~~~~~~~~~~~~~~~~~~~
-You can get some information regarding Dahdi channels by running one of the
-following commands:
-
-    lsdahdi
-       or
-    cat /proc/dahdi/*
-
-- Those two are almost the same. The lsdahdi produced more correctly sorted
-  output if you have more than 10 spans, and also make the output listing
-  looks a little bit nicer.
-- You can see if your Dahdi spans and channels were loaded, if
-  they were configured by dahdi_cfg and if they are in use (typically by
-  Asterisk).
-  For example:
-  Not configured Astribank FXS channel will be displayed as:
-
-     42 FXS
-
-- When a channel has been configured with *dahdi_cfg* (that applies
-  /etc/dahdi/system.conf), you will see an extra column for the signalling
-  type of the channel. The same channel after it has been configured:
-
-    42 FXS        FXOKS
-
-- If a program (which is typically Asterisk) uses it, you'll see:
-
-    42 FXS        FXOKS      (In use)
-
-
-
-Asterisk Level Information
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-  asterisk -rx 'dahdi show channels'
-
-- If you get error "Unable to connect to remote asterisk" then it
-  means that the Asterisk is not running. It is possible that Asterisk
-  has failed to start due to misconfigured zapata.conf or whatever reason.
-  Check /var/log/asterisk/messages or /var/log/asterisk/full .
-- If you get the error that "there is no such command" then it means that
-  chan_zap.so is not loaded. There are two reasons for such problem:
-  * chan_zap.so is not even built. Check if the file exists:
-
-       ls -l /usr/lib/asterisk/modules/chan_dahdi.so
-
-  * the chan_zap.so file exists but it is not loaded. Try to load it manually:
-
-       asterisk -rx 'load module chan_dahdi.so'
-
-- You see "pseudo" channel only. It means that you have not configured any
-  channels. If you have configured channels in zapata.conf, you may
-  need either to restart the Asterisk or unload/load chan_zap.so manually.
-  You can use the following Asterisk CLI commands for it: `unload chan_zap.so` 
-  and `load chan_zap.so`
-
-
-Known Issues
-~~~~~~~~~~~~
-Empty /proc dir
-^^^^^^^^^^^^^^^
-.Symptoms:
-- Error message:
-
-  "ERR-xpd_fxo: XBUS-00/XPD-00: Failed initializing registers (-22)"
-  
-- Likewise for all XPDs. 
-- The directory /proc/xpp exists but is empty (not even the files 
-  'xbuses' and 'sync').
-
-.Cause:
-The driver failed to recreate the procfs directory /proc/xpp and hence
-everything under it. This is because it has already existed. And it
-existed because a process still uses it. This is typically because you
-have a shell whose working directory is /proc/xpp or somewhere under
-it:
-
-  # lsof /proc/xpp
-  COMMAND  PID USER   FD   TYPE DEVICE SIZE       NODE NAME
-  bash    2741 root  cwd    DIR    0,3    0 4026532684 /proc/xpp
-
-.Fix:
-Move that process from that directory, or close the file it uses from
-under /proc/xpp and reload the dahdi / xpp drivers.
-
-
-Bad Firmware Version
-^^^^^^^^^^^^^^^^^^^^
-.Symptoms:
-- An Astribank finishes initialization quickly, the /proc/XBUS-nn
-  directory has no XPD-mm subdirectories.
-- Error in the kernel logs about:
-
-  NOTICE-xpp: XBUS-00: XPD at 00: type=6.0 has bad firmware revision 2.6 
-
-.Cause:
-This is normally caused by an Astribank with an older firmware connected
-to a 
-
-The protocol version supported by the firmware will typically be the same 
-one as in the device initialization scripts installed to 
-/usr/share/dahdi . Hence if this version installed 
-`/usr/share/dahdi/init_card_3_29` it will probably include firmware of 
-protocol version 29.
-
-.Fix:
-Reset the firmware:
-
-  /usr/share/dahdi/xpp_fxloader reset
-
-Or disconnect the Astribank from the power and reocnnect. On some older 
-versions of the USB firmware resetting the firmware (or any operation of 
-fpga_load) would fail if the driver is loaded. Hence you would need to 
-run `rmmod xpp_usb` . In the end, reload the drivers.
-
-
-USB Errors at Shutdown
-^^^^^^^^^^^^^^^^^^^^^^
-.Symptoms:
-You see USB-related errors similar to the following whenever you shut
-down the drivers of the Astribank or disconnect its drivers:
-
-  ERR-xpp_usb: XBUS-00: Failed to submit a receive urb
-
-.Cause:
-This is a normal part of the shutdown of the USB connection. 
-
-.Fix:
-Ignore them. Unless the USB should not have disconnected at that time.
-
-
-BRI Layer 1 Down
-^^^^^^^^^^^^^^^^
-.Symptoms:
-With the BRI module only, and not in the middle of an active call, you
-notice that suddenly the line goes down. The LED of the port stops
-blinking, layer1 not listed as "active" in the bri_info file in
-/proc/xpp, and the span is in RED alarm in Dahdi.
-
-You may also see an error message such as:
-
-  NOTICE-xpd_bri: XBUS-00/XPD-02: D-Chan RX Bad checksum: [2A:01=FC] (252)
-
-from the exact time of the disconnecting.
-
-.Cause:
-This is expected with most european BRI PtMP providers. If they support
-PtMP, they are normally also expected to support ISDN phones, that get
-the power from the provider. And thus they shut down the line whenever
-there's no active call. 
-
-Sometimes the line is shut down in the middle of a layer 2 message. In
-the BRI driver the HDLC decoding/encoding is done in the card. In that
-case we may get the above error.
-
-.Fix:
-Normaly this is not a problem. The driver will re-establish a connection
-once a new call needs to be made.
-
-
-Both default and sysconfig Exist
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.Symptoms:
-The firmware fails to load. Manually running xpp_fxloader gives:
-
-  Both '/etc/default/zaptel' and '/etc/sysconfig/zaptel' exist
-
-Alternatively: an initialization script fails and gives the error
-
-  An '/etc/default/zaptel' collides with 'etc/sysconfig/zaptel'
-
-.Cause:
-/etc/default/<service name> is the place used in Debian-based 
-systems for initialization scripts. /etc/sysconfig/<service name> is
-used in Redhat and similar for the same purpose. For historical reasons
-many of our programs read configuration from there: either from
-/etc/default/zaptel or from /etc/sysconfig/zaptel .
-
-The problem is what to do if both of those exist. Selecting an arbitrary
-one can lead to unexpected results. Likewise sourcing both of them.
-Therefore we prefer to fail in a noisy and expected way. In the future
-we will probably me to reading configuration from a file under /etc/dahdi .
-
-.Fix:
-Remove one of those two. There should be no reason to have both on the
-same system.
-
-
-Astribank not initialized: Premature packet end
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.Symptoms:
-After upgrading to Zaptel 1.4.12 / 1.2.25 the initialization of the
-Astribank times out. In the logs you see:
-
-  kernel: NOTICE-xpp: XBUS-00(00): FIRMWARE: ERROR_CODE CODE = 0x3 (Premature packet end) 
-
-.Cause:
-When an Astribank is detected, the driver asks it what is its version
-and what components it has. Normally if the version of the firmware and
-of the driver does not match the driver gives an ugly message and fails
-the initialization.
-
-However in the change of the protocol between versions 2.9 (29) and 3.0
-(30), the response that the new driver recieves from a device with the
-old version is now considered to be an illegal packet and gets
-discarded. As a result, the Astribank waits till time-out for the
-initilization to end.
-
-.Fix:
-Reset the firmware of the Astribank by either:
-
-  /usr/share/dahdi/xpp_fxloader reset
-
-or disconnecting it from the power and reconnecting it.
-
-
-Reference
----------
-LEDs Indication
-~~~~~~~~~~~~~~~
-The Astribank has 4 global indication leds and one or two per-port leds.
-On some of the models the LEDs are located on the left side on the front
-panel. If there are no separate LEDs there, then the red LEDs of the
-upper left-most ports of the device are used as the indication LEDs. Don't 
-confuse them with green port status LEDs.
-
-The first led is the "Power" led. It is on if the unit gets power.
-The second led is the "Active" led, which is on when there is at 
-least one "active" port (in a call / off-hook, though the meaning of this is 
-different in BRI).
-The last led is called "Hardware OK", but is actually only is on in case of  
-the hardware failure.
-
-The third led is the "Sync" led. If it blinks, the device is synchronized 
-with the driver on the computer. If the device is selected to be the  
-synchronization source for all of the Astribank devices then it will blink
-a quick single blink.
-If the device gets synchronization from the driver, it will blink in a 
-more steady frequency.
-
-"Double blink" indicates that the unit has an FXO module, and still is
-getting synchronization from the computer, and is not the synchronization
-source.
-
-The per-port green led on analog (both FXS and FXO) indicates that the
-port is off-hook.
-
-On the BRI, the green led indicates a TE port whereas an orange led
-indicates an NT port. If the led is solid, the port is down (not even
-layer-1 connection is up). If it is blinking a double blink, layer 1
-is up. A slower single blinking indicates that layer 2 is up as well
-(which means that Asterisk is driving the port).
-
-
-PRI Ports Configuration
-~~~~~~~~~~~~~~~~~~~~~~~
-Astribank PRI module has two RJ-45 sockets for each PRI port. The lower
-socket provides typical PRI CPE side wiring: Rx- pins 1,2; Tx - pins 
-4,5. The upper socket provides typical PRI Network side  wiring: Rx- pins
-4,5; Tx - pins 1,2. The both sockets are permanently active and you can 
-use any of them regardless of any configuration parameters (Both
-connectors are live. And connecting both of them with a flat 8-wire
-ethernet cable is a simple way to do a loop test for the port).
-
-
-For each port there are two optional parameters that define its
-behavior:
-
-Each port in the PRI module can be configured either as E1 or T1. The
-port type defaults to E1 and can be changed to T1 in the Dahdi Init 
-Configuration File.
-
-The Astribank xpp driver uses that information for correct hardware
-initialization that is performed before the Dahdi span registration
-process takes place. Because of that, xpp driver can't use the 
-information from file /etc/dahdi/system.conf.
-
-Another parameter that also can be defined in the Dahdi Init
-Configuration File is the function group TE (CPE) or NT (Network). This
-parameter is used for (a) building correct Dahdi & Asterisk
-configuration by genzaptelconf and (b) control RJ-45 sockets LEDs for 
-better visual port control:
-
-A port in the PRI module can be either E1 (default) or T1. It can also be 
-either "TE" (default) or "NT".
-
-TE::
-  Green LED of the lower socket will light. Hint that this is a TE
-  (CPE) port. This is the default.
-
-NT::
-    Orange LED of the upper socket will light. Hint that this is an
-    NT (network) port.
-
-//////////////////////////////////////////////////
-FIXME: Update for DAHDI
-//////////////////////////////////////////////////
-To set them to a non-default value, you should use the variable
-XPP_PRI_SETUP in the 
-xref:dahdi_init_configuration_file[Dahdi Init Configuration File]
-(/etc/sysconfig/zaptel on Redhats, /etc/default/zaptel on Debians).
-This value is a whitespace-separated list of conditions. When a port is 
-initialized it checks those conditions and uses the first one that 
-matches.
-
-Match expressions may be:
-- CONNECTOR/usb..../XPD-nn	To identify by physical connector
-- NUM/XBUS-mm/XPD-nn		To identify by bus number
-
-Match expressions may contain "wildcards":
-
-- * matches zero or more characters.
-- ? matches one charater
-- [xyz] - any of 'x', 'y', or 'z'.
-
-For each line you should define both if it is E1 or T1 and if it is NT
-or TE.
-
-The list implicitly contains an 'NUM/*=TE,E1' catch all default, appended
-to its end.
-
-A number of useful examples. Note that you should use just one of them.
----------------------------------------------
-# All ports are E1 and CPE
-#XPP_PRI_SETUP=  #no need to set it
-
-# All ports are T1 and CPE:
-XPP_PRI_SETUP='NUM/*=T1,TE'
-
-# Now you want to test a loop between ports 1 and 2 and between 
-# port 3 and 4. So let's make ports 2 and 4 network:
-XPP_PRI_SETUP='NUM/*/XPD-0[24]=E1,NT'
-
-# The same with T1. In this case we also need to set the default of all 
-# the others to T1. Note that we can use more than one item and the
-# first one that matches counts:
-XPP_PRI_SETUP='
-  NUM/*/XPD-0[24]=T1,NT
-  NUM/*=T1,TE
-'
-
-# Actually, there is an implicit 'NUM/*=E1,TE' added to the end of the
-# value and set as the value if there is none. This is how the default
-# is set.
-
-# If you have more than one Astribank and you wish to configure
-# different Astribanks differently, you can use the CONNECTOR option:
-# e.g: set one specific Astribank as E1 network. The others default to
-# E1 CPE:
-XPP_PRI_SETUP='CONNECTOR/usb-0000:00:10.4-4/*=E1,NT'
-
-# Theoretically you could use: XPP_PRI_SETUP='NUM/XBUS-01/*=E1,NT'
-# but the XBUS number depends on the specific load order and is thus
-# might differ in a manual load and a system boot.
----------------------------------------------
-
-This is currently implemented by writing a value to the 
-xref:_proc_xpp_xbus_nn_xpd_mm_pri_info[pri_info file in procfs], but
-that may change in future versions.
-
-
-Device Startup
-~~~~~~~~~~~~~~
-This section describes in great depth the initialization of the Xorcom
-Astribank. Normally it would not be really needed, as the standard
-installation of Dahdi should put everything in place.
-
-Terminology
-^^^^^^^^^^^
-There are some technical terms that are used in this document and in the
-driver / dahdi.
-
-span:
-Dahdi breaks the channels it knows about to logical units called
-"spans". A port in a E1/T1/ISDN card is usually a span. An whole
-analog card is also a "span". You can see the list of spans as the list
-of files under /proc/dahdi directory or in output of the dahdi_tool
-utility.
-
-XBUS:
-A funny way to call an Astribank device.
-
-XPD:
-Basically this is a logical unit of the Astribank. It will be registered in
-Dahdi as a single span. This can be either an analog (FXS or FXO)
-module or a single port in case of a BRI module.
-
-
-Loading Firmware
-^^^^^^^^^^^^^^^^
-Normally this is done using the script /usr/share/dahdi/xpp_fxloader.
-If it works fine, you don't need to bother reading this section.
-Once the firmware is loaded the USB Vendor ID and Product ID of the Astribank
-became to be e4e4 11x2, and now the driver can pick it up.
-
-First and foremost: the simplest and most useful tool to debug problems
-is lsusb. The output of lsusb should show you if the device is connected
-if its firmware is loaded. 
-
-The firmware files are named *.hex. They are presented in the text
-hexadecimal format The files are copied from xpp/utils to /usr/share/dahdi
-folder during the Dahdi installation.
-
-The Astribank needs a firmware loaded into it. Without the firmware, 
-the device will appear in lsusb with Vendor ID e4e4 and Product ID 1130.
-The firmware loading process consists of two stages. In the first stage the
-"USB" firmware is loaded by using program fxload. When the first stage is
-completed the Vendor ID is e4e4 and the Product ID is 1131.
-
-You can use the following command in order to load the "USB" firmware
-manually:
-
-  fxload -t fx2 -D /proc/bus/usb/MMM/NNN -I /usr/share/dahdi/USB_FW.hex
-
-where,
-
-fxload::
-  A standard program that is typically part either of package 'fxload' 
-  or 'hotplug-utils' . 
-/proc/bus/usb::
-  The mount point of the USB file-system (usbfs).
-MMM::
-  the first number (bus number)
-NNN::
-  the second number (device number) you see for the device in lsusb
-
-If the loading process has been completed successfully, the device 
-disconnects and then connects again itself with USB Product ID 1131 
-(and a new device number).
-
-In the second stage, the "FPGA" firmware is loaded.
-The second-stage firmware loading is performed by using program fpga_load, 
-which is built in the directory xpp/utils and then copied to folder 
-/usr/sbin during Dahdi installation.
-
-The command syntax is similar to the syntax of fxload. You can use the 
-following command in order to load the FPGA firmware manually:
-
-  fpga_load -D /proc/bus/usb/MMM/NNN -I /usr/share/dahdi/FPGA_1151.hex
-
-Please note, that  NNN value differs from that that was used for the 
-fxload command due to the fact that device has "reconnected" itself 
-with another Product ID number. So you need to run lsusb again and get 
-the new NNN value. Usually, the new value is equal to the old value 
-incremented by 1.
-
-
-Firmware Loading with Hotplug
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Hotplug framework was popular for hot-plugging different devices and 
-usually also for automatic device drivers loading. If Hotplug is used in 
-your system, you'll see many files in folder /etc/hotplug. Hotplug will 
-automatically load the most relevant USB and PCI kernel modules according 
-to the USB and PCI IDs provided by devices. Please note, that if the 
-Hotplug framework is in place and the correct configuration files are 
-located in the right place, then the firmware should be loaded automatically.
-
-In order to get the Hotplug framework to load the firmware into the 
-Astribank automatically, the configuration file xpp_fxloader.usermap and
-the script xpp_fxloader should be copied into /etc/hotplug/usb/ . This is 
-done by 'make -C xpp/utils install'.
-
-File xpp_fxloader.usermap includes a map of USB IDs and the command to run 
-when such devices are encountered. It instructs the Hotplug to run the script 
-xpp_fxloader from that directory. This is also done by 'make -C
-xpp/utils install' .
-
-When xpp_fxloader is run without any parameters it assumes that it was
-run by the hotplug scripts. Then it will check if the "add" event was 
-accepted and if so, xpp_fxloader will install the required firmware file. 
-The xpp_fxloader will be called twice, as after the load of the USB 
-firmware the device will re-enumerate itself and thus "unplug" and 
-"replug" in order to load the FPGA firmware.
-
-
-Firmware Loading with UDEV
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-The UDEV framework has replaced Hotplug in most recent systems. If you
-have a recent 2.6 system without Hotplug and with many files in folder
-/etc/udev, then there are good chances that are you using udev.
-As in case of Hotplug, if your udev framework is configured properly
-then the firmware should be loaded automatically.
-
-In order to get udev to automatically load the firmware into the Astribank, 
-the configuration file xpp.rules should be copied into folder /etc/udev/rules.d 
-and the script xpp_fxloader should be copied into folder /etc/hotplug/usb/ . 
-This is done by 'make -C xpp/utils install' during Dahdi installation.
-
-File xpp.rules instructs the udevd daemon to run xpp_fxloader script with
-the option "udev" and with the Astribank USB ID obtained from the 
-device when it is plugged in.
-Please note, that exactly like in case of Hotplug, the xpp_fxloader will be
-called twice by the udevd. First time for the USB firmware loading and the 
-second time for FPGA firmware loading.
-
-
-Firmware Resetting
-^^^^^^^^^^^^^^^^^^
-Newer versions of the USB firmware can now be reset using 'fpga_load -r'.
-
-Also you can try the following:
-
-  /usr/share/dahdi/xpp_fxloader reset
-  # if asterisk was running: you may need to stop/restart it now. 
-  # if there are some "disconnected" spans in /proc/xpp/xbuses
-  # wait a while, until you see the 1152 IDs again, and then:
-  /etc/init.d/dahdi start
-  # and start/restart asterisk.
-
-
-Loading The Modules
-^^^^^^^^^^^^^^^^^^^
-Here is what should happen:
-In short: you should plug the Astribank device(s) or have them plugged in at
-the boot time. Then all the modules should be loaded automatically.
-You will see xpp_usb , xpd_fxs and, possibly, xpd_fxo in the modules list
-(the output of lsmod).
-
-After the module xpp is loaded, you'll also be able to see the directory
-/proc/xpp. For any Astribank device discovered, you will see there a 
-directory /proc/xpp/XBUS-n (where n is a number: typically 0). Once a unit have
-been discovered you'll see subdirectories: /proc/xpp/XBUS-n/XPD-m (where
-m may be another number: 0, 1 ,etc).
-
-Now to the ugly details:
-
-The driver of the Astribank is composed of several modules: 
-
-* xpp     - the basic module, that communicates with Dahdi and provides
-            some common services to other modules.
-* xpd_fxs - the module for controlling FXS modules.
-* xpd_fxo - the module for controlling FXO modules. 
-* xpd_bri - the module for controlling BRI modules. 
-* xpd_pri - the module for controlling E1/T1 modules. 
-* xpp_usb - the module that holds the functionality needed to connect to the
-            USB bus.
-
-All modules depend on xpp, and modprobing them will install xpp as well.
-However the xpd_* modules are installed on-demand: no need to install
-the xpd_fxo if you have only Astribank FXS.
-
-Once an Astribank device connected and the firmware is loaded, the
-Vendor-ID/Product-ID of the device will be  e4e4/1132 . The handler for that
-combination is listed as the kernel module xpp_usb. Therefore, the system
-runs 'modprobe xpp_usb' if that module is not already loaded.
-
-The module xpp_usb depends on the dahdi and xpp modules. Both of them 
-are loaded before xpp_usb. As usual, parameters and rules form
-/etc/modprobe.conf and/or from /etc/modprobe.d/* will be applied to 
-the module.
-
-When command 'modprobe xpp_usb' returns, the span type specific modules
-(e.g., xpd_fxs, xpd_fxo) may or may not have been loaded yet.
-
-At this point the xpp driver "asks" the box about its software
-(firmware) version) and the type of telephony modules it has. According 
-to the answers it receives, the xpp driver will "modprobe" the required 
-xpd_* modules. 
-
-
-Device Initializations Scripts
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The chips in the device need to be initialized. This requires sending a
-bunch of values to certain registers in those chips. We decided that
-hardwiring those values in the driver code is not a good idea.
-Before registering a XPD as a span in Dahdi, we run an initialization
-script: /usr/share/dahdi/init_card_N_MM (
-where,
-
-* N  - is 1 for an FXS span and 2 for an FXO span, 3 for BRI and 4 for PRI.
-* MM - is a version number. Currently it equals 30.
-
-Those scripts must be executable. Funny things happen if such a script
-exists but is not executable.
-
-If because of some reasons this fails (the script is not in the place, or the
-file doesn't have the executable permissions), then you will get an error 
-message in the logs and the XPD will then be removed (you won't see directory
-for that XPD under the corresponding /proc/xpp/XBUS-* directory) and will not
-be registered in Dahdi.
-
-As the XPD is initialized, you'll see the green LEDs of the ports steadily 
-turn on and later off ("a train of lights"). This is a bit slower than the 
-faster "blinking" when the XPDs register as Dahdi spans. The initialization 
-of an FXS XPD may take a few seconds.
-
-
-Registering in DAHDI
-^^^^^^^^^^^^^^^^^^^^
-The XPDs will not automatically register as Dahdi spans. This is
-intended to allow you to set the registration order (and hence the order
-of Dahdi spans and channels) among multiple Astribank devices,
-or between an Astribank and a different Dahdi device.
-
-When the XPD registers to Dahdi, all the green LEDs will be lit for a
-short while. 
-
-Spans are normally registered with the utility dahdi_registration. Simply
-running 'dahdi_registration' shows the available XPDs and whether or not
-they are registered. To register: 
-
-  dahdi_registration on
-
-For a system with several spans you'll see a "fast train of lights".
-
-If you have multiple Astribank devices, dahdi_registration will register
-them by the order of the "connector" field. This means that as long as
-the same Astribank is connected to the same port, the order of plugging
-is not important..
-
-dahdi_registration checks if a span is registered or tries to register a
-span using the file /proc/xpp/XBUS-nn/XPD-mm/dahdi_registration . Reading
-from that file returns 0 if the span is unregisters or 1 if it is
-registered. You can register a span or ask to unregister it by writing 1
-(register) or 0 (unregister) to that file. Registration should
-generally always succeed. Unregistration may fail if a span is in use.
-
-You may choose to register the XPDs in Dahdi automatically. This may
-make the startup sequence a bit simpler, but is generally not
-recommended on a system with more than one Astribank or an Astribank and
-a different Dahdi device. This behavior may be defined by setting 
-parameter zap_autoreg in the modprobe configuration file (A file under 
-/etc/modprobe.d or /etc/modprobe.conf):
-
-  options xpp zap_autoreg=1
-
-
-DAHDI And Above
-^^^^^^^^^^^^^^^
-From here you get a standard Dahdi span. It still needs to be
-configured by dahdi_cfg and used by a program such as Asterisk like any
-other Dahdi device. In order for you to get a dial-tone in a phone
-connected to the FXS port or a fully synchronized BRI port (layer 2
-activated, as signalled by a more steady blink) you will actually need
-both the span configured by Dahdi and the channels configured in
-Asterisk.
-
-You should generally refer to the general Dahdi documentation on how to
-configure those levels. e.g, the README file in the top-level directory,
-and
-
-  http://voip-info.org/wiki/view/Asterisk+config+zapata.conf[]
-
-
-Dahdi now includes a utility called genzaptelconf (written as a big
-ugly shell script) to configure Dahdi automatically as good as
-possible. For analog channels it works quite well (because, IMHO, the
-"configuration" level on Dahdi should be optional there - there are
-already sane defaults). For digital spans - BRI and PRI , it may take
-some tuning.
-
-Alternatively, write you own configuration, based on the sample from the
-"Sample Configurations" section.
-
-
-/proc Interface
-~~~~~~~~~~~~~~~
-The Astribank drivers provide their own /proc interface under /proc/xpp.
-Here we review the more useful details of the procfs interface. There
-are many other debugging details that are exposed through the procfs
-interface. 
-
-Also note that those details are subject to changes. Generally the
-recommended stable interface are the Dahdi-perl utilities from the
-xpp/utils directory.
-
-
-/proc/xpp/xbuses
-^^^^^^^^^^^^^^^^
-File /proc/xpp/xbuses lists the connected Astribank devices (one line 
-per device).
-
-A device is normally has status "connected". The status "missing" means that
-the device has been disconnected, but Asterisk still holds channels from it
-open.
-
-
-/proc/xpp/sync
-^^^^^^^^^^^^^^
-A read/write file. It contains information about current synchronization 
-source. You can change the synchronization source by writing special 
-command to the file. For example, command
-   echo SYNC=01 > /proc/xpp/sync
-
-Possible values are:
-
-<number>::
-  Make the Astribank XBUS-<number> the sync source for other Astribanks.
-
-DAHDI::
-  Make the Astribanks synchronize with the Dahdi timing master span.
-  You probably need this to get faxes from a non-Astribank adapter to an
-  Astribank.
-
-Though you'll normally use xpp_sync(8) for that.
-
-For each Astribank device there is folder /proc/xpp/XBUS-nn and for each device
-module (span in the terms of Dahdi) there is folder /proc/XBUS-nn/XPD-mm.
-
-
-/proc/xpp/XBUS-nn/waitfor_xpds
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Reading from this file only returns when the Astribank has finished
-initialization of the XPDs or in case of a timeout. It prints the number
-of XPDs to initialize, and the number initialize. Unless something went
-wrong, those two numbers are the same. Once the span was initialized,
-reading from this file returns immediately:
-
-  XPDS_READY: XBUS-00: 3/3
-
-
-/proc/xpp/XBUS-nn/XPD-mm/dahdi_registration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-is a read/write file. Reading from it gives 0 if the span is
-unregistered, or the span number if it is registered.
-
-Writing to it allows manual registration / unregistration from Dahdi:
-writing 1 registers a span (if it wasn't already registered) and writing
-0 attempts to unregister it (if it is registered.  Span unregistration 
-will fail if some channels from the span are used  (e.g: by Asterisk).
-
-A more convenient interface to this is the command dahdi_registration that
-registers or unregisters all the spans at once with a predefined order,
-and this is what you should normally use.
-
-Alternatively you can use the parameter zap_autoreg to register spans
-automatically. But this is only recommended on a system with a single
-Astribank and no other Dahdi device.
-
-
-/proc/xpp/XBUS-nn/XPD-mm/summary 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Contains detailed information about port statuses of the device module 
-(off-hook, on-hook etc.) For example, you can run the following command
-in order to monitor the port statuses in the real time:
-
-  watch -n1 cat /proc/xpp/XBUS-00/XPD-00/summary
-
-
-/proc/xpp/XBUS-nn/XPD-mm/slics
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Provides direct read/write interface to the registers of each chip. 
-Reading from the file shows the result of the last read request. To make
-either a read request or a write request you need to write to that file.
-
-It is mainly used by the initialization scripts (card_init_*).
-
-Incorrect usage of this file is one possible way of damaging the
-Astribank.
-
-
-/proc/xpp/XBUS-nn/XPD-mm/fxo_info
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Only for FXO modules. Apart from showing the status of the LEDs, it also
-shows for each FXO port if it is connected to a provider: look for the
-value of "battery" for that specific port, and a bunch of other
-characteristics of the port.
-
-
-/proc/xpp/XBUS-nn/XPD-mm/bri_info
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In addition to the usual information about the LEDs, this file also
-provides useful information regarding ISDN Layer 1 and Layer 2 status.
-For example, you can run the following command in order to monitor
-the Layer 1 port statuses for all BRI devices in the real time:
-
-  watch -n1 -d 'grep "Layer 1:" /proc/xpp/XBUS-*/XPD-*/bri_info'
-
-For the status of the D channel of the ports on all BRI spans, run:
-
-  watch -n1 -d 'grep D-Channel: /proc/xpp/XBUS-*/XPD-*/bri_info'
-
-
-/proc/xpp/XBUS-nn/XPD-mm/pri_info
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In addition to the usual information about the LEDs, this file also
-provides useful information regarding ISDN Layer 1 and Layer 2 status.
-For example, you can run the following command in order to monitor
-the Layer 1 port statuses for all E1/T1 devices in the real time:
-
-  watch -n1 -d 'grep "Layer 1:" /proc/xpp/XBUS-*/XPD-*/pri_info'
-
-For the status of the D channel of the ports on all PRI spans, run:
-
-  watch -n1 -d 'grep D-Channel: /proc/xpp/XBUS-*/XPD-*/pri_info'
-
-Note: the layer 2 status is much more of a guesswork based on changes in
-the contents of the channel that is supposed to be the D channel.
-
-Writing to this file can be used to change the type of the device. The
-device type can only be changed when the XPD is not registered as a
-Dahdi span. The value is a whitespace-separated list of values that can 
-be of:
-
-E1::
-  Provides 31 channels, of which channel 16 is normally the D-channel. 
-  Common in places outside of North America and Japan. This is the 
-  default setup.
-
-T1::
-  T1 provides 24 channels. The last one is normally the D-Channel.
-  Common in North America.
-
-TE::
-  Use the bottom port (green LED) and don't invert any wiring. Hint to
-  higher layers that this will be the TE side of the connection. This is
-  the default setup.
-
-NT::
-  Use the top port (orange LED) and invert wiring (this is done to allow
-  connecting an NT port and a TE port using a standard straight 8 wires 
-  "ethernet" cable). Hint to higher layers that this will be the NT side 
-  of the connection.
-
-LOCALOOP::
-  Set the device into local loop mode: loops the transmitted channels
-  directly into the received channels.
-
-NOLOCALLOOP::
-  Ends local loop mode.
-
-Normally those are set by the PRI initialization script . See the
-definition of XPP_PRI_SETUP in 
-xref:dahdi_init_configuration_file[the sample Dahdi init 
-configuration file] .
-
-
-There are a bunch of other status files under /proc/xpp/.
-
-
-/sys Interface
-~~~~~~~~~~~~~~
-When an Astribank device loads it generates a device node in the bus 
-'astribanks' in sysfs. You can see a directory for each device under 
-/sys/bus/astribanks/devices/ and under it there are several attributes
-for each Astribank (such as its connector string).
-
-On each time an Astribank is initialized or destroyed a udev event is
-generated. The rules from our sample udev rules file (xpp/utils/xpp.rules) 
-make that event run the script /usr/share/dahdi/astribank_hook with the
-parameter 'add' or 'remove', if such script exists. An example script
-that just adjusts the Astribank sync settings is included in xpp/utils. 
-
-cls::
-  CLear Statistics: writing to this file clear the procfs statistics for
-  this bus.
-
-connector::
-  Connector string for the device. The place to which the Astribank is
-  connected. e.g: usb-0000:00:03.3-2
-
-label::
-  The label string of the Astribank unit. E.g: usb:00000135
-
-status::
-  'connected' (normal operation) or 'disconnected' (has been disconnected,
-  some channels are still open).
-
-timing::
-  Provides some statistics in case the Astribank is not the sync source.
-  The format of this file is subject to future changes.
-
-
-Useful Module Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~
-Compilation-time defaults for the all modules can be shown as part of the
-description line for the parameter in the "modinfo" command output.
-
-zap_autoreg (xpp)::
-  Register spans automatically (1) or not (0). Default: 0. 
-  Setting it simplifies operations with a single Astribank and no other 
-  Dahdi hardware. However if you have such systems, automatic
-  registration can cause the order of spans to be unpredictable.
-  The standard startup scripts use 'dahdi_registration on' instead of this.
-
-initdir (xpp)::
-  This is the directory containing the initialization scripts.
-  The default is /usr/share/dahdi .
-  Setting this value could be useful if that location is inconvenient for you.
-
-rx_tasklet (xpp)::
-  Enable (1) or disable (0) doing most of the packets processing in
-  separate tasklets. This should probably help on higher-end systems with
-  multiple Astribanks.
-
-debug (all modules)::
-  It will make the driver to print tons of debugging messages. You can 
-  set/unset the parameter at run-time. The parameter value is a bitmask 
-  of several values. The different bits  meaning as it defined in 
-  xpp/zap_debug.h: 
-
-  * 0  - Disable debug messages
-  * 1  - GENERAL - General debug comments.
-  * 2  - PCM - PCM-related messages. Tends to flood logs.
-  * 4  - LEDS - Anything related to the LEDs status control. The driver
-         produces a lot of messages when the option is enabled.
-  * 8  - SYNC - Synchronization related messages.
-  * 16 - SIGNAL - Dahdi signalling related messages.
-  * 32 - PROC - Messages related to the procfs interface.
-  * 64 - REGS - Reading and writing to chip registers. Tends to flood
-  	 logs.
-  * 128 - DEVICES - Device instantiation, destruction and such.
-  * 256 - COMMANDS - Protocol commands. Tends to flood logs.
-
-  For example,
-
-    echo 33 >/sys/modules/xpp/parameters/debug 
-
-  forces module xpp to print general debugging messages (1) and procfs
-  debugging messages (32).
-
-vmwineon (xpd_fxs)::
-  Enable (1) or disable (0) sending the voicemail message waiting indication
-  signal to phones equipped with the Message Waiting neon lamp. It is 
-  disabled by default because the feature requires extra work of the driver
-  even when such a phone is not used and also may cause some unusual
-  side effects with some phone models.
-
-usb1 (xpp_usb)::
-  Enable (1) or disable (0) support of USB1 devices. Disabled by default.
-
-  USB1 devices are not well-tested. It seems that they don't work at all
-  for Astribank BRI. Generally they should work with the current code, but
-  we expect the voice quality issues. Hence we would like to make it
-  very clear that you if you have a USB1 port (rather than a USB2 one, as 
-  recommended) you will have to take an action to enable the device.
-
-poll intervals (various)::
-  There are various values which the driver occasionally polls the device
-  for. For instance, the parameter poll_battery_interval for xpd_fxo
-  to poll the battery, in order to know if the telco line is actually
-  connected.
-
-  The value of those parameters is typically a number in milliseconds. 
-  0 is used to disable polling. Under normal operation there should be 
-  no reason to play with those parameters.
-
-dtmf_detection (xpd_fxs)::
-  Enable (1) or disable (0) support of hardware DTMF detection by the 
-  Astribank.
-
-
-NOTE: XPP here does not stand for X Printing Panel, XML Pull Parser, 
-X-Windows Phase Plane or XML Professional Publisher. It is simply the 
-Xorcom Peripheral Protocol, which connects a computer to a XPD (Xorcom 
-Peripheral Device). An XBUS (originally XPP Bus) is actually a single
-Astribank device and the XPDs have become the single modules in it.