olympic.txt
上传用户:jlfgdled
上传日期:2013-04-10
资源大小:33168k
文件大小:4k
源码类别:

Linux/Unix编程

开发平台:

Unix_Linux

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