1 2IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README 3 4Release 0.2.0 - Release 5 June 8th 1999 Peter De Schrijver & Mike Phillips 6Release 0.9.C - Release 7 April 18th 2001 Mike Phillips 8 9Thanks: 10Erik De Cock, Adrian Bridgett and Frank Fiene for their 11patience and testing. 12Donald Champion for the cardbus support 13Kyle Lucke for the dma api changes. 14Jonathon Bitner for hardware support. 15Everybody on linux-tr for their continued support. 16 17Options: 18 19The driver accepts four options: ringspeed, pkt_buf_sz, 20message_level and network_monitor. 21 22These options can be specified differently for each card found. 23 24ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will 25make the card autosense the ringspeed and join at the appropriate speed, 26this will be the default option for most people. 4 or 16 allow you to 27explicitly force the card to operate at a certain speed. The card will fail 28if you try to insert it at the wrong speed. (Although some hubs will allow 29this so be *very* careful). The main purpose for explicitly setting the ring 30speed is for when the card is first on the ring. In autosense mode, if the card 31cannot detect any active monitors on the ring it will not open, so you must 32re-init the card at the appropriate speed. Unfortunately at present the only 33way of doing this is rmmod and insmod which is a bit tough if it is compiled 34in the kernel. 35 36pkt_buf_sz: This is this initial receive buffer allocation size. This will 37default to 4096 if no value is entered. You may increase performance of the 38driver by setting this to a value larger than the network packet size, although 39the driver now re-sizes buffers based on MTU settings as well. 40 41message_level: Controls level of messages created by the driver. Defaults to 0: 42which only displays start-up and critical messages. Presently any non-zero 43value will display all soft messages as well. NB This does not turn 44debugging messages on, that must be done by modified the source code. 45 46network_monitor: Any non-zero value will provide a quasi network monitoring 47mode. All unexpected MAC frames (beaconing etc.) will be received 48by the driver and the source and destination addresses printed. 49Also an entry will be added in /proc/net called olympic_tr%d, where tr%d 50is the registered device name, i.e tr0, tr1, etc. This displays low 51level information about the configuration of the ring and the adapter. 52This feature has been designed for network administrators to assist in 53the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR, 54but has now changed to allow each adapter to be configured differently and 55to alleviate the necessity to re-compile olympic to turn the option on). 56 57Multi-card: 58 59The driver will detect multiple cards and will work with shared interrupts, 60each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The 61driver should also happily reside in the system with other drivers. It has 62been tested with ibmtr.c running, and I personally have had one Olicom PCI 63card and two IBM olympic cards (all on the same interrupt), all running 64together. 65 66Variable MTU size: 67 68The driver can handle a MTU size up to either 4500 or 18000 depending upon 69ring speed. The driver also changes the size of the receive buffers as part 70of the mtu re-sizing, so if you set mtu = 18000, you will need to be able 71to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 72position = 296,000 bytes of memory space, plus of course anything 73necessary for the tx sk_buff's. Remember this is per card, so if you are 74building routers, gateway's etc, you could start to use a lot of memory 75real fast. 76 77 786/8/99 Peter De Schrijver and Mike Phillips 79 80