view Documentation/networking/3c509.txt @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
line source
1 Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher)
2 ----------------------------------------------------------------------------
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.
7 release 1.0
8 28 February 2002
9 Current maintainer (corrections to):
10 David Ruggiero <jdr@farfalle.com>
12 ----------------------------------------------------------------------------
14 (0) Introduction
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:
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)
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.
37 (1) Special Driver Features
39 Overriding card settings
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:
46 ether=10,0x310,3,0x3c509,eth0
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:
55 options 3c509 xcvr=3,1 irq=10,11
58 (2) Full-duplex mode
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:
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).
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.
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.
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.
97 (3) Available Transceiver Types
99 For versions of the driver v1.18c and above, the available transceiver types are:
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
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.
118 (4a) Interpretation of error messages and common problems
120 Error Messages
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:
128 - a "green" mode enabled that slows the processor down when there is no
129 keyboard activitiy.
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.
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.
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.
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.
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.
161 (4b) Decoding Status and Error Messages
163 The bits in the main status register are:
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
175 The bits in the transmit (Tx) status word are:
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).
187 When a transmit error occurs the driver produces a status message such as
189 eth0: Transmit error, Tx status register 82
191 The two values typically seen here are:
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.
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).
203 Both of these errors are the result of network problems that should be
204 corrected. They do not represent driver malfunction.
207 (5) Revision history (this file)
209 28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs