| |
| 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 |
