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