* [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.24
From: Roland Dreier @ 2007-09-17 21:47 UTC (permalink / raw)
To: Shirley Ma; +Cc: netdev, linux-kernel, general, netdev-owner
In-Reply-To: <OF1B5CCF10.3CE4B194-ON87257356.00661AD2-88257356.0065F05E@us.ibm.com>
> > IPoIB CM handles this properly by gathering together single pages in
> > skbs' fragment lists.
> Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
^ permalink raw reply
* Re: [PATCH] bonding: update some distro-specific documentation
From: Andy Gospodarek @ 2007-09-17 21:53 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <21001.1189189669@death>
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=no
> >+BONDING_OPTS="mode=balance-alb miimon=100"
> >
> > Be sure to change the networking specific lines (IPADDR,
> > NETMASK, NETWORK and BROADCAST) to match your network configuration.
> >+You also need to set the BONDING_OPTS= line to specify the desired
> >+options for your bond0 interface. Specifying bonding options in this
> >+way is the preferred method for configuring bonding interfaces.
>
> Can you add something here that mentions that, for the
> arp_ip_target option, it has to be supplied as "arp_ip_target=+10.0.0.1"
> and not just "arp_ip_target=10.0.0.1"? Also, multiple targets require
> multiple instances of the arp_ip_target option; it doesn't work to put
> multiple IP addresses as in the module option (i.e.,
> "arp_ip_target=10.0.0.1,10.0.0.2").
>
> This is necessary because ifup-eth isn't adding the "+" when it
> translates the option for use with sysfs or parsing the multiple IP
> address syntax.
>
> -J
>
Crap, I just realized I had arp_monitor (huh?) instead of arp_ip_target.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
bonding.txt | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1da5666..2402412 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file.
------------------------------------------
This section applies to distros using a version of initscripts
-with bonding support, for example, Red Hat Linux 9 or Red Hat
-Enterprise Linux version 3 or 4. On these systems, the network
-initialization scripts have some knowledge of bonding, and can be
+with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise
+Linux version 3, 4 or 5, Fedora, etc. On these systems, the network
+initialization scripts have some knowledge of bonding, and can be
configured to control bonding devices.
These distros will not automatically load the network adapter
@@ -802,18 +802,27 @@ BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
+BONDING_OPTS="mode=active-backup arp_ip_target=+192.168.1.254"
Be sure to change the networking specific lines (IPADDR,
NETMASK, NETWORK and BROADCAST) to match your network configuration.
-
- Finally, it is necessary to edit /etc/modules.conf (or
+You also need to set the BONDING_OPTS= line to specify the desired
+options for your bond0 interface. Specifying bonding options in this
+way is the preferred method for configuring bonding interfaces. The
+options specified in BONDING_OPTS are identical to the bonding module
+parameters except for the arp_ip_target field. Each target should be
+included as a separate address and should be preceded by a '+' to
+indicate it should be added to the list of queried targets.
+
+ It is no longer necessary to edit /etc/modules.conf (or
/etc/modprobe.conf, depending upon your distro) to load the bonding
module with your desired options when the bond0 interface is brought
up. The following lines in /etc/modules.conf (or modprobe.conf) will
-load the bonding module, and select its options:
+load the bonding module, and select its options but this is no longer
+the preferred method.
alias bond0 bonding
-options bond0 mode=balance-alb miimon=100
+options bond0 mode=active-backup arp_ip_target=192.168.1.254
Replace the sample parameters with the appropriate set of
options for your configuration.
@@ -826,8 +835,9 @@ up and running.
---------------------------------
Recent versions of initscripts (the version supplied with
-Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do
-have support for assigning IP information to bonding devices via DHCP.
+Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to
+work) do have support for assigning IP information to bonding devices
+via DHCP.
To configure bonding for DHCP, configure it as described
above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
@@ -837,18 +847,19 @@ is case sensitive.
3.2.2 Configuring Multiple Bonds with Initscripts
-------------------------------------------------
- At this writing, the initscripts package does not directly
-support loading the bonding driver multiple times, so the process for
-doing so is the same as described in the "Configuring Multiple Bonds
-Manually" section, below.
-
- NOTE: It has been observed that some Red Hat supplied kernels
-are apparently unable to rename modules at load time (the "-o bond1"
-part). Attempts to pass that option to modprobe will produce an
-"Operation not permitted" error. This has been reported on some
-Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
-exhibiting this problem, it will be impossible to configure multiple
-bonds with differing parameters.
+ Initscripts packages that are included with Fedora 7 and Red
+Hat Enterprise Linux 5 support multiple bonding interfaces by simply
+specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is
+the number of the bond. Other distros may not include support in
+initscripts for multiple bonding interfaces, so you may need to follow
+the process as described in the "Configuring Multiple Bonds Manually"
+section, below.
+
+ It has been observed that much older kernels are apparently
+unable to rename modules at load time (the "-o bond1" part). Attempts
+to pass that option to modprobe will produce an "Operation not
+permitted" error. On kernels exhibiting this problem, it will be
+impossible to configure multiple bonds with differing parameters.
3.3 Configuring Bonding Manually with Ifenslave
-----------------------------------------------
^ permalink raw reply related
* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-17 22:08 UTC (permalink / raw)
To: Domen Puncer; +Cc: Jeff Garzik, netdev, linuxppc-embedded
In-Reply-To: <20070917202140.GB2642@nd47.coderock.org>
On 9/17/07, Domen Puncer <domen@coderock.org> wrote:
> Export phy_mii_ioctl, so network drivers can use it when built
> as modules too.
Domen, do you want to collect all of these changes for MPC5200 FEC in
to a single patch series? The code is getting scattered around, I'll
check it over to make sure it is all working. I have these patches
applied individually and they all work.
It builds on this series:
[PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
If you can put this together is a clean series, I should be able to
layer support for the Phytec pcm030 on top of it.
It would be these three combined...
http://coderock.org/tmp/fec-v3rc1/
diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c
index 922e9a8..c4442e0 100644
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -1087,11 +1087,13 @@ static struct of_platform_driver mpc52xx_fec_driver = {
/* ======================================================================== */
/* Module */
/* ======================================================================== */
+extern int fec_mdio_init(void);
+void fec_mdio_exit(void);
static int __init
mpc52xx_fec_init(void)
{
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
int ret;
ret = fec_mdio_init();
if (ret) {
@@ -1106,7 +1108,7 @@ static void __exit
mpc52xx_fec_exit(void)
{
of_unregister_platform_driver(&mpc52xx_fec_driver);
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
fec_mdio_exit();
#endif
}
>
> Signed-off-by: Domen Puncer <domen@coderock.org>
>
> ---
> On 17/09/07 11:53 +0200, Sven Luther wrote:
> > On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote:
> > > Updated and split version at:
> > > http://coderock.org/tmp/fec-v3rc1/
> > >
> > > I'll repost to lists once I run-test them.
> >
> > When applying those patches, the build did die with :
> >
> >
> > ERROR: "phy_mii_ioctl" [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined!
> >
> > Apparently, phy_mii_ioctl is not an exported symbol.
> >
> > Domen, did you maybe forget a little snipplet when you cut the patches
> > in different pieces ? Or did i mess up applying them ?
> >
> > Friendly,
> >
> > Sven Luther
>
>
> drivers/net/phy/phy.c | 1 +
> 1 files changed, 1 insertion(+)
>
> Index: linux.git/drivers/net/phy/phy.c
> ===================================================================
> --- linux.git.orig/drivers/net/phy/phy.c
> +++ linux.git/drivers/net/phy/phy.c
> @@ -409,6 +409,7 @@ int phy_mii_ioctl(struct phy_device *phy
>
> return 0;
> }
> +EXPORT_SYMBOL(phy_mii_ioctl);
>
> /**
> * phy_start_aneg - start auto-negotiation for this PHY device
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
From: Roland Dreier @ 2007-09-17 22:11 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev, Jay Vosburgh, linux-kernel, general
In-Reply-To: <46ECEE3F.60301@voltaire.com>
> The IGMP enabling patch posted by me on September 2nd isn't on your list
> http://lists.openfabrics.org/pipermail/general/2007-September/040250.html
> can you add it?
Yes, I lost that somehow. I will add it to my list of things to take
a look at (no opinion yet).
- R.
^ permalink raw reply
* [ofa-general] Re: [PATCH 01/11] IB/ipoib: Export call to call_netdevice_notifiers and add new private flag
From: Roland Dreier @ 2007-09-17 22:17 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, general, jgarzik, davem
In-Reply-To: <11898132322950-git-send-email-fubar@us.ibm.com>
I tried to look at the ipoib stuff in this series... this patch looks
fine but it doesn't actually touch ipoib, so the subject line is a bit
misleading...
^ permalink raw reply
* Re: [PATCH 04/11] IB/ipoib: Verify address handle validity on send
From: Roland Dreier @ 2007-09-17 22:20 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, monis, monisonlists, ogerlitz, jgarzik, davem, general
In-Reply-To: <11898132372856-git-send-email-fubar@us.ibm.com>
Looks fine overall, with one minor nitpick:
> - if (unlikely(memcmp(&neigh->dgid.raw,
> + if (unlikely((memcmp(&neigh->dgid.raw,
> skb->dst->neighbour->ha + 4,
> - sizeof(union ib_gid)))) {
> + sizeof(union ib_gid))) ||
> + (neigh->dev != dev))) {
the indentation here makes this confusing to read -- I would just do:
} else if (neigh->ah) {
if (unlikely(memcmp(&neigh->dgid.raw,
skb->dst->neighbour->ha + 4,
- sizeof(union ib_gid)))) {
+ sizeof(union ib_gid)) ||
+ neigh->dev != dev)) {
^ permalink raw reply
* [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
From: Roland Dreier @ 2007-09-17 22:22 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, general, jgarzik, davem
In-Reply-To: <1189813234208-git-send-email-fubar@us.ibm.com>
OK with me.
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/11] IB/ipoib: Bound the net device to the ipoib_neigh structue
From: Roland Dreier @ 2007-09-17 22:23 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, general, jgarzik, davem
In-Reply-To: <11898132352341-git-send-email-fubar@us.ibm.com>
Overall idea looks good... one comment:
> + if (n->dev->flags & IFF_MASTER) {
> + /* n->dev is not an IPoIB device and we have
> + to take priv from elsewhere */
> + neigh = *to_ipoib_neigh(n);
> + if (neigh) {
> + priv = netdev_priv(neigh->dev);
> + ipoib_dbg(priv, "neigh_destructor for bonding device: %s\n",
> + n->dev->name);
> + } else
> + return;
> + }
seems like it would be cleaner not to worry about bonding here and
just use neigh->dev all the time rather than having two ways to look
up the device.
^ permalink raw reply
* [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.24
From: Shirley Ma @ 2007-09-17 22:24 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, linux-kernel, general, netdev-owner
In-Reply-To: <ada1wcxnev5.fsf@cisco.com>
[-- Attachment #1.1: Type: text/plain, Size: 782 bytes --]
netdev-owner@vger.kernel.org wrote on 09/17/2007 02:47:42 PM:
> > > IPoIB CM handles this properly by gathering together single pages in
> > > skbs' fragment lists.
>
> > Then can we reuse IPoIB CM code here?
>
> Yes, if possible, refactoring things so that the rx skb allocation
> code becomes common between CM and non-CM would definitely make sense.
This is also applied to MTU=2K size as well since ppage size is greater
than 2K on different platforms is not guaranteed. This skb issue is an
independent effort with supporting MTU=4K. We need to address non-CM skb
issue in general. Let's have a simple patch to enable MTU=4K support first
in 2.6.24, then address non-CM skb issue in a different patch next, Do you
agree?
Thanks
Shirley
[-- Attachment #1.2: Type: text/html, Size: 944 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
From: Roland Dreier @ 2007-09-17 22:25 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, general, jgarzik, davem
In-Reply-To: <1189813234208-git-send-email-fubar@us.ibm.com>
Actually, thinking about this some more... would it be cleaner to more
the knowledge about bonding out of the ipoib driver? in other words,
export something similar to
> +static int ipoib_slave_detach(struct net_device *dev)
> +{
> + int ret = 0;
> + if (dev->flags & IFF_SLAVE) {
> + dev->priv_flags |= IFF_SLAVE_DETACH;
> + rtnl_lock();
> + ret = call_netdevice_notifiers(NETDEV_CHANGE, dev);
> + rtnl_unlock();
> + }
> + return ret;
> +}
for drivers to use, rather than putting use of IFF_SLAVE and
IFF_SLAVE_DETACH outside of the bonding driver.
Also it seems this function could return void, since both call sites
ignore the return value and I don't see anything sensible that IPoIB
could do with the notifier chain return value anyway.
- R.
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones @ 2007-09-17 22:48 UTC (permalink / raw)
To: John Heffner; +Cc: netdev
In-Reply-To: <46EEE74A.9090003@psc.edu>
John Heffner wrote:
> Rick Jones wrote:
>
>> John Heffner wrote:
>>
>>> Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
>>> that setting idiag_rqueue and idiag_wqueue are sufficient.
>>
>>
>> Different fields for different structures. The tcp_info struct
>> doesn't have the idiag_mumble, so to get the two values shown in
>> /proc/net/tcp I use tcpi_unacked and tcpi_sacked.
>>
>> For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
>> then covers ss.
>
>
> Maybe I'm missing something. get_tcp[46]_sock() does not use struct
> tcp_info. The only way I see using this is by doing
> getsockopt(TCP_INFO) on your listen socket. Is this the intention?
Yes. Sorry I got a triffle turned-around there.
rick
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Randy Dunlap @ 2007-09-17 22:57 UTC (permalink / raw)
To: Urs Thuermann
Cc: Thomas Gleixner, netdev, David Miller, Patrick McHardy,
Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygflkb5rp9d.fsf@janus.isnogud.escape.de>
On 17 Sep 2007 22:49:34 +0200 Urs Thuermann wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
>
> OK, here it is:
Just a few more minor changes... Thanks again.
> +3. Socket CAN concept
> +---------------------
> +
> + As described in chapter 2 it is the main goal of Socket CAN to
> + provide a socket interface to user space applications which builds
> + upon the Linux networklayer. In contrast to the commonly known
network layer.
> + TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
> + medium that has no MAC-layer addressing like ethernet. The CAN-identifier
> + (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
> + have to be chosen uniquely on the bus. When designing a CAN-ECU
> + network the CAN-IDs are mapped to be sent by a specific ECU.
> + For this reason a CAN-ID can be treated best as a kind of source address.
> +
> + 3.2 loopback
> +
> + As known from other networking concepts the data exchanging
> + applications may run on the same or different nodes without any
> + change (except for the according addressing information):
> +
> + ___ ___ ___ _______ ___
> + | _ | | _ | | _ | | _ _ | | _ |
> + ||A|| ||B|| ||C|| ||A| |B|| ||C||
> + |___| |___| |___| |_______| |___|
> + | | | | |
> + -----------------(1)- CAN bus -(2)---------------
> +
> + To ensure that application A receives the same information in the
> + example (2) as it would receive in example (1) there is need for
> + some kind of local loopback on the appropriate node.
> +
> + The Linux network devices (by default) just can handle the
> + transmission and reception of media dependent frames. Due to the
> + arbritration on the CAN bus the transmission of a low prio CAN-ID
> + may be delayed by the recepition of a high prio CAN frame. To
reception
> + reflect the correct* traffic on the node the loopback of the sent
> + data has to be performed right after a successful transmission. If
> + the CAN network interface is not capable of performing the loopback for
> + some reason the SocketCAN core can do this task as a fallback solution.
> + See chapter 6.2 for details (recommended).
> +
> + The loopback functionality is enabled by default to reflect standard
> + networking behaviour for CAN applications. Due to some requests from
> + the RT-SocketCAN group the loopback optionally may be disabled for each
> + separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
> +
> + * = you really like to have this when you're running analyser tools
> + like 'candump' or 'cansniffer' on the (same) node.
> +
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] bonding: update some distro-specific documentation
From: Andy Gospodarek @ 2007-09-17 23:00 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <21001.1189189669@death>
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=no
> >+BONDING_OPTS="mode=balance-alb miimon=100"
> >
> > Be sure to change the networking specific lines (IPADDR,
> > NETMASK, NETWORK and BROADCAST) to match your network configuration.
> >+You also need to set the BONDING_OPTS= line to specify the desired
> >+options for your bond0 interface. Specifying bonding options in this
> >+way is the preferred method for configuring bonding interfaces.
>
> Can you add something here that mentions that, for the
> arp_ip_target option, it has to be supplied as "arp_ip_target=+10.0.0.1"
> and not just "arp_ip_target=10.0.0.1"? Also, multiple targets require
> multiple instances of the arp_ip_target option; it doesn't work to put
> multiple IP addresses as in the module option (i.e.,
> "arp_ip_target=10.0.0.1,10.0.0.2").
>
> This is necessary because ifup-eth isn't adding the "+" when it
> translates the option for use with sysfs or parsing the multiple IP
> address syntax.
>
Third time's the charm, right?
(an arp_interval parameter would be nice)
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
bonding.txt | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1da5666..2402412 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file.
------------------------------------------
This section applies to distros using a version of initscripts
-with bonding support, for example, Red Hat Linux 9 or Red Hat
-Enterprise Linux version 3 or 4. On these systems, the network
-initialization scripts have some knowledge of bonding, and can be
+with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise
+Linux version 3, 4 or 5, Fedora, etc. On these systems, the network
+initialization scripts have some knowledge of bonding, and can be
configured to control bonding devices.
These distros will not automatically load the network adapter
@@ -802,18 +802,27 @@ BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
+BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254"
Be sure to change the networking specific lines (IPADDR,
NETMASK, NETWORK and BROADCAST) to match your network configuration.
-
- Finally, it is necessary to edit /etc/modules.conf (or
+You also need to set the BONDING_OPTS= line to specify the desired
+options for your bond0 interface. Specifying bonding options in this
+way is the preferred method for configuring bonding interfaces. The
+options specified in BONDING_OPTS are identical to the bonding module
+parameters except for the arp_ip_target field. Each target should be
+included as a separate address and should be preceded by a '+' to
+indicate it should be added to the list of queried targets.
+
+ It is no longer necessary to edit /etc/modules.conf (or
/etc/modprobe.conf, depending upon your distro) to load the bonding
module with your desired options when the bond0 interface is brought
up. The following lines in /etc/modules.conf (or modprobe.conf) will
-load the bonding module, and select its options:
+load the bonding module, and select its options but this is no longer
+the preferred method.
alias bond0 bonding
-options bond0 mode=balance-alb miimon=100
+options bond0 mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254
Replace the sample parameters with the appropriate set of
options for your configuration.
@@ -826,8 +835,9 @@ up and running.
---------------------------------
Recent versions of initscripts (the version supplied with
-Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do
-have support for assigning IP information to bonding devices via DHCP.
+Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to
+work) do have support for assigning IP information to bonding devices
+via DHCP.
To configure bonding for DHCP, configure it as described
above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
@@ -837,18 +847,19 @@ is case sensitive.
3.2.2 Configuring Multiple Bonds with Initscripts
-------------------------------------------------
- At this writing, the initscripts package does not directly
-support loading the bonding driver multiple times, so the process for
-doing so is the same as described in the "Configuring Multiple Bonds
-Manually" section, below.
-
- NOTE: It has been observed that some Red Hat supplied kernels
-are apparently unable to rename modules at load time (the "-o bond1"
-part). Attempts to pass that option to modprobe will produce an
-"Operation not permitted" error. This has been reported on some
-Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
-exhibiting this problem, it will be impossible to configure multiple
-bonds with differing parameters.
+ Initscripts packages that are included with Fedora 7 and Red
+Hat Enterprise Linux 5 support multiple bonding interfaces by simply
+specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is
+the number of the bond. Other distros may not include support in
+initscripts for multiple bonding interfaces, so you may need to follow
+the process as described in the "Configuring Multiple Bonds Manually"
+section, below.
+
+ It has been observed that much older kernels are apparently
+unable to rename modules at load time (the "-o bond1" part). Attempts
+to pass that option to modprobe will produce an "Operation not
+permitted" error. On kernels exhibiting this problem, it will be
+impossible to configure multiple bonds with differing parameters.
3.3 Configuring Bonding Manually with Ifenslave
-----------------------------------------------
^ permalink raw reply related
* Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!
From: David Miller @ 2007-09-17 23:13 UTC (permalink / raw)
To: akpm; +Cc: kamalesh, linux-kernel, netdev
In-Reply-To: <20070917141622.330b27b8.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 17 Sep 2007 14:16:22 -0700
> On Mon, 17 Sep 2007 17:46:38 +0530
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> > Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
> >
> > kernel BUG at include/linux/netdevice.h:339!
>
> (please cc netdev@vger.kernel.org on networking-related matters)
>
> You died here:
>
> static inline void napi_complete(struct napi_struct *n)
> {
> BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
>
> The NAPI changes have had a few problems and hopefully things have
> been fixed up since then. I'll try to get rc6-mm1 out this evening,
> so please retest that?
And if you trigger this still it is absolutely critical that
you tell us what networking device driver you are using at
the time.
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Urs Thuermann @ 2007-09-17 23:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: Thomas Gleixner, netdev, David Miller, Patrick McHardy,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <20070917155718.ee2cc803.randy.dunlap@oracle.com>
Hi Randy,
> Just a few more minor changes... Thanks again.
Again, thank you. I have applied these two typo fixes, too.
urs
^ permalink raw reply
* [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
From: Jay Vosburgh @ 2007-09-17 23:23 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, general, jgarzik, davem
In-Reply-To: <adatzptkjyk.fsf@cisco.com>
Roland Dreier <rdreier@cisco.com> wrote:
>Actually, thinking about this some more... would it be cleaner to more
>the knowledge about bonding out of the ipoib driver? in other words,
>export something similar to
>
> > +static int ipoib_slave_detach(struct net_device *dev)
> > +{
> > + int ret = 0;
> > + if (dev->flags & IFF_SLAVE) {
> > + dev->priv_flags |= IFF_SLAVE_DETACH;
> > + rtnl_lock();
> > + ret = call_netdevice_notifiers(NETDEV_CHANGE, dev);
> > + rtnl_unlock();
> > + }
> > + return ret;
> > +}
>
>for drivers to use, rather than putting use of IFF_SLAVE and
>IFF_SLAVE_DETACH outside of the bonding driver.
Conceptually, I see your point and I'm ok with doing it either
way. My only question is, would this change would make the ipoib module
dependent upon having the bonding module loaded (to resolve all of the
symbols)?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
From: Roland Dreier @ 2007-09-17 23:33 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, monis, monisonlists, ogerlitz, jgarzik, davem, general
In-Reply-To: <18593.1190071438@death>
> Conceptually, I see your point and I'm ok with doing it either
> way. My only question is, would this change would make the ipoib module
> dependent upon having the bonding module loaded (to resolve all of the
> symbols)?
Yes, I guess so, if that function is in bonding. Hmm, that wouldn't
be a good change.
Maybe this new notification function should be in net/core/dev.c
instead of exporting call_netdevice_notifiers()?
- R.
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-17 23:39 UTC (permalink / raw)
To: akpm; +Cc: netdev, linville, jgarzik
In-Reply-To: <20070917144037.100b3fc1.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 17 Sep 2007 14:40:37 -0700
> These two:
>
> git://porch.greyhouse.net/gospo/tehuti-2.6.git
> ipg-add-ip1000a-driver-to-kernel-tree.patch
>
> plus boatloads of stuff in wireless.
Andrew, can you send these two to me under seperate cover? I'll
integrate them once I have them in my inbox.
Why don't we sit a bit on the wireless tree, and John please start to
merge that stuff to net-2.6.24 and toss the patches my way?
Thanks!
^ permalink raw reply
* Re: net-2.6.24 plans
From: John W. Linville @ 2007-09-17 23:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev, jgarzik
In-Reply-To: <20070917144037.100b3fc1.akpm@linux-foundation.org>
On Mon, Sep 17, 2007 at 02:40:37PM -0700, Andrew Morton wrote:
> On Mon, 17 Sep 2007 14:18:26 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> > I guess a lot of this could be avoided if I simply merge in whatever
> > external stuff you're sucking in.
> plus boatloads of stuff in wireless.
>
> > I imagine this is just one of
> > Linville's trees (I'm surprised that hasn't been sent to me frankly)
> > and some specific new drivers you're merging in.
The stuff in wireless-dev is a collection of drivers (some of which
probably should be merged now) and some mac80211 gorp that is not
yet merge-worthy. Trust me, I'm trying to get as many items out of
it as possible.
> Yeah, git-net versus git-wireless isn't pretty. The huge amount of pending
> wireless stuff has been a bit of a nuisance for some months. But it's
> probably a bigger nuisance for John ;)
Yeah...<sigh>...yeah...<sigh>...yeah... :-(
But as hch would surely point-out, it is my own laziness at fault...and
driver authors who tremble in fear when I mention merging their
drivers upstream...but, I digress... :-)
I just (minutes ago) finished the mop-up of the patch mess which
had accumulated on me during my KS-related travel and the subsequent
period of catching-up. (I'm sure I still missed something or botched
something). I think I can get an -mm suitable patch together within
the next few hours.
John
P.S. Andrew, I'll send you a link to a new git-wireless.patch --
I'm sure you don't want a complicated git invocation... Until then,
I don't think you should try pulling wireless-dev...
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-17 23:42 UTC (permalink / raw)
To: linville; +Cc: akpm, netdev, jgarzik
In-Reply-To: <20070917231830.GG9282@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 17 Sep 2007 19:18:30 -0400
> I just (minutes ago) finished the mop-up of the patch mess which
> had accumulated on me during my KS-related travel and the subsequent
> period of catching-up. (I'm sure I still missed something or botched
> something). I think I can get an -mm suitable patch together within
> the next few hours.
I'm happy you're taking care of this, but it would be nice if
you could sent this to me as patches for net-2.6.24 inclusion
as well :-)
^ permalink raw reply
* Re: net-2.6.24 plans
From: Andrew Morton @ 2007-09-17 23:49 UTC (permalink / raw)
To: John W. Linville; +Cc: David Miller, netdev, jgarzik
In-Reply-To: <20070917231830.GG9282@tuxdriver.com>
On Mon, 17 Sep 2007 19:18:30 -0400
"John W. Linville" <linville@tuxdriver.com> wrote:
> P.S. Andrew, I'll send you a link to a new git-wireless.patch --
> I'm sure you don't want a complicated git invocation... Until then,
> I don't think you should try pulling wireless-dev...
OK, thanks.
The stuff I have now does actually compile, although the chances of it
actually working are epsilon.
So I'd rather not breathe on it today: I'l shove it out the door as-is
with a big "this is probably broken" label on it. I'll at least test
ipw2200 before doing so.
^ permalink raw reply
* Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
From: Satyam Sharma @ 2007-09-17 23:56 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Dhaval Giani, Andrew James Wade, thunder7, Jeff Garzik,
Andrew Morton, Linux Kernel Mailing List,
Linux Netdev Mailing List, Manfred Spraul
In-Reply-To: <46EE8A13.1070102@sw.ru>
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
> Dhaval Giani wrote:
> > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> >> EIP: [<c037d81b>] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated, but multiple people have reported that
same oops now -- adding Manfred Spraul to CC. [ original thread is at:
http://lkml.org/lkml/2007/9/1/115 ]
^ permalink raw reply
* Re: net-2.6.24 plans
From: Andrew Morton @ 2007-09-17 23:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linville, jgarzik, Andy Gospodarek, Francois Romieu
In-Reply-To: <20070917.163929.107941522.davem@davemloft.net>
On Mon, 17 Sep 2007 16:39:29 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Mon, 17 Sep 2007 14:40:37 -0700
>
> > These two:
> >
> > git://porch.greyhouse.net/gospo/tehuti-2.6.git
> > ipg-add-ip1000a-driver-to-kernel-tree.patch
> >
> > plus boatloads of stuff in wireless.
>
> Andrew, can you send these two to me under seperate cover? I'll
> integrate them once I have them in my inbox.
The Tehuti driver you should probably pull from the above git tree.
Andy sent me a fix-it-for-net-2.6.24 patch which I'll send. It applies
on top of the git tree.
ipg-add-ip1000a-driver-to-kernel-tree.patch got broken by git-2.6.24 and I
just disabled it in Kconfig. I'll send it anyway but someone will need to
repair it. For some reason this driver doesn't have a changelog.
^ permalink raw reply
* RE: net-2.6.24 plans
From: Nelson, Shannon @ 2007-09-17 23:57 UTC (permalink / raw)
To: David Miller, netdev; +Cc: akpm, linville, jgarzik
In-Reply-To: <20070917.141826.70218261.davem@davemloft.net>
>From: netdev-owner@vger.kernel.org
>[mailto:netdev-owner@vger.kernel.org] On Behalf Of David Miller
>Sent: Monday, September 17, 2007 2:18 PM
>To: netdev@vger.kernel.org
>Cc: akpm@linux-foundation.org; linville@tuxdriver.com;
>jgarzik@pobox.com
>Subject: Re: net-2.6.24 plans
[...]
>
>Andrew, I removed the troublesome IOAT patch. The only conflicts
>and fixes you should need at this point are:
>
[...]
Which IOAT patch are you referring to?
sln
--
======================================================================
Mr. Shannon Nelson LAN Access Division, Intel Corp.
Shannon.Nelson@intel.com I don't speak for Intel
(503) 712-7659 Parents can't afford to be squeamish.
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-18 0:04 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, akpm, linville, jgarzik
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C030EF13C@orsmsx418.amr.corp.intel.com>
From: "Nelson, Shannon" <shannon.nelson@intel.com>
Date: Mon, 17 Sep 2007 16:57:03 -0700
> >From: netdev-owner@vger.kernel.org
> >[mailto:netdev-owner@vger.kernel.org] On Behalf Of David Miller
> >Sent: Monday, September 17, 2007 2:18 PM
> >To: netdev@vger.kernel.org
> >Cc: akpm@linux-foundation.org; linville@tuxdriver.com;
> >jgarzik@pobox.com
> >Subject: Re: net-2.6.24 plans
> [...]
> >
> >Andrew, I removed the troublesome IOAT patch. The only conflicts
> >and fixes you should need at this point are:
> >
> [...]
>
> Which IOAT patch are you referring to?
The 'uninitialized variable' one, you should have a copy.
If not, Andrew definitely does.
^ 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