SliceCOM adapter user's documentation - for the 0.51 driver version Written by Bartók István English translation: Lakatos György 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 MultiGate (COMX) synchronous Support for MUNICH based boards: SliceCOM, PCICOM (NEW) 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