2.4.19

 Documentation

 networking

diff -urN linux-2.4.18/Documentation/networking/slicecom.txt linux-2.4.19/Documentation/networking/slicecom.txt
--- linux-2.4.18/Documentation/networking/slicecom.txt   Wed Dec 31 16:00:00 1969
+++ linux-2.4.19/Documentation/networking/slicecom.txt   Fri Aug  2 17:39:42 2002
@@ -0,0 +1,369 @@
+
+SliceCOM adapter user's documentation - for the 0.51 driver version
+
+Written by Bartók István <bartoki@itc.hu>
+
+English translation: Lakatos György <gyuri@itc.hu>
+Mon Dec 11 15:28:42 CET 2000
+
+Last modified: Wed Aug 29 17:25:37 CEST 2001
+
+-----------------------------------------------------------------
+
+Usage:
+
+Compiling the kernel:
+
+Code maturity level options
+   [*] Prompt for development and/or incomplete code/drivers
+
+Network device support
+   Wan interfaces
+      <M> MultiGate (COMX) synchronous
+         <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
+         <M> Support for HDLC and syncPPP...
+
+
+Loading the modules:
+
+modprobe comx
+
+modprobe comx-proto-ppp      # module for  Cisco-HDLC and SyncPPP protocols
+
+modprobe comx-hw-munich      # the module logs information by the kernel
+            # about the detected boards
+
+
+Configuring the board:
+
+# This interface will use the Cisco-HDLC line protocol,
+# the timeslices assigned are 1,2 (128 KiBit line speed)
+# (the first data timeslice in the G.703 frame is no. 1)
+#
+mkdir /proc/comx/comx0.1/
+echo slicecom   >/proc/comx/comx0.1/boardtype
+echo hdlc   >/proc/comx/comx0.1/protocol
+echo 1 2   >/proc/comx/comx0.1/timeslots
+
+
+# This interface uses SyncPPP line protocol, the assigned 
+# is no. 3 (64 KiBit line speed)
+#
+mkdir /proc/comx/comx0.2/
+echo slicecom   >/proc/comx/comx0.2/boardtype
+echo ppp   >/proc/comx/comx0.2/protocol
+echo 3      >/proc/comx/comx0.2/timeslots
+
+...
+
+ifconfig comx0.1 up
+ifconfig comx0.2 up
+
+-----------------------------------------------------------------
+
+The COMX interfaces use a 10 packet transmit queue by default, however WAN
+networks sometimes use bigger values (20 to 100), to utilize the line better
+by large traffic (though the line delay increases because of more packets
+join the queue).
+
+# ifconfig comx0 txqueuelen 50
+
+This option is only supported by the ifconfig command of the later 
+distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
+
+You can download a newer netbase packet from 
+http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
+ifconfig. You can get further information about using 2.2 kernel with
+Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
+
+-----------------------------------------------------------------
+
+The SliceCom LEDs:
+
+red   - on, if the interface is unconfigured, or it gets Remote Alarm-s
+green   - on, if the board finds frame-sync in the received signal    
+
+A bit more detailed:
+
+red:   green:   meaning:
+
+-   -   no frame-sync, no signal received, or signal SNAFU.
+-   on   "Everything is OK"
+on   on   Recepion is ok, but the remote end sends Remote Alarm
+on   -   The interface is unconfigured
+
+-----------------------------------------------------------------
+
+A more detailed description of the hardware setting options:
+
+The general and the protocol layer options described in the 'comx.txt' file
+apply to the SliceCom as well, I only summarize the SliceCom hardware specific
+settings below.
+
+The '/proc/comx' configuring interface:
+
+An interface directory should be created for every timeslot group with
+'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
+specific interface. The Cisco-like naming convention (serial3:1 - first
+timeslot group of the 3rd. board) can't be used here, because these mean IP
+aliasing in Linux.
+
+You can give any meaningful name to keep the configuration clear; 
+e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
+with two interfaces each.
+
+Settings, which apply to the board:
+
+Neither 'io' nor 'irq' settings required, the driver uses the resources
+given by the PCI BIOS.
+
+comx0/boardnum   - board number of the SliceCom in the PC (using the 'natural'
+      PCI order) as listed in '/proc/pci' or the output of the
+       'lspci' command, generally the slots nearer to the motherboard
+      PCI driver chips have the lower numbers.
+      
+      Default: 0 (the counting starts with 0)
+
+Though the options below are to be set on a single interface, they apply to the
+whole board. The restriction, to use them on 'UP' interfaces, is because the 
+command sequence below could lead to unpredicable results.
+
+   # echo 0        >boardnum
+   # echo internal >clock_source
+   # echo 1        >boardnum
+
+The sequence would set the clock source of board 0.
+
+These settings will persist after all the interfaces are cleared, but are
+cleared when the driver module is unloaded and loaded again.
+
+comx0/clock_source - source of the transmit clock
+   Usage:
+
+   # echo line     >/proc/comx/comx0/clock_source
+   # echo internal >/proc/comx/comx0/clock_source
+
+   line   - The Tx clock is being decoded if the input data stream,
+      if no clock seen on the input, then the board will use it's
+      own clock generator.
+
+   internal - The Tx clock is supplied by the builtin clock generator.    
+
+   Default: line
+
+   Normally, the telecommunication company's end device (the HDSL
+   modem) provides the Tx clock, that's why 'line' is the default.
+
+comx0/framing   - Switching CRC4 off/on
+
+   CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
+   PCM frame, nothing to do with HDLC frames) are divided into 2x8
+   groups, each group has a 4 bit CRC.
+
+   # echo crc4   >/proc/comx/comx0/framing
+   # echo no-crc4   >/proc/comx/comx0/framing
+
+   Default is 'crc4', the Hungarian MATAV lines behave like this. 
+   The traffic generally passes if this setting on both ends don't match.
+
+comx0/linecode   - Setting the line coding
+
+   # echo hdb3   >/proc/comx/comx0/linecode
+   # echo ami   >/proc/comx/comx0/linecode
+
+   Default a 'hdb3', MATAV lines use this.
+   
+   (AMI coding is rarely used with E1 lines). Frame sync may occur, if
+   this setting doesn't match the other end's, but CRC4 and data errors
+   will come, which will result in CRC errors on HDLC/SyncPPP level. 
+
+comx0/reg   - direct access to the board's MUNICH (reg) and FALC (lbireg)
+comx0/lbireg   circuit's registers  
+
+   # echo >reg 0x04 0x0   - write 0 to register 4
+   # echo >reg 0x104   - write the contents of register 4 with
+            printk() to syslog
+
+WARNING! These are only for development purposes, messing with this will
+   result much trouble!
+
+comx0/loopback - Places a loop to the board's G.703 signals
+
+   # echo none   >/proc/comx/comx0/loopback
+   # echo local  >/proc/comx/comx0/loopback
+   # echo remote >/proc/comx/comx0/loopback
+
+   none   - normal operation, no loop
+   local  - the board receives it's own output
+   remote - the board sends the received data to the remote side
+
+   Default: none
+
+-----------------------------------------------------------------
+
+Interface (channel group in Cisco terms) settings: 
+
+comx0/timeslots   - which timeslots belong to the given interface
+
+   Setting:
+
+   # echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
+
+   # cat /proc/comx/comx0/timeslots
+   1 2 5 6 7 8 
+   #
+
+   Finding a timeslot: 
+
+   # grep ' 4' /proc/comx/comx*/timeslots
+   /proc/comx/comx0/timeslots:1 3 4 5 6
+   #
+
+   The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
+
+   The interface has to be DOWN during the setting ('ifconfig comx0
+   down'), but the other interfaces could operate normally.
+
+   The driver checks if the assigned timeslots are vacant, if not, then
+   the setting won't be applied.
+
+   The timeslot values are treated as decimal numbers, not to misunderstand
+   values of 08, 09 form.
+
+-----------------------------------------------------------------
+
+Checking the interface and board status:
+
+- Lines beginning with ' ' (space) belong to the original output, the lines
+which begin with '//' are the comments.
+
+ papaya:~$ cat /proc/comx/comx1/status
+ Interface administrative status is UP, modem status is UP, protocol is UP
+ Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
+ Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
+               (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
+ Debug flags: none
+ RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
+            buffer overrun: 0, pbuffer overrun: 0
+ TX errors: underrun: 0
+ Line keepalive (value: 10) status UP [0]
+
+// The hardware specific part starts here:
+ Controller status:
+         No alarms
+
+// Alarm: 
+//
+// No alarms - Everything OK
+//
+// LOS  - Loss Of Signal - No signal sensed on the input
+// AIS  - Alarm Indication Signal - The remot side sends '11111111'-s, 
+//   it tells, that there's an error condition, or it's not
+//   initialised.
+// AUXP - Auxiliary Pattern Indication - 01010101.. received.
+// LFA  - Loss of Frame Alignment - no frame sync received.
+// RRA  - Receive Remote Alarm - the remote end's OK, but singnals error cond.
+// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
+// NMF  - No Multiframe alignment Found after 400 msec - no such alarm using
+//   no-crc4 or crc4 framing, see below.
+//
+// Other possible error messages:
+//
+// Transmit Line Short - the board felt, that it's output is short-circuited,
+//    so it switched the transmission off. (The board can't definitely tell,
+//   that it's output is short-circuited.)
+
+// Chained list of the received packets, for debug purposes:
+
+ Rx ring:
+         rafutott: 0
+         lastcheck: 50845731, jiffies: 51314281
+         base: 017b1858
+         rx_desc_ptr: 0
+         rx_desc_ptr: 017b1858
+         hw_curr_ptr: 017b1858
+         06040000 017b1868 017b1898 c016ff00
+         06040000 017b1878 017b1e9c c016ff00
+         46040000 017b1888 017b24a0 c016ff00
+         06040000 017b1858 017b2aa4 c016ff00
+
+// All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
+// comx2, using timeslot 17, etc.
+
+ Interfaces using this board: (channel-group, interface, timeslots)
+          0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+          1 comx2: 17
+          2 comx3: 18
+          3 comx4: 19
+          4 comx5: 20
+          5 comx6: 21
+          6 comx7: 22
+          7 comx8: 23
+          8 comx9: 24
+          9 comx10: 25
+         10 comx11: 26
+         11 comx12: 27
+         12 comx13: 28
+         13 comx14: 29
+         14 comx15: 30
+         15 comx16: 31
+
+// The number of events handled by the driver during an interrupt cycle:
+
+ Interrupt work histogram:
+ hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
+ hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
+ hist[ 8]:        0 hist[ 9]:        7
+
+// The number of packets to send in the Tx ring, when a new one arrived:
+
+ Tx ring histogram:
+ hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
+
+// The error counters of the E1 interface, according to the RFC2495,
+// (similar to the Cisco "show controllers e1" command's output:
+// http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
+
+Data in current interval (91 seconds elapsed):
+   9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
+   0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
+Data in Interval 1 (15 minutes):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 4 intervals (1 hour):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 96 intervals (24 hours):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+
+-----------------------------------------------------------------
+
+Some unique options, (may get into the driver later):
+Treat them very carefully, these can cause much trouble!
+
+   modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
+   devices: (see page 107 and g706 Annex B)
+      lbireg[ 0x1b ] |= 0x08
+      lbireg[ 0x1c ] |= 0xc0
+
+   - The NMF - 'No Multiframe alignment Found after 400 msec' alarm 
+   comes into account.
+
+   FALC - the line driver chip.
+   local loop - I hear my transmission back.
+   remote loop - I echo the remote transmission back.
+
+   Something useful for finding errors:
+   
+      - local loop for timeslot 1 in the FALC chip:
+
+   # echo >lbireg 0x1d 0x21
+
+      - Swithing the loop off:
+
+   # echo >lbireg 0x1d 0x00