1da177e4c3
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
369 lines
12 KiB
Text
369 lines
12 KiB
Text
|
|
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
|