* Re: [PATCH 3/8] ethoc: enable interrupts after napi_complete
From: Laurent Chavey @ 2010-11-24 19:33 UTC (permalink / raw)
To: Jonas Bonn; +Cc: netdev, Adam Edvardsson
In-Reply-To: <AANLkTim=Y6NGk8MSq=hJTrBKaYuk4SJ_7wA=f+UBy3d0@mail.gmail.com>
actually my previous comments are not correct.
the check for work_done < budget will
only cause an extra call with work_done == 0
if no more work is done.
so that will work.
--
--------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/8] ethoc: Add device tree configuration
From: David Miller @ 2010-11-24 19:35 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1290606058-26703-2-git-send-email-jonas@southpole.se>
From: Jonas Bonn <jonas@southpole.se>
Date: Wed, 24 Nov 2010 14:40:51 +0100
> This patch adds the ability to describe ethernet devices via a flattened
> device tree. As device tree remains an optional feature, these bits all
> need to be guarded by CONFIG_OF ifdefs.
>
> MAC address is settable via the device tree parameter "local-mac-address";
> however, the selection of the phy id is limited to probing, for now.
>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
...
> + }
Trailing whitespace.
^ permalink raw reply
* [PATCH] hso: fix disable_net
From: Filip Aben @ 2010-11-24 19:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
jhovold-Re5JQEeQqe8AvxtiuMwx3w, pki-/L4m51SJ8HhmR6Xm/wNWPw,
j.dumon-x9gZzRpC1QbQT0dZR+AlfA
The HSO driver incorrectly creates a serial device instead of a net
device when disable_net is set. It shouldn't create anything for the
network interface.
Signed-off-by: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
---
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b154a94..b05c235 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2994,10 +2994,10 @@ static int hso_probe(struct usb_interface *interface,
case HSO_INTF_BULK:
/* It's a regular bulk interface */
- if (((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK) &&
- !disable_net)
+ if ((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK) {
+ if(!disable_net)
hso_dev = hso_create_net_device(interface, port_spec);
- else
+ } else
hso_dev =
hso_create_bulk_serial_device(interface, port_spec);
if (!hso_dev)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 4/8] ethoc: prevent overflow of rx counter
From: David Miller @ 2010-11-24 19:36 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1290606058-26703-5-git-send-email-jonas@southpole.se>
From: Jonas Bonn <jonas@southpole.se>
Date: Wed, 24 Nov 2010 14:40:54 +0100
> Rewind cur_rx to prevent it from overflowing.
>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
...
> + /* Prevent overflow of priv->cur_rx by rewinding it */
Trailing whitespace, also please integrate the feedback from Ben
and Eric Dumazet about making this computation less expensive.
^ permalink raw reply
* Re: [PATCH 5/8] ethoc: Double check pending RX packet
From: David Miller @ 2010-11-24 19:37 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1290606058-26703-6-git-send-email-jonas@southpole.se>
From: Jonas Bonn <jonas@southpole.se>
Date: Wed, 24 Nov 2010 14:40:55 +0100
> An interrupt may occur between checking bd.stat and clearing the
> interrupt source register which would result in the packet going totally
> unnoticed as the interrupt will be missed. Double check bd.stat after
> clearing the interrupt source register to guard against such an
> occurrence.
>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
...
> + if (bd.stat & RX_BD_EMPTY)
Trailing whitespace.
> + break;
> +
> + }
Unnecessary empty line.
^ permalink raw reply
* Re: [PATCH 6/8] ethoc: rework interrupt handling
From: David Miller @ 2010-11-24 19:38 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1290606058-26703-7-git-send-email-jonas@southpole.se>
From: Jonas Bonn <jonas@southpole.se>
Date: Wed, 24 Nov 2010 14:40:56 +0100
> The old interrupt handling was incorrect in that it did not account for the
> fact that the interrupt source bits get set irregardless of whether or not
> their corresponding mask is set. This patch fixes that by masking off the
> source bits for masked interrupts.
>
> Furthermore, the handling of transmission events is moved to the NAPI polling
> handler alongside the reception handler, thus preventing a whole bunch of
> interrupts during heavy traffic.
>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
> + * and clearing the interrupt source, then we risk
...
> + * right away when we reenable it; hence, check
Trailing whitespace.
> - if ((priv->cur_tx - priv->dty_tx) <= (priv->num_tx / 2))
> + if ((priv->cur_tx - priv->dty_tx) <= (priv->num_tx / 2)) {
> netif_wake_queue(dev);
> + }
>
One-line statement does not require braces.
^ permalink raw reply
* Re: [PATCH 1/2 v7] xps: Improvements in TX queue selection
From: David Miller @ 2010-11-24 19:45 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <alpine.DEB.2.00.1011211501180.14901@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 21 Nov 2010 15:17:29 -0800 (PST)
> In dev_pick_tx, don't do work in calculating queue
> index or setting
> the index in the sock unless the device has more than one queue. This
> allows the sock to be set only with a queue index of a multi-queue
> device which is desirable if device are stacked like in a tunnel.
>
> We also allow the mapping of a socket to queue to be changed. To
> maintain in order packet transmission a flag (ooo_okay) has been
> added to the sk_buff structure. If a transport layer sets this flag
> on a packet, the transmit queue can be changed for the socket.
> Presumably, the transport would set this if there was no possbility
> of creating OOO packets (for instance, there are no packets in flight
> for the socket). This patch includes the modification in TCP output
> for setting this flag.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2 v7] xps: Transmit Packet Steering
From: David Miller @ 2010-11-24 19:45 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <alpine.DEB.2.00.1011211501430.14906@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 21 Nov 2010 15:17:27 -0800 (PST)
> This patch implements transmit packet steering (XPS) for multiqueue
> devices. XPS selects a transmit queue during packet transmission based
> on configuration. This is done by mapping the CPU transmitting the
> packet to a queue. This is the transmit side analogue to RPS-- where
> RPS is selecting a CPU based on receive queue, XPS selects a queue
> based on the CPU (previously there was an XPS patch from Eric
> Dumazet, but that might more appropriately be called transmit completion
> steering).
>
> Each transmit queue can be associated with a number of CPUs which will
> use the queue to send packets. This is configured as a CPU mask on a
> per queue basis in:
>
> /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus
>
> The mappings are stored per device in an inverted data structure that
> maps CPUs to queues. In the netdevice structure this is an array of
> num_possible_cpu structures where each structure holds and array of
> queue_indexes for queues which that CPU can use.
>
> The benefits of XPS are improved locality in the per queue data
> structures. Also, transmit completions are more likely to be done
> nearer to the sending thread, so this should promote locality back
> to the socket on free (e.g. UDP). The benefits of XPS are dependent on
> cache hierarchy, application load, and other factors. XPS would
> nominally be configured so that a queue would only be shared by CPUs
> which are sharing a cache, the degenerative configuration woud be that
> each CPU has it's own queue.
>
> Below are some benchmark results which show the potential benfit of
> this patch. The netperf test has 500 instances of netperf TCP_RR test
> with 1 byte req. and resp.
>
> bnx2x on 16 core AMD
> XPS (16 queues, 1 TX queue per CPU) 1234K at 100% CPU
> No XPS (16 queues) 996K at 100% CPU
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, please consider Eric's feedback about map NUMA node placement.
^ permalink raw reply
* Re: possible kernel oops from user MSS
From: David Miller @ 2010-11-24 19:47 UTC (permalink / raw)
To: mzhang; +Cc: netdev
In-Reply-To: <4CDDC6EE.2010005@mvista.com>
From: Min Zhang <mzhang@mvista.com>
Date: Fri, 12 Nov 2010 14:59:58 -0800
> Regarding commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ("tcp:
> Increase TCP_MAXSEG socket option minimum"). What is the reason
> TCP_MAXSEG minimum be 64? Isn't the exact be 40 which is
> TCPOLEN_MD5SIG_ALIGNED(20) + TCPOLEN_TSTAMP_ALIGNED(12) + 8?
>
> Or is it better to use TCP_MIN_MSS from tcp.h:
>
> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
> #define TCP_MIN_MSS 88U
Committed to net-2.6:
--------------------
>From c39508d6f118308355468314ff414644115a07f3 Mon Sep 17 00:00:00 2001
From: David S. Miller <davem@davemloft.net>
Date: Wed, 24 Nov 2010 11:47:22 -0800
Subject: [PATCH] tcp: Make TCP_MAXSEG minimum more correct.
Use TCP_MIN_MSS instead of constant 64.
Reported-by: Min Zhang <mzhang@mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/tcp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0814199..f15c36a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2246,7 +2246,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
/* Values greater than interface MTU won't take effect. However
* at the point when this call is done we typically don't yet
* know which interface is going to be used */
- if (val < 64 || val > MAX_TCP_WINDOW) {
+ if (val < TCP_MIN_MSS || val > MAX_TCP_WINDOW) {
err = -EINVAL;
break;
}
--
1.7.3.2
^ permalink raw reply related
* Unplug ethernet cable, the route persists. Why?
From: Mike Caoco @ 2010-11-24 19:48 UTC (permalink / raw)
To: Netdev, LKML; +Cc: caoco2002
Hello,
This may have been discussed, but all search engines couldn't give me a good answer...
I notice that when an interface is up/running, a local route is in the routing table:
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:13:20:0e:2f:ed
inet addr:192.168.1.125 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35984995 errors:0 dropped:0 overruns:0 frame:0
TX packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3252413825 (3.2 GB) TX bytes:1340077250 (1.3 GB)
$ ip route
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.120
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.125
default via 192.168.20.254 dev eth1 metric 100
After I unplug the cable from eth1, the RUNNING flag disappears, but the route is still there:
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:13:20:0e:2f:ed
inet addr:192.168.1.125 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:35985023 errors:0 dropped:0 overruns:0 frame:0
TX packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3252415633 (3.2 GB) TX bytes:1340077250 (1.3 GB)
$ ip route
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.120
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.125
default via 192.168.20.254 dev eth1 metric 100
And that *prevents* from using the default route to reach 192.168.1/24 subnet after eth1 is out.
I looked at the code, it seems the IFF_RUNNING flag change is ignored in dev_change_flags():
void __dev_notify_flags(struct net_device *dev, unsigned int old_flags)
{
.....
if (dev->flags & IFF_UP &&
(changes & ~(IFF_UP | IFF_PROMISC | IFF_ALLMULTI | IFF_VOLATILE)))
call_netdevice_notifiers(NETDEV_CHANGE, dev);
}
I searched in the Internet, and saw some people suggest using an application listener (eg, netplug) to remove the route.
My question is why cannot the kernel remove the route automatically when the link becomes down? Why should this complexity be pushed to the user to find a program to do that?
Thanks,
Joe
^ permalink raw reply
* Re: Generalizing mmap'ed sockets
From: Michael S. Tsirkin @ 2010-11-24 19:57 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, rick.jones2, netdev
In-Reply-To: <AANLkTik7HU0wyub3krZb_aABsHp-_LvNLtAr5CaAo4_A@mail.gmail.com>
On Fri, Nov 19, 2010 at 02:49:46PM -0800, Tom Herbert wrote:
> > I think the ACK (or for UDP, the kfree_skb() after TX completes) should
> > move the consumer pointer. Otherwise you have to copy, and the ACKs
> > do not clock the sender process properly.
> >
> Right, with the caveats that even ACK'ed data might still go out on
> the with that was discussed in the vmsplice() related patches. I
> don't think this should make the problem any worse.
Or any better. Sigh. Any idea how to actually track pages
in question so we can either really know when the stack is no longer
referencing them, or force a copy if they hang around after ack?
--
MST
^ permalink raw reply
* Re: Unplug ethernet cable, the route persists. Why?
From: Stephen Hemminger @ 2010-11-24 20:18 UTC (permalink / raw)
To: Mike Caoco; +Cc: Netdev, LKML
In-Reply-To: <242082.99180.qm@web63407.mail.re1.yahoo.com>
On Wed, 24 Nov 2010 11:48:03 -0800 (PST)
Mike Caoco <caoco2002@yahoo.com> wrote:
> Hello,
>
> This may have been discussed, but all search engines couldn't give me a good answer...
>
> I notice that when an interface is up/running, a local route is in the routing table:
>
> $ ifconfig eth1
> eth1 Link encap:Ethernet HWaddr 00:13:20:0e:2f:ed
> inet addr:192.168.1.125 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:35984995 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3252413825 (3.2 GB) TX bytes:1340077250 (1.3 GB)
>
> $ ip route
> 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.120
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.125
> default via 192.168.20.254 dev eth1 metric 100
>
> After I unplug the cable from eth1, the RUNNING flag disappears, but the route is still there:
>
> $ ifconfig eth1
> eth1 Link encap:Ethernet HWaddr 00:13:20:0e:2f:ed
> inet addr:192.168.1.125 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:35985023 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3252415633 (3.2 GB) TX bytes:1340077250 (1.3 GB)
>
> $ ip route
> 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.120
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.125
> default via 192.168.20.254 dev eth1 metric 100
>
> And that *prevents* from using the default route to reach 192.168.1/24 subnet after eth1 is out.
>
> I looked at the code, it seems the IFF_RUNNING flag change is ignored in dev_change_flags():
>
> void __dev_notify_flags(struct net_device *dev, unsigned int old_flags)
> {
> .....
> if (dev->flags & IFF_UP &&
> (changes & ~(IFF_UP | IFF_PROMISC | IFF_ALLMULTI | IFF_VOLATILE)))
> call_netdevice_notifiers(NETDEV_CHANGE, dev);
> }
>
> I searched in the Internet, and saw some people suggest using an application listener (eg, netplug) to remove the route.
>
> My question is why cannot the kernel remove the route automatically when the link becomes down? Why should this complexity be pushed to the user to find a program to do that?
>
Because there is no reason for the kernel to not expect the link to come back.
It is up to user space to do routing policy. For desktop/laptop users this is
done typically with NetworkManager or Connman; for routers this is done with
Quagga; and for servers use other tools.
If the kernel automatically removed the route, it would cause routing daemons
to recompute the route table (and propagate the change) every time a cable
got pulled or NIC needed to be reset.
--
^ permalink raw reply
* Re: bonding: propagation of offload settings
From: David Miller @ 2010-11-24 20:27 UTC (permalink / raw)
To: horms; +Cc: netdev, fubar
In-Reply-To: <20101030025435.GF12842@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Sat, 30 Oct 2010 11:54:35 +0900
> It seems to me that from a user point of view it may make more sense to:
>
> a) propagate settings from the master to the slaves and;
> b) possibly disallow setting the slaves directly
Yeah, good question.
Propagation from master to slave(s) would have difficult semantics.
If any of the slave changes fail (f.e. unsupported feature or memory
allocation failure) we'd have to unwind all of the slaves which did
accept the change without error.
What if the unwind operation fails, due to lack of resources? A lot
of state would thus need to be tracked to support this reasonably.
However we pretty much have to respect whatever changes get made
directly to the slaves, since the master must at all times claim
support for only the lowest common denominator, feature wise, amongst
that master's slaves.
^ permalink raw reply
* Re: tg3 driver not advertising 1000mbit
From: Krzysztof Olędzki @ 2010-11-24 20:09 UTC (permalink / raw)
To: Matt Carlson
Cc: Jean-Louis Dupond, Michael Chan, netdev@vger.kernel.org,
David Christensen
In-Reply-To: <20090702164212.GA8430@xw6200.broadcom.net>
On 2009-07-02 18:42, Matt Carlson wrote:
> On Tue, Jun 30, 2009 at 02:20:45AM -0700, Jean-Louis Dupond wrote:
>> # ethtool -i eth0
>> driver: tg3
>> version: 3.97
>> firmware-version: 5722-v3.08, ASFIPMI v6.02
>> bus-info: 0000:01:00.0
>>
>> Kernel version 2.6.29.4
>
> Rats. I mirrored your setup here, but I still can't reproduce the
> problem. I still suspect this is a bad driver<=> firmware interaction.
>
> Can you apply the following patch and show me the resulting syslog
> entries? The patch is just making sure the firmware request to shutdown
> really goes through.
>
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 46a3f86..900e28b 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -1124,6 +1124,9 @@ static void tg3_wait_for_event_ack(struct tg3 *tp)
> break;
> udelay(8);
> }
> +
> + if (i == delay_cnt)
> + printk( KERN_WARNING "Firmware didn't ack driver event!\n" );
> }
>
> /* tp->lock is held. */
> @@ -6330,12 +6333,16 @@ static void tg3_stop_fw(struct tg3 *tp)
> /* Wait for RX cpu to ACK the previous event. */
> tg3_wait_for_event_ack(tp);
>
> + printk( KERN_NOTICE "%s: Stopping firmware.\n", tp->dev->name );
> +
> tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX, FWCMD_NICDRV_PAUSE_FW);
>
> tg3_generate_fw_event(tp);
>
> /* Wait for RX cpu to ACK this event. */
> tg3_wait_for_event_ack(tp);
> +
> + printk( KERN_NOTICE "%s: Operation completed.\n", tp->dev->name );
> }
> }
>
> @@ -7537,6 +7544,8 @@ static void tg3_timer(unsigned long __opaque)
> !(tp->tg3_flags3& TG3_FLG3_ENABLE_APE)) {
> tg3_wait_for_event_ack(tp);
>
> + printk( KERN_NOTICE "%s: Sending keepalive event.\n", tp->dev->name );
> +
> tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX,
> FWCMD_NICDRV_ALIVE3);
> tg3_write_mem(tp, NIC_SRAM_FW_CMD_LEN_MBOX, 4);
Hello,
Have you been able to solve this issue? I have a similar problem with
Dell PowerEdge R300 servers connected to HP2610 100Mbps switches. The
servers contain two BCM5722 NICs and after a reboot, with probability
about 70%, I end up with 10Mbps HD mainly on the first NIC.
I discovered that it is enough to run:
/sbin/mii-tool -R eth0
/sbin/mii-tool -R eth1
to trigger renegotiation that brings expected 100Mbps FD. For now, I
added this to my startups scripts as a workaround.
This problem exists in 2.6.30-stable, 2.6.31-stable and 2.6.34-stable
which I'm currently running.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: Unplug ethernet cable, the route persists. Why?
From: Mike Caoco @ 2010-11-24 20:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev, LKML
In-Reply-To: <20101124121826.39dd6ed1@nehalam>
--- On Wed, 11/24/10, Stephen Hemminger <shemminger@vyatta.com> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Subject: Re: Unplug ethernet cable, the route persists. Why?
> To: "Mike Caoco" <caoco2002@yahoo.com>
> Cc: "Netdev" <netdev@vger.kernel.org>, "LKML" <linux-kernel@vger.kernel.org>
> Date: Wednesday, November 24, 2010, 12:18 PM
> On Wed, 24 Nov 2010 11:48:03 -0800
> (PST)
> Mike Caoco <caoco2002@yahoo.com>
> wrote:
>
> > Hello,
> >
> > This may have been discussed, but all search engines
> couldn't give me a good answer...
> >
> > I notice that when an interface is up/running, a local
> route is in the routing table:
> >
> > $ ifconfig eth1
> > eth1 Link encap:Ethernet
> HWaddr 00:13:20:0e:2f:ed
> > inet
> addr:192.168.1.125 Bcast:192.168.1.255
> Mask:255.255.255.0
> > inet6
> addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
> > UP
> BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX
> packets:35984995 errors:0 dropped:0 overruns:0 frame:0
> > TX
> packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
> >
> collisions:0 txqueuelen:1000
> > RX
> bytes:3252413825 (3.2 GB) TX bytes:1340077250 (1.3
> GB)
> >
> > $ ip route
> > 192.168.20.0/24 dev eth0 proto kernel
> scope link src 192.168.20.120
> > 192.168.1.0/24 dev eth1 proto kernel scope
> link src 192.168.1.125
> > default via 192.168.20.254 dev eth1 metric 100
> >
> > After I unplug the cable from eth1, the RUNNING flag
> disappears, but the route is still there:
> >
> > $ ifconfig eth1
> > eth1 Link encap:Ethernet
> HWaddr 00:13:20:0e:2f:ed
> > inet
> addr:192.168.1.125 Bcast:192.168.1.255
> Mask:255.255.255.0
> > inet6
> addr: fe80::213:20ff:fe0e:2fed/64 Scope:Link
> > UP
> BROADCAST MULTICAST MTU:1500 Metric:1
> > RX
> packets:35985023 errors:0 dropped:0 overruns:0 frame:0
> > TX
> packets:7409151 errors:0 dropped:0 overruns:0 carrier:0
> >
> collisions:0 txqueuelen:1000
> > RX
> bytes:3252415633 (3.2 GB) TX bytes:1340077250 (1.3
> GB)
> >
> > $ ip route
> > 192.168.20.0/24 dev eth0 proto kernel
> scope link src 192.168.20.120
> > 192.168.1.0/24 dev eth1 proto kernel scope
> link src 192.168.1.125
> > default via 192.168.20.254 dev eth1 metric 100
> >
> > And that *prevents* from using the default route to
> reach 192.168.1/24 subnet after eth1 is out.
> >
> > I looked at the code, it seems the IFF_RUNNING flag
> change is ignored in dev_change_flags():
> >
> > void __dev_notify_flags(struct net_device *dev,
> unsigned int old_flags)
> > {
> > .....
> > if
> (dev->flags & IFF_UP &&
> >
> (changes & ~(IFF_UP | IFF_PROMISC |
> IFF_ALLMULTI | IFF_VOLATILE)))
> >
> call_netdevice_notifiers(NETDEV_CHANGE,
> dev);
> > }
> >
> > I searched in the Internet, and saw some people
> suggest using an application listener (eg, netplug) to
> remove the route.
> >
> > My question is why cannot the kernel remove the route
> automatically when the link becomes down? Why should
> this complexity be pushed to the user to find a program to
> do that?
> >
>
> Because there is no reason for the kernel to not expect the
> link to come back.
> It is up to user space to do routing policy. For
> desktop/laptop users this is
> done typically with NetworkManager or Connman; for routers
> this is done with
> Quagga; and for servers use other tools.
>
> If the kernel automatically removed the route, it would
> cause routing daemons
> to recompute the route table (and propagate the change)
> every time a cable
> got pulled or NIC needed to be reset.
>
So if you rely on NetworkManager or Connman or Quagga to remove the route, the routing daemons will recompute the route table anyway. So why cannot this be done in the kernel?
Even when no NetworkManager/Quagga is present, I think it is a legitimate reason to recompute the route when a cable is unplugged, which should not be a frequent event unless when under error conditions.
Thanks,
^ permalink raw reply
* Re: Unplug ethernet cable, the route persists. Why?
From: David Miller @ 2010-11-24 20:44 UTC (permalink / raw)
To: caoco2002; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <144174.46619.qm@web63401.mail.re1.yahoo.com>
From: Mike Caoco <caoco2002@yahoo.com>
Date: Wed, 24 Nov 2010 12:29:43 -0800 (PST)
> Even when no NetworkManager/Quagga is present, I think it is a
> legitimate reason to recompute the route when a cable is unplugged,
> which should not be a frequent event unless when under error
> conditions.
Cards periodically reset themselves, faulty switchs flap occaisionally,
this is life and it shouldn't cause route table recomputations across
your entire region.
Also Stephen listed places where such policy should be employed in
userspace, he absolutely did not say they should act that way by
default.
^ permalink raw reply
* RE: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
From: Loke, Chetan @ 2010-11-24 20:57 UTC (permalink / raw)
To: Rick Jones, Ben Hutchings
Cc: Matt Domsch, Greg KH, K, Narendra, linux-hotplug, netdev,
Hargrave, Jordan, Rose, Charles
In-Reply-To: <4CE18ACC.3020508@hp.com>
>
> > - "mbe" = MotherBoard Ethernet. Looks a bit like "GbE" as some OEMs
put
> > on the port labels.
>
> Collides with Multi-Bit Error.
>
> > - "eom" = Ethernet On Motherboard
>
> Collides with End of Message.
>
On board ethernet(obe)?
On board nic(obn)?
^ permalink raw reply
* RE: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
From: Loke, Chetan @ 2010-11-24 21:13 UTC (permalink / raw)
To: Rick Jones, Ben Hutchings
Cc: Matt Domsch, Greg KH, K, Narendra, linux-hotplug, netdev,
Hargrave, Jordan, Rose, Charles
In-Reply-To: <4CE18ACC.3020508@hp.com>
>
> Are folks sufficently confident that using anything other than "eth"
> won't cause some unpleasant "our app always ass-u-me-d interfaces
started with
> 'eth'" situations?
>
Good point. I'm sure folks use 'eth' in their regex filters. Please
ignore my obe/obn email.
> rick jones
Chetan Loke
^ permalink raw reply
* [PATCH net-26] cxgb4vf: fix setting unicast/multicast addresses ...
From: Casey Leedom @ 2010-11-24 22:23 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
We were truncating the number of unicast and multicast MAC addresses
supported. Additionally, we were incorrectly computing the MAC Address
hash (a "1 << N" where we needed a "1ULL << N").
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 73 +++++++++++++++++----------
drivers/net/cxgb4vf/t4vf_hw.c | 96 ++++++++++++++++++++++-------------
2 files changed, 105 insertions(+), 64 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 9246d2f..f54af48 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -814,40 +814,48 @@ static struct net_device_stats *cxgb4vf_get_stats(struct net_device *dev)
}
/*
- * Collect up to maxaddrs worth of a netdevice's unicast addresses into an
- * array of addrss pointers and return the number collected.
+ * Collect up to maxaddrs worth of a netdevice's unicast addresses, starting
+ * at a specified offset within the list, into an array of addrss pointers and
+ * return the number collected.
*/
-static inline int collect_netdev_uc_list_addrs(const struct net_device *dev,
- const u8 **addr,
- unsigned int maxaddrs)
+static inline unsigned int collect_netdev_uc_list_addrs(const struct net_device *dev,
+ const u8 **addr,
+ unsigned int offset,
+ unsigned int maxaddrs)
{
+ unsigned int index = 0;
unsigned int naddr = 0;
const struct netdev_hw_addr *ha;
- for_each_dev_addr(dev, ha) {
- addr[naddr++] = ha->addr;
- if (naddr >= maxaddrs)
- break;
- }
+ for_each_dev_addr(dev, ha)
+ if (index++ >= offset) {
+ addr[naddr++] = ha->addr;
+ if (naddr >= maxaddrs)
+ break;
+ }
return naddr;
}
/*
- * Collect up to maxaddrs worth of a netdevice's multicast addresses into an
- * array of addrss pointers and return the number collected.
+ * Collect up to maxaddrs worth of a netdevice's multicast addresses, starting
+ * at a specified offset within the list, into an array of addrss pointers and
+ * return the number collected.
*/
-static inline int collect_netdev_mc_list_addrs(const struct net_device *dev,
- const u8 **addr,
- unsigned int maxaddrs)
+static inline unsigned int collect_netdev_mc_list_addrs(const struct net_device *dev,
+ const u8 **addr,
+ unsigned int offset,
+ unsigned int maxaddrs)
{
+ unsigned int index = 0;
unsigned int naddr = 0;
const struct netdev_hw_addr *ha;
- netdev_for_each_mc_addr(ha, dev) {
- addr[naddr++] = ha->addr;
- if (naddr >= maxaddrs)
- break;
- }
+ netdev_for_each_mc_addr(ha, dev)
+ if (index++ >= offset) {
+ addr[naddr++] = ha->addr;
+ if (naddr >= maxaddrs)
+ break;
+ }
return naddr;
}
@@ -860,16 +868,20 @@ static int set_addr_filters(const struct net_device *dev, bool sleep)
u64 mhash = 0;
u64 uhash = 0;
bool free = true;
- u16 filt_idx[7];
+ unsigned int offset, naddr;
const u8 *addr[7];
- int ret, naddr = 0;
+ int ret;
const struct port_info *pi = netdev_priv(dev);
/* first do the secondary unicast addresses */
- naddr = collect_netdev_uc_list_addrs(dev, addr, ARRAY_SIZE(addr));
- if (naddr > 0) {
+ for (offset = 0; ; offset += naddr) {
+ naddr = collect_netdev_uc_list_addrs(dev, addr, offset,
+ ARRAY_SIZE(addr));
+ if (naddr == 0)
+ break;
+
ret = t4vf_alloc_mac_filt(pi->adapter, pi->viid, free,
- naddr, addr, filt_idx, &uhash, sleep);
+ naddr, addr, NULL, &uhash, sleep);
if (ret < 0)
return ret;
@@ -877,12 +889,17 @@ static int set_addr_filters(const struct net_device *dev, bool sleep)
}
/* next set up the multicast addresses */
- naddr = collect_netdev_mc_list_addrs(dev, addr, ARRAY_SIZE(addr));
- if (naddr > 0) {
+ for (offset = 0; ; offset += naddr) {
+ naddr = collect_netdev_mc_list_addrs(dev, addr, offset,
+ ARRAY_SIZE(addr));
+ if (naddr == 0)
+ break;
+
ret = t4vf_alloc_mac_filt(pi->adapter, pi->viid, free,
- naddr, addr, filt_idx, &mhash, sleep);
+ naddr, addr, NULL, &mhash, sleep);
if (ret < 0)
return ret;
+ free = false;
}
return t4vf_set_addr_hash(pi->adapter, pi->viid, uhash != 0,
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index f7d7f97..35fc803 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -1014,48 +1014,72 @@ int t4vf_alloc_mac_filt(struct adapter *adapter, unsigned int viid, bool free,
unsigned int naddr, const u8 **addr, u16 *idx,
u64 *hash, bool sleep_ok)
{
- int i, ret;
+ int offset, ret = 0;
+ unsigned nfilters = 0;
+ unsigned int rem = naddr;
struct fw_vi_mac_cmd cmd, rpl;
- struct fw_vi_mac_exact *p;
- size_t len16;
- if (naddr > ARRAY_SIZE(cmd.u.exact))
+ if (naddr > FW_CLS_TCAM_NUM_ENTRIES)
return -EINVAL;
- len16 = DIV_ROUND_UP(offsetof(struct fw_vi_mac_cmd,
- u.exact[naddr]), 16);
- memset(&cmd, 0, sizeof(cmd));
- cmd.op_to_viid = cpu_to_be32(FW_CMD_OP(FW_VI_MAC_CMD) |
- FW_CMD_REQUEST |
- FW_CMD_WRITE |
- (free ? FW_CMD_EXEC : 0) |
- FW_VI_MAC_CMD_VIID(viid));
- cmd.freemacs_to_len16 = cpu_to_be32(FW_VI_MAC_CMD_FREEMACS(free) |
- FW_CMD_LEN16(len16));
+ for (offset = 0; offset < naddr; /**/) {
+ unsigned int fw_naddr = (rem < ARRAY_SIZE(cmd.u.exact)
+ ? rem
+ : ARRAY_SIZE(cmd.u.exact));
+ size_t len16 = DIV_ROUND_UP(offsetof(struct fw_vi_mac_cmd,
+ u.exact[fw_naddr]), 16);
+ struct fw_vi_mac_exact *p;
+ int i;
- for (i = 0, p = cmd.u.exact; i < naddr; i++, p++) {
- p->valid_to_idx =
- cpu_to_be16(FW_VI_MAC_CMD_VALID |
- FW_VI_MAC_CMD_IDX(FW_VI_MAC_ADD_MAC));
- memcpy(p->macaddr, addr[i], sizeof(p->macaddr));
- }
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.op_to_viid = cpu_to_be32(FW_CMD_OP(FW_VI_MAC_CMD) |
+ FW_CMD_REQUEST |
+ FW_CMD_WRITE |
+ (free ? FW_CMD_EXEC : 0) |
+ FW_VI_MAC_CMD_VIID(viid));
+ cmd.freemacs_to_len16 =
+ cpu_to_be32(FW_VI_MAC_CMD_FREEMACS(free) |
+ FW_CMD_LEN16(len16));
+
+ for (i = 0, p = cmd.u.exact; i < fw_naddr; i++, p++) {
+ p->valid_to_idx = cpu_to_be16(
+ FW_VI_MAC_CMD_VALID |
+ FW_VI_MAC_CMD_IDX(FW_VI_MAC_ADD_MAC));
+ memcpy(p->macaddr, addr[offset+i], sizeof(p->macaddr));
+ }
+
+
+ ret = t4vf_wr_mbox_core(adapter, &cmd, sizeof(cmd), &rpl,
+ sleep_ok);
+ if (ret && ret != -ENOMEM)
+ break;
- ret = t4vf_wr_mbox_core(adapter, &cmd, sizeof(cmd), &rpl, sleep_ok);
- if (ret)
- return ret;
-
- for (i = 0, p = rpl.u.exact; i < naddr; i++, p++) {
- u16 index = FW_VI_MAC_CMD_IDX_GET(be16_to_cpu(p->valid_to_idx));
-
- if (idx)
- idx[i] = (index >= FW_CLS_TCAM_NUM_ENTRIES
- ? 0xffff
- : index);
- if (index < FW_CLS_TCAM_NUM_ENTRIES)
- ret++;
- else if (hash)
- *hash |= (1 << hash_mac_addr(addr[i]));
+ for (i = 0, p = rpl.u.exact; i < fw_naddr; i++, p++) {
+ u16 index = FW_VI_MAC_CMD_IDX_GET(
+ be16_to_cpu(p->valid_to_idx));
+
+ if (idx)
+ idx[offset+i] =
+ (index >= FW_CLS_TCAM_NUM_ENTRIES
+ ? 0xffff
+ : index);
+ if (index < FW_CLS_TCAM_NUM_ENTRIES)
+ nfilters++;
+ else if (hash)
+ *hash |= (1ULL << hash_mac_addr(addr[offset+i]));
+ }
+
+ free = false;
+ offset += fw_naddr;
+ rem -= fw_naddr;
}
+
+ /*
+ * If there were no errors or we merely ran out of room in our MAC
+ * address arena, return the number of filters actually written.
+ */
+ if (ret == 0 || ret == -ENOMEM)
+ ret = nfilters;
return ret;
}
--
1.7.0.4
^ permalink raw reply related
* Re: tg3 driver not advertising 1000mbit
From: Jean-Louis Dupond @ 2010-11-24 22:27 UTC (permalink / raw)
To: Krzysztof Olędzki
Cc: Matt Carlson, Michael Chan, netdev@vger.kernel.org,
David Christensen
In-Reply-To: <4CED7110.9030801@ans.pl>
I didn't do more research on the issue.
The guys @ broadcom advised me to do BIOS update, so the firmware of the
NIC is updated.
Maby you can try that also?
Sincerely,
Jean-Louis Dupond
Op 24-11-10 21:09, Krzysztof Olędzki schreef:
> On 2009-07-02 18:42, Matt Carlson wrote:
>> On Tue, Jun 30, 2009 at 02:20:45AM -0700, Jean-Louis Dupond wrote:
>>> # ethtool -i eth0
>>> driver: tg3
>>> version: 3.97
>>> firmware-version: 5722-v3.08, ASFIPMI v6.02
>>> bus-info: 0000:01:00.0
>>>
>>> Kernel version 2.6.29.4
>>
>> Rats. I mirrored your setup here, but I still can't reproduce the
>> problem. I still suspect this is a bad driver<=> firmware interaction.
>>
>> Can you apply the following patch and show me the resulting syslog
>> entries? The patch is just making sure the firmware request to shutdown
>> really goes through.
>>
>>
>> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
>> index 46a3f86..900e28b 100644
>> --- a/drivers/net/tg3.c
>> +++ b/drivers/net/tg3.c
>> @@ -1124,6 +1124,9 @@ static void tg3_wait_for_event_ack(struct tg3 *tp)
>> break;
>> udelay(8);
>> }
>> +
>> + if (i == delay_cnt)
>> + printk( KERN_WARNING "Firmware didn't ack driver event!\n" );
>> }
>>
>> /* tp->lock is held. */
>> @@ -6330,12 +6333,16 @@ static void tg3_stop_fw(struct tg3 *tp)
>> /* Wait for RX cpu to ACK the previous event. */
>> tg3_wait_for_event_ack(tp);
>>
>> + printk( KERN_NOTICE "%s: Stopping firmware.\n", tp->dev->name );
>> +
>> tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX, FWCMD_NICDRV_PAUSE_FW);
>>
>> tg3_generate_fw_event(tp);
>>
>> /* Wait for RX cpu to ACK this event. */
>> tg3_wait_for_event_ack(tp);
>> +
>> + printk( KERN_NOTICE "%s: Operation completed.\n", tp->dev->name );
>> }
>> }
>>
>> @@ -7537,6 +7544,8 @@ static void tg3_timer(unsigned long __opaque)
>> !(tp->tg3_flags3& TG3_FLG3_ENABLE_APE)) {
>> tg3_wait_for_event_ack(tp);
>>
>> + printk( KERN_NOTICE "%s: Sending keepalive event.\n", tp->dev->name );
>> +
>> tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX,
>> FWCMD_NICDRV_ALIVE3);
>> tg3_write_mem(tp, NIC_SRAM_FW_CMD_LEN_MBOX, 4);
>
> Hello,
>
> Have you been able to solve this issue? I have a similar problem with
> Dell PowerEdge R300 servers connected to HP2610 100Mbps switches. The
> servers contain two BCM5722 NICs and after a reboot, with probability
> about 70%, I end up with 10Mbps HD mainly on the first NIC.
>
> I discovered that it is enough to run:
> /sbin/mii-tool -R eth0
> /sbin/mii-tool -R eth1
> to trigger renegotiation that brings expected 100Mbps FD. For now, I
> added this to my startups scripts as a workaround.
>
> This problem exists in 2.6.30-stable, 2.6.31-stable and 2.6.34-stable
> which I'm currently running.
>
> Best regards,
>
> Krzysztof Olędzki
^ permalink raw reply
* [PATCH] bonding: check for assigned mac before adopting the slaves mac address
From: David Strand @ 2010-11-24 23:12 UTC (permalink / raw)
To: netdev; +Cc: Jay Vosburgh, linux-kernel
Restore the check for a missing mac address before adopting the first
slaves as it's own. This regression was introduced in:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=c20811a79e671a6a1fe86a8c1afe04aca8a7f085
Signed-off-by: David Strand dpstrand@gmail.com
---
diff -uprN a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c 2010-11-24 11:36:58.125640000 -0800
+++ b/drivers/net/bonding/bond_main.c 2010-11-24 11:40:58.175640000 -0800
@@ -1577,8 +1577,9 @@ int bond_enslave(struct net_device *bond
/* If this is the first slave, then we need to set the master's hardware
* address to be the same as the slave's. */
if (bond->slave_cnt == 0)
- memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
- slave_dev->addr_len);
+ if (is_zero_ether_addr(bond->dev->dev_addr))
+ memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
+ slave_dev->addr_len);
new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
^ permalink raw reply
* [net-next-2.6 PATCH] 8021q: vlan device is lockless do not transfer real_num_{tx|rx}_queues
From: John Fastabend @ 2010-11-24 23:14 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet
Now that the vlan device is lockless and single queue do not
transfer the real num queues. This is causing a BUG_ON to occur.
kernel BUG at net/8021q/vlan.c:345!
Call Trace:
[<ffffffff813fd6e8>] ? fib_rules_event+0x28/0x1b0
[<ffffffff814ad2b5>] notifier_call_chain+0x55/0x80
[<ffffffff81089156>] raw_notifier_call_chain+0x16/0x20
[<ffffffff813e5af7>] call_netdevice_notifiers+0x37/0x70
[<ffffffff813e6756>] netdev_features_change+0x16/0x20
[<ffffffffa02995be>] ixgbe_fcoe_enable+0xae/0x100 [ixgbe]
[<ffffffffa01da06a>] vlan_dev_fcoe_enable+0x2a/0x30 [8021q]
[<ffffffffa02d08c3>] fcoe_create+0x163/0x630 [fcoe]
[<ffffffff811244d5>] ? mmap_region+0x255/0x5a0
[<ffffffff81080ef0>] param_attr_store+0x50/0x80
[<ffffffff810809b6>] module_attr_store+0x26/0x30
[<ffffffff811b9db2>] sysfs_write_file+0xf2/0x180
[<ffffffff8114fc88>] vfs_write+0xc8/0x190
[<ffffffff81150621>] sys_write+0x51/0x90
[<ffffffff8100c0b2>] system_call_fastpath+0x16/0x1b
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/8021q/vlan.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index dc10713..6e64f7c 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -341,9 +341,6 @@ static void vlan_transfer_features(struct net_device *dev,
#if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid;
#endif
- vlandev->real_num_tx_queues = dev->real_num_tx_queues;
- BUG_ON(vlandev->real_num_tx_queues > vlandev->num_tx_queues);
-
if (old_features != vlandev->features)
netdev_features_change(vlandev);
}
^ permalink raw reply related
* Re: [PATCH] bonding: check for assigned mac before adopting the slaves mac address
From: Jay Vosburgh @ 2010-11-24 23:33 UTC (permalink / raw)
To: David Strand; +Cc: netdev, linux-kernel
In-Reply-To: <AANLkTinpO=FmoecfV8epubXU4OrhFsXJ7-Kc68yNhMEs@mail.gmail.com>
David Strand <dpstrand@gmail.com> wrote:
>Restore the check for a missing mac address before adopting the first
>slaves as it's own. This regression was introduced in:
>http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=c20811a79e671a6a1fe86a8c1afe04aca8a7f085
How exactly is this a regression? The above referenced patch
changes the method used to decide if the bonding master needs to have
it's MAC address set. The original way was "bonding master's MAC is
zero," after the above, it's "adding first slave."
Do you have some use case that manually sets the master's MAC
address prior to adding any slaves?
-J
>Signed-off-by: David Strand dpstrand@gmail.com
>---
>diff -uprN a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>--- a/drivers/net/bonding/bond_main.c 2010-11-24 11:36:58.125640000 -0800
>+++ b/drivers/net/bonding/bond_main.c 2010-11-24 11:40:58.175640000 -0800
>@@ -1577,8 +1577,9 @@ int bond_enslave(struct net_device *bond
> /* If this is the first slave, then we need to set the master's hardware
> * address to be the same as the slave's. */
> if (bond->slave_cnt == 0)
>- memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
>- slave_dev->addr_len);
>+ if (is_zero_ether_addr(bond->dev->dev_addr))
>+ memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
>+ slave_dev->addr_len);
>
>
> new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [PATCH 1/1] NET: wan/x25_asy, move lapb_unregister to x25_asy_close_tty
From: Jiri Slaby @ 2010-11-24 23:54 UTC (permalink / raw)
To: davem; +Cc: netdev, slapin, linux-kernel, jirislaby, Andrew Hendry
We register lapb when tty is created, but unregister it only when the
device is UP. So move the lapb_unregister to x25_asy_close_tty after
the device is down.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Sergey Lapin <slapin@ossfans.org>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
---
drivers/net/wan/x25_asy.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 66cda25..24297b2 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -498,7 +498,6 @@ norbuff:
static int x25_asy_close(struct net_device *dev)
{
struct x25_asy *sl = netdev_priv(dev);
- int err;
spin_lock(&sl->lock);
if (sl->tty)
@@ -507,10 +506,6 @@ static int x25_asy_close(struct net_device *dev)
netif_stop_queue(dev);
sl->rcount = 0;
sl->xleft = 0;
- err = lapb_unregister(dev);
- if (err != LAPB_OK)
- printk(KERN_ERR "x25_asy_close: lapb_unregister error -%d\n",
- err);
spin_unlock(&sl->lock);
return 0;
}
@@ -595,6 +590,7 @@ static int x25_asy_open_tty(struct tty_struct *tty)
static void x25_asy_close_tty(struct tty_struct *tty)
{
struct x25_asy *sl = tty->disc_data;
+ int err;
/* First make sure we're connected. */
if (!sl || sl->magic != X25_ASY_MAGIC)
@@ -605,6 +601,11 @@ static void x25_asy_close_tty(struct tty_struct *tty)
dev_close(sl->dev);
rtnl_unlock();
+ err = lapb_unregister(sl->dev);
+ if (err != LAPB_OK)
+ printk(KERN_ERR "x25_asy_close: lapb_unregister error -%d\n",
+ err);
+
tty->disc_data = NULL;
sl->tty = NULL;
x25_asy_free(sl);
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] bonding: check for assigned mac before adopting the slaves mac address
From: Laurent Chavey @ 2010-11-25 0:44 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: David Strand, netdev, linux-kernel
In-Reply-To: <31169.1290641617@death>
based on the new code, the behavior of ifenslave works the same.
>- if (bond->slave_cnt == 0)
>+ if (is_zero_ether_addr(bond->dev->dev_addr))
>- memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
>- slave_dev->addr_len);
> + bond_sethwaddr(bond, slave_dev);
On Wed, Nov 24, 2010 at 3:33 PM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> David Strand <dpstrand@gmail.com> wrote:
>
>>Restore the check for a missing mac address before adopting the first
>>slaves as it's own. This regression was introduced in:
>>http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=c20811a79e671a6a1fe86a8c1afe04aca8a7f085
>
> How exactly is this a regression? The above referenced patch
> changes the method used to decide if the bonding master needs to have
> it's MAC address set. The original way was "bonding master's MAC is
> zero," after the above, it's "adding first slave."
>
> Do you have some use case that manually sets the master's MAC
> address prior to adding any slaves?
>
> -J
>
>>Signed-off-by: David Strand dpstrand@gmail.com
>>---
>>diff -uprN a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>>--- a/drivers/net/bonding/bond_main.c 2010-11-24 11:36:58.125640000 -0800
>>+++ b/drivers/net/bonding/bond_main.c 2010-11-24 11:40:58.175640000 -0800
>>@@ -1577,8 +1577,9 @@ int bond_enslave(struct net_device *bond
>> /* If this is the first slave, then we need to set the master's hardware
>> * address to be the same as the slave's. */
>> if (bond->slave_cnt == 0)
>>- memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
>>- slave_dev->addr_len);
>>+ if (is_zero_ether_addr(bond->dev->dev_addr))
>>+ memcpy(bond->dev->dev_addr, slave_dev->dev_addr,
>>+ slave_dev->addr_len);
>>
>>
>> new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
--------------------------------------------------------------------------------
^ 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