* Re: iproute2: potential upgrade regression with 58a3e827
From: Eric W. Biederman @ 2013-11-08 22:42 UTC (permalink / raw)
To: Chris J Arges; +Cc: shemminger, netdev
In-Reply-To: <527D65FB.8000407@canonical.com>
Chris J Arges <chris.j.arges@canonical.com> writes:
> Fair enough. I really wanted to get a feel if this seemed like an actual
> bug, or rather it's behaving like we'd expect. I don't mind writing
> code, but I want to know if I'm hunting a bug, or adding a feature.
Making it ip netns add work reliably inside of ip netns exec and
handling all of the permutations is adding a feature.
Understanding why ip netns exec is failing in your specific case sounds
like there may be a missing error message. Clearly you get into a
context where /var/run/netns/netns_old is no the bind mount we would
expect it to be.
I saw nothing that should unmake /var/run/netns/nnetns_old as a mount
point. So something strange is going on.
So you might want to go through and inspect to see what is happening.
Perhaps there is a missing error message somewhere.
Without understanding why that mountpoint fails to exist I can't say if
it is a real bug or if it just something weird caused by using an ip
netns exec it was not designed to be used and is known not to be 100%
robust in.
Eric
^ permalink raw reply
* Re: [PATCH v3] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2013-11-08 22:54 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, wg, linux-can, linux-sh, vksavl
In-Reply-To: <527CAC38.6040800@pengutronix.de>
Hello.
On 11/08/2013 12:17 PM, Marc Kleine-Budde wrote:
>>>> Index: linux-can-next/drivers/net/can/rcar_can.c
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ linux-can-next/drivers/net/can/rcar_can.c
>>>> @@ -0,0 +1,893 @@
[...]
>>>> +#define DRV_NAME "rcar_can"
>>>> +
>>>> +/* Mailbox configuration:
>>>> + * mailbox 0 - not used
>>>> + * mailbox 1-31 - Rx
>>>> + * mailbox 32-63 - Tx
>>>> + * no FIFO mailboxes
>>>> + */
>>>> +#define N_MBX 64
>>>> +#define FIRST_TX_MB 32
>>>> +#define N_TX_MB (N_MBX - FIRST_TX_MB)
>>>> +#define RX_MBX_MASK 0xFFFFFFFE
>>> Please use a common prefix for all defines.
>> OK, done now. Could you however explain why the file-local #define's
>> should be prefixed? It's not quite obvious to me...
> It's about readability and maintainability. If you don't know the
> driver, but all driver local defines and functions have a common prefix,
> it's much easier to read if you are not the author of the driver IMHO.
Well, actually I think the last changes somewhat impaired the readability.
My idea was that you want to exclude name conflicts with #include'd headers
this way...
>> [...]
>>>> +static netdev_tx_t rcar_can_start_xmit(struct sk_buff *skb,
>>>> + struct net_device *ndev)
>>>> +{
>>>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>>>> + struct can_frame *cf = (struct can_frame *)skb->data;
>>>> + u32 data, mier1, mbxno, i;
>>>> + unsigned long flags;
>>>> + u8 mctl = 0;
>>>> +
>>>> + if (can_dropped_invalid_skb(ndev, skb))
>>>> + return NETDEV_TX_OK;
>>>> +
>>>> + spin_lock_irqsave(&priv->mier_lock, flags);
>>>> + mier1 = readl(&priv->regs->mier1);
>>>> + if (mier1) {
>>>> + i = __builtin_clz(mier1);
>>>> + mbxno = i ? N_MBX - i : FIRST_TX_MB;
>>>> + } else {
>>>> + mbxno = FIRST_TX_MB;
>>>> + }
>>> Can you explain how the hardware arbitration works, and you do you
>>> guarantee the CAN frames are send by the hardware in the same order you
>>> put them into the hardware.
>> Tx mailbox with the smallest mailbox number has the highest priority.
>> The other possible Tx mailbox selection rule (not used by the driver
>> now) is ID priority transmit mode (as defined in the ISO 11898-1 specs).
>> The algorithm used guarantees the mailboxes are filled sequentially.
Well, not quite, unfortunately -- it wraps at the last mailbox...
> I see. You are using mier1 to track the used mailboxes....correct?
Yes, the mailbox interrupts in MIER1 are enabled only for used mailboxes.
>> + if (unlikely(mier1 == 0xffffffff))
>> + netif_stop_queue(ndev);
> Then you have a race condition in your tx-complete handler
> rcar_can_tx_done(), as you call netif_wake_queue() unconditionally. If
Yes, I'm seeing it now...
> mier1 == 0xffffffff you must wait until _all_ mailboxes are transmitted
That 0xffffffff criterion seems wrong for me now, I changed the algorithm
and moved the criterion but didn't update it. The correct one seems to be:
if (unlikely(mier1 & 0x80000000))
netif_stop_queue(ndev);
> until you are allowed to reenable the mailboxes. Have a look at the
> at91_can driver, it's using a similar scheme. The lowest mailbox is
> transmitted first, but there are three additional bits that indicate the
> priority.
You mean 4 bits? Priorities are from 0 to 15...
>> I've used 'canfdtest' as suggested by Wolfgang Grandegger to verify, see
>> the log below:
>> root@am335x-evm:~# ./canfdtest -v -g can0
>> interface = can0, family = 29, type = 3, proto = 1
>> ...............................................................................C
>>
>> Test messages sent and received: 483203
>> Exiting...
>> root@am335x-evm:~#
As you can see, 'canfdtest' didn't detect any race, maybe you could
recommend a test which would help to detect it?
>> [...]
>>>> +static int rcar_can_rx_poll(struct napi_struct *napi, int quota)
>>>> +{
>>>> + struct rcar_can_priv *priv = container_of(napi,
>>>> + struct rcar_can_priv, napi);
>>>> + int num_pkts = 0;
>>>> +
>>>> + /* Find mailbox */
>>>> + while (num_pkts < quota) {
>>>> + u8 mctl, mbx;
>>>> +
>>>> + mbx = readb(&priv->regs->mssr);
>>> How does the RX work? Is it a hardware FIFO?
>> In short, the MSSR register provides the smallest Rx mailbox number
>> that is looked up in the Rx search mode. We read MSSR until no search
>> results can be obtained, so it is some sort of FIFO.
> This looks racy....
Could you please elaborate?
>> And there is separate FIFO operation mode: some mailboxes can be
>> configured as FIFO and serviced by special registers but this operation
>> mode is not supported by the driver.
> if you hardware supports a real FIFO then I strongly suggest to make use
> of it.
Well, Tx/Rx FIFOs are only 4 frames deep (although I haven't seen more
than 2 Rx mailboxes ready in a row, there are 32 Tx mailboxes); also FIFO mode
is less documented than mailbox mode (hence some nasty surprises are
possible). We still can use mailboxes when in FIFO mode, it's just 8 of them
are reserved for Tx/Rx FIFOs.
>> [...]
>>>> +static int rcar_can_probe(struct platform_device *pdev)
>>>> +{
[...]
>>>> + ndev->netdev_ops = &rcar_can_netdev_ops;
>>>> + ndev->irq = irq;
>>>> + ndev->flags |= IFF_ECHO;
>>>> + priv->ndev = ndev;
>>>> + priv->regs = addr;
>>>> + priv->clock_select = pdata->clock_select;
>>>> + priv->can.clock.freq = clk_get_rate(priv->clk);
>>>> + priv->can.bittiming_const = &rcar_can_bittiming_const;
>>>> + priv->can.do_set_bittiming = rcar_can_set_bittiming;
>>> Please call this function directly during the open() function.
>> OK, done, and the method installation was removed. However, I'm not
>> sure why you requested this as many drivers are still using the method.
> The callback was there from the beginning, but then we figured out that
> we don't need it in the driver, but no one has cleaned up the drivers
> yet. So don't use it in new drivers. I know it's not documented anywhere :(
You should have clarified that in your first review -- that would have
prevented me from going the wrong way...
> regards,
> Marc
WBR, Sergei
^ permalink raw reply
* Re: Using HTB over MultiQ
From: John Fastabend @ 2013-11-08 23:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Anton 'EvilMan' Danilov, netdev
In-Reply-To: <1383947802.16391.3.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/8/2013 1:56 PM, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 19:53 +0400, Anton 'EvilMan' Danilov wrote:
>
>> Hm.. I think I need another way to classify packets for using of mq
>> qdisc, because it don't support classify at root (not supported error
>> on try attach filter).
>
> I think it might be time to add filters on the device, and run them
> without any lock (rcu protection only)
>
> John, I think you had some previous work ?
Yes, I have a net-next fork with this but I currently introduced a bug
in the u32 classifier. I'll resurrect this next week and send something
out. We can take a look and see if its useful.
>
>> On next week i'll try to write ipset extension for setting of priority
>> and queue_mapping value through the IPSET netfilter target.
>
> Sounds a nice idea as well.
>
Another thought would be to put a netfilter hook above the qdisc and on
ingress (not in the bridge module). I've been meaning to take a look
at nftables I'm not sure how much duplication exists between nftables
and tc classifiers at this point.
>
> --
> 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
* Re: [RFC] tcp: randomize TCP source ports
From: Rick Jones @ 2013-11-08 23:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383876294.9412.136.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/07/2013 06:04 PM, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 17:07 -0800, Rick Jones wrote:
>
>> For perhaps most definitions of well deployed. There is at least one
>> load balancer which, while it offers TCP Window Scaling, does not also
>> offer TCP Time Stamps...
>>
>> By rights they should (must) be offering TCP Time Stamps, and they are,
>> I am told, "working on it."
>>
>> Is all going to be "well" when it is the (non-Linux) remote system which
>> has the TIME_WAIT endpoint?
>
> Hey, tell us why netperf does a bind(port=0, addr=ANY) and SO_REUSEADDR
> tricks before connect()
>
> It seems you do request randomization, but you do not want it for
> applications written by innocent people...
That bind() call is not there to request randomization of the TCP source
port.
The bind() call in src/nettest_bsd.c/create_data_socket() is so
netserver can report a port number back to netperf. It is also there so
a TCP_CRR test can explicitly use more than the configured ephemeral
port range. It is also used when setting explicit port numbers for
getting through firewalls.
In the establish_control() path the bind() call is also there to allow
specifying an explicit port number for the control connection. I just
don't bother avoiding the call when someone hasn't selected an explicit
client-side port number for the control connection.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Eric Dumazet @ 2013-11-08 23:42 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, netdev
In-Reply-To: <527D7320.4050008@hp.com>
On Fri, 2013-11-08 at 15:26 -0800, Rick Jones wrote:
> On 11/07/2013 06:04 PM, Eric Dumazet wrote:
> >
> > It seems you do request randomization, but you do not want it for
> > applications written by innocent people...
>
> That bind() call is not there to request randomization of the TCP source
> port.
I was actually doing some kind of humor, I should have added a ;)
Thanks
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Rick Jones @ 2013-11-08 23:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383954154.16391.4.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/08/2013 03:42 PM, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 15:26 -0800, Rick Jones wrote:
>> On 11/07/2013 06:04 PM, Eric Dumazet wrote:
>>>
>>> It seems you do request randomization, but you do not want it for
>>> applications written by innocent people...
>>
>> That bind() call is not there to request randomization of the TCP source
>> port.
>
> I was actually doing some kind of humor, I should have added a ;)
Sorry - been watching one of my kids most of the day, my humor/snark
detectors were offline :)
rick
^ permalink raw reply
* Re: [PATCH net] netlink: fix netlink_ack with large messages
From: Thomas Graf @ 2013-11-09 0:04 UTC (permalink / raw)
To: David Miller; +Cc: jbenc, netdev, pablo
In-Reply-To: <20131108.150741.966018155704146843.davem@davemloft.net>
On 11/08/13 at 03:07pm, David Miller wrote:
> From: Jiri Benc <jbenc@redhat.com>
> Date: Thu, 7 Nov 2013 19:57:45 +0100
>
> > Commit c05cdb1b864f ("netlink: allow large data transfers from user-space")
> > does not handle cases where netlink_ack is used to report an error. In such
> > case, the original message is copied to the ack message, which needs to be
> > large enough.
> >
> > Signed-off-by: Jiri Benc <jbenc@redhat.com>
>
> I have two problems with this change.
>
> First of all, if netlink_ack() has this problem, do not extend the
> netlink_alloc_large_skb() usage to dumps too as your patch is
> doing here.
>
> Secondly, it seems sort of over the top to quote such enormous
> messages, and in fact wasteful. We have the sequence number in
> the netlink header, so the user can tell exactly which message
> we are erroring.
>
> Just quoting such huge requests in ACKs by default doesn't seem
> to make any sense. I would say that we should have a way to
> turn off the quoting, or at least limit it, and turn this knob
> off for things like nftables that can hit these kinds of cases.
I agree it seems over the top for pure ACKs but we also use
netlink_ack() to report errors where it makes sense to quote
the full message.
^ permalink raw reply
* [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-09 0:54 UTC (permalink / raw)
To: hannes
Cc: netdev, davem, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen, Nicolas Dichtel
In-Reply-To: <1383958474-6255-1-git-send-email-nicolas.dichtel@6wind.com>
This feature allows to a send packets with address source set to 0.0.0.0 even if
an ip address is available on another interface.
It's useful for DHCP client, to allow them to use UDP sockets and be compliant
with the RFC2131, Section 4.1:
4.1 Constructing and sending DHCP messages
...
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
Based on a previous work from
Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/linux/udp.h | 3 ++-
include/uapi/linux/udp.h | 1 +
net/ipv4/udp.c | 21 +++++++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 42278bbf7a88..ca947206f0fe 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -63,7 +63,8 @@ struct udp_sock {
#define UDPLITE_SEND_CC 0x2 /* set via udplite setsockopt */
#define UDPLITE_RECV_CC 0x4 /* set via udplite setsocktopt */
__u8 pcflag; /* marks socket as UDP-Lite if > 0 */
- __u8 unused[3];
+ __u8 src_any:1; /* saddr to 0 when no IP is available */
+ __u8 unused[2];
/*
* For encapsulation sockets.
*/
diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
index e2bcfd75a30d..daf4a48face1 100644
--- a/include/uapi/linux/udp.h
+++ b/include/uapi/linux/udp.h
@@ -29,6 +29,7 @@ struct udphdr {
/* UDP socket options */
#define UDP_CORK 1 /* Never send partially complete segments */
#define UDP_ENCAP 100 /* Set the socket to accept encapsulated packets */
+#define UDP_SRC_ANY 101 /* Set src addr to 0 when no IP is available */
/* UDP encapsulation types */
#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 89909dd730dd..f58945187dbd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -111,6 +111,7 @@
#include <linux/static_key.h>
#include <trace/events/skb.h>
#include <net/busy_poll.h>
+#include <linux/inetdevice.h>
#include "udp_impl.h"
struct udp_table udp_table __read_mostly;
@@ -1015,6 +1016,18 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto do_confirm;
back_from_confirm:
+ if (up->src_any && sk->sk_bound_dev_if) {
+ struct net_device *dev;
+ struct in_device *in_dev;
+
+ rcu_read_lock();
+ dev = dev_get_by_index_rcu(sock_net(sk), sk->sk_bound_dev_if);
+ in_dev = dev ? __in_dev_get_rcu(dev) : NULL;
+ if (!inet_confirm_addr(sock_net(sk), in_dev, 0, 0,
+ RT_SCOPE_HOST))
+ fl4->saddr = 0;
+ rcu_read_unlock();
+ }
saddr = fl4->saddr;
if (!ipc.addr)
daddr = ipc.addr = fl4->daddr;
@@ -2045,6 +2058,10 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
up->pcflag |= UDPLITE_RECV_CC;
break;
+ case UDP_SRC_ANY:
+ up->src_any = val ? 1 : 0;
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -2107,6 +2124,10 @@ int udp_lib_getsockopt(struct sock *sk, int level, int optname,
val = up->pcrlen;
break;
+ case UDP_SRC_ANY:
+ val = up->src_any;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
1.8.4.1
^ permalink raw reply related
* [RFC PATCH net-next 1/2] ipv4: fix wildcard search with inet_confirm_addr()
From: Nicolas Dichtel @ 2013-11-09 0:54 UTC (permalink / raw)
To: hannes
Cc: netdev, davem, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen, Nicolas Dichtel
In-Reply-To: <20131105205744.GK8832@order.stressinduktion.org>
Help of this function says: "in_dev: only on this interface, 0=any interface",
but in fact the code supposes that it will never be NULL.
Note that this function was never called with in_dev == NULL, but it's exported
and may be used by an external module.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
This patch has been submitted formally for net (some rework are needed), but the
next one is based on it, it's why I send it here.
drivers/net/bonding/bonding.h | 10 +++-------
include/linux/inetdevice.h | 4 ++--
net/ipv4/arp.c | 3 ++-
net/ipv4/devinet.c | 8 ++++----
4 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 77a07a12e77f..203deaf30f83 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -377,15 +377,11 @@ static inline bool bond_is_slave_inactive(struct slave *slave)
static inline __be32 bond_confirm_addr(struct net_device *dev, __be32 dst, __be32 local)
{
- struct in_device *in_dev;
- __be32 addr = 0;
+ __be32 addr;
rcu_read_lock();
- in_dev = __in_dev_get_rcu(dev);
-
- if (in_dev)
- addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
-
+ addr = inet_confirm_addr(dev_net(dev), __in_dev_get_rcu(dev), dst,
+ local, RT_SCOPE_HOST);
rcu_read_unlock();
return addr;
}
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 0d678aefe69d..f188e7598edd 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -164,8 +164,8 @@ int devinet_ioctl(struct net *net, unsigned int cmd, void __user *);
void devinet_init(void);
struct in_device *inetdev_by_index(struct net *, int);
__be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope);
-__be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst, __be32 local,
- int scope);
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev, __be32 dst,
+ __be32 local, int scope);
struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32 prefix,
__be32 mask);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7808093cede6..fc5ebc7e1962 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -408,7 +408,8 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
default:
return 0;
}
- return !inet_confirm_addr(in_dev, sip, tip, scope);
+ return !inet_confirm_addr(dev_net(in_dev->dev), in_dev, sip, tip,
+ scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a1b5bcbd04ae..47cdb035f817 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1236,22 +1236,22 @@ static __be32 confirm_addr_indev(struct in_device *in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
+ * - net: netns to check, cannot be NULL
* - in_dev: only on this interface, 0=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev,
__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
struct net_device *dev;
- struct net *net;
if (scope != RT_SCOPE_LINK)
- return confirm_addr_indev(in_dev, dst, local, scope);
+ return in_dev ? confirm_addr_indev(in_dev, dst, local, scope) :
+ 0;
- net = dev_net(in_dev->dev);
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
in_dev = __in_dev_get_rcu(dev);
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2013-11-09 1:02 UTC (permalink / raw)
To: Wolfgang Grandegger, netdev, mkl, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <52657CA1.2040708@grandegger.com>
Hello.
On 10/21/2013 11:12 PM, Wolfgang Grandegger wrote:
>> Sorry for the belated reply -- was on vacations.
And again sorry, couldn't get to this due to other things.
>>> thanks for your contribution. The patch looks already quite good. Before
>>> I find time for a detailed review could you please check error handling
>>> and bus-off recovery by reporting the output of "$ candump -td -e
>>> any,0:0,#FFFFFFFF" while sending messages to the device ...
[...]
>> root@10.0.0.101:/opt/can-utils# ip -details link show can0
>> 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>> qlen 10 link/can
>> can state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0
>> bitrate 297619 sample-point 0.714
> Strange, what bitrate did you configure?
300000.
>> tq 480 prop-seg 2 phase-seg1 2 phase-seg2 2 sjw 1
>> rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
>> clock 49999999
> Could you please try if the algorithm works better with 50000000.
It doesn't. Look at the logs below:
Bitrate setting:
----------------
actual:
300KHz
ip -details link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 297619 sample-point 0.714
tq 480 prop-seg 2 phase-seg1 2 phase-seg2 2 sjw 1
rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 49999999
500KHz:
ip -details link show can0
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 10
link/can
can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
bitrate 499999 sample-point 0.800
tq 200 prop-seg 3 phase-seg1 4 phase-seg2 2 sjw 1
rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 49999999
700KHz:
ip -details link show can0
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 10
link/can
can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
bitrate 694444 sample-point 0.750
tq 180 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 49999999
--------------
Forced:
priv->can.clock.freq = 50000000;
300KHz:
ip -details link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 297619 sample-point 0.714
tq 480 prop-seg 2 phase-seg1 2 phase-seg2 2 sjw 1
rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 50000000
root@10.0.0.101:/opt#
700KHz:
root@10.0.0.101:/opt# ip -details link show can0
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 10
link/can
can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
bitrate 694444 sample-point 0.750
tq 180 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 50000000
>> root@10.0.0.101:/opt/can-utils#
>> dmesg:
>> rcar_can rcar_can.0 can0: bitrate error 0.7%
>> rcar_can rcar_can.0 can0: Error warning interrupt
>> rcar_can rcar_can.0 can0: Bus error interrupt:
>> rcar_can rcar_can.0 can0: ACK Error
>> rcar_can rcar_can.0 can0: Error passive interrupt
>>> 2. ... with short-circuited CAN high and low and doing some time later
>>> a manual recovery with "ip link set can0 type can restart"
>> Now we have auto recovery only. Manual recovery was tested with the
>> first driver version and worked.
> What do you mean with "auto recovery"? Auto recovery by the hardware or
> via "restart-ms <ms>"? How do you choose between "manual" and "auto"
> recovery?
This exact test was done with hardware auto-recovery only. No "restart-ms"
was programmed.
>> Terminal 1:
>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>> root@10.0.0.104:/opt/can-utils#
>> Terminal 2:
>> root@10.0.0.104:/opt/can-utils# ./candump -td -e any,0:0,#FFFFFFFF
>> (000.000000) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
>> protocol-violation{{tx-dominant-bit-error}{}}
>> bus-error
>> (000.021147) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
>> bus-off
>> restarted-after-bus-off
> Why does it get "restarted" directly after the bus-off?
Because we have hardware auto-recovery enabled.
>> (011.738522) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
> What controller problem? data[1] is not set for some reasom.
Not comments. Looking into it.
>> protocol-violation{{tx-dominant-bit-error}{}}
>> bus-error
>> (000.021163) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
>> bus-off
>> restarted-after-bus-off
>> (001.666625) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
>> protocol-violation{{tx-dominant-bit-error}{}}
>> bus-error
>> (000.021157) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>> controller-problem{}
>> bus-off
>> restarted-after-bus-off
>> dmesg:
>> rcar_can rcar_can.0 can0: Error warning interrupt
>> rcar_can rcar_can.0 can0: Error passive interrupt
>> rcar_can rcar_can.0 can0: Bus error interrupt:
>> rcar_can rcar_can.0 can0: Bit Error (dominant)
>> rcar_can rcar_can.0 can0: Error warning interrupt
>> rcar_can rcar_can.0 can0: Error passive interrupt
> Why are they reported again. You are already in error passive.
Don't know. :-/
[...]
>>> I also wonder if the messages are always sent in order. You could use
>>> the program "canfdtest" [1] from the can-utils for validation.
>> This program is PITA. With the driver workaroung it works:
> What workaround?
Doesn't matter already, got rid of it.
> Wolfgang.
WBR, Sergei
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Hannes Frederic Sowa @ 2013-11-09 4:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383923478.9412.240.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Nov 08, 2013 at 07:11:18AM -0800, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 15:28 +0100, Hannes Frederic Sowa wrote:
>
> > What do you think about using a timer to keep the reseed out of fast-path
> > and switch to the non-arch get_random_bytes instead?
>
> Well, the initial seed value is get_random_bytes(). I felt that using a
> xor with the _arch() version would be safe enough.
>
> For the timer, I do not think its worth the pain : Do you want a per cpu
> timer, or a global one ?
This untested diff came to my mind (it is based on the random tree). I
actually consider to propose something like this for 3.13. UDP port
randomization is really critical.
In 3.14 timeframe I suggest abandon net_random and use prandom_u32
directly so code gets easier to audit.
Would it hurt to use "proper" get_random_byte calls for port randomization?
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cdf4cfb..e9d0136 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -657,9 +657,11 @@ retry:
r->entropy_total += nbits;
if (!r->initialized && nbits > 0) {
if (r->entropy_total > 128) {
- if (r == &nonblocking_pool)
+ if (r == &nonblocking_pool) {
pr_notice("random: %s pool is initialized\n",
r->name);
+ prandom_reseed();
+ }
r->initialized = 1;
r->entropy_total = 0;
}
diff --git a/include/linux/random.h b/include/linux/random.h
index 6312dd9..4f878c0 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -29,6 +29,7 @@ unsigned long randomize_range(unsigned long start, unsigned long end, unsigned l
u32 prandom_u32(void);
void prandom_bytes(void *buf, int nbytes);
void prandom_seed(u32 seed);
+void prandom_reseed(void);
u32 prandom_u32_state(struct rnd_state *);
void prandom_bytes_state(struct rnd_state *state, void *buf, int nbytes);
diff --git a/lib/random32.c b/lib/random32.c
index 52280d5..1ee611f 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -174,11 +174,31 @@ static int __init prandom_init(void)
}
core_initcall(prandom_init);
+static void __prandom_timer(unsigned long dontcare);
+static DEFINE_TIMER(seed_timer, __prandom_timer, 0, 0);
+
+static void __prandom_timer(unsigned long dontcare)
+{
+ u32 entropy;
+ get_random_bytes(&entropy, sizeof(entropy));
+ prandom_seed(entropy);
+ seed_timer.expires = jiffies + 60 * HZ;
+ add_timer(&seed_timer);
+}
+
+static int prandom_start_seed_timer(void)
+{
+ seed_timer.expires = jiffies + 60 * HZ;
+ add_timer(&seed_timer);
+ return 0;
+}
+late_initcall(prandom_start_seed_timer);
+
/*
* Generate better values after random number generator
* is fully initialized.
*/
-static int __init prandom_reseed(void)
+void prandom_reseed(void)
{
int i;
@@ -196,4 +216,3 @@ static int __init prandom_reseed(void)
}
return 0;
}
-late_initcall(prandom_reseed);
Greetings,
Hannes
^ permalink raw reply related
* Re: [PATCH net] netlink: fix netlink_ack with large messages
From: David Miller @ 2013-11-09 5:00 UTC (permalink / raw)
To: tgraf; +Cc: jbenc, netdev, pablo
In-Reply-To: <20131109000434.GD28793@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Sat, 9 Nov 2013 00:04:34 +0000
> I agree it seems over the top for pure ACKs but we also use
> netlink_ack() to report errors where it makes sense to quote
> the full message.
The user has the message, they gave it to us in the sendmsg()
we are responding to. We absolutely do not need to give it
to them again.
If they care about referring to the contents of that message, they can
refer to it in their own copy and make sure they are really looking at
the same thing by comparing the sequence number in the netlink ACK to
the one they used in the netlink header they gave to the kernel in the
sendmsg() call.
What happens now is pure duplication, and for such huge netlink
messages it's really not smart at all.
^ permalink raw reply
* BCM5720 transmit queue 1 timed out
From: Atif Faheem @ 2013-11-09 5:24 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi. I need some help with transmit Q timeouts on the 5720. We are using Linux kernel 3.4.34, with channel bonding on 5720 on embedded. Occasionally immediately after a reboot or a power cycle we get a lockup on the 5720, which looks like given below; the problem seems to happen on some 5720’s more often. Recently there has been a lot of discussion on this issue on the list and based on that I have incorporated the following 2 patches from upstream into the driver, but the problem still continues to happen.
-- After Power-on-reset, the 5719's TX DMA length registers may contain
uninitialized values and cause TX DMA to stall. Check for invalid
values and set a register bit to flush the TX channels. The bit
needs to be turned off after the DMA channels have been flushed.
-- There was a subsequent fix (06/13) that applies the patch above to the 5720. Commit 091f0ea30074bc43f9250961b3247af713024bc6.
Is there anything else that might be missing from 3.4.34 as far as the transmit lockups are concerned? Any ideas will be great.
Thanks.
Atif Faheem
BTI Systems
net
------------[ cut here ]------------
WARNING: at /home/jenkins/jobs/r102-os/workspace/opt/os/wrlinux/builds/atom64/bitbake_build/tmp/work/intel_atom_64-wrs-linux/linux-windriver-3.4-r0/linux/net/sched/sch_generic.c:256 dev_watchdog+0x277/0x280()
Hardware name: To be filled by O.E.M.
NETDEV WATCHDOG: eth1 (tg3): transmit queue 1 timed out
Modules linked in: firmware_class libphy tg3 bonding
Pid: 0, comm: swapper/0 Not tainted 3.4.34-WR5.0.1.3_standard #1
Call Trace:
<IRQ> [<ffffffff81030c84>] warn_slowpath_common+0x84/0xc0
[<ffffffff81030d77>] warn_slowpath_fmt+0x47/0x50
[<ffffffff816799f7>] dev_watchdog+0x277/0x280
[<ffffffff81040784>] run_timer_softirq+0x134/0x420
[<ffffffff8134f5ee>] ? timerqueue_add+0x6e/0xc0
[<ffffffff81679780>] ? qdisc_reset+0x50/0x50
[<ffffffff8103811d>] __do_softirq+0xbd/0x280
[<ffffffff81079375>] ? clockevents_program_event+0x75/0xf0
[<ffffffff8107a7b4>] ? tick_program_event+0x24/0x30
[<ffffffff81777b8c>] call_softirq+0x1c/0x30
[<ffffffff810037b5>] do_softirq+0x55/0x90
[<ffffffff810385ee>] irq_exit+0x8e/0xb0
[<ffffffff817781e9>] smp_apic_timer_interrupt+0x99/0x1cd
[<ffffffff817773c7>] apic_timer_interrupt+0x67/0x70
<EOI> [<ffffffff813c2689>] ? acpi_idle_enter_bm+0x240/0x281
[<ffffffff813c2684>] ? acpi_idle_enter_bm+0x23b/0x281
[<ffffffff815cc58f>] ? menu_select+0xff/0x3c0
[<ffffffff815ca8d8>] cpuidle_enter+0x18/0x20
[<ffffffff815caf59>] cpuidle_idle_call+0xc9/0x3b0
[<ffffffff8100b59f>] cpu_idle+0x7f/0xd0
[<ffffffff8174b3a7>] rest_init+0x7b/0x84
[<ffffffff81cd3b76>] start_kernel+0x35b/0x369
[<ffffffff81cd3616>] ? repair_env_string+0x5a/0x5a
[<ffffffff81cd3321>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cd3416>] x86_64_start_kernel+0xf1/0xf9
---[ end trace b625d70ff7be1bd7 ]—
kernel: tg3 0000:03:00.1: eth1: transmit timed out, resetting
kernel: tg3 0000:03:00.1: eth1: 0x00000000: 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
kernel: tg3 0000:03:00.1: eth1: 0x00000010: 0xbc14000c, 0x00000000, 0xbc13000c, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000020: 0xbc12000c, 0x00000000, 0x00000000, 0x165f14e4
kernel: tg3 0000:03:00.1: eth1: 0x00000030: 0x00000000, 0x00000048, 0x00000000, 0x0000020b
kernel: tg3 0000:03:00.1: eth1: 0x00000040: 0x00000000, 0x03000000, 0xc8035001, 0x64002008
kernel: tg3 0000:03:00.1: eth1: 0x00000050: 0x00005803, 0x00000000, 0x0086a005, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000060: 0x00000000, 0x00000000, 0xf0000298, 0x00380081
kernel: tg3 0000:03:00.1: eth1: 0x00000070: 0x00071090, 0xffffe0ff, 0x00000438, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000080: 0x0000024c, 0x40000040, 0x00000000, 0x0000000c
kernel: tg3 0000:03:00.1: eth1: 0x00000090: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
kernel: tg3 0000:03:00.1: eth1: 0x000000a0: 0x8010ac11, 0x00000004, 0x00001004, 0x00020010
kernel: tg3 0000:03:00.1: eth1: 0x000000b0: 0x15048d81, 0x00102400, 0x0004cc22, 0x10110040
kernel: tg3 0000:03:00.1: eth1: 0x000000d0: 0x0000001f, 0x00000000, 0x00000000, 0x00010000
kernel: tg3 0000:03:00.1: eth1: 0x000000f0: 0x00000000, 0x05720000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000100: 0x13c10001, 0x00000000, 0x00000000, 0x00062030
kernel: tg3 0000:03:00.1: eth1: 0x00000110: 0x00002080, 0x00002000, 0x000000a0, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000130: 0x00000000, 0x00000000, 0x00000000, 0x15010003
kernel: tg3 0000:03:00.1: eth1: 0x00000140: 0xd0400c65, 0x00000014, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000150: 0x16010004, 0x00000000, 0x0007811b, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000160: 0x00010002, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000170: 0x00000000, 0x800000ff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000200: 0x00000000, 0x03000000, 0x00000000, 0x0d000000
kernel: tg3 0000:03:00.1: eth1: 0x00000210: 0x00000000, 0x07000000, 0x00000000, 0x0b000000
kernel: tg3 0000:03:00.1: eth1: 0x00000220: 0x00000000, 0x04000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000260: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
kernel: tg3 0000:03:00.1: eth1: 0x00000280: 0x00000000, 0x0000000c, 0x00000000, 0x00000006
kernel: tg3 0000:03:00.1: eth1: 0x00000290: 0x00000000, 0x0000000a, 0x00000000, 0x00000004
kernel: tg3 0000:03:00.1: eth1: 0x00000300: 0x00000001, 0x00000000, 0x00000000, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00000400: 0x18e04808, 0x00400000, 0x00001000, 0x00000880
kernel: tg3 0000:03:00.1: eth1: 0x00000410: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
kernel: tg3 0000:03:00.1: eth1: 0x00000420: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
kernel: tg3 0000:03:00.1: eth1: 0x00000430: 0x00000400, 0x00000000, 0x000002dd, 0x000005f2
kernel: tg3 0000:03:00.1: eth1: 0x00000440: 0x00000000, 0x00000000, 0x00000000, 0x04584400
kernel: tg3 0000:03:00.1: eth1: 0x00000450: 0x00000001, 0x00008000, 0x00000000, 0x00000102
kernel: tg3 0000:03:00.1: eth1: 0x00000460: 0x00000008, 0x00002620, 0x01ff0002, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000470: 0x80000000, 0x00000080, 0x00000000, 0x40200000
kernel: tg3 0000:03:00.1: eth1: 0x00000480: 0x42000000, 0x7fffffff, 0x06000004, 0x7fffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000500: 0x00000008, 0x00000002, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000540: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000590: 0x00e00000, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000005b0: 0x00000000, 0x00000008, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000005c0: 0xb26ff6f0, 0xa1d5ff82, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000600: 0xffffffff, 0x00f80011, 0x00000000, 0x00001f04
kernel: tg3 0000:03:00.1: eth1: 0x00000610: 0xffffffff, 0x00000000, 0x07c00004, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000620: 0x00000040, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000630: 0x01230123, 0x01230123, 0x01230123, 0x01230123
kernel: tg3 0000:03:00.1: eth1: 0x00000640: 0x01230123, 0x01230123, 0x01230123, 0x01230123
kernel: tg3 0000:03:00.1: eth1: 0x00000650: 0x01230123, 0x01230123, 0x01230123, 0x01230123
kernel: tg3 0000:03:00.1: eth1: 0x00000660: 0x01230123, 0x01230123, 0x01230123, 0x01230123
kernel: tg3 0000:03:00.1: eth1: 0x00000670: 0x5f865437, 0xe4ac62cc, 0x50103a45, 0x36621985
kernel: tg3 0000:03:00.1: eth1: 0x00000680: 0xbf14c0e8, 0x1bc27a1e, 0x84f4b556, 0x094ea6fe
kernel: tg3 0000:03:00.1: eth1: 0x00000690: 0x7dda01e7, 0xc04d7481, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000006c0: 0x00000000, 0x00000000, 0x04000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000006d0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000800: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000810: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000820: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000830: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000840: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000850: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000860: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000880: 0x00000108, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000890: 0x00000002, 0x00000001, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000008f0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000900: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000910: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000920: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000930: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000940: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000950: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
kernel: tg3 0000:03:00.1: eth1: 0x00000960: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000980: 0x00000108, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000990: 0x0000000a, 0x00000020, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000c00: 0x0000000a, 0x00000000, 0x00000003, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00000c10: 0x00000000, 0x00000000, 0x00000000, 0x01420000
kernel: tg3 0000:03:00.1: eth1: 0x00000c80: 0x00000002, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00000ce0: 0x79fa6c02, 0x00000001, 0x00000142, 0x00040028
kernel: tg3 0000:03:00.1: eth1: 0x00000cf0: 0x00000000, 0x50000001, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001000: 0x00000002, 0x00000000, 0xa0000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001400: 0x00000006, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001440: 0x00000000, 0x00000001, 0x00000001, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001480: 0x00003321, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001800: 0x00000036, 0x00000000, 0x00000000, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00001810: 0x00000001, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00001830: 0x00000000, 0x00000000, 0x00000000, 0x74218000
kernel: tg3 0000:03:00.1: eth1: 0x00001840: 0x79012000, 0x00000001, 0x00000204, 0xc0000000
kernel: tg3 0000:03:00.1: eth1: 0x00001850: 0x0000001f, 0x00000000, 0x00004800, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00001860: 0x01000100, 0x00000000, 0x78f2e000, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00001c00: 0x00000002, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002000: 0x00000002, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002010: 0x00000181, 0x00000001, 0x00780003, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002100: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002110: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002120: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002130: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002140: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002150: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002160: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002170: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002180: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002190: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021a0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021b0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021c0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021d0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021e0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000021f0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002200: 0x0000002a, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002250: 0x0000000a, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002400: 0x00010012, 0x00000000, 0x00204001, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002410: 0x0000000f, 0x00005d00, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002440: 0x00000000, 0x00000000, 0x00000002, 0x00044400
kernel: tg3 0000:03:00.1: eth1: 0x00002450: 0x00000001, 0x73a10000, 0x08001800, 0x00040000
kernel: tg3 0000:03:00.1: eth1: 0x00002470: 0x00000000, 0x00000020, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002500: 0x00000000, 0x00000000, 0x00000002, 0x00044800
kernel: tg3 0000:03:00.1: eth1: 0x00002510: 0x00000000, 0x00000000, 0x00000002, 0x00040400
kernel: tg3 0000:03:00.1: eth1: 0x00002520: 0x00000000, 0x00000000, 0x00000002, 0x00044c00
kernel: tg3 0000:03:00.1: eth1: 0x00002530: 0x00000000, 0x00000000, 0x00000002, 0x00040800
kernel: tg3 0000:03:00.1: eth1: 0x00002540: 0x00000000, 0x00000000, 0x00000002, 0x00045000
kernel: tg3 0000:03:00.1: eth1: 0x00002550: 0x00000000, 0x00000000, 0x00000002, 0x00040c00
kernel: tg3 0000:03:00.1: eth1: 0x00002560: 0x00000000, 0x00000000, 0x00000002, 0x00045400
kernel: tg3 0000:03:00.1: eth1: 0x00002570: 0x00000000, 0x00000000, 0x00000002, 0x00041000
kernel: tg3 0000:03:00.1: eth1: 0x00002580: 0x00000000, 0x00000000, 0x00000002, 0x00045800
kernel: tg3 0000:03:00.1: eth1: 0x00002590: 0x00000000, 0x00000000, 0x00000002, 0x00041400
kernel: tg3 0000:03:00.1: eth1: 0x000025a0: 0x00000000, 0x00000000, 0x00000002, 0x00045c00
kernel: tg3 0000:03:00.1: eth1: 0x000025b0: 0x00000000, 0x00000000, 0x00000002, 0x00041800
kernel: tg3 0000:03:00.1: eth1: 0x000025c0: 0x00000000, 0x00000000, 0x00000002, 0x00046000
kernel: tg3 0000:03:00.1: eth1: 0x000025d0: 0x00000000, 0x00000000, 0x00000002, 0x00041c00
kernel: tg3 0000:03:00.1: eth1: 0x000025e0: 0x00000000, 0x00000000, 0x00000002, 0x00046400
kernel: tg3 0000:03:00.1: eth1: 0x000025f0: 0x00000000, 0x00000000, 0x00000002, 0x00042000
kernel: tg3 0000:03:00.1: eth1: 0x00002600: 0x00000000, 0x00000000, 0x00000002, 0x00046800
kernel: tg3 0000:03:00.1: eth1: 0x00002610: 0x00000000, 0x00000000, 0x00000002, 0x00042400
kernel: tg3 0000:03:00.1: eth1: 0x00002620: 0x00000000, 0x00000000, 0x00000002, 0x00046c00
kernel: tg3 0000:03:00.1: eth1: 0x00002630: 0x00000000, 0x00000000, 0x00000002, 0x00042800
kernel: tg3 0000:03:00.1: eth1: 0x00002640: 0x00000000, 0x00000000, 0x00000002, 0x00047000
kernel: tg3 0000:03:00.1: eth1: 0x00002650: 0x00000000, 0x00000000, 0x00000002, 0x00042c00
kernel: tg3 0000:03:00.1: eth1: 0x00002660: 0x00000000, 0x00000000, 0x00000002, 0x00047400
kernel: tg3 0000:03:00.1: eth1: 0x00002670: 0x00000000, 0x00000000, 0x00000002, 0x00043000
kernel: tg3 0000:03:00.1: eth1: 0x00002680: 0x00000000, 0x00000000, 0x00000002, 0x00047800
kernel: tg3 0000:03:00.1: eth1: 0x00002690: 0x00000000, 0x00000000, 0x00000002, 0x00043400
kernel: tg3 0000:03:00.1: eth1: 0x000026a0: 0x00000000, 0x00000000, 0x00000002, 0x00047c00
kernel: tg3 0000:03:00.1: eth1: 0x000026b0: 0x00000000, 0x00000000, 0x00000002, 0x00043800
kernel: tg3 0000:03:00.1: eth1: 0x000026c0: 0x00000000, 0x00000000, 0x00000002, 0x00048000
kernel: tg3 0000:03:00.1: eth1: 0x000026d0: 0x00000000, 0x00000000, 0x00000002, 0x00043c00
kernel: tg3 0000:03:00.1: eth1: 0x000026e0: 0x00000000, 0x00000000, 0x00000002, 0x00048400
kernel: tg3 0000:03:00.1: eth1: 0x000026f0: 0x00000000, 0x00000000, 0x00000002, 0x00044000
kernel: tg3 0000:03:00.1: eth1: 0x00002800: 0x00000006, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002c00: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
kernel: tg3 0000:03:00.1: eth1: 0x00002c10: 0x00000000, 0x00000000, 0x00000019, 0x0000000c
kernel: tg3 0000:03:00.1: eth1: 0x00002c20: 0x00000001, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00002d00: 0x00000080, 0x00000040, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003000: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
kernel: tg3 0000:03:00.1: eth1: 0x00003440: 0x00000000, 0x00000000, 0x00000000, 0x00000110
kernel: tg3 0000:03:00.1: eth1: 0x00003600: 0x00000600, 0x00170000, 0x00110000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003610: 0x00170000, 0x00000000, 0x00130000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003620: 0x00110011, 0x00000000, 0x00000000, 0x40032080
kernel: tg3 0000:03:00.1: eth1: 0x00003630: 0x00800000, 0x87748774, 0x02c01000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003640: 0x00000000, 0x00000000, 0x00000020, 0x00000019
kernel: tg3 0000:03:00.1: eth1: 0x00003650: 0x00000171, 0x000f03ff, 0x05720000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003660: 0x00000000, 0x00000000, 0x02000000, 0x00000202
kernel: tg3 0000:03:00.1: eth1: 0x00003670: 0x00000000, 0xfeffbff7, 0x00000000, 0x00000020
kernel: tg3 0000:03:00.1: eth1: 0x00003680: 0x30018010, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000036a0: 0x000001a0, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000036b0: 0x0010034c, 0x07ff07ff, 0x07ff07ff, 0x01000004
kernel: tg3 0000:03:00.1: eth1: 0x000036c0: 0xffffffff, 0x00000000, 0x00000000, 0x000001c6
kernel: tg3 0000:03:00.1: eth1: 0x000036d0: 0x0000019d, 0x00000000, 0x00000000, 0x0000485f
kernel: tg3 0000:03:00.1: eth1: 0x000036f0: 0x00000000, 0x00000000, 0x00000000, 0x00013301
kernel: tg3 0000:03:00.1: eth1: 0x00003800: 0x00000001, 0x00000000, 0x0000000e, 0x0516028b
kernel: tg3 0000:03:00.1: eth1: 0x00003810: 0x000001f6, 0x00000052, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003c00: 0x00000306, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003c30: 0x00000000, 0x00000000, 0x00000001, 0x74320000
kernel: tg3 0000:03:00.1: eth1: 0x00003c40: 0x00000000, 0x00000b00, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003c50: 0x00000000, 0x00000020, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003c80: 0x0000000c, 0x00000006, 0x0000000a, 0x00000004
kernel: tg3 0000:03:00.1: eth1: 0x00003cd0: 0x00000000, 0x0000000f, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00003d00: 0x00000001, 0x790b7000, 0x00000001, 0x7429d000
kernel: tg3 0000:03:00.1: eth1: 0x00003d10: 0x00000001, 0x76be5000, 0x00000001, 0x79abb000
kernel: tg3 0000:03:00.1: eth1: 0x00003d80: 0x00000014, 0x00000048, 0x00000005, 0x00000035
kernel: tg3 0000:03:00.1: eth1: 0x00003d90: 0x00000005, 0x00000005, 0x00000014, 0x00000048
kernel: tg3 0000:03:00.1: eth1: 0x00003da0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
kernel: tg3 0000:03:00.1: eth1: 0x00003db0: 0x00000014, 0x00000048, 0x00000005, 0x00000035
kernel: tg3 0000:03:00.1: eth1: 0x00003dc0: 0x00000005, 0x00000005, 0x00000014, 0x00000048
kernel: tg3 0000:03:00.1: eth1: 0x00003dd0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
kernel: tg3 0000:03:00.1: eth1: 0x00003fc0: 0x00000026, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004000: 0x00000002, 0x00000000, 0x0003afe9, 0x0014654c
kernel: tg3 0000:03:00.1: eth1: 0x00004010: 0x00000000, 0x00261012, 0x00000480, 0x00848042
kernel: tg3 0000:03:00.1: eth1: 0x00004020: 0x00000000, 0x00000000, 0x00000010, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004030: 0x00000010, 0x00000050, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004040: 0x00000000, 0x00000000, 0x01090020, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004050: 0x00000000, 0x00000000, 0x0025d010, 0x00000002
kernel: tg3 0000:03:00.1: eth1: 0x00004060: 0x00400000, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004400: 0x00000016, 0x00000000, 0x00010000, 0x0000a000
kernel: tg3 0000:03:00.1: eth1: 0x00004410: 0x00000000, 0x0000002a, 0x000000a0, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004420: 0x0000003d, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004440: 0x00000000, 0x00000000, 0x00000000, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00004450: 0x0002033f, 0x00620063, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004800: 0x380303fe, 0x00000000, 0x00000000, 0x00000100
kernel: tg3 0000:03:00.1: eth1: 0x00004810: 0x00000000, 0x00000004, 0x00009c80, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004820: 0x737c0014, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004840: 0x00000000, 0x00000000, 0x00d73500, 0x00fd175d
kernel: tg3 0000:03:00.1: eth1: 0x00004850: 0xe58e042e, 0xd1927a2c, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004860: 0x00000014, 0x11548788, 0x00100800, 0x00040000
kernel: tg3 0000:03:00.1: eth1: 0x00004870: 0x05ea0000, 0x003e1820, 0x003e1820, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004880: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004900: 0x28190404, 0x00305407, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004910: 0x000f001c, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004a00: 0x180303fe, 0x00200000, 0x00200020, 0x00210000
kernel: tg3 0000:03:00.1: eth1: 0x00004a10: 0x73a113a0, 0x008ca924, 0x00200012, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004a20: 0x00000000, 0x00000000, 0xf02c0000, 0x73a11400
kernel: tg3 0000:03:00.1: eth1: 0x00004a30: 0x00000000, 0x00000084, 0x00000084, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004a40: 0x73a11380, 0x73a113a0, 0x73a11340, 0x73a11360
kernel: tg3 0000:03:00.1: eth1: 0x00004a50: 0x00200020, 0x00200020, 0x00200020, 0x00200020
kernel: tg3 0000:03:00.1: eth1: 0x00004a70: 0x28190404, 0x00305407, 0x000f001c, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004b00: 0x180303fe, 0x005a0003, 0x30000000, 0x01420160
kernel: tg3 0000:03:00.1: eth1: 0x00004b10: 0xe01a0000, 0x00000003, 0x005adc88, 0x00001692
kernel: tg3 0000:03:00.1: eth1: 0x00004b20: 0x00000000, 0x02000000, 0x00000000, 0x005a0000
kernel: tg3 0000:03:00.1: eth1: 0x00004b30: 0x00000000, 0x00420000, 0x00000000, 0x001a0000
kernel: tg3 0000:03:00.1: eth1: 0x00004b50: 0x00000000, 0x00000000, 0x88000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004b60: 0x00000000, 0x00000000, 0x88000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004b70: 0x00000000, 0x00000000, 0x88000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004b80: 0x00000000, 0x11548788, 0x00100800, 0x00040000
kernel: tg3 0000:03:00.1: eth1: 0x00004b90: 0x05ea0000, 0x28190404, 0x00305407, 0x000f001c
kernel: tg3 0000:03:00.1: eth1: 0x00004ba0: 0x330c3000, 0x00000000, 0x11548788, 0x000f001c
kernel: tg3 0000:03:00.1: eth1: 0x00004bc0: 0x738e8002, 0x79fa6c02, 0x1ce29ebe, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004bd0: 0x79fa6402, 0x746ed002, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004be0: 0x0142005a, 0x0000e01a, 0x00460142, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004bf0: 0x00000000, 0x00000000, 0x88000000, 0x00003333
kernel: tg3 0000:03:00.1: eth1: 0x00004c00: 0x200003fe, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004c10: 0x0000002a, 0x00000000, 0x00000006, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004c20: 0x00000000, 0x00000000, 0x00000000, 0x00000006
kernel: tg3 0000:03:00.1: eth1: 0x00004c30: 0x00000000, 0x00018000, 0x00108000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00004c40: 0x00000020, 0x00000000, 0x001d0020, 0x00040020
kernel: tg3 0000:03:00.1: eth1: 0x00004c50: 0x0900500b, 0x0000b003, 0x0400a006, 0x00200303
kernel: tg3 0000:03:00.1: eth1: 0x00004c60: 0x00000020, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005000: 0x00009800, 0x80004000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005010: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
kernel: tg3 0000:03:00.1: eth1: 0x00005020: 0x0e000b25, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x00005030: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005040: 0x00000000, 0x00000000, 0x080019d2, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005080: 0x00009800, 0x80000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005090: 0x00000000, 0x00000000, 0x00000000, 0x08001fac
kernel: tg3 0000:03:00.1: eth1: 0x000050a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x000050b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000050c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005100: 0x00009800, 0x80000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005110: 0x00000000, 0x00000000, 0x00000000, 0x080019c4
kernel: tg3 0000:03:00.1: eth1: 0x00005120: 0x30422000, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x00005130: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005140: 0x00000000, 0x00000000, 0x08002cd4, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005180: 0x00009800, 0x80004000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005190: 0x00000000, 0x00000000, 0x00000000, 0x08002ca0
kernel: tg3 0000:03:00.1: eth1: 0x000051a0: 0x00621024, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x000051b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000051c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005200: 0x14600027, 0x144001e2, 0x144001e2, 0x3c038000
kernel: tg3 0000:03:00.1: eth1: 0x00005210: 0x01020000, 0x01020000, 0xc0000000, 0xdeaddead
kernel: tg3 0000:03:00.1: eth1: 0x00005220: 0xdeaddead, 0x3c038000, 0xc0000000, 0x01020000
kernel: tg3 0000:03:00.1: eth1: 0x00005230: 0x14600027, 0x00000000, 0xc0000000, 0x14600027
kernel: tg3 0000:03:00.1: eth1: 0x00005240: 0xb49a89ab, 0x144001e2, 0x144001e2, 0x14600027
kernel: tg3 0000:03:00.1: eth1: 0x00005250: 0x00000b50, 0x144001e2, 0x3c038000, 0xc0010000
kernel: tg3 0000:03:00.1: eth1: 0x00005260: 0x00000000, 0x00000b50, 0x01020000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005270: 0x00000000, 0x14600027, 0xb49a89ab, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005280: 0x00009800, 0x80000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005290: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
kernel: tg3 0000:03:00.1: eth1: 0x000052a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x000052b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000052c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005300: 0x00009800, 0x80004000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005310: 0x00000000, 0x00000000, 0x00000000, 0x08001fc0
kernel: tg3 0000:03:00.1: eth1: 0x00005320: 0x00831824, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x00005330: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005340: 0x00000000, 0x00000000, 0x08002cb6, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005380: 0x00009800, 0x80004000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005390: 0x00000000, 0x00000000, 0x00000000, 0x08002068
kernel: tg3 0000:03:00.1: eth1: 0x000053a0: 0x8c434014, 0x00000000, 0x00000000, 0x40000020
kernel: tg3 0000:03:00.1: eth1: 0x000053b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000053c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005800: 0x03000000, 0x03000000, 0x0d000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005810: 0x07000000, 0x00000000, 0x0b000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005820: 0x04000000, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005860: 0x00000000, 0x00000000, 0x000000e8, 0x000000e8
kernel: tg3 0000:03:00.1: eth1: 0x00005880: 0x0000000c, 0x0000000c, 0x00000006, 0x00000006
kernel: tg3 0000:03:00.1: eth1: 0x00005890: 0x0000000a, 0x0000000a, 0x00000004, 0x00000004
kernel: tg3 0000:03:00.1: eth1: 0x00005900: 0x00000000, 0x00000000, 0x00000001, 0x00000001
kernel: tg3 0000:03:00.1: eth1: 0x00005980: 0x00000000, 0x00000001, 0x00000001, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00005a00: 0x000f601f, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006000: 0x00010082, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006400: 0x00000000, 0x00000000, 0x00010091, 0xc0000000
kernel: tg3 0000:03:00.1: eth1: 0x00006410: 0x0a000064, 0x0a000064, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006430: 0x00000000, 0x14e4165f, 0x165f14e4, 0x00020000
kernel: tg3 0000:03:00.1: eth1: 0x00006440: 0x0000304f, 0x000002e4, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000064c0: 0x00000010, 0x00000004, 0x00001004, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000064d0: 0x00000000, 0x10008d81, 0x00000000, 0x00315e22
kernel: tg3 0000:03:00.1: eth1: 0x000064e0: 0x00000031, 0x0000001f, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000064f0: 0x00000002, 0x00000031, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006500: 0x01e10003, 0xd0400c65, 0x00000014, 0x00000003
kernel: tg3 0000:03:00.1: eth1: 0x00006510: 0x0007811b, 0x00058116, 0x00046113, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006550: 0x00000000, 0x02800000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000065f0: 0x00000000, 0x00000109, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006800: 0x14130034, 0x20099082, 0x01000008, 0x00a16dd0
kernel: tg3 0000:03:00.1: eth1: 0x00006810: 0x01020000, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006830: 0xffffffff, 0xffffffff, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006840: 0x00000000, 0x00000001, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00006890: 0x00000000, 0x88003800, 0x00000000, 0x04102040
kernel: tg3 0000:03:00.1: eth1: 0x000068a0: 0x00000020, 0x00000001, 0x03ff03ff, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000068b0: 0xe0011514, 0x00000000, 0x00000000, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x000068f0: 0x00ff000e, 0x00ff0000, 0x00000000, 0x04444444
kernel: tg3 0000:03:00.1: eth1: 0x00006920: 0x00000000, 0x00000000, 0x00000001, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0x00007000: 0x00000008, 0x00000000, 0x00000000, 0x00004868
kernel: tg3 0000:03:00.1: eth1: 0x00007010: 0x1a5876c2, 0x01c080f3, 0x00d70081, 0x03008200
kernel: tg3 0000:03:00.1: eth1: 0x00007020: 0x00000000, 0x00000000, 0x00000406, 0x10004000
kernel: tg3 0000:03:00.1: eth1: 0x00007030: 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
kernel: tg3 0000:03:00.1: eth1: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(00f2:0000:0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 1: Host status block [00000001:00000013:(0000:0000:0000):(0012:0000)]
kernel: tg3 0000:03:00.1: eth1: 1: NAPI info [00000013:00000013:(0000:0000:01ff):0012:(0012:0012:0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 2: Host status block [00000001:00000007:(0006:0000:0000):(0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 2: NAPI info [00000007:00000007:(0001:0000:01ff):0006:(0006:0006:0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 3: Host status block [00000001:0000000b:(0000:0000:0000):(0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 3: NAPI info [0000000b:0000000b:(0001:0000:01ff):000a:(000a:000a:0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 4: Host status block [00000001:00000007:(0000:0000:0008):(0000:0000)]
kernel: tg3 0000:03:00.1: eth1: 4: NAPI info [00000007:00000007:(0000:0000:01ff):0008:(0008:0008:0000:0000)]
kernel: tg3 0000:03:00.1: eth1: Link is down
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 19
Region 0: Memory at bc140000 (64-bit, prefetchable) [size=64K]
Region 2: Memory at bc130000 (64-bit, prefetchable) [size=64K]
Region 4: Memory at bc120000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Product Name: Broadcom NetXtreme Gigabit Ethernet Controller
Read-only fields:
[PN] Part number: BCM95720
[EC] Engineering changes: 106679-15
[MN] Manufacture ID: 31 34 65 34
[RV] Reserved: checksum good, 28 byte(s) reserved
^ permalink raw reply
* Re: [PATCH net-next v2 0/10] bonding: rebuild the lock use for bond monitor
From: Ding Tianhong @ 2013-11-09 8:03 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D120E.3080706@redhat.com>
于 2013/11/9 0:32, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:07 AM, Ding Tianhong wrote:
>> Now the bond slave list is not protected by bond lock, only by RTNL,
>> but the monitor still use the bond lock to protect the slave list,
>> it is useless, according to the Veaceslav's opinion, there were
>> three way to fix the protect problem:
>>
>> 1. add bond_master_upper_dev_link() and bond_upper_dev_unlink()
>> in bond->lock, but it is unsafe to call call_netdevice_notifiers()
>> in write lock.
>> 2. remove unused bond->lock for monitor function, only use the exist
>> rtnl lock(), it will take performance loss in fast path.
>> 3. use RCU to protect the slave list, of course, performance is better,
>> but in slow path, it is ignored.
>>
>> obviously the solution 1 is not fit here, I will consider the 2 and 3
>> solution. My principle is simple, if in fast path, RCU is better,
>> otherwise in slow path, both is well, but according to the Jay Vosburgh's
>> opinion, the monitor will loss performace if use RTNL to protect the all
>> slave list, so remove the bond lock and replace with RCU.
>>
>> The second problem is the curr_slave_lock for bond, it is too old and
>> unwanted in many place, because the curr_active_slave would only be
>> changed in 3 place:
>>
>> 1. enslave slave.
>> 2. release slave.
>> 3. change active slave.
>>
>> all above were already holding bond lock, RTNL and curr_slave_lock
>> together, it is tedious and no need to add so mach lock, when change
>> the curr_active_slave, you have to hold the RTNL and curr_slave_lock
>> together, and when you read the curr_active_slave, RTNL or curr_slave_lock,
>> any one of them is no problem.
>>
>> for the stability, I did not change the logic for the monitor,
>> all change is clear and simple, I have test the patch set for lockdep,
>> it work well and stability.
>>
>> v2. accept the Jay Vosburgh's opinion, remove the RTNL and replace with RCU,
>> also add some rcu function for bond use, so the patch set reach 10.
>>
>> Best Regards
>> Ding Tianhong
>>
> Hi,
> I've left my comments from a quick overview of the patches, my opinion on the
> patchset is that it wasn't tested thoroughly enough (or at all). There're
> multiple places that use a weaker compiler barrier instead of directly using
> rcu_dereference() or rcu_access_pointer(), also there're multiple places which
> can directly use macros already present in the RCU API.
>
> Cheers,
> Nik
Thanks, Nik, for overview the long patches, point out the problem, I
will review the
details which your point out and fix it.
Best Regards
Ding
>
> --
> 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
* Re: [PATCH] can: add Renesas R-Car CAN driver
From: Wolfgang Grandegger @ 2013-11-09 10:53 UTC (permalink / raw)
To: Sergei Shtylyov, netdev, mkl, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <527D89A3.1070403@cogentembedded.com>
Hi Sergei,
On 11/09/2013 02:02 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 10/21/2013 11:12 PM, Wolfgang Grandegger wrote:
>
>>> Sorry for the belated reply -- was on vacations.
>
> And again sorry, couldn't get to this due to other things.
>
>>>> thanks for your contribution. The patch looks already quite good.
>>>> Before
>>>> I find time for a detailed review could you please check error handling
>>>> and bus-off recovery by reporting the output of "$ candump -td -e
>>>> any,0:0,#FFFFFFFF" while sending messages to the device ...
>
> [...]
>
>>> root@10.0.0.101:/opt/can-utils# ip -details link show can0
>>> 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>>> qlen 10 link/can
>>> can state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0
>>> bitrate 297619 sample-point 0.714
>
>> Strange, what bitrate did you configure?
>
> 300000.
Ah, OK. It's just a very unusual CAN bitrate. Common are 125k, 250k,
500kB, 800kB and 1 MBit/s. Is it your choice?
>>> tq 480 prop-seg 2 phase-seg1 2 phase-seg2 2 sjw 1
>>> rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
>>> clock 49999999
>
>> Could you please try if the algorithm works better with 50000000.
>
> It doesn't. Look at the logs below:
OK, I was mainly confused by the bitrate. Anyway, the bitrate algorithim
sometimes does not like exotic clock frequencies or bitrates. Then
manual setting of the bit-timing parameters might be necessary. But that
seem not the case here.
>>>> 2. ... with short-circuited CAN high and low and doing some time later
>>>> a manual recovery with "ip link set can0 type can restart"
>
>>> Now we have auto recovery only. Manual recovery was tested with the
>>> first driver version and worked.
>
>> What do you mean with "auto recovery"? Auto recovery by the hardware or
>> via "restart-ms <ms>"? How do you choose between "manual" and "auto"
>> recovery?
>
> This exact test was done with hardware auto-recovery only. No
> "restart-ms" was programmed.
OK, you already explained that in another mail and your driver does not
use/support hardware auto-recovery any longer.
>
>>> Terminal 1:
>
>>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@10.0.0.104:/opt/can-utils#
>
>>> Terminal 2:
>
>>> root@10.0.0.104:/opt/can-utils# ./candump -td -e any,0:0,#FFFFFFFF
>>> (000.000000) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> protocol-violation{{tx-dominant-bit-error}{}}
>>> bus-error
>>> (000.021147) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> bus-off
>>> restarted-after-bus-off
>
>> Why does it get "restarted" directly after the bus-off?
>
> Because we have hardware auto-recovery enabled.
>
>>> (011.738522) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>
>> What controller problem? data[1] is not set for some reasom.
>
> Not comments. Looking into it.
>
>>> protocol-violation{{tx-dominant-bit-error}{}}
>>> bus-error
>>> (000.021163) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> bus-off
>>> restarted-after-bus-off
>>> (001.666625) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> protocol-violation{{tx-dominant-bit-error}{}}
>>> bus-error
>>> (000.021157) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> bus-off
>>> restarted-after-bus-off
>
>>> dmesg:
>>> rcar_can rcar_can.0 can0: Error warning interrupt
>>> rcar_can rcar_can.0 can0: Error passive interrupt
>>> rcar_can rcar_can.0 can0: Bus error interrupt:
>>> rcar_can rcar_can.0 can0: Bit Error (dominant)
>>> rcar_can rcar_can.0 can0: Error warning interrupt
>>> rcar_can rcar_can.0 can0: Error passive interrupt
>
>> Why are they reported again. You are already in error passive.
>
> Don't know. :-/
The hardware might not be that smart. Then the software should care.
>>>> I also wonder if the messages are always sent in order. You could use
>>>> the program "canfdtest" [1] from the can-utils for validation.
>
>>> This program is PITA. With the driver workaroung it works:
>
>> What workaround?
>
> Doesn't matter already, got rid of it.
OK. BTW: I suggest to run "canfdtest" at *1* MB/s with additional system
and I/O load and for much longer than a minute to increase the
probability of an out-of-order transmissions to occur.
Wolfgang.
^ permalink raw reply
* Re: [patch net-next 1/2] ip6_output: fragment outgoing reassembled skb properly
From: Jiri Pirko @ 2013-11-09 11:00 UTC (permalink / raw)
To: David Miller
Cc: netdev, pablo, netfilter-devel, yoshfuji, kadlec, kaber, mleitner,
kuznet, jmorris, wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, fw
In-Reply-To: <20131108.144915.635810300359291522.davem@davemloft.net>
Fri, Nov 08, 2013 at 08:49:15PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Fri, 8 Nov 2013 08:52:01 +0100
>
>> Fri, Nov 08, 2013 at 12:54:53AM CET, davem@davemloft.net wrote:
>>>From: Jiri Pirko <jiri@resnulli.us>
>>>Date: Wed, 6 Nov 2013 17:52:19 +0100
>>>
>>>> If reassembled packet would fit into outdev MTU, it is not fragmented
>>>> according the original frag size and it is send as single big packet.
>>>>
>>>> The second case is if skb is gso. In that case fragmentation does not happen
>>>> according to the original frag size.
>>>>
>>>> This patch fixes these.
>>>>
>>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ...
>>>
>>>> if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) ||
>>>> - dst_allfrag(skb_dst(skb)))
>>>> + dst_allfrag(skb_dst(skb)) ||
>>>> + (IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size))
>>>> return ip6_fragment(skb, ip6_finish_output2);
>>>
>>>Jiri are you sure that you don't need to take GSO into account in the
>>>new part you are adding to the test?
>>
>>
>> For gso skb, we need co cap outgoing fragments by the original frag size
>> as well. So I believe that this code is correct for that case as well.
>
>I'm still not so sure I agree, even after having taken a second look
>at this.
>
>Look at ipv4's logic for this same facility:
>
> if (skb->len > ip_skb_dst_mtu(skb) && !skb_is_gso(skb))
> return ip_fragment(skb, ip_finish_output2);
>
>Strictly, we only call ip_fragment() if skb_is_gso() is false. And then
>in ip_fragment():
>
> if (unlikely(((iph->frag_off & htons(IP_DF)) && !skb->local_df) ||
> (IPCB(skb)->frag_max_size &&
> IPCB(skb)->frag_max_size > dst_mtu(&rt->dst)))) {
>
>And that second branch of this test is what you're trying to duplicate
>into ipv6.
That is a different check and the same one is already in ip6_fragment().
You cannot compare this to ipv4 directly. In ipv4 if frag skbs are
reassembled into one, they can be forwarded out in different frag sizes
(bigger or smaller) or not in frags at all. Therefore you can lay off
the work to offload.
But for ipv6, the same frags need to go out as they came in. Offload would
not do that as it would try to max the flag sizes to the MTU ->
That is exactly why I add the "skb->len > IP6CB(skb)->frag_max_size" check.
Imagine scenario:
hostA-NIC(MTU1400) ------ NIC(MTU1400)-hostB-NIC(MTU1500) ------ NIC(MTU1500)-hostC
And fragmented packets go hostA->hostB->hostC, and we are doing
forwadring on hostB.
I hope I cleared this out.
^ permalink raw reply
* [net 1/2] igb: Update link modes display in ethtool
From: Jeff Kirsher @ 2013-11-09 12:52 UTC (permalink / raw)
To: davem; +Cc: Carolyn Wyborny, netdev, gospo, sassmann, Jeff Kirsher
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
This patch fixes multiple problems in the link modes display in ethtool.
Newer parts have more complicated methods to determine actual link
capabilities. Older parts cannot communicate with their SFP modules.
Finally, all the available defines are not displayed by ethtool. This
updates the link modes to be as accurate as possible depending on what data
is available to the driver at any given time.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 51 +++++++++++++++-------------
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 151e00c..430b12f 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -146,6 +146,7 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
struct e1000_sfp_flags *eth_flags = &dev_spec->eth_flags;
u32 status;
+ status = rd32(E1000_STATUS);
if (hw->phy.media_type == e1000_media_type_copper) {
ecmd->supported = (SUPPORTED_10baseT_Half |
@@ -169,13 +170,22 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
ecmd->transceiver = XCVR_INTERNAL;
} else {
ecmd->supported = (SUPPORTED_FIBRE |
+ SUPPORTED_1000baseKX_Full |
SUPPORTED_Autoneg |
SUPPORTED_Pause);
- ecmd->advertising = ADVERTISED_FIBRE;
-
- if ((eth_flags->e1000_base_lx) || (eth_flags->e1000_base_sx)) {
- ecmd->supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ ecmd->advertising = (ADVERTISED_FIBRE |
+ ADVERTISED_1000baseKX_Full);
+ if (hw->mac.type == e1000_i354) {
+ if ((hw->device_id ==
+ E1000_DEV_ID_I354_BACKPLANE_2_5GBPS) &&
+ !(status & E1000_STATUS_2P5_SKU_OVER)) {
+ ecmd->supported |= SUPPORTED_2500baseX_Full;
+ ecmd->supported &=
+ ~SUPPORTED_1000baseKX_Full;
+ ecmd->advertising |= ADVERTISED_2500baseX_Full;
+ ecmd->advertising &=
+ ~ADVERTISED_1000baseKX_Full;
+ }
}
if (eth_flags->e100_base_fx) {
ecmd->supported |= SUPPORTED_100baseT_Full;
@@ -187,35 +197,29 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
ecmd->port = PORT_FIBRE;
ecmd->transceiver = XCVR_EXTERNAL;
}
-
if (hw->mac.autoneg != 1)
ecmd->advertising &= ~(ADVERTISED_Pause |
ADVERTISED_Asym_Pause);
- if (hw->fc.requested_mode == e1000_fc_full)
+ switch (hw->fc.requested_mode) {
+ case e1000_fc_full:
ecmd->advertising |= ADVERTISED_Pause;
- else if (hw->fc.requested_mode == e1000_fc_rx_pause)
+ break;
+ case e1000_fc_rx_pause:
ecmd->advertising |= (ADVERTISED_Pause |
ADVERTISED_Asym_Pause);
- else if (hw->fc.requested_mode == e1000_fc_tx_pause)
+ break;
+ case e1000_fc_tx_pause:
ecmd->advertising |= ADVERTISED_Asym_Pause;
- else
+ break;
+ default:
ecmd->advertising &= ~(ADVERTISED_Pause |
ADVERTISED_Asym_Pause);
-
- status = rd32(E1000_STATUS);
-
+ }
if (status & E1000_STATUS_LU) {
- if (hw->mac.type == e1000_i354) {
- if ((status & E1000_STATUS_2P5_SKU) &&
- !(status & E1000_STATUS_2P5_SKU_OVER)) {
- ecmd->supported = SUPPORTED_2500baseX_Full;
- ecmd->advertising = ADVERTISED_2500baseX_Full;
- ecmd->speed = SPEED_2500;
- } else {
- ecmd->supported = SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_1000baseT_Full;
- }
+ if ((status & E1000_STATUS_2P5_SKU) &&
+ !(status & E1000_STATUS_2P5_SKU_OVER)) {
+ ecmd->speed = SPEED_2500;
} else if (status & E1000_STATUS_SPEED_1000) {
ecmd->speed = SPEED_1000;
} else if (status & E1000_STATUS_SPEED_100) {
@@ -232,7 +236,6 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
ecmd->speed = -1;
ecmd->duplex = -1;
}
-
if ((hw->phy.media_type == e1000_media_type_fiber) ||
hw->mac.autoneg)
ecmd->autoneg = AUTONEG_ENABLE;
--
1.8.3.1
^ permalink raw reply related
* [net 2/2] ixgbe: add warning when max_vfs is out of range.
From: Jeff Kirsher @ 2013-11-09 12:52 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, gospo, sassmann, Jeff Kirsher
From: Jacob Keller <jacob.e.keller@intel.com>
The max_vfs parameter has a limit of 63 and silently fails (adding 0 vfs) when
it is out of range. This patch adds a warning so that the user knows something
went wrong. Also, this patch moves the warning in ixgbe_enable_sriov() to where
max_vfs is checked, so that even an out of range value will show the deprecated
warning. Previously, an out of range parameter didn't even warn the user to use
the new sysfs interface instead.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 ----
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0ade0cd..2767cf2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -132,7 +132,7 @@ static struct notifier_block dca_notifier = {
static unsigned int max_vfs;
module_param(max_vfs, uint, 0);
MODULE_PARM_DESC(max_vfs,
- "Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63");
+ "Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63. (Deprecated)");
#endif /* CONFIG_PCI_IOV */
static unsigned int allow_unsupported_sfp;
@@ -4816,11 +4816,20 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
hw->fc.disable_fc_autoneg = ixgbe_device_supports_autoneg_fc(hw);
#ifdef CONFIG_PCI_IOV
+ if (max_vfs > 0)
+ e_dev_warn("Enabling SR-IOV VFs using the max_vfs module parameter is deprecated - please use the pci sysfs interface instead.\n");
+
/* assign number of SR-IOV VFs */
- if (hw->mac.type != ixgbe_mac_82598EB)
- adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
+ if (hw->mac.type != ixgbe_mac_82598EB) {
+ if (max_vfs > 63) {
+ adapter->num_vfs = 0;
+ e_dev_warn("max_vfs parameter out of range. Not assigning any SR-IOV VFs\n");
+ } else {
+ adapter->num_vfs = max_vfs;
+ }
+ }
+#endif /* CONFIG_PCI_IOV */
-#endif
/* enable itr by default in dynamic mode */
adapter->rx_itr_setting = 1;
adapter->tx_itr_setting = 1;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 276d7b1..9e0c9c7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -129,10 +129,6 @@ void ixgbe_enable_sriov(struct ixgbe_adapter *adapter)
if (!pre_existing_vfs && !adapter->num_vfs)
return;
- if (!pre_existing_vfs)
- dev_warn(&adapter->pdev->dev,
- "Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface.\n");
-
/* If there are pre-existing VFs then we have to force
* use of that many - over ride any module parameter value.
* This may result from the user unloading the PF driver
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] netlink: fix netlink_ack with large messages
From: Jamal Hadi Salim @ 2013-11-09 13:43 UTC (permalink / raw)
To: David Miller, tgraf; +Cc: jbenc, netdev, pablo
In-Reply-To: <20131109.000012.1393414533296613338.davem@davemloft.net>
On 11/09/13 00:00, David Miller wrote:
> The user has the message, they gave it to us in the sendmsg()
> we are responding to. We absolutely do not need to give it
> to them again.
>
> If they care about referring to the contents of that message, they can
> refer to it in their own copy and make sure they are really looking at
> the same thing by comparing the sequence number in the netlink ACK to
> the one they used in the netlink header they gave to the kernel in the
> sendmsg() call.
>
> What happens now is pure duplication, and for such huge netlink
> messages it's really not smart at all.
>
for errors, we need to give the user something back. This has been the
behavior for 80 years now. Giving them a HUGE message
back is rediculuos(tm). Ive had enough of SCTP doing that.
We need to cap it - sort of what ICMP does.
ICMP caps at 64B; something like 128B is reasonable.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v2 2/10] bonding: rebuild the lock use for bond_mii_monitor()
From: Ding Tianhong @ 2013-11-09 13:51 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D0303.8030806@redhat.com>
于 2013/11/8 23:28, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:07 AM, Ding Tianhong wrote:
> In fact the bond cannot disappear while this function is running, so this test
> should be able to run outside the RCU region if I'm not missing something :-)
> It'll be just as useful as running inside the region, at most a free run may
> happen if there's one slave and it disappears.
>
>
> This is unnecessary, bond_has_slaves() should be enough. See bond_start_xmit()
> and also the list_empty comment in include/linux/rculist.h for more information why.
> My bond_has_slaves() comments apply to all the patches that use it.
>
>
yes, you are right, I make a silly mistake, the bond list itself is no
need to copy, it
dose not occur any problem if it be changed.
The curr_active_slave needs copy for peer, as it may be changed at
monitor running.
Regards.
Ding
> --
> 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
* Re: [PATCH net-next v2 7/10] bonding: rebuild the lock use for bond_3ad_state_machine_handler()
From: Ding Tianhong @ 2013-11-09 13:54 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D0692.8000401@redhat.com>
于 2013/11/8 23:43, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:08 AM, Ding Tianhong wrote:
>> The bond_3ad_state_machine_handler() use the bond lock to protect
>> the bond slave list and slave port, so as the before patch said,
>> I remove bond lock and replace with RCU.
>>
>> The nots in the function is still too old, clean up the nots.
>>
>> Suggested-by: Jay Vosburgh <fubar@us.ibm.com>
>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_3ad.c | 21 ++++++++++-----------
>> 1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>> index 187b1b7..09edccf61 100644
>> --- a/drivers/net/bonding/bond_3ad.c
>> +++ b/drivers/net/bonding/bond_3ad.c
>> @@ -2068,18 +2068,18 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
>> struct slave *slave;
>> struct port *port;
>>
>> - read_lock(&bond->lock);
>> + rcu_read_lock();
>>
>> - //check if there are any slaves
>> - if (!bond_has_slaves(bond))
>> + /* check if there are any slaves */
>> + if (!bond_has_slaves_rcu(bond))
>> goto re_arm;
>>
>> - // check if agg_select_timer timer after initialize is timed out
>> + /* check if agg_select_timer timer after initialize is timed out */
>> if (BOND_AD_INFO(bond).agg_select_timer && !(--BOND_AD_INFO(bond).agg_select_timer)) {
>> - slave = bond_first_slave(bond);
>> + slave = bond_first_slave_rcu(bond);
>> port = slave ? &(SLAVE_AD_INFO(slave).port) : NULL;
>>
>> - // select the active aggregator for the bond
>> + /* select the active aggregator for the bond */
>> if (port) {
>> if (!port->slave) {
>> pr_warning("%s: Warning: bond's first port is uninitialized\n",
> This continues to execute:
> aggregator = __get_first_agg(port);
> ad_agg_selection_logic(aggregator)
> And neither ad_agg_selection_logic nor __get_first_agg are RCU-safe.
>
yes, I miss it, thanks a lot.
Regards.
Ding
> --
> 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
* Re: [PATCH net-next v2 6/10] bonding: rebuild the lock use for bond_activebackup_arp_mon()
From: Ding Tianhong @ 2013-11-09 14:08 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D0AEF.1060802@redhat.com>
于 2013/11/9 0:01, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:08 AM, Ding Tianhong wrote:
>> The bond_activebackup_arp_mon() use the bond lock for read to
>> protect the slave list, it is no effect, and the RTNL is only
>> called for bond_ab_arp_commit() and peer notify, for the performance
>> better, use RCU instead of the bond lock, because the bond slave
>> list need to called in RCU, add a new bond_first_slave_rcu()
>> to get the first slave in RCU protection.
>>
>> When bond_ab_arp_inspect() and should_notify_peers is true, the
>> RTNL will called twice, it is a loss of performance, so make the
>> two RTNL together to avoid performance loss.
>>
>> Suggested-by: Jay Vosburgh <fubar@us.ibm.com>
>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_main.c | 35 +++++++++++++++++++----------------
>> drivers/net/bonding/bonding.h | 7 +++++++
>> 2 files changed, 26 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 759dcd0..b48ca55 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -2524,7 +2524,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
>> struct slave *slave;
>> int commit = 0;
>>
>> - bond_for_each_slave(bond, slave, iter) {
>> + bond_for_each_slave_rcu(bond, slave, iter) {
>> slave->new_link = BOND_LINK_NOCHANGE;
>> last_rx = slave_last_rx(bond, slave);
>>
>> @@ -2586,7 +2586,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
>> * Called to commit link state changes noted by inspection step of
>> * active-backup mode ARP monitor.
>> *
>> - * Called with RTNL and bond->lock for read.
>> + * Called with RTNL hold.
>> */
>> static void bond_ab_arp_commit(struct bonding *bond)
>> {
>> @@ -2661,7 +2661,7 @@ do_failover:
>> /*
>> * Send ARP probes for active-backup mode ARP monitor.
>> *
>> - * Called with bond->lock held for read.
>> + * Called with rcu_read_lock hold.
>> */
>> static void bond_ab_arp_probe(struct bonding *bond)
>> {
>> @@ -2690,14 +2690,14 @@ static void bond_ab_arp_probe(struct bonding *bond)
>> */
>>
>> if (!bond->current_arp_slave) {
>> - bond->current_arp_slave = bond_first_slave(bond);
>> + bond->current_arp_slave = bond_first_slave_rcu(bond);
>> if (!bond->current_arp_slave)
>> return;
>> }
>>
>> bond_set_slave_inactive_flags(bond->current_arp_slave);
>>
>> - bond_for_each_slave(bond, slave, iter) {
>> + bond_for_each_slave_rcu(bond, slave, iter) {
>> if (!found && !before && IS_UP(slave->dev))
>> before = slave;
>>
>> @@ -2745,43 +2745,46 @@ void bond_activebackup_arp_mon(struct work_struct *work)
>> bool should_notify_peers = false;
>> int delta_in_ticks;
>>
>> - read_lock(&bond->lock);
>> -
>> delta_in_ticks = msecs_to_jiffies(bond->params.arp_interval);
>>
>> - if (!bond_has_slaves(bond))
>> + rcu_read_lock();
>> +
>> + if (!bond_has_slaves_rcu(bond)) {
>> + rcu_read_unlock();
>> goto re_arm;
>> + }
>>
>> should_notify_peers = bond_should_notify_peers(bond);
> Again, bond_should_notify_peers() is not RCU-safe.
yes.
>>
>> if (bond_ab_arp_inspect(bond)) {
>> - read_unlock(&bond->lock);
>> + rcu_read_unlock();
>>
>> /* Race avoidance with bond_close flush of workqueue */
>> if (!rtnl_trylock()) {
>> - read_lock(&bond->lock);
>> delta_in_ticks = 1;
>> should_notify_peers = false;
>> goto re_arm;
>> }
>>
>> - read_lock(&bond->lock);
>> -
>> bond_ab_arp_commit(bond);
>>
>> - read_unlock(&bond->lock);
>> + if (should_notify_peers) {
>> + call_netdevice_notifiers(NETDEV_NOTIFY_PEERS,
>> + bond->dev);
>> + should_notify_peers = false;
>> + }
>> +
>> rtnl_unlock();
>> - read_lock(&bond->lock);
>> + rcu_read_lock();
>> }
>>
>> bond_ab_arp_probe(bond);
> Generally you might be safe in bond_ab_arp_probe() due to the synchronization
> done by netdev_rx_handler_unregister(), but this code may run after that (and
> after the unlinked slave) but before current_arp_slave is set to NULL and thus
> use it. Now I don't see a direct problem with that, only a complication that can
> bite us later. I vaguely remember that I re-worked the bond_ab_arp_probe() and
> the way current_arp_slave works when doing this transition in my patches.
maybe I miss the patch, pls send me the commit and I will check it again.
>> + rcu_read_unlock();
>>
>> re_arm:
>> if (bond->params.arp_interval)
>> queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
>>
>> - read_unlock(&bond->lock);
>> -
>> if (should_notify_peers) {
>> if (!rtnl_trylock())
>> return;
>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>> index deb9738..90b745c 100644
>> --- a/drivers/net/bonding/bonding.h
>> +++ b/drivers/net/bonding/bonding.h
>> @@ -97,6 +97,13 @@
>> netdev_adjacent_get_private(bond_slave_list(bond)->prev) : \
>> NULL)
>>
>> +#define bond_first_slave_rcu(bond) \
>> + ({struct list_head *__ptr = (bond_slave_list(bond)); \
>> + struct list_head *__next = ACCESS_ONCE(__ptr->next); \
>> + likely(__ptr != __next) ? \
>> + netdev_adjacent_get_private_rcu(__next) : NULL; \
>> + })
>> +
> Honestly, I don't like this, it sure can be re-written in a more
> straight-forward manner.
ok, I will re-write it and make it more comfortable.
Regards.
Ding
>> #define bond_is_first_slave(bond, pos) (pos == bond_first_slave(bond))
>> #define bond_is_last_slave(bond, pos) (pos == bond_last_slave(bond))
>>
>>
> --
> 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
* Re: [PATCH net-next v2 3/10] bonding: rebuild the lock use for bond_alb_monitor()
From: Ding Tianhong @ 2013-11-09 14:15 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D0C42.3010402@redhat.com>
于 2013/11/9 0:07, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:07 AM, Ding Tianhong wrote:
>> The bond_alb_monitor use bond lock to protect the bond slave list,
>> it is no effect here, we need to use RTNL or RCU to replace bond lock,
>> the bond_alb_monitor will called 10 times one second, RTNL may loss
>> performance here, so the bond lock replace with RCU to protect the
>> bond slave list, also the RTNL is preserved, the logic of the monitor
>> did not changed.
>>
>> Suggested-by: Jay Vosburgh <fubar@us.ibm.com>
>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_alb.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>> index 1fae915..ffdb91b 100644
>> --- a/drivers/net/bonding/bond_alb.c
>> +++ b/drivers/net/bonding/bond_alb.c
>> @@ -816,7 +816,7 @@ static void rlb_rebalance(struct bonding *bond)
>> for (; hash_index != RLB_NULL_INDEX;
>> hash_index = client_info->used_next) {
>> client_info = &(bond_info->rx_hashtbl[hash_index]);
>> - assigned_slave = rlb_next_rx_slave(bond);
>> + assigned_slave = __rlb_next_rx_slave(bond);
>> if (assigned_slave && (client_info->slave != assigned_slave)) {
>> client_info->slave = assigned_slave;
>> client_info->ntt = 1;
>> @@ -1495,9 +1495,10 @@ void bond_alb_monitor(struct work_struct *work)
>> struct list_head *iter;
>> struct slave *slave;
>>
>> - read_lock(&bond->lock);
>> + rcu_read_lock();
>>
>> - if (!bond_has_slaves(bond)) {
>> + if (!bond_has_slaves_rcu(bond)) {
>> + rcu_read_unlock();
>> bond_info->tx_rebalance_counter = 0;
>> bond_info->lp_counter = 0;
>> goto re_arm;
> If I'm not mistaken there's one more bond_for_each_slave() inside this function
> which should be converted to RCU.
But I really could not find any place should converted to RCU,
__rlb_next_rx_slave() is in RCU yet.
pls remind me if I miss something.
Regards
Ding
>> @@ -1528,7 +1529,7 @@ void bond_alb_monitor(struct work_struct *work)
>>
>> read_lock(&bond->curr_slave_lock);
>>
>> - bond_for_each_slave(bond, slave, iter) {
>> + bond_for_each_slave_rcu(bond, slave, iter) {
>> tlb_clear_slave(bond, slave, 1);
>> if (slave == bond->curr_active_slave) {
>> SLAVE_TLB_INFO(slave).load =
>> @@ -1552,11 +1553,9 @@ void bond_alb_monitor(struct work_struct *work)
>> * dev_set_promiscuity requires rtnl and
>> * nothing else. Avoid race with bond_close.
>> */
>> - read_unlock(&bond->lock);
>> - if (!rtnl_trylock()) {
>> - read_lock(&bond->lock);
>> + rcu_read_unlock();
>> + if (!rtnl_trylock())
>> goto re_arm;
>> - }
>>
>> bond_info->rlb_promisc_timeout_counter = 0;
>>
>> @@ -1568,7 +1567,7 @@ void bond_alb_monitor(struct work_struct *work)
>> bond_info->primary_is_promisc = 0;
>>
>> rtnl_unlock();
>> - read_lock(&bond->lock);
>> + rcu_read_lock();
>> }
>>
>> if (bond_info->rlb_rebalance) {
>> @@ -1590,11 +1589,9 @@ void bond_alb_monitor(struct work_struct *work)
>> }
>> }
>> }
>> -
>> + rcu_read_unlock();
>> re_arm:
>> queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
>> -
>> - read_unlock(&bond->lock);
>> }
>>
>> /* assumption: called before the slave is attached to the bond
>>
> --
> 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
* Re: [PATCH net-next v2 9/10] bonding: remvoe unwanted lock for bond enslave and release
From: Ding Tianhong @ 2013-11-09 14:15 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527D1C47.4040008@redhat.com>
于 2013/11/9 1:15, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:08 AM, Ding Tianhong wrote:
>> The bond_change_active_slave() and bond_select_active_slave()
>> do't need bond lock anymore, so remove the unwanted bond lock
>> for these two functions.
>>
>> The bond_select_active_slave() will release and acquire
>> curr_slave_lock, so the curr_slave_lock need to protect
>> the function.
>>
>> In bond enslave and bond release, the bond slave list is also
>> protected by RTNL, so bond lock is no need to exist, remove
>> the lock and clean the functions.
>>
>> Suggested-by: Jay Vosburgh <fubar@us.ibm.com>
>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
> Small nitpick about the subject:
> "remvoe" -> "remove"
:-)
>
> --
> 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
* Re: [PATCH net-next v2 3/10] bonding: rebuild the lock use for bond_alb_monitor()
From: Nikolay Aleksandrov @ 2013-11-09 14:30 UTC (permalink / raw)
To: Ding Tianhong
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Veaceslav Falico, Netdev
In-Reply-To: <527E4365.6060107@gmail.com>
On 11/09/2013 03:15 PM, Ding Tianhong wrote:
> 于 2013/11/9 0:07, Nikolay Aleksandrov 写道:
>> On 11/08/2013 03:07 AM, Ding Tianhong wrote:
>>> The bond_alb_monitor use bond lock to protect the bond slave list,
>>> it is no effect here, we need to use RTNL or RCU to replace bond lock,
>>> the bond_alb_monitor will called 10 times one second, RTNL may loss
>>> performance here, so the bond lock replace with RCU to protect the
>>> bond slave list, also the RTNL is preserved, the logic of the monitor
>>> did not changed.
>>>
>>> Suggested-by: Jay Vosburgh <fubar@us.ibm.com>
>>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>> ---
>>> drivers/net/bonding/bond_alb.c | 21 +++++++++------------
>>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_alb.c
>>> b/drivers/net/bonding/bond_alb.c
>>> index 1fae915..ffdb91b 100644
>>> --- a/drivers/net/bonding/bond_alb.c
>>> +++ b/drivers/net/bonding/bond_alb.c
>>> @@ -816,7 +816,7 @@ static void rlb_rebalance(struct bonding *bond)
>>> for (; hash_index != RLB_NULL_INDEX;
>>> hash_index = client_info->used_next) {
>>> client_info = &(bond_info->rx_hashtbl[hash_index]);
>>> - assigned_slave = rlb_next_rx_slave(bond);
>>> + assigned_slave = __rlb_next_rx_slave(bond);
>>> if (assigned_slave && (client_info->slave != assigned_slave)) {
>>> client_info->slave = assigned_slave;
>>> client_info->ntt = 1;
>>> @@ -1495,9 +1495,10 @@ void bond_alb_monitor(struct work_struct *work)
>>> struct list_head *iter;
>>> struct slave *slave;
>>> - read_lock(&bond->lock);
>>> + rcu_read_lock();
>>> - if (!bond_has_slaves(bond)) {
>>> + if (!bond_has_slaves_rcu(bond)) {
>>> + rcu_read_unlock();
>>> bond_info->tx_rebalance_counter = 0;
>>> bond_info->lp_counter = 0;
>>> goto re_arm;
>> If I'm not mistaken there's one more bond_for_each_slave() inside this
>> function
>> which should be converted to RCU.
>
> But I really could not find any place should converted to RCU,
>
> __rlb_next_rx_slave() is in RCU yet.
>
> pls remind me if I miss something.
>
> Regards
> Ding
>
>
I was talking about this piece of code inside bond_alb_monitor():
/* send learning packets */
if (bond_info->lp_counter >= BOND_ALB_LP_TICKS(bond)) {
/* change of curr_active_slave involves swapping of mac
addresses.
* in order to avoid this swapping from happening while
* sending the learning packets, the curr_slave_lock must
be held for
* read.
*/
read_lock(&bond->curr_slave_lock);
bond_for_each_slave(bond, slave, iter)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
alb_send_learning_packets(slave, slave->dev->dev_addr);
read_unlock(&bond->curr_slave_lock);
bond_info->lp_counter = 0;
}
This is copied after your patch-set was applied.
Cheers,
Nik
>>> @@ -1528,7 +1529,7 @@ void bond_alb_monitor(struct work_struct *work)
>>> read_lock(&bond->curr_slave_lock);
>>> - bond_for_each_slave(bond, slave, iter) {
>>> + bond_for_each_slave_rcu(bond, slave, iter) {
>>> tlb_clear_slave(bond, slave, 1);
>>> if (slave == bond->curr_active_slave) {
>>> SLAVE_TLB_INFO(slave).load =
>>> @@ -1552,11 +1553,9 @@ void bond_alb_monitor(struct work_struct *work)
>>> * dev_set_promiscuity requires rtnl and
>>> * nothing else. Avoid race with bond_close.
>>> */
>>> - read_unlock(&bond->lock);
>>> - if (!rtnl_trylock()) {
>>> - read_lock(&bond->lock);
>>> + rcu_read_unlock();
>>> + if (!rtnl_trylock())
>>> goto re_arm;
>>> - }
>>> bond_info->rlb_promisc_timeout_counter = 0;
>>> @@ -1568,7 +1567,7 @@ void bond_alb_monitor(struct work_struct *work)
>>> bond_info->primary_is_promisc = 0;
>>> rtnl_unlock();
>>> - read_lock(&bond->lock);
>>> + rcu_read_lock();
>>> }
>>> if (bond_info->rlb_rebalance) {
>>> @@ -1590,11 +1589,9 @@ void bond_alb_monitor(struct work_struct *work)
>>> }
>>> }
>>> }
>>> -
>>> + rcu_read_unlock();
>>> re_arm:
>>> queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
>>> -
>>> - read_unlock(&bond->lock);
>>> }
>>> /* assumption: called before the slave is attached to the bond
>>>
>> --
>> 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
>>
>
> --
> 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