diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/networking/3c509.txt |
Linux-2.6.12-rc2v2.6.12-rc2
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!
Diffstat (limited to 'Documentation/networking/3c509.txt')
-rw-r--r-- | Documentation/networking/3c509.txt | 210 |
1 files changed, 210 insertions, 0 deletions
diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt new file mode 100644 index 000000000000..867a99f88c68 --- /dev/null +++ b/Documentation/networking/3c509.txt | |||
@@ -0,0 +1,210 @@ | |||
1 | Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher) | ||
2 | ---------------------------------------------------------------------------- | ||
3 | |||
4 | This file contains the instructions and caveats for v1.18c and higher versions | ||
5 | of the 3c509 driver. You should not use the driver without reading this file. | ||
6 | |||
7 | release 1.0 | ||
8 | 28 February 2002 | ||
9 | Current maintainer (corrections to): | ||
10 | David Ruggiero <jdr@farfalle.com> | ||
11 | |||
12 | ---------------------------------------------------------------------------- | ||
13 | |||
14 | (0) Introduction | ||
15 | |||
16 | The following are notes and information on using the 3Com EtherLink III series | ||
17 | ethercards in Linux. These cards are commonly known by the most widely-used | ||
18 | card's 3Com model number, 3c509. They are all 10mb/s ISA-bus cards and shouldn't | ||
19 | be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905" | ||
20 | (aka "Vortex" or "Boomerang") series. Kernel support for the 3c509 family is | ||
21 | provided by the module 3c509.c, which has code to support all of the following | ||
22 | models: | ||
23 | |||
24 | 3c509 (original ISA card) | ||
25 | 3c509B (later revision of the ISA card; supports full-duplex) | ||
26 | 3c589 (PCMCIA) | ||
27 | 3c589B (later revision of the 3c589; supports full-duplex) | ||
28 | 3c529 (MCA) | ||
29 | 3c579 (EISA) | ||
30 | |||
31 | Large portions of this documentation were heavily borrowed from the guide | ||
32 | written the original author of the 3c509 driver, Donald Becker. The master | ||
33 | copy of that document, which contains notes on older versions of the driver, | ||
34 | currently resides on Scyld web server: http://www.scyld.com/network/3c509.html. | ||
35 | |||
36 | |||
37 | (1) Special Driver Features | ||
38 | |||
39 | Overriding card settings | ||
40 | |||
41 | The driver allows boot- or load-time overriding of the card's detected IOADDR, | ||
42 | IRQ, and transceiver settings, although this capability shouldn't generally be | ||
43 | needed except to enable full-duplex mode (see below). An example of the syntax | ||
44 | for LILO parameters for doing this: | ||
45 | |||
46 | ether=10,0x310,3,0x3c509,eth0 | ||
47 | |||
48 | This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and | ||
49 | transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts | ||
50 | with other card types when overriding the I/O address. When the driver is | ||
51 | loaded as a module, only the IRQ and transceiver setting may be overridden. | ||
52 | For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using | ||
53 | the xcvr and irq module options: | ||
54 | |||
55 | options 3c509 xcvr=3,1 irq=10,11 | ||
56 | |||
57 | |||
58 | (2) Full-duplex mode | ||
59 | |||
60 | The v1.18c driver added support for the 3c509B's full-duplex capabilities. | ||
61 | In order to enable and successfully use full-duplex mode, three conditions | ||
62 | must be met: | ||
63 | |||
64 | (a) You must have a Etherlink III card model whose hardware supports full- | ||
65 | duplex operations. Currently, the only members of the 3c509 family that are | ||
66 | positively known to support full-duplex are the 3c509B (ISA bus) and 3c589B | ||
67 | (PCMCIA) cards. Cards without the "B" model designation do *not* support | ||
68 | full-duplex mode; these include the original 3c509 (no "B"), the original | ||
69 | 3c589, the 3c529 (MCA bus), and the 3c579 (EISA bus). | ||
70 | |||
71 | (b) You must be using your card's 10baseT transceiver (i.e., the RJ-45 | ||
72 | connector), not its AUI (thick-net) or 10base2 (thin-net/coax) interfaces. | ||
73 | AUI and 10base2 network cabling is physically incapable of full-duplex | ||
74 | operation. | ||
75 | |||
76 | (c) Most importantly, your 3c509B must be connected to a link partner that is | ||
77 | itself full-duplex capable. This is almost certainly one of two things: a full- | ||
78 | duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on | ||
79 | another system that's connected directly to the 3c509B via a crossover cable. | ||
80 | |||
81 | /////Extremely important caution concerning full-duplex mode///// | ||
82 | Understand that the 3c509B's hardware's full-duplex support is much more | ||
83 | limited than that provide by more modern network interface cards. Although | ||
84 | at the physical layer of the network it fully supports full-duplex operation, | ||
85 | the card was designed before the current Ethernet auto-negotiation (N-way) | ||
86 | spec was written. This means that the 3c509B family ***cannot and will not | ||
87 | auto-negotiate a full-duplex connection with its link partner under any | ||
88 | circumstances, no matter how it is initialized***. If the full-duplex mode | ||
89 | of the 3c509B is enabled, its link partner will very likely need to be | ||
90 | independently _forced_ into full-duplex mode as well; otherwise various nasty | ||
91 | failures will occur - at the very least, you'll see massive numbers of packet | ||
92 | collisions. This is one of very rare circumstances where disabling auto- | ||
93 | negotiation and forcing the duplex mode of a network interface card or switch | ||
94 | would ever be necessary or desirable. | ||
95 | |||
96 | |||
97 | (3) Available Transceiver Types | ||
98 | |||
99 | For versions of the driver v1.18c and above, the available transceiver types are: | ||
100 | |||
101 | 0 transceiver type from EEPROM config (normally 10baseT); force half-duplex | ||
102 | 1 AUI (thick-net / DB15 connector) | ||
103 | 2 (undefined) | ||
104 | 3 10base2 (thin-net == coax / BNC connector) | ||
105 | 4 10baseT (RJ-45 connector); force half-duplex mode | ||
106 | 8 transceiver type and duplex mode taken from card's EEPROM config settings | ||
107 | 12 10baseT (RJ-45 connector); force full-duplex mode | ||
108 | |||
109 | Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note | ||
110 | that the new transceiver codes 8 and 12 are the *only* ones that will enable | ||
111 | full-duplex mode, no matter what the card's detected EEPROM settings might be. | ||
112 | This insured that merely upgrading the driver from an earlier version would | ||
113 | never automatically enable full-duplex mode in an existing installation; | ||
114 | it must always be explicitly enabled via one of these code in order to be | ||
115 | activated. | ||
116 | |||
117 | |||
118 | (4a) Interpretation of error messages and common problems | ||
119 | |||
120 | Error Messages | ||
121 | |||
122 | eth0: Infinite loop in interrupt, status 2011. | ||
123 | These are "mostly harmless" message indicating that the driver had too much | ||
124 | work during that interrupt cycle. With a status of 0x2011 you are receiving | ||
125 | packets faster than they can be removed from the card. This should be rare | ||
126 | or impossible in normal operation. Possible causes of this error report are: | ||
127 | |||
128 | - a "green" mode enabled that slows the processor down when there is no | ||
129 | keyboard activitiy. | ||
130 | |||
131 | - some other device or device driver hogging the bus or disabling interrupts. | ||
132 | Check /proc/interrupts for excessive interrupt counts. The timer tick | ||
133 | interrupt should always be incrementing faster than the others. | ||
134 | |||
135 | No received packets | ||
136 | If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never | ||
137 | receives packets (as reported by /proc/net/dev or 'ifconfig') you likely | ||
138 | have an interrupt line problem. Check /proc/interrupts to verify that the | ||
139 | card is actually generating interrupts. If the interrupt count is not | ||
140 | increasing you likely have a physical conflict with two devices trying to | ||
141 | use the same ISA IRQ line. The common conflict is with a sound card on IRQ10 | ||
142 | or IRQ5, and the easiest solution is to move the 3c509 to a different | ||
143 | interrupt line. If the device is receiving packets but 'ping' doesn't work, | ||
144 | you have a routing problem. | ||
145 | |||
146 | Tx Carrier Errors Reported in /proc/net/dev | ||
147 | If an EtherLink III appears to transmit packets, but the "Tx carrier errors" | ||
148 | field in /proc/net/dev increments as quickly as the Tx packet count, you | ||
149 | likely have an unterminated network or the incorrect media transceiver selected. | ||
150 | |||
151 | 3c509B card is not detected on machines with an ISA PnP BIOS. | ||
152 | While the updated driver works with most PnP BIOS programs, it does not work | ||
153 | with all. This can be fixed by disabling PnP support using the 3Com-supplied | ||
154 | setup program. | ||
155 | |||
156 | 3c509 card is not detected on overclocked machines | ||
157 | Increase the delay time in id_read_eeprom() from the current value, 500, | ||
158 | to an absurdly high value, such as 5000. | ||
159 | |||
160 | |||
161 | (4b) Decoding Status and Error Messages | ||
162 | |||
163 | The bits in the main status register are: | ||
164 | |||
165 | value description | ||
166 | 0x01 Interrupt latch | ||
167 | 0x02 Tx overrun, or Rx underrun | ||
168 | 0x04 Tx complete | ||
169 | 0x08 Tx FIFO room available | ||
170 | 0x10 A complete Rx packet has arrived | ||
171 | 0x20 A Rx packet has started to arrive | ||
172 | 0x40 The driver has requested an interrupt | ||
173 | 0x80 Statistics counter nearly full | ||
174 | |||
175 | The bits in the transmit (Tx) status word are: | ||
176 | |||
177 | value description | ||
178 | 0x02 Out-of-window collision. | ||
179 | 0x04 Status stack overflow (normally impossible). | ||
180 | 0x08 16 collisions. | ||
181 | 0x10 Tx underrun (not enough PCI bus bandwidth). | ||
182 | 0x20 Tx jabber. | ||
183 | 0x40 Tx interrupt requested. | ||
184 | 0x80 Status is valid (this should always be set). | ||
185 | |||
186 | |||
187 | When a transmit error occurs the driver produces a status message such as | ||
188 | |||
189 | eth0: Transmit error, Tx status register 82 | ||
190 | |||
191 | The two values typically seen here are: | ||
192 | |||
193 | 0x82 | ||
194 | Out of window collision. This typically occurs when some other Ethernet | ||
195 | host is incorrectly set to full duplex on a half duplex network. | ||
196 | |||
197 | 0x88 | ||
198 | 16 collisions. This typically occurs when the network is exceptionally busy | ||
199 | or when another host doesn't correctly back off after a collision. If this | ||
200 | error is mixed with 0x82 errors it is the result of a host incorrectly set | ||
201 | to full duplex (see above). | ||
202 | |||
203 | Both of these errors are the result of network problems that should be | ||
204 | corrected. They do not represent driver malfunction. | ||
205 | |||
206 | |||
207 | (5) Revision history (this file) | ||
208 | |||
209 | 28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs | ||
210 | |||