| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 |  | 
|  | 2 | SliceCOM adapter user's documentation - for the 0.51 driver version | 
|  | 3 |  | 
| John Anthony Kazos Jr | be2a608 | 2007-05-09 08:50:42 +0200 | [diff] [blame] | 4 | Written by Bartók István <bartoki@itc.hu> | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 5 |  | 
| John Anthony Kazos Jr | be2a608 | 2007-05-09 08:50:42 +0200 | [diff] [blame] | 6 | English translation: Lakatos György <gyuri@itc.hu> | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 7 | Mon Dec 11 15:28:42 CET 2000 | 
|  | 8 |  | 
|  | 9 | Last modified: Wed Aug 29 17:25:37 CEST 2001 | 
|  | 10 |  | 
|  | 11 | ----------------------------------------------------------------- | 
|  | 12 |  | 
|  | 13 | Usage: | 
|  | 14 |  | 
|  | 15 | Compiling the kernel: | 
|  | 16 |  | 
|  | 17 | Code maturity level options | 
|  | 18 | [*] Prompt for development and/or incomplete code/drivers | 
|  | 19 |  | 
|  | 20 | Network device support | 
|  | 21 | Wan interfaces | 
|  | 22 | <M> MultiGate (COMX) synchronous | 
|  | 23 | <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW) | 
|  | 24 | <M> Support for HDLC and syncPPP... | 
|  | 25 |  | 
|  | 26 |  | 
|  | 27 | Loading the modules: | 
|  | 28 |  | 
|  | 29 | modprobe comx | 
|  | 30 |  | 
|  | 31 | modprobe comx-proto-ppp		# module for  Cisco-HDLC and SyncPPP protocols | 
|  | 32 |  | 
|  | 33 | modprobe comx-hw-munich		# the module logs information by the kernel | 
|  | 34 | # about the detected boards | 
|  | 35 |  | 
|  | 36 |  | 
|  | 37 | Configuring the board: | 
|  | 38 |  | 
|  | 39 | # This interface will use the Cisco-HDLC line protocol, | 
|  | 40 | # the timeslices assigned are 1,2 (128 KiBit line speed) | 
|  | 41 | # (the first data timeslice in the G.703 frame is no. 1) | 
|  | 42 | # | 
|  | 43 | mkdir /proc/comx/comx0.1/ | 
|  | 44 | echo slicecom	>/proc/comx/comx0.1/boardtype | 
|  | 45 | echo hdlc	>/proc/comx/comx0.1/protocol | 
|  | 46 | echo 1 2	>/proc/comx/comx0.1/timeslots | 
|  | 47 |  | 
|  | 48 |  | 
|  | 49 | # This interface uses SyncPPP line protocol, the assigned | 
|  | 50 | # is no. 3 (64 KiBit line speed) | 
|  | 51 | # | 
|  | 52 | mkdir /proc/comx/comx0.2/ | 
|  | 53 | echo slicecom	>/proc/comx/comx0.2/boardtype | 
|  | 54 | echo ppp	>/proc/comx/comx0.2/protocol | 
|  | 55 | echo 3		>/proc/comx/comx0.2/timeslots | 
|  | 56 |  | 
|  | 57 | ... | 
|  | 58 |  | 
|  | 59 | ifconfig comx0.1 up | 
|  | 60 | ifconfig comx0.2 up | 
|  | 61 |  | 
|  | 62 | ----------------------------------------------------------------- | 
|  | 63 |  | 
|  | 64 | The COMX interfaces use a 10 packet transmit queue by default, however WAN | 
|  | 65 | networks sometimes use bigger values (20 to 100), to utilize the line better | 
|  | 66 | by large traffic (though the line delay increases because of more packets | 
|  | 67 | join the queue). | 
|  | 68 |  | 
|  | 69 | # ifconfig comx0 txqueuelen 50 | 
|  | 70 |  | 
|  | 71 | This option is only supported by the ifconfig command of the later | 
|  | 72 | distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2. | 
|  | 73 |  | 
|  | 74 | You can download a newer netbase packet from | 
|  | 75 | http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new | 
|  | 76 | ifconfig. You can get further information about using 2.2 kernel with | 
|  | 77 | Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2 | 
|  | 78 |  | 
|  | 79 | ----------------------------------------------------------------- | 
|  | 80 |  | 
|  | 81 | The SliceCom LEDs: | 
|  | 82 |  | 
|  | 83 | red	- on, if the interface is unconfigured, or it gets Remote Alarm-s | 
|  | 84 | green	- on, if the board finds frame-sync in the received signal | 
|  | 85 |  | 
|  | 86 | A bit more detailed: | 
|  | 87 |  | 
|  | 88 | red:	green:	meaning: | 
|  | 89 |  | 
|  | 90 | -	-	no frame-sync, no signal received, or signal SNAFU. | 
|  | 91 | -	on	"Everything is OK" | 
| Matt LaPlante | d6bc8ac | 2006-10-03 22:54:15 +0200 | [diff] [blame] | 92 | on	on	Reception is ok, but the remote end sends Remote Alarm | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 93 | on	-	The interface is unconfigured | 
|  | 94 |  | 
|  | 95 | ----------------------------------------------------------------- | 
|  | 96 |  | 
|  | 97 | A more detailed description of the hardware setting options: | 
|  | 98 |  | 
|  | 99 | The general and the protocol layer options described in the 'comx.txt' file | 
|  | 100 | apply to the SliceCom as well, I only summarize the SliceCom hardware specific | 
|  | 101 | settings below. | 
|  | 102 |  | 
|  | 103 | The '/proc/comx' configuring interface: | 
|  | 104 |  | 
|  | 105 | An interface directory should be created for every timeslot group with | 
|  | 106 | 'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the | 
|  | 107 | specific interface. The Cisco-like naming convention (serial3:1 - first | 
|  | 108 | timeslot group of the 3rd. board) can't be used here, because these mean IP | 
|  | 109 | aliasing in Linux. | 
|  | 110 |  | 
|  | 111 | You can give any meaningful name to keep the configuration clear; | 
|  | 112 | e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards | 
|  | 113 | with two interfaces each. | 
|  | 114 |  | 
|  | 115 | Settings, which apply to the board: | 
|  | 116 |  | 
|  | 117 | Neither 'io' nor 'irq' settings required, the driver uses the resources | 
|  | 118 | given by the PCI BIOS. | 
|  | 119 |  | 
|  | 120 | comx0/boardnum	- board number of the SliceCom in the PC (using the 'natural' | 
|  | 121 | PCI order) as listed in '/proc/pci' or the output of the | 
|  | 122 | 'lspci' command, generally the slots nearer to the motherboard | 
|  | 123 | PCI driver chips have the lower numbers. | 
|  | 124 |  | 
|  | 125 | Default: 0 (the counting starts with 0) | 
|  | 126 |  | 
|  | 127 | Though the options below are to be set on a single interface, they apply to the | 
|  | 128 | whole board. The restriction, to use them on 'UP' interfaces, is because the | 
| Matt LaPlante | 4ae0edc | 2006-11-30 04:58:40 +0100 | [diff] [blame] | 129 | command sequence below could lead to unpredictable results. | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 130 |  | 
|  | 131 | # echo 0        >boardnum | 
|  | 132 | # echo internal >clock_source | 
|  | 133 | # echo 1        >boardnum | 
|  | 134 |  | 
|  | 135 | The sequence would set the clock source of board 0. | 
|  | 136 |  | 
|  | 137 | These settings will persist after all the interfaces are cleared, but are | 
|  | 138 | cleared when the driver module is unloaded and loaded again. | 
|  | 139 |  | 
|  | 140 | comx0/clock_source - source of the transmit clock | 
|  | 141 | Usage: | 
|  | 142 |  | 
|  | 143 | # echo line     >/proc/comx/comx0/clock_source | 
|  | 144 | # echo internal >/proc/comx/comx0/clock_source | 
|  | 145 |  | 
|  | 146 | line	- The Tx clock is being decoded if the input data stream, | 
|  | 147 | if no clock seen on the input, then the board will use it's | 
|  | 148 | own clock generator. | 
|  | 149 |  | 
|  | 150 | internal - The Tx clock is supplied by the builtin clock generator. | 
|  | 151 |  | 
|  | 152 | Default: line | 
|  | 153 |  | 
|  | 154 | Normally, the telecommunication company's end device (the HDSL | 
|  | 155 | modem) provides the Tx clock, that's why 'line' is the default. | 
|  | 156 |  | 
|  | 157 | comx0/framing	- Switching CRC4 off/on | 
|  | 158 |  | 
|  | 159 | CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a | 
|  | 160 | PCM frame, nothing to do with HDLC frames) are divided into 2x8 | 
|  | 161 | groups, each group has a 4 bit CRC. | 
|  | 162 |  | 
|  | 163 | # echo crc4	>/proc/comx/comx0/framing | 
|  | 164 | # echo no-crc4	>/proc/comx/comx0/framing | 
|  | 165 |  | 
|  | 166 | Default is 'crc4', the Hungarian MATAV lines behave like this. | 
|  | 167 | The traffic generally passes if this setting on both ends don't match. | 
|  | 168 |  | 
|  | 169 | comx0/linecode	- Setting the line coding | 
|  | 170 |  | 
|  | 171 | # echo hdb3	>/proc/comx/comx0/linecode | 
|  | 172 | # echo ami	>/proc/comx/comx0/linecode | 
|  | 173 |  | 
|  | 174 | Default a 'hdb3', MATAV lines use this. | 
|  | 175 |  | 
|  | 176 | (AMI coding is rarely used with E1 lines). Frame sync may occur, if | 
|  | 177 | this setting doesn't match the other end's, but CRC4 and data errors | 
|  | 178 | will come, which will result in CRC errors on HDLC/SyncPPP level. | 
|  | 179 |  | 
|  | 180 | comx0/reg	- direct access to the board's MUNICH (reg) and FALC (lbireg) | 
|  | 181 | comx0/lbireg	circuit's registers | 
|  | 182 |  | 
|  | 183 | # echo >reg 0x04 0x0	- write 0 to register 4 | 
|  | 184 | # echo >reg 0x104	- write the contents of register 4 with | 
|  | 185 | printk() to syslog | 
|  | 186 |  | 
|  | 187 | WARNING! These are only for development purposes, messing with this will | 
|  | 188 | result much trouble! | 
|  | 189 |  | 
|  | 190 | comx0/loopback - Places a loop to the board's G.703 signals | 
|  | 191 |  | 
|  | 192 | # echo none   >/proc/comx/comx0/loopback | 
|  | 193 | # echo local  >/proc/comx/comx0/loopback | 
|  | 194 | # echo remote >/proc/comx/comx0/loopback | 
|  | 195 |  | 
|  | 196 | none   - normal operation, no loop | 
|  | 197 | local  - the board receives it's own output | 
|  | 198 | remote - the board sends the received data to the remote side | 
|  | 199 |  | 
|  | 200 | Default: none | 
|  | 201 |  | 
|  | 202 | ----------------------------------------------------------------- | 
|  | 203 |  | 
|  | 204 | Interface (channel group in Cisco terms) settings: | 
|  | 205 |  | 
|  | 206 | comx0/timeslots	- which timeslots belong to the given interface | 
|  | 207 |  | 
|  | 208 | Setting: | 
|  | 209 |  | 
|  | 210 | # echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots | 
|  | 211 |  | 
|  | 212 | # cat /proc/comx/comx0/timeslots | 
|  | 213 | 1 2 5 6 7 8 | 
|  | 214 | # | 
|  | 215 |  | 
|  | 216 | Finding a timeslot: | 
|  | 217 |  | 
|  | 218 | # grep ' 4' /proc/comx/comx*/timeslots | 
|  | 219 | /proc/comx/comx0/timeslots:1 3 4 5 6 | 
|  | 220 | # | 
|  | 221 |  | 
|  | 222 | The timeslots can be in any order, '1 2 3' is the same as '1 3 2'. | 
|  | 223 |  | 
|  | 224 | The interface has to be DOWN during the setting ('ifconfig comx0 | 
|  | 225 | down'), but the other interfaces could operate normally. | 
|  | 226 |  | 
|  | 227 | The driver checks if the assigned timeslots are vacant, if not, then | 
|  | 228 | the setting won't be applied. | 
|  | 229 |  | 
|  | 230 | The timeslot values are treated as decimal numbers, not to misunderstand | 
|  | 231 | values of 08, 09 form. | 
|  | 232 |  | 
|  | 233 | ----------------------------------------------------------------- | 
|  | 234 |  | 
|  | 235 | Checking the interface and board status: | 
|  | 236 |  | 
|  | 237 | - Lines beginning with ' ' (space) belong to the original output, the lines | 
|  | 238 | which begin with '//' are the comments. | 
|  | 239 |  | 
|  | 240 | papaya:~$ cat /proc/comx/comx1/status | 
|  | 241 | Interface administrative status is UP, modem status is UP, protocol is UP | 
|  | 242 | Modem status changes: 0, Transmitter status is IDLE, tbusy: 0 | 
|  | 243 | Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m) | 
|  | 244 | (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m) | 
|  | 245 | Debug flags: none | 
|  | 246 | RX errors: len: 22, overrun: 1, crc: 0, aborts: 0 | 
|  | 247 | buffer overrun: 0, pbuffer overrun: 0 | 
|  | 248 | TX errors: underrun: 0 | 
|  | 249 | Line keepalive (value: 10) status UP [0] | 
|  | 250 |  | 
|  | 251 | // The hardware specific part starts here: | 
|  | 252 | Controller status: | 
|  | 253 | No alarms | 
|  | 254 |  | 
|  | 255 | // Alarm: | 
|  | 256 | // | 
|  | 257 | // No alarms - Everything OK | 
|  | 258 | // | 
|  | 259 | // LOS  - Loss Of Signal - No signal sensed on the input | 
| Matt LaPlante | d6bc8ac | 2006-10-03 22:54:15 +0200 | [diff] [blame] | 260 | // AIS  - Alarm Indication Signal - The remote side sends '11111111'-s, | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 261 | //	it tells, that there's an error condition, or it's not | 
|  | 262 | //	initialised. | 
|  | 263 | // AUXP - Auxiliary Pattern Indication - 01010101.. received. | 
|  | 264 | // LFA  - Loss of Frame Alignment - no frame sync received. | 
| Matt LaPlante | 53cb472 | 2006-10-03 22:55:17 +0200 | [diff] [blame] | 265 | // RRA  - Receive Remote Alarm - the remote end's OK, but signals error cond. | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 266 | // LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync. | 
|  | 267 | // NMF  - No Multiframe alignment Found after 400 msec - no such alarm using | 
|  | 268 | //	no-crc4 or crc4 framing, see below. | 
|  | 269 | // | 
|  | 270 | // Other possible error messages: | 
|  | 271 | // | 
|  | 272 | // Transmit Line Short - the board felt, that it's output is short-circuited, | 
|  | 273 | // 	so it switched the transmission off. (The board can't definitely tell, | 
|  | 274 | //	that it's output is short-circuited.) | 
|  | 275 |  | 
|  | 276 | // Chained list of the received packets, for debug purposes: | 
|  | 277 |  | 
|  | 278 | Rx ring: | 
|  | 279 | rafutott: 0 | 
|  | 280 | lastcheck: 50845731, jiffies: 51314281 | 
|  | 281 | base: 017b1858 | 
|  | 282 | rx_desc_ptr: 0 | 
|  | 283 | rx_desc_ptr: 017b1858 | 
|  | 284 | hw_curr_ptr: 017b1858 | 
|  | 285 | 06040000 017b1868 017b1898 c016ff00 | 
|  | 286 | 06040000 017b1878 017b1e9c c016ff00 | 
|  | 287 | 46040000 017b1888 017b24a0 c016ff00 | 
|  | 288 | 06040000 017b1858 017b2aa4 c016ff00 | 
|  | 289 |  | 
|  | 290 | // All the interfaces using the board: comx1, using the 1,2,...16 timeslots, | 
|  | 291 | // comx2, using timeslot 17, etc. | 
|  | 292 |  | 
|  | 293 | Interfaces using this board: (channel-group, interface, timeslots) | 
|  | 294 | 0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | 
|  | 295 | 1 comx2: 17 | 
|  | 296 | 2 comx3: 18 | 
|  | 297 | 3 comx4: 19 | 
|  | 298 | 4 comx5: 20 | 
|  | 299 | 5 comx6: 21 | 
|  | 300 | 6 comx7: 22 | 
|  | 301 | 7 comx8: 23 | 
|  | 302 | 8 comx9: 24 | 
|  | 303 | 9 comx10: 25 | 
|  | 304 | 10 comx11: 26 | 
|  | 305 | 11 comx12: 27 | 
|  | 306 | 12 comx13: 28 | 
|  | 307 | 13 comx14: 29 | 
|  | 308 | 14 comx15: 30 | 
|  | 309 | 15 comx16: 31 | 
|  | 310 |  | 
|  | 311 | // The number of events handled by the driver during an interrupt cycle: | 
|  | 312 |  | 
|  | 313 | Interrupt work histogram: | 
|  | 314 | hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79 | 
|  | 315 | hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1 | 
|  | 316 | hist[ 8]:        0 hist[ 9]:        7 | 
|  | 317 |  | 
|  | 318 | // The number of packets to send in the Tx ring, when a new one arrived: | 
|  | 319 |  | 
|  | 320 | Tx ring histogram: | 
|  | 321 | hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0 | 
|  | 322 |  | 
|  | 323 | // The error counters of the E1 interface, according to the RFC2495, | 
|  | 324 | // (similar to the Cisco "show controllers e1" command's output: | 
|  | 325 | // http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126) | 
|  | 326 |  | 
|  | 327 | Data in current interval (91 seconds elapsed): | 
|  | 328 | 9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors | 
|  | 329 | 0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins | 
|  | 330 | 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs | 
|  | 331 | Data in Interval 1 (15 minutes): | 
|  | 332 | 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors | 
|  | 333 | 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins | 
|  | 334 | 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs | 
|  | 335 | Data in last 4 intervals (1 hour): | 
|  | 336 | 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors | 
|  | 337 | 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins | 
|  | 338 | 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs | 
|  | 339 | Data in last 96 intervals (24 hours): | 
|  | 340 | 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors | 
|  | 341 | 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins | 
|  | 342 | 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs | 
|  | 343 |  | 
|  | 344 | ----------------------------------------------------------------- | 
|  | 345 |  | 
|  | 346 | Some unique options, (may get into the driver later): | 
|  | 347 | Treat them very carefully, these can cause much trouble! | 
|  | 348 |  | 
|  | 349 | modified CRC-4, for improved interworking of CRC-4 and non-CRC-4 | 
|  | 350 | devices: (see page 107 and g706 Annex B) | 
|  | 351 | lbireg[ 0x1b ] |= 0x08 | 
|  | 352 | lbireg[ 0x1c ] |= 0xc0 | 
|  | 353 |  | 
|  | 354 | - The NMF - 'No Multiframe alignment Found after 400 msec' alarm | 
|  | 355 | comes into account. | 
|  | 356 |  | 
|  | 357 | FALC - the line driver chip. | 
|  | 358 | local loop - I hear my transmission back. | 
|  | 359 | remote loop - I echo the remote transmission back. | 
|  | 360 |  | 
|  | 361 | Something useful for finding errors: | 
|  | 362 |  | 
|  | 363 | - local loop for timeslot 1 in the FALC chip: | 
|  | 364 |  | 
|  | 365 | # echo >lbireg 0x1d 0x21 | 
|  | 366 |  | 
| Matt LaPlante | 53cb472 | 2006-10-03 22:55:17 +0200 | [diff] [blame] | 367 | - Switching the loop off: | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 368 |  | 
|  | 369 | # echo >lbireg 0x1d 0x00 |