* [DOC] update bonding documentation with sysfs
From: Auke Kok @ 2006-06-08 18:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, Mitch Williams, Auke Kok, Kok, Auke
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Jeff,
Attached patch is pushed on top of #upstream on our git server also containing
the resent patches earlier today.
Please pull:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
Cheers,
Auke
---
[DOC] Update bonding documentation with sysfs info
Bonding documentation needed an update to include sysfs specific
information. This patch adds information on how to change bonding
parameters at runtime using the sysfs interface.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
bonding.txt | 323 ++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 229 insertions(+), 94 deletions(-)
---
[-- Attachment #2: bonding_doc.patch --]
[-- Type: text/x-patch, Size: 26248 bytes --]
[DOC] Update bonding documentation with sysfs info
Bonding documentation needed an update to include sysfs specific
information. This patch adds information on how to change bonding
parameters at runtime using the sysfs interface.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
bonding.txt | 323 ++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 229 insertions(+), 94 deletions(-)
---
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 8d8b4e5..afac780 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1,7 +1,7 @@
Linux Ethernet Bonding Driver HOWTO
- Latest update: 21 June 2005
+ Latest update: 24 April 2006
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
@@ -12,6 +12,8 @@ Corrections, HA extensions : 2000/10/03-
- Jay Vosburgh <fubar at us dot ibm dot com>
Reorganized and updated Feb 2005 by Jay Vosburgh
+Added Sysfs information: 2006/04/24
+ - Mitch Williams <mitch.a.williams at intel.com>
Introduction
============
@@ -38,61 +40,62 @@ Table of Contents
2. Bonding Driver Options
3. Configuring Bonding Devices
-3.1 Configuration with sysconfig support
-3.1.1 Using DHCP with sysconfig
-3.1.2 Configuring Multiple Bonds with sysconfig
-3.2 Configuration with initscripts support
-3.2.1 Using DHCP with initscripts
-3.2.2 Configuring Multiple Bonds with initscripts
-3.3 Configuring Bonding Manually
+3.1 Configuration with Sysconfig Support
+3.1.1 Using DHCP with Sysconfig
+3.1.2 Configuring Multiple Bonds with Sysconfig
+3.2 Configuration with Initscripts Support
+3.2.1 Using DHCP with Initscripts
+3.2.2 Configuring Multiple Bonds with Initscripts
+3.3 Configuring Bonding Manually with Ifenslave
3.3.1 Configuring Multiple Bonds Manually
+3.4 Configuring Bonding Manually via Sysfs
-5. Querying Bonding Configuration
-5.1 Bonding Configuration
-5.2 Network Configuration
+4. Querying Bonding Configuration
+4.1 Bonding Configuration
+4.2 Network Configuration
-6. Switch Configuration
+5. Switch Configuration
-7. 802.1q VLAN Support
+6. 802.1q VLAN Support
-8. Link Monitoring
-8.1 ARP Monitor Operation
-8.2 Configuring Multiple ARP Targets
-8.3 MII Monitor Operation
+7. Link Monitoring
+7.1 ARP Monitor Operation
+7.2 Configuring Multiple ARP Targets
+7.3 MII Monitor Operation
-9. Potential Trouble Sources
-9.1 Adventures in Routing
-9.2 Ethernet Device Renaming
-9.3 Painfully Slow Or No Failed Link Detection By Miimon
+8. Potential Trouble Sources
+8.1 Adventures in Routing
+8.2 Ethernet Device Renaming
+8.3 Painfully Slow Or No Failed Link Detection By Miimon
-10. SNMP agents
+9. SNMP agents
-11. Promiscuous mode
+10. Promiscuous mode
-12. Configuring Bonding for High Availability
-12.1 High Availability in a Single Switch Topology
-12.2 High Availability in a Multiple Switch Topology
-12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-12.2.2 HA Link Monitoring for Multiple Switch Topology
+11. Configuring Bonding for High Availability
+11.1 High Availability in a Single Switch Topology
+11.2 High Availability in a Multiple Switch Topology
+11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+11.2.2 HA Link Monitoring for Multiple Switch Topology
-13. Configuring Bonding for Maximum Throughput
-13.1 Maximum Throughput in a Single Switch Topology
-13.1.1 MT Bonding Mode Selection for Single Switch Topology
-13.1.2 MT Link Monitoring for Single Switch Topology
-13.2 Maximum Throughput in a Multiple Switch Topology
-13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
-13.2.2 MT Link Monitoring for Multiple Switch Topology
+12. Configuring Bonding for Maximum Throughput
+12.1 Maximum Throughput in a Single Switch Topology
+12.1.1 MT Bonding Mode Selection for Single Switch Topology
+12.1.2 MT Link Monitoring for Single Switch Topology
+12.2 Maximum Throughput in a Multiple Switch Topology
+12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
+12.2.2 MT Link Monitoring for Multiple Switch Topology
-14. Switch Behavior Issues
-14.1 Link Establishment and Failover Delays
-14.2 Duplicated Incoming Packets
+13. Switch Behavior Issues
+13.1 Link Establishment and Failover Delays
+13.2 Duplicated Incoming Packets
-15. Hardware Specific Considerations
-15.1 IBM BladeCenter
+14. Hardware Specific Considerations
+14.1 IBM BladeCenter
-16. Frequently Asked Questions
+15. Frequently Asked Questions
-17. Resources and Links
+16. Resources and Links
1. Bonding Driver Installation
@@ -156,6 +159,9 @@ you're trying to build it for. Some dis
onwards) do not have /usr/include/linux symbolically linked to the
default kernel source include directory.
+SECOND IMPORTANT NOTE:
+ If you plan to configure bonding using sysfs, you do not need
+to use ifenslave.
2. Bonding Driver Options
=========================
@@ -270,7 +276,7 @@ mode
In bonding version 2.6.2 or later, when a failover
occurs in active-backup mode, bonding will issue one
or more gratuitous ARPs on the newly active slave.
- One gratutious ARP is issued for the bonding master
+ One gratuitous ARP is issued for the bonding master
interface and each VLAN interfaces configured above
it, provided that the interface has at least one IP
address configured. Gratuitous ARPs issued for VLAN
@@ -377,7 +383,7 @@ mode
When a link is reconnected or a new slave joins the
bond the receive traffic is redistributed among all
active slaves in the bond by initiating ARP Replies
- with the selected mac address to each of the
+ with the selected MAC address to each of the
clients. The updelay parameter (detailed below) must
be set to a value equal or greater than the switch's
forwarding delay so that the ARP Replies sent to the
@@ -498,11 +504,12 @@ not exist, and the layer2 policy is the
3. Configuring Bonding Devices
==============================
- There are, essentially, two methods for configuring bonding:
-with support from the distro's network initialization scripts, and
-without. Distros generally use one of two packages for the network
-initialization scripts: initscripts or sysconfig. Recent versions of
-these packages have support for bonding, while older versions do not.
+ You can configure bonding using either your distro's network
+initialization scripts, or manually using either ifenslave or the
+sysfs interface. Distros generally use one of two packages for the
+network initialization scripts: initscripts or sysconfig. Recent
+versions of these packages have support for bonding, while older
+versions do not.
We will first describe the options for configuring bonding for
distros using versions of initscripts and sysconfig with full or
@@ -530,7 +537,7 @@ issue the command:
If this returns any matches, then your initscripts or
sysconfig has support for bonding.
-3.1 Configuration with sysconfig support
+3.1 Configuration with Sysconfig Support
----------------------------------------
This section applies to distros using a version of sysconfig
@@ -538,7 +545,7 @@ with bonding support, for example, SuSE
SuSE SLES 9's networking configuration system does support
bonding, however, at this writing, the YaST system configuration
-frontend does not provide any means to work with bonding devices.
+front end does not provide any means to work with bonding devices.
Bonding devices can be managed by hand, however, as follows.
First, if they have not already been configured, configure the
@@ -660,7 +667,7 @@ format can be found in an example ifcfg
Note that the template does not document the various BONDING_
settings described above, but does describe many of the other options.
-3.1.1 Using DHCP with sysconfig
+3.1.1 Using DHCP with Sysconfig
-------------------------------
Under sysconfig, configuring a device with BOOTPROTO='dhcp'
@@ -670,7 +677,7 @@ attempt to obtain the device address fro
the slave devices. Without active slaves, the DHCP requests are not
sent to the network.
-3.1.2 Configuring Multiple Bonds with sysconfig
+3.1.2 Configuring Multiple Bonds with Sysconfig
-----------------------------------------------
The sysconfig network initialization system is capable of
@@ -685,7 +692,7 @@ ifcfg-bondX files.
options in the ifcfg-bondX file, it is not necessary to add them to
the system /etc/modules.conf or /etc/modprobe.conf configuration file.
-3.2 Configuration with initscripts support
+3.2 Configuration with Initscripts Support
------------------------------------------
This section applies to distros using a version of initscripts
@@ -756,7 +763,7 @@ options for your configuration.
will restart the networking subsystem and your bond link should be now
up and running.
-3.2.1 Using DHCP with initscripts
+3.2.1 Using DHCP with Initscripts
---------------------------------
Recent versions of initscripts (the version supplied with
@@ -768,7 +775,7 @@ above, except replace the line "BOOTPROT
and add a line consisting of "TYPE=Bonding". Note that the TYPE value
is case sensitive.
-3.2.2 Configuring Multiple Bonds with initscripts
+3.2.2 Configuring Multiple Bonds with Initscripts
-------------------------------------------------
At this writing, the initscripts package does not directly
@@ -784,8 +791,8 @@ Fedora Core kernels, and has been seen o
exhibiting this problem, it will be impossible to configure multiple
bonds with differing parameters.
-3.3 Configuring Bonding Manually
---------------------------------
+3.3 Configuring Bonding Manually with Ifenslave
+-----------------------------------------------
This section applies to distros whose network initialization
scripts (the sysconfig or initscripts package) do not have specific
@@ -888,12 +895,140 @@ install bond1 /sbin/modprobe --ignore-in
This may be repeated any number of times, specifying a new and
unique name in place of bond1 for each subsequent instance.
+
+3.4 Configuring Bonding Manually via Sysfs
+------------------------------------------
+
+ Starting with version 3.0, Channel Bonding may be configured
+via the sysfs interface. This interface allows dynamic configuration
+of all bonds in the system without unloading the module. It also
+allows for adding and removing bonds at runtime. Ifenslave is no
+longer required, though it is still supported.
+
+ Use of the sysfs interface allows you to use multiple bonds
+with different configurations without having to reload the module.
+It also allows you to use multiple, differently configured bonds when
+bonding is compiled into the kernel.
+
+ You must have the sysfs filesystem mounted to configure
+bonding this way. The examples in this document assume that you
+are using the standard mount point for sysfs, e.g. /sys. If your
+sysfs filesystem is mounted elsewhere, you will need to adjust the
+example paths accordingly.
+
+Creating and Destroying Bonds
+-----------------------------
+To add a new bond foo:
+# echo +foo > /sys/class/net/bonding_masters
+
+To remove an existing bond bar:
+# echo -bar > /sys/class/net/bonding_masters
+
+To show all existing bonds:
+# cat /sys/class/net/bonding_masters
+
+NOTE: due to 4K size limitation of sysfs files, this list may be
+truncated if you have more than a few hundred bonds. This is unlikely
+to occur under normal operating conditions.
+
+Adding and Removing Slaves
+--------------------------
+ Interfaces may be enslaved to a bond using the file
+/sys/class/net/<bond>/bonding/slaves. The semantics for this file
+are the same as for the bonding_masters file.
+
+To enslave interface eth0 to bond bond0:
+# ifconfig bond0 up
+# echo +eth0 > /sys/class/net/bond0/bonding/slaves
+
+To free slave eth0 from bond bond0:
+# echo -eth0 > /sys/class/net/bond0/bonding/slaves
+
+ NOTE: The bond must be up before slaves can be added. All
+slaves are freed when the interface is brought down.
+
+ When an interface is enslaved to a bond, symlinks between the
+two are created in the sysfs filesystem. In this case, you would get
+/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
+/sys/class/net/eth0/master pointing to /sys/class/net/bond0.
+
+ This means that you can tell quickly whether or not an
+interface is enslaved by looking for the master symlink. Thus:
+# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves
+will free eth0 from whatever bond it is enslaved to, regardless of
+the name of the bond interface.
+
+Changing a Bond's Configuration
+-------------------------------
+ Each bond may be configured individually by manipulating the
+files located in /sys/class/net/<bond name>/bonding
+
+ The names of these files correspond directly with the command-
+line parameters described elsewhere in in this file, and, with the
+exception of arp_ip_target, they accept the same values. To see the
+current setting, simply cat the appropriate file.
+
+ A few examples will be given here; for specific usage
+guidelines for each parameter, see the appropriate section in this
+document.
+
+To configure bond0 for balance-alb mode:
+# ifconfig bond0 down
+# echo 6 > /sys/class/net/bond0/bonding/mode
+ - or -
+# echo balance-alb > /sys/class/net/bond0/bonding/mode
+ NOTE: The bond interface must be down before the mode can be
+changed.
+
+To enable MII monitoring on bond0 with a 1 second interval:
+# echo 1000 > /sys/class/net/bond0/bonding/miimon
+ NOTE: If ARP monitoring is enabled, it will disabled when MII
+monitoring is enabled, and vice-versa.
+
+To add ARP targets:
+# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
+# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target
+ NOTE: up to 10 target addresses may be specified.
+
+To remove an ARP target:
+# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
+
+Example Configuration
+---------------------
+ We begin with the same example that is shown in section 3.3,
+executed with sysfs, and without using ifenslave.
+
+ To make a simple bond of two e100 devices (presumed to be eth0
+and eth1), and have it persist across reboots, edit the appropriate
+file (/etc/init.d/boot.local or /etc/rc.d/rc.local), and add the
+following:
+
+modprobe bonding
+modprobe e100
+echo balance-alb > /sys/class/net/bond0/bonding/mode
+ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
+echo 100 > /sys/class/net/bond0/bonding/miimon
+echo +eth0 > /sys/class/net/bond0/bonding/slaves
+echo +eth1 > /sys/class/net/bond0/bonding/slaves
+
+ To add a second bond, with two e1000 interfaces in
+active-backup mode, using ARP monitoring, add the following lines to
+your init script:
+
+modprobe e1000
+echo +bond1 > /sys/class/net/bonding_masters
+echo active-backup > /sys/class/net/bond1/bonding/mode
+ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
+echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
+echo 2000 > /sys/class/net/bond1/bonding/arp_interval
+echo +eth2 > /sys/class/net/bond1/bonding/slaves
+echo +eth3 > /sys/class/net/bond1/bonding/slaves
-5. Querying Bonding Configuration
+4. Querying Bonding Configuration
=================================
-5.1 Bonding Configuration
+4.1 Bonding Configuration
-------------------------
Each bonding device has a read-only file residing in the
@@ -923,7 +1058,7 @@ generally as follows:
The precise format and contents will change depending upon the
bonding configuration, state, and version of the bonding driver.
-5.2 Network configuration
+4.2 Network configuration
-------------------------
The network configuration can be inspected using the ifconfig
@@ -958,7 +1093,7 @@ eth1 Link encap:Ethernet HWaddr 00
collisions:0 txqueuelen:100
Interrupt:9 Base address:0x1400
-6. Switch Configuration
+5. Switch Configuration
=======================
For this section, "switch" refers to whatever system the
@@ -991,7 +1126,7 @@ transmit policy for an EtherChannel grou
with another EtherChannel group.
-7. 802.1q VLAN Support
+6. 802.1q VLAN Support
======================
It is possible to configure VLAN devices over a bond interface
@@ -1042,7 +1177,7 @@ underlying device -- i.e. the bonding in
mode, which might not be what you want.
-8. Link Monitoring
+7. Link Monitoring
==================
The bonding driver at present supports two schemes for
@@ -1053,7 +1188,7 @@ monitor.
bonding driver itself, it is not possible to enable both ARP and MII
monitoring simultaneously.
-8.1 ARP Monitor Operation
+7.1 ARP Monitor Operation
-------------------------
The ARP monitor operates as its name suggests: it sends ARP
@@ -1071,7 +1206,7 @@ those slaves will stay down. If network
shows the ARP requests and replies on the network, then it may be that
your device driver is not updating last_rx and trans_start.
-8.2 Configuring Multiple ARP Targets
+7.2 Configuring Multiple ARP Targets
------------------------------------
While ARP monitoring can be done with just one target, it can
@@ -1094,7 +1229,7 @@ alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.100
-8.3 MII Monitor Operation
+7.3 MII Monitor Operation
-------------------------
The MII monitor monitors only the carrier state of the local
@@ -1120,14 +1255,14 @@ does not support or had some error in pr
and ethtool requests), then the MII monitor will assume the link is
up.
-9. Potential Sources of Trouble
+8. Potential Sources of Trouble
===============================
-9.1 Adventures in Routing
+8.1 Adventures in Routing
-------------------------
When bonding is configured, it is important that the slave
-devices not have routes that supercede routes of the master (or,
+devices not have routes that supersede routes of the master (or,
generally, not have routes at all). For example, suppose the bonding
device bond0 has two slaves, eth0 and eth1, and the routing table is
as follows:
@@ -1154,11 +1289,11 @@ by the state of the routing table.
The solution here is simply to insure that slaves do not have
routes of their own, and if for some reason they must, those routes do
-not supercede routes of their master. This should generally be the
+not supersede routes of their master. This should generally be the
case, but unusual configurations or errant manual or automatic static
route additions may cause trouble.
-9.2 Ethernet Device Renaming
+8.2 Ethernet Device Renaming
----------------------------
On systems with network configuration scripts that do not
@@ -1207,7 +1342,7 @@ modprobe with --ignore-install to cause
place. Full documentation on this can be found in the modprobe.conf
and modprobe manual pages.
-9.3. Painfully Slow Or No Failed Link Detection By Miimon
+8.3. Painfully Slow Or No Failed Link Detection By Miimon
---------------------------------------------------------
By default, bonding enables the use_carrier option, which
@@ -1235,7 +1370,7 @@ carrier state. It has no way to determi
beyond other ports of a switch, or if a switch is refusing to pass
traffic while still maintaining carrier on.
-10. SNMP agents
+9. SNMP agents
===============
If running SNMP agents, the bonding driver should be loaded
@@ -1281,7 +1416,7 @@ ifDescr, the association between the IP
and SNMP functions such as Interface_Scan_Next will report that
association.
-11. Promiscuous mode
+10. Promiscuous mode
====================
When running network monitoring tools, e.g., tcpdump, it is
@@ -1308,7 +1443,7 @@ sending to peers that are unassigned or
the active slave changes (e.g., due to a link failure), the
promiscuous setting will be propagated to the new active slave.
-12. Configuring Bonding for High Availability
+11. Configuring Bonding for High Availability
=============================================
High Availability refers to configurations that provide
@@ -1318,7 +1453,7 @@ goal is to provide the maximum availabil
(i.e., the network always works), even though other configurations
could provide higher throughput.
-12.1 High Availability in a Single Switch Topology
+11.1 High Availability in a Single Switch Topology
--------------------------------------------------
If two hosts (or a host and a single switch) are directly
@@ -1332,7 +1467,7 @@ the load will be rebalanced across the r
See Section 13, "Configuring Bonding for Maximum Throughput"
for information on configuring bonding with one peer device.
-12.2 High Availability in a Multiple Switch Topology
+11.2 High Availability in a Multiple Switch Topology
----------------------------------------------------
With multiple switches, the configuration of bonding and the
@@ -1359,7 +1494,7 @@ switches (ISL, or inter switch link), an
the outside world ("port3" on each switch). There is no technical
reason that this could not be extended to a third switch.
-12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-------------------------------------------------------------
In a topology such as the example above, the active-backup and
@@ -1381,7 +1516,7 @@ broadcast: This mode is really a special
necessary for some specific one-way traffic to reach both
independent networks, then the broadcast mode may be suitable.
-12.2.2 HA Link Monitoring Selection for Multiple Switch Topology
+11.2.2 HA Link Monitoring Selection for Multiple Switch Topology
----------------------------------------------------------------
The choice of link monitoring ultimately depends upon your
@@ -1402,10 +1537,10 @@ regardless of which switch is active, th
target to query.
-13. Configuring Bonding for Maximum Throughput
+12. Configuring Bonding for Maximum Throughput
==============================================
-13.1 Maximizing Throughput in a Single Switch Topology
+12.1 Maximizing Throughput in a Single Switch Topology
------------------------------------------------------
In a single switch configuration, the best method to maximize
@@ -1476,7 +1611,7 @@ destination to make load balancing decis
mode is described below.
-13.1.1 MT Bonding Mode Selection for Single Switch Topology
+12.1.1 MT Bonding Mode Selection for Single Switch Topology
-----------------------------------------------------------
This configuration is the easiest to set up and to understand,
@@ -1607,7 +1742,7 @@ balance-alb: This mode is everything tha
device driver must support changing the hardware address while
the device is open.
-13.1.2 MT Link Monitoring for Single Switch Topology
+12.1.2 MT Link Monitoring for Single Switch Topology
----------------------------------------------------
The choice of link monitoring may largely depend upon which
@@ -1616,7 +1751,7 @@ support the use of the ARP monitor, and
the MII monitor (which does not provide as high a level of end to end
assurance as the ARP monitor).
-13.2 Maximum Throughput in a Multiple Switch Topology
+12.2 Maximum Throughput in a Multiple Switch Topology
-----------------------------------------------------
Multiple switches may be utilized to optimize for throughput
@@ -1651,7 +1786,7 @@ a single 72 port switch.
can be equipped with an additional network device connected to an
external network; this host then additionally acts as a gateway.
-13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
+12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
-------------------------------------------------------------
In actual practice, the bonding mode typically employed in
@@ -1664,7 +1799,7 @@ packets has arrived). When employed in
mode allows individual connections between two hosts to effectively
utilize greater than one interface's bandwidth.
-13.2.2 MT Link Monitoring for Multiple Switch Topology
+12.2.2 MT Link Monitoring for Multiple Switch Topology
------------------------------------------------------
Again, in actual practice, the MII monitor is most often used
@@ -1674,10 +1809,10 @@ advantages over the MII monitor are miti
needed as the number of systems involved grows (remember that each
host in the network is configured with bonding).
-14. Switch Behavior Issues
+13. Switch Behavior Issues
==========================
-14.1 Link Establishment and Failover Delays
+13.1 Link Establishment and Failover Delays
-------------------------------------------
Some switches exhibit undesirable behavior with regard to the
@@ -1712,7 +1847,7 @@ switches take a long time to go into bac
to not activate a backup interface immediately after a link goes down.
Failover may be delayed via the downdelay bonding module option.
-14.2 Duplicated Incoming Packets
+13.2 Duplicated Incoming Packets
--------------------------------
It is not uncommon to observe a short burst of duplicated
@@ -1751,14 +1886,14 @@ behavior, it can be induced by clearing
most Cisco switches, the privileged command "clear mac address-table
dynamic" will accomplish this).
-15. Hardware Specific Considerations
+14. Hardware Specific Considerations
====================================
This section contains additional information for configuring
bonding on specific hardware platforms, or for interfacing bonding
with particular switches or other devices.
-15.1 IBM BladeCenter
+14.1 IBM BladeCenter
--------------------
This applies to the JS20 and similar systems.
@@ -1861,7 +1996,7 @@ (either the internal Ethernet Switch Mod
avoid fail-over delay issues when using bonding.
-16. Frequently Asked Questions
+15. Frequently Asked Questions
==============================
1. Is it SMP safe?
@@ -1925,7 +2060,7 @@ not have special switch requirements, bu
support specific features (described in the appropriate section under
module parameters, above).
- In 802.3ad mode, it works with with systems that support IEEE
+ In 802.3ad mode, it works with systems that support IEEE
802.3ad Dynamic Link Aggregation. Most managed and many unmanaged
switches currently available support 802.3ad.
^ permalink raw reply related
* Re: [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
From: Jari Takkala @ 2006-06-08 18:21 UTC (permalink / raw)
To: David Miller, akpm; +Cc: netdev
On Mon, 5 Jun 2006, David Miller wrote:
> This patch doesn't make any sense, I've been over it a few times.
>
> The seqfile layer should take care of that user buffering issue
transparently as
> long as we implement the interface callbacks properly.
>
> Even if something needs to be fixed in the pneigh dumper, special
casing *pos==1
> doesn't look right. Also, if pneigh has this problem, how come the
neigh seqfile
> iterators don't have the same problem or do they?
>From my analysis, the problem is that pneigh_get_next() ends up
assigning pn to one entry ahead of what it should be pointing too. This
only occurs when the user's read buffer fills up, where pneigh_get_idx()
is called, which calls pneigh_get_next() until *pos is not true.
I have not checked neigh seqfile iterators, the problem may exist in
there as well. My patch solves this issue for us, however a more elegant
solution would be most welcome. Could the root of the problem be that
*pos is off by one when pneigh_get_idx() is called?
Jari
^ permalink raw reply
* Re: [PATCH 1/2] e1000: fix netpoll with NAPI
From: John W. Linville @ 2006-06-08 18:39 UTC (permalink / raw)
To: Mitch Williams
Cc: Kok, Auke-jan H, Matt Mackall, Garzik, Jeff, Neil Horman,
Jeff Moyer, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <1149787436.2928.9.camel@strongmad>
On Thu, Jun 08, 2006 at 10:23:56AM -0700, Mitch Williams wrote:
> On Wed, 2006-06-07 at 11:54 -0700, John W. Linville wrote:
>
> > Pedantic objection, but I think this would read easier w/o the extra
> > newline before disable_irq.
>
> Heh. I prefer to have a newline between declarations and code. The
Normally I would agree. But in this case, I find the distraction of
the random newline after the #else to be more compelling.
> real problem is the position of the #ifdef -- that's what makes it
> difficult to read. The other solution would be
> {
> struct e1000_adapter *adapter = netdev_priv(netdev);
> #ifdef CONFIG_E1000_NAPI
> int budget = 0;
> #endif
>
> disable_irq(adapter->pdev->irq);
>
> #ifdef CONFIG_E1000_NAPI
> < all that stuff >
> #else
> <rest of the stuff >
> #endif
> }
>
> Which I think is worse to read.
I presume it is the double #ifdef that you find objectionable?
I don't really like it, but at least that idiom is quite common.
Given that the disable_irq appears in both code paths (almost by
necessity), there is a certain appeal to having it outside of the
#ifdef block. That seems more maintainable.
To me, the idiomatic #ifdef placement seems more readable, if for no
other reason than familiarity. I suppose we can agree to disagree.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: David Miller @ 2006-06-08 18:51 UTC (permalink / raw)
To: gerrit; +Cc: yoshfuji, kuznet, pekkas, jmorris, kaber, linux-kernel, netdev
In-Reply-To: <200606081222.54856.gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 8 Jun 2006 12:22:54 +0100
> I am sorry, I don't at the moment have the time to port to v6 with the
> same degree of rigour.
You give the impression that you would just disappear from the face of
the planet should your work actually be integrated into the kernel
tree.
So I can only assume that you are posting this for people to play
around with, and not for serious consideration of inclusion into the
kernel tree.
We're trying to avoid this serious problem we have where a group or
individual submits on a piece of code, works just hard enough to get
it integrated into the tree, then disappears and does not stick around
to support the inevitable ensuing bugs and problem reports. Such
behavior is totally irresponsible, yet it happens quite a bit.
So if you can't be bothered to cook up IPV6 support, chances are you
won't stick around to support your code if it went into the tree
either.
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: David Miller @ 2006-06-08 18:53 UTC (permalink / raw)
To: gerrit; +Cc: alan, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <200606081703.55361.gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 8 Jun 2006 17:03:54 +0100
> Understood. Please, anyone, disregard or un-apply the previous
> UDP-Lite patch. A revised patch will be prepared and posted as soon
> as testing permits.
Nobody is going to integrate your patch anywhere, don't worry.
You make it clear that once you toss this piece of code over
the wall, you'll disappear.
^ permalink raw reply
* Firewall question
From: Alex Davis @ 2006-06-08 18:57 UTC (permalink / raw)
To: netfilter, netdev
The scenario:
I have a DSL modem in pass through (bridge) mode. The linux firewall/router
has a single ethernet card. It is running pppoe. This gives two interfaces:
eth0 and ppp0. The firewall is running iptables. There are several machines
behind the firewall.
Problem:
I've been told that if someone whose public IP address is on the same
network subnet as mine were to get my mac address, (s)he could bypass
the firewall and talk directly to the machines behind it.
Is this true?
Thanks.
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [Bugme-new] [Bug 6666] New: invalid tcp socket connection to windows stacks
From: David Miller @ 2006-06-08 18:57 UTC (permalink / raw)
To: akpm; +Cc: netdev, technik, bugme-daemon
In-Reply-To: <20060608103627.23cfc83a.akpm@osdl.org>
FIN only gets output when the connection is actually closed
for sending, and that is controlled by the application not
by the kernel.
^ permalink raw reply
* Re: Firewall question
From: Lennart Sorensen @ 2006-06-08 19:26 UTC (permalink / raw)
To: Alex Davis; +Cc: netfilter, netdev
In-Reply-To: <20060608185712.79340.qmail@web50207.mail.yahoo.com>
On Thu, Jun 08, 2006 at 11:57:12AM -0700, Alex Davis wrote:
> The scenario:
> I have a DSL modem in pass through (bridge) mode. The linux firewall/router
> has a single ethernet card. It is running pppoe. This gives two interfaces:
> eth0 and ppp0. The firewall is running iptables. There are several machines
> behind the firewall.
>
> Problem:
> I've been told that if someone whose public IP address is on the same
> network subnet as mine were to get my mac address, (s)he could bypass
> the firewall and talk directly to the machines behind it.
>
> Is this true?
Well the DSL modem only transfers whatever data the ISP end sends to it,
which in your case is just PPP packets (LCC or LCP I think). No one out
on the internet would be able to send ethernet data over the DSL link,
so the only way to send data to another machine on your network (that
the DSL modem is connected to physically) is if you have other machines
on your local network which are also running PPPoE and listening for
that traffic.
So the worst thing I can see happening is that someone on your local
network could potentially take over your PPPoE session, but that's about
it. I just can't see anything else that could happen. I used to run
exactly the setup you describe before I had to drop the DSL connection
(I moved).
Len Sorensen
^ permalink raw reply
* Using netconsole for debugging suspend/resume
From: Jeremy Fitzhardinge @ 2006-06-08 17:50 UTC (permalink / raw)
To: Matt Mackall, Linux Kernel Mailing List, netdev
I've been trying to get suspend/resume working well on my new laptop.
In general, netconsole has been pretty useful for extracting oopses and
other messages, but it is of more limited help in debugging the actual
suspend/resume cycle. The problem looks like the e1000 driver won't
suspend while netconsole is using it, so I have to rmmod/modprobe
netconsole around the actual suspend/resume.
This is a big problem during resume because the screen is also blank, so
I get no useful clue as to what went wrong when things go wrong. I'm
wondering if there's some way to keep netconsole alive to the last
possible moment during suspend, and re-woken as soon as possible during
resume. It would be nice to have a clean solution, but I'm willing to
use a bletcherous hack if that's what it takes.
Any ideas?
Thanks,
J
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 19:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <1149720298.23938.207.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
> Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
ACK, but patch does not apply to netdev-2.6.git#upstream.
Jeff
^ permalink raw reply
* Re: [PATCH 1/5] skge: use workq for PHY handling
From: Jeff Garzik @ 2006-06-08 19:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20060606171341.432229000@zqx3.pdx.osdl.net>
applied 1-5 to #upstream
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: James Morris @ 2006-06-08 19:46 UTC (permalink / raw)
To: David Miller
Cc: gerrit, alan, kuznet, pekkas, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <20060608.115331.71094388.davem@davemloft.net>
On Thu, 8 Jun 2006, David Miller wrote:
> > Understood. Please, anyone, disregard or un-apply the previous
> > UDP-Lite patch. A revised patch will be prepared and posted as soon
> > as testing permits.
>
> Nobody is going to integrate your patch anywhere, don't worry.
> You make it clear that once you toss this piece of code over
> the wall, you'll disappear.
Having dealt with more than enough code thrown over the wall in recent
times, I agree.
But, if someone well known & trusted wants to claim responsibility for the
code once it's upstream, that might be a way forward (I think the Apache
project has or had a policy like this).
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Please pull 'upstream-fixes' branch of wireless-2.6
From: Jeff Garzik @ 2006-06-08 19:46 UTC (permalink / raw)
To: jeff, netdev
In-Reply-To: <20060605215353.GA7381@tuxdriver.com>
John W. Linville wrote:
> This pull is intended for 2.6.17 if at all possible.
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit 672c6108a51bf559d19595d9f8193dfd81f0f752:
> Linus Torvalds:
> Merge master.kernel.org:/.../jejb/scsi-rc-fixes-2.6
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes
pulled
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Jeff Garzik @ 2006-06-08 19:48 UTC (permalink / raw)
To: John W. Linville, netdev
In-Reply-To: <20060605215513.GB7381@tuxdriver.com>
John W. Linville wrote:
> This pull is intended for 2.6.18.
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit f6882a0688ea83db5fc2f3491ac9fcdce0834cc7:
> John W. Linville:
> Merge branch 'upstream-fixes' into upstream
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream
applied
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Gerrit Renker @ 2006-06-08 20:09 UTC (permalink / raw)
To: James Morris
Cc: David Miller, alan, kuznet, pekkas, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <Pine.LNX.4.64.0606081542390.3555@d.namei>
Quoting James Morris:
| On Thu, 8 Jun 2006, David Miller wrote:
|
| > > Understood. Please, anyone, disregard or un-apply the previous
| > > UDP-Lite patch. A revised patch will be prepared and posted as soon
| > > as testing permits.
| >
| > Nobody is going to integrate your patch anywhere, don't worry.
| > You make it clear that once you toss this piece of code over
| > the wall, you'll disappear.
|
| Having dealt with more than enough code thrown over the wall in recent
| times, I agree.
I understand the points of both of you well enough. But how come this is interpreted
as saying I'd "toss this piece of code over the wall"? I can understand getting tired
of cowboy coding jobs, but there is a misunderstanding here.
Of course do and will I maintain that code and every issue related it. I have been
maintaining, improving, testing this code for 9 months. The protocol spec (RFC 3828)
was developed at University of Aberdeen, and there is continuing research into
UDP-Lite here, i.e. it is not a `dead' project. That is why I held back regarding the
IPv6 port: I can ensure that this (IPv4) code is up to standard and to date, but am
lacking the required additional time to implement the same for IPv6.
I am trying to contact people to help with the port, but for the moment I will take
responsibility only for the IPv4 version.
And if there is someone `well-known and respected' who is interested in taking this code
over, I would only be happy for him/her to do this. But I won't simply `disappear' :-)
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <44887BD3.7000009@garzik.org>
On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote:
> Jon Loeliger wrote:
> > Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
> > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> ACK, but patch does not apply to netdev-2.6.git#upstream.
>
> Jeff
Thanks, Jeff.
Are you willing to take the netdev parts as-is, then?
Or would you like me to reformat the netdev parts to
apply against the netdev-2.6.git#upstream branch?
The patch is currently for the Paul Mackerras powerpc.git
tree as it stands now. Should we apply it through that
path now as you have ACK'ed it?
Thanks,
jdl
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Auke Kok @ 2006-06-08 20:35 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
>
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
>
> Any ideas?
Have you tried using different cards/drivers? This might or might not be
either a netconsole problem (generic) or driver related (which could impact
other drivers too).
From the top of my head I don't see any reason why the e1000 shouldn't handle
the suspend event - but mind you that a fix for e1000/WoL impacting shutdown
handlers was only recently added. Which kernels does this impact?
Auke
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 20:36 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <1149797603.23938.251.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote:
>> Jon Loeliger wrote:
>>> Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
>>> Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>> ACK, but patch does not apply to netdev-2.6.git#upstream.
>>
>> Jeff
>
> Thanks, Jeff.
>
> Are you willing to take the netdev parts as-is, then?
> Or would you like me to reformat the netdev parts to
> apply against the netdev-2.6.git#upstream branch?
> The patch is currently for the Paul Mackerras powerpc.git
> tree as it stands now. Should we apply it through that
> path now as you have ACK'ed it?
Is it dependent on other stuff in Paul's tree?
Normally this should come through netdev-2.6.git#upstream...
Jeff
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Rafael J. Wysocki @ 2006-06-08 20:40 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
>
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
>
> Any ideas?
Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend.
Greetings,
Rafael
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <44888A37.3090401@garzik.org>
On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote:
> Is it dependent on other stuff in Paul's tree?
Yes, very much so. Most of this patch set is an
entirely new PPC board port against his arch/powerpc
basis. The new PHY is incidentally on that board,
but the patches for its introduction could be
introduced through the netdev tree if needed.
It would just need to be coordinated some. I am,
of course, willing to work it either way as needed.
jdl
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 20:46 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev, Paul Mackerras
In-Reply-To: <1149799209.23938.256.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote:
>> Is it dependent on other stuff in Paul's tree?
>
> Yes, very much so. Most of this patch set is an
> entirely new PPC board port against his arch/powerpc
> basis. The new PHY is incidentally on that board,
> but the patches for its introduction could be
> introduced through the netdev tree if needed.
> It would just need to be coordinated some. I am,
> of course, willing to work it either way as needed.
I leave it up to you and Paul to coordinate, then :)
I'm fine with the patch, and if its better to merge via linuxppc.git,
that's OK with me. If you would prefer to send it via my tree, to go
ahead and get it in, that's fine too.
Jeff
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, netdev
In-Reply-To: <44888CB3.1060507@garzik.org>
On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote:
> I leave it up to you and Paul to coordinate, then :)
>
> I'm fine with the patch, and if its better to merge via linuxppc.git,
> that's OK with me. If you would prefer to send it via my tree, to go
> ahead and get it in, that's fine too.
OK, thanks. I need to re-submit 5 of 10 parts for
other cleanup issues anyway, so I think I will:
- Resubmit the entire patch set,
- Resubmit netdev parts to Paul, and netdev with
an added ACK: by you line (OK?),
- Throw myself on the mercy of "Help us Obi-wan Mackerras"
and see what he says when he wakes up!
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 21:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev, Paul Mackerras
In-Reply-To: <1149799949.23938.264.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote:
>
>> I leave it up to you and Paul to coordinate, then :)
>>
>> I'm fine with the patch, and if its better to merge via linuxppc.git,
>> that's OK with me. If you would prefer to send it via my tree, to go
>> ahead and get it in, that's fine too.
>
> OK, thanks. I need to re-submit 5 of 10 parts for
> other cleanup issues anyway, so I think I will:
>
> - Resubmit the entire patch set,
> - Resubmit netdev parts to Paul, and netdev with
> an added ACK: by you line (OK?),
OK with me. Since we use a specific header to indicate such, that would be:
Acked-by: Jeff Garzik <jeff@garzik.org>
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Matt Mackall @ 2006-06-08 21:07 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thu, Jun 08, 2006 at 10:50:57AM -0700, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
It's generally going to suck, because unlike a polled serial port, the
device needs to be put to sleep. But if you're doing suspend to RAM,
you might be able to do something like this:
- unhook net device from suspend machinery (possibly just return success)
- bounce out of suspend before the final call to ACPI is made
Net effect is you do OS-level suspend and resume of everything but the
NIC without actually powering down the core. Which should let you
debug just about everything.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: New tulip maintainer...
From: Valerie Henson @ 2006-06-08 21:24 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, Netdev List
In-Reply-To: <20060608160639.GH8246@colo.lackof.org>
On 6/8/06, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote:
> > Now that we have a new tulip maintainer, perhaps a resend of the
> > long-outstanding tulip phy patches could be resent?
>
> All the tulip patches I have are archived here:
> ftp://ftp.parisc-linux.org/patches/
>
> Anything else tulip I've been involved with is available
> via CVS from cvs.parisc-linux.org/linux-2.6/
>
> Thibaut Varene has also committed his changes to that CVS.
Hey folks,
Just a quick note to say that, yes, in a moment of weak-willed
delusion, I did let Jeff pressure me into becoming the tulip
maintainer. I will accept tokens of condolence in the form of beer,
money, and old tulip cards (email me for my shipping address).
I'm going to be a tiny bit busy the next couple of weeks - minor
things like running the file systems workshop and moving house - but I
am paying attention and will start testing and shipping patches as
soon as possible.
One quick note: please use my spiffy val_henson@linux.intel.com
address (see From: address) for Linux stuff. Besides giving props to
my employer, it's much easier to send/receive patches from that
account.
-VAL
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox