* [PATCH 3/3] can: c_can: fix calculation of transmitted bytes on tx complete
From: Marc Kleine-Budde @ 2013-11-25 20:56 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Holger Bechtold, Marc Kleine-Budde
In-Reply-To: <1385412987-31205-1-git-send-email-mkl@pengutronix.de>
From: Holger Bechtold <Holger.Bechtold@gmx.net>
The number of bytes transmitted was not updated correctly, if several CAN
messages (with different length) were transmitted in one 'bunch'. Thus
programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that
the message object whose DLC is to be read was not necessarily the active one
at the time when
priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK;
was executed.
Signed-off-by: Holger Bechtold <Holger.Bechtold@gmx.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e59c42b..77061ee 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -763,6 +763,7 @@ static void c_can_do_tx(struct net_device *dev)
if (!(val & (1 << (msg_obj_no - 1)))) {
can_get_echo_skb(dev,
msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
+ c_can_object_get(dev, 0, msg_obj_no, IF_COMM_ALL);
stats->tx_bytes += priv->read_reg(priv,
C_CAN_IFACE(MSGCTRL_REG, 0))
& IF_MCONT_DLC_MASK;
--
1.8.5.rc0
^ permalink raw reply related
* [PATCH 1/3] can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
From: Marc Kleine-Budde @ 2013-11-25 20:56 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Oliver Hartkopp, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1385412987-31205-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
This patch fixes the issue that the sja1000_interrupt() function may have
returned IRQ_NONE without processing the optional pre_irq() and post_irq()
function before. Further the irq processing counter 'n' is moved to the end of
the while statement to return correct IRQ_[NONE|HANDLED] values at error
conditions.
Reported-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/sja1000.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 7164a99..f17c301 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -494,20 +494,20 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
uint8_t isrc, status;
int n = 0;
- /* Shared interrupts and IRQ off? */
- if (priv->read_reg(priv, SJA1000_IER) == IRQ_OFF)
- return IRQ_NONE;
-
if (priv->pre_irq)
priv->pre_irq(priv);
+ /* Shared interrupts and IRQ off? */
+ if (priv->read_reg(priv, SJA1000_IER) == IRQ_OFF)
+ goto out;
+
while ((isrc = priv->read_reg(priv, SJA1000_IR)) &&
(n < SJA1000_MAX_IRQ)) {
- n++;
+
status = priv->read_reg(priv, SJA1000_SR);
/* check for absent controller due to hw unplug */
if (status == 0xFF && sja1000_is_absent(priv))
- return IRQ_NONE;
+ goto out;
if (isrc & IRQ_WUI)
netdev_warn(dev, "wakeup interrupt\n");
@@ -535,7 +535,7 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
status = priv->read_reg(priv, SJA1000_SR);
/* check for absent controller */
if (status == 0xFF && sja1000_is_absent(priv))
- return IRQ_NONE;
+ goto out;
}
}
if (isrc & (IRQ_DOI | IRQ_EI | IRQ_BEI | IRQ_EPI | IRQ_ALI)) {
@@ -543,8 +543,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
if (sja1000_err(dev, isrc, status))
break;
}
+ n++;
}
-
+out:
if (priv->post_irq)
priv->post_irq(priv);
--
1.8.5.rc0
^ permalink raw reply related
* Re: request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: Greg KH @ 2013-11-25 21:05 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: stable, linux-can@vger.kernel.org, kernel@pengutronix.de,
Holger.Bechtold, Linux Netdev List
In-Reply-To: <52928480.8010803@pengutronix.de>
On Sun, Nov 24, 2013 at 11:58:08PM +0100, Marc Kleine-Budde wrote:
> Hello Greg,
>
> can you please queue
>
> 5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB
>
> for the stable trees.
>
> This patch was part of a two-patches pull request to David's net/master
> tree, which was merged in:
>
> e9b51a1 Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can
>
> One patch has already been queued, the other not.
It was part of my "to-apply" queue. It's now applied, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next 6/8] openvswitch: Allow update of dp with OVS_DP_CMD_NEW if NLM_F_REPLACE is set
From: Jesse Gross @ 2013-11-25 21:23 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
fleitner-H+wXaHxf7aLQT0dZR+AlfA, Eric Dumazet, netdev,
Ben Hutchings, David Miller
In-Reply-To: <2b77b94f043dbed36a08dcc0a876830d6ad1a97a.1385137618.git.tgraf-G/eBtMaohhA@public.gmane.org>
On Fri, Nov 22, 2013 at 8:56 AM, Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org> wrote:
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 95d4424..3f1fb87 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
I'm a little worried that this introduces some quirks to the interface. Such as:
> @@ -1190,6 +1185,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
> struct vport *vport;
> struct ovs_net *ovs_net;
> int err, i;
> + bool allocated = false;
>
> err = -EINVAL;
> if (!a[OVS_DP_ATTR_NAME] || !a[OVS_DP_ATTR_UPCALL_PID])
This requires that DP_CMD_SET supply an OVS_DP_ATTR_UPCALL_PID
although I don't think that it's really necessary. In fact, we used to
completely ignore that field on SET since it's really only useful on
datapath creation and can otherwise be done more naturally through the
vport interface.
> @@ -1197,11 +1193,26 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
>
> ovs_lock();
>
> + dp = lookup_datapath(sock_net(skb->sk), info->userhdr, info->attrs);
> + if (!IS_ERR(dp)) {
> + if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE)
> + goto update;
Conversely, this won't respect the UPCALL_PID field, which I would
expect it to since I think NLM_F_REPLACE should be roughly equivalent
to a delete and create. I believe that's the only field that is
missing although it seems easy to have the same problem as others are
added in the future.
^ permalink raw reply
* Re: netfilter: ipset: fix incorret comparison in hash_netnet4_data_equal()
From: Pablo Neira Ayuso @ 2013-11-25 21:45 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, oliver, netfilter-devel
In-Reply-To: <20131114154101.GA22625@redhat.com>
On Thu, Nov 14, 2013 at 10:41:01AM -0500, Dave Jones wrote:
> Both sides of the comparison are the same, looks like a cut-and-paste error.
>
> Spotted by Coverity.
Applied, thanks Dave.
Please, cc netfilter-devel for netfilter patches next time.
^ permalink raw reply
* Re: [ovs-dev] [PATCH openvswitch] netlink: Implement & enable memory mapped netlink i/o
From: Ben Pfaff @ 2013-11-25 23:02 UTC (permalink / raw)
To: Thomas Graf; +Cc: jesse, dev, fleitner, netdev
In-Reply-To: <2336aeee25d64eab89302c28c33b7cb7d1a55560.1385057738.git.tgraf@redhat.com>
On Thu, Nov 21, 2013 at 07:16:54PM +0100, Thomas Graf wrote:
> Based on the initial patch by Cong Wang posted a couple of months
> ago.
>
> This is the user space counterpart needed for the kernel patch
> '[PATCH net-next 3/8] openvswitch: Enable memory mapped Netlink i/o'
>
> Allows the kernel to construct Netlink messages on memory mapped
> buffers and thus avoids copying. The functionality is enabled on
> sockets used for unicast traffic.
>
> Further optimizations are possible by avoiding the copy into the
> ofpbuf after reading.
>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> Signed-off-by: Thomas Graf <tgraf@redhat.com>
Does this depend on other patches or some specific Linux kernel
headers? It doesn't build here on GCC (similar results with Clang):
../lib/netlink-socket.c: In function 'nl_sock_set_ring':
../lib/netlink-socket.c:101:12: error: variable 'req' has initializer but incomplete type
../lib/netlink-socket.c:102:9: error: unknown field 'nm_block_size' specified in initializer
../lib/netlink-socket.c:102:9: error: excess elements in struct initializer [-Werror]
../lib/netlink-socket.c:102:9: error: (near initialization for 'req') [-Werror]
../lib/netlink-socket.c:103:9: error: unknown field 'nm_block_nr' specified in initializer
../lib/netlink-socket.c:103:9: error: excess elements in struct initializer [-Werror]
../lib/netlink-socket.c:103:9: error: (near initialization for 'req') [-Werror]
../lib/netlink-socket.c:104:9: error: unknown field 'nm_frame_size' specified in initializer
../lib/netlink-socket.c:104:9: error: excess elements in struct initializer [-Werror]
../lib/netlink-socket.c:104:9: error: (near initialization for 'req') [-Werror]
../lib/netlink-socket.c:101:24: error: storage size of 'req' isn't known
../lib/netlink-socket.c:109:43: error: 'NETLINK_RX_RING' undeclared (first use in this function)
../lib/netlink-socket.c:109:43: note: each undeclared identifier is reported only once for each function it appears in
../lib/netlink-socket.c:110:46: error: 'NETLINK_TX_RING' undeclared (first use in this function)
../lib/netlink-socket.c:101:24: error: unused variable 'req' [-Werror=unused-variable]
../lib/netlink-socket.c: In function 'nl_sock_send_mmap':
../lib/netlink-socket.c:369:22: error: 'NL_MMAP_HDRLEN' undeclared (first use in this function)
../lib/netlink-socket.c:374:12: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:374:27: error: 'NL_MMAP_STATUS_UNUSED' undeclared (first use in this function)
../lib/netlink-socket.c:385:8: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:386:8: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:386:23: error: 'NL_MMAP_STATUS_VALID' undeclared (first use in this function)
../lib/netlink-socket.c: In function 'nl_sock_recv_mmap':
../lib/netlink-socket.c:514:16: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:515:10: error: 'NL_MMAP_STATUS_VALID' undeclared (first use in this function)
../lib/netlink-socket.c:516:16: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:518:16: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:518:30: error: 'NL_MMAP_STATUS_UNUSED' undeclared (first use in this function)
../lib/netlink-socket.c:523:40: error: 'NL_MMAP_HDRLEN' undeclared (first use in this function)
../lib/netlink-socket.c:523:59: error: dereferencing pointer to incomplete type
../lib/netlink-socket.c:527:10: error: 'NL_MMAP_STATUS_COPY' undeclared (first use in this function)
../lib/netlink-socket.c:535:10: error: 'NL_MMAP_STATUS_RESERVED' undeclared (first use in this function)
../lib/netlink-socket.c:546:8: error: dereferencing pointer to incomplete type
cc1: all warnings being treated as errors
^ permalink raw reply
* Re: [PATCH 2/5] igb: Convert to use devm_hwmon_device_register_with_groups
From: Jeff Kirsher @ 2013-11-25 23:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Nithin Nayak Sujir,
Michael Chan, e1000-devel, lm-sensors
In-Reply-To: <1385186881-7931-3-git-send-email-linux@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Fri, 2013-11-22 at 22:07 -0800, Guenter Roeck wrote:
> Simplify the code. Attach hwmon sysfs attributes to hwmon device
> instead of pci device. Avoid race conditions caused by attributes
> being created after registration and provide mandatory 'name'
> attribute by using new hwmon API.
>
> Other cleanup:
>
> Instead of allocating memory for hwmon attributes, move attributes
> and all other hwmon related data into struct hwmon_buff and allocate
> the entire structure using devm_kzalloc.
>
> Check return value from calls to igb_add_hwmon_attr() one by one
> instead
> of logically combining them all together.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 8 ++-
> drivers/net/ethernet/intel/igb/igb_hwmon.c | 100
> +++++++++++++---------------
> 2 files changed, 53 insertions(+), 55 deletions(-)
I have added this to my queue, thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] ixgbe: Convert to use devm_hwmon_device_register_with_groups
From: Jeff Kirsher @ 2013-11-25 23:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Nithin Nayak Sujir,
Michael Chan, e1000-devel, lm-sensors
In-Reply-To: <1385186881-7931-4-git-send-email-linux@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Fri, 2013-11-22 at 22:07 -0800, Guenter Roeck wrote:
> Simplify the code. Attach hwmon sysfs attributes to hwmon device
> instead of pci device. Avoid race conditions caused by attributes
> being created after hwmon device registration. Implicitly
> (through hwmon API) add mandatory 'name' sysfs attribute.
>
> Other cleanup:
>
> Instead of allocating memory for hwmon attributes, move attributes
> and all other hwmon related data into struct hwmon_buff and allocate
> the entire structure using devm_kzalloc.
>
> Check return value from calls to igb_add_hwmon_attr() one by one
> instead
> of logically combining them all together.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 8 ++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c | 76
> ++++++++++--------------
> 2 files changed, 36 insertions(+), 48 deletions(-)
I have added this to my queue, thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] igb: Start temperature sensor attribute index with 1
From: Jeff Kirsher @ 2013-11-25 23:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Nithin Nayak Sujir,
Michael Chan, e1000-devel, lm-sensors
In-Reply-To: <1385186881-7931-5-git-send-email-linux@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Fri, 2013-11-22 at 22:08 -0800, Guenter Roeck wrote:
> Per hwmon ABI, temperature sensor attribute index starts with 1, not
> 0.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/net/ethernet/intel/igb/igb_hwmon.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
I have also added this to my queue, thank you.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] ixgbe: Start temperature sensor attribute index with 1
From: Jeff Kirsher @ 2013-11-25 23:18 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Nithin Nayak Sujir,
Michael Chan, e1000-devel, lm-sensors
In-Reply-To: <1385186881-7931-6-git-send-email-linux@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Fri, 2013-11-22 at 22:08 -0800, Guenter Roeck wrote:
> Per hwmon ABI, temperature sensor attribute index starts with 1, not
> 0.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
I have also added this to my queue, thank you.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST
From: Richard Weinberger @ 2013-11-25 23:27 UTC (permalink / raw)
To: Shawn Landden
Cc: Hannes Frederic Sowa, Eric Dumazet, LKML, linux-fsdevel, Al Viro,
linux-crypto, netdev@vger.kernel.org, Herbert Xu, Tom Herbert,
David S. Miller, stable
In-Reply-To: <1385361388-2175-1-git-send-email-shawn@churchofgit.com>
On Mon, Nov 25, 2013 at 7:36 AM, Shawn Landden <shawn@churchofgit.com> wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> MSG_MORE.
>
> algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
> and need to see the new flag as identical to MSG_MORE.
>
> This fixes sendfile() on AF_ALG.
>
> v3: also fix udp
>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: <stable@vger.kernel.org> # 3.4.x + 3.2.x
> Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
> Original-patch: Richard Weinberger <richard@nod.at>
> Signed-off-by: Shawn Landden <shawn@churchofgit.com>
May I ask why you took over the my patch without even CC'in me nor
replying to the original
thread "[PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we
set MSG_SENDPAGE_NOTLAST"?
You are acting very rude.
The discussion at the original thread is not done.
Does skcipher_sendpage() really also need fixing? or UDP?
I didn't send another patch because I'm waiting for Eric's answer first.
Thanks,
//richard
> ---
> crypto/algif_hash.c | 3 +++
> crypto/algif_skcipher.c | 3 +++
> net/ipv4/udp.c | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index ef5356c..8502462 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -114,6 +114,9 @@ static ssize_t hash_sendpage(struct socket *sock, struct page *page,
> struct hash_ctx *ctx = ask->private;
> int err;
>
> + if (flags & MSG_SENDPAGE_NOTLAST)
> + flags |= MSG_MORE;
> +
> lock_sock(sk);
> sg_init_table(ctx->sgl.sg, 1);
> sg_set_page(ctx->sgl.sg, page, size, offset);
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index 6a6dfc0..a19c027 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -378,6 +378,9 @@ static ssize_t skcipher_sendpage(struct socket *sock, struct page *page,
> struct skcipher_sg_list *sgl;
> int err = -EINVAL;
>
> + if (flags & MSG_SENDPAGE_NOTLAST)
> + flags |= MSG_MORE;
> +
> lock_sock(sk);
> if (!ctx->more && ctx->used)
> goto unlock;
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 5944d7d..8bd04df 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1098,6 +1098,9 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
> struct udp_sock *up = udp_sk(sk);
> int ret;
>
> + if (flags & MSG_SENDPAGE_NOTLAST)
> + flags |= MSG_MORE;
> +
> if (!up->pending) {
> struct msghdr msg = { .msg_flags = flags|MSG_MORE };
>
> --
> 1.8.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH net-next 7/8] openvswitch: Drop user features if old user space attempted to create datapath
From: Jesse Gross @ 2013-11-25 23:40 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, dev@openvswitch.org, netdev, Daniel Borkmann,
ffusco, fleitner, Eric Dumazet, Ben Hutchings
In-Reply-To: <a207b27c2830c9098045455808e1ca6d203a5d9a.1385137618.git.tgraf@suug.ch>
On Fri, Nov 22, 2013 at 8:56 AM, Thomas Graf <tgraf@suug.ch> wrote:
> diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
> index 07ef2c3..a6863e2 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -40,7 +40,15 @@ struct ovs_header {
>
> #define OVS_DATAPATH_FAMILY "ovs_datapath"
> #define OVS_DATAPATH_MCGROUP "ovs_datapath"
> -#define OVS_DATAPATH_VERSION 0x1
> +
> +/* V2:
> + * - API users are expected to provide OVS_DP_ATTR_USER_FEATURES
> + * with NLM_F_REPLACE when creating the datapath.
> + */
> +#define OVS_DATAPATH_VERSION 2
I'm not sure that I understand this comment - I guess it means that
there's no legacy path when using NLM_F_REPLACE?
^ permalink raw reply
* [PATCH net 1/1] via-velocity: fix netif_receive_skb use in irq disabled section.
From: Francois Romieu @ 2013-11-25 23:40 UTC (permalink / raw)
To: netdev
Cc: David Miller, Alex A. Schmidt, Michele Baldessari, Jamie Heilman,
Julia Lawall
2fdac010bdcf10a30711b6924612dfc40daf19b8 ("via-velocity.c: update napi
implementation") overlooked an irq disabling spinlock when the Rx part
of the NAPI poll handler was converted from netif_rx to netif_receive_skb.
NAPI Rx processing can be taken out of the locked section with a pair of
napi_{disable / enable} since it only races with the MTU change function.
An heavier rework of the NAPI locking would be able to perform NAPI Tx
before Rx where I simply removed one of velocity_tx_srv calls.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1022733
Fixes: 2fdac010bdcf (via-velocity.c: update napi implementation)
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Alex A. Schmidt <aaschmidt1@gmail.com>
Cc: Jamie Heilman <jamie@audible.transient.net>
Cc: Michele Baldessari <michele@acksyn.org>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
---
It is relevant for stable 3.11.x and 3.12.y.
drivers/net/ethernet/via/via-velocity.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index d022bf9..ad61d26 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -2172,16 +2172,13 @@ static int velocity_poll(struct napi_struct *napi, int budget)
unsigned int rx_done;
unsigned long flags;
- spin_lock_irqsave(&vptr->lock, flags);
/*
* Do rx and tx twice for performance (taken from the VIA
* out-of-tree driver).
*/
- rx_done = velocity_rx_srv(vptr, budget / 2);
- velocity_tx_srv(vptr);
- rx_done += velocity_rx_srv(vptr, budget - rx_done);
+ rx_done = velocity_rx_srv(vptr, budget);
+ spin_lock_irqsave(&vptr->lock, flags);
velocity_tx_srv(vptr);
-
/* If budget not fully consumed, exit the polling mode */
if (rx_done < budget) {
napi_complete(napi);
@@ -2342,6 +2339,8 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
if (ret < 0)
goto out_free_tmp_vptr_1;
+ napi_disable(&vptr->napi);
+
spin_lock_irqsave(&vptr->lock, flags);
netif_stop_queue(dev);
@@ -2362,6 +2361,8 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
velocity_give_many_rx_descs(vptr);
+ napi_enable(&vptr->napi);
+
mac_enable_int(vptr->mac_regs);
netif_start_queue(dev);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH openvswitch] linux: Signal datapath that unaligned Netlink message can be received
From: Jesse Gross @ 2013-11-25 23:41 UTC (permalink / raw)
To: Thomas Graf; +Cc: dev@openvswitch.org, netdev
In-Reply-To: <48c93fb3c82bca0c9858ff528e2cf79d72d76082.1385057672.git.tgraf@redhat.com>
On Thu, Nov 21, 2013 at 10:15 AM, Thomas Graf <tgraf@redhat.com> wrote:
> diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
> index 1dcf321..5c952bc 100644
> --- a/lib/dpif-linux.c
> +++ b/lib/dpif-linux.c
> @@ -232,6 +233,7 @@ dpif_linux_open(const struct dpif_class *class OVS_UNUSED, const char *name,
> dp_request.cmd = OVS_DP_CMD_GET;
> }
> dp_request.name = name;
> + dp_request.user_features |= OVS_DP_F_UNALIGNED;
Should we restrict this to just OVS_DP_CMD_NEW?
^ permalink raw reply
* Re: [PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we set MSG_SENDPAGE_NOTLAST
From: Eric Dumazet @ 2013-11-26 0:02 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, linux-fsdevel, viro, shawnlandden, linux-crypto,
netdev, herbert, Tom Herbert, David S. Miller, stable
In-Reply-To: <47783210.a9ocpbYofP@sandpuppy>
On Mon, 2013-11-25 at 08:42 +0100, Richard Weinberger wrote:
> In the commit message of your patch you wrote "For all sendpage() providers,
> its a transparent change.". Why does AF_ALG need special handling?
> If users have to care about MSG_SENDPAGE_NOTLAST it is no longer really an
> internal flag.
MSG_SENDPAGE_NOTLAST is an internal (kernel) flag.
Fact that I missed some MSG_MORE 'users' in the kernel was an oversight.
I am not saying your patch is not needed, I am only saying it reverts
a useful TCP optimization, and we can do better, dont we ?
^ permalink raw reply
* Supporting 4 way connections in LKSCTP
From: Sun Paul @ 2013-11-26 1:03 UTC (permalink / raw)
To: linux-sctp, netdev, linux-kernel
Hi
we have a problem on using LKSCTP to form a 4 ways multi-homing network.
Configuration
- Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
IP-B (eth2)
- Node-B has 2 IP addresses in different subnets, known as IP-X (eth1),
IP-Y (eth2)
the four way paths are shown below.
1. IP-A (11.1.1.1) to IP-X (11.1.1.11)
2. IP-B (12.1.1.1) to IP-Y (12.1.1.11)
3. IP-A (11.1.1.1) to IP-Y (12.1.1.11)
4. IP-B (12.1.1.1) to IP-X (11.1.1.11)
the HB/HB_ACK is normal for the paths " IP-A to IP-X" and "IP-B to
IP-Y", but it is not correct for the rest of two.
First of all, we are using iproute2 to form 2 table such that when
IP-B arrives on IP-X, it will know how to route back to IP-B on the
same interface, i.e (eth1). Same logic for the path "IP-A to IP-X".
What we observed here is that when 12.1.1.1 sends INIT to 11.1.1.11,
LKSCTP will send back the INIT_ACK to 12.1.1.1 using 12.1.1.11 but not
using the IP 11.1.1.11.
The above operation makes the subsequence HB/HB_ACK in using wrong IP address.
TCP trace on eth1
18:02:41.058640 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
[init tag: 19933036] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
18:02:41.061634 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
18:02:41.062642 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.062846 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.361811 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.661791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.961791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
TCP trace on eth2
18:02:41.058755 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
[init tag: 424726157] [rwnd: 131072] [OS: 5] [MIS: 5] [init TSN:
3340756356]
18:02:41.061696 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
18:02:41.062663 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.062791 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.361777 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.661772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.961772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.161771 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.461770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.675770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
If we are using single homing, there is no problem on the SCTP
communication. Below is the TCP trace on eth1 using sctp_test
18:09:55.356727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
[init tag: 32516609] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
18:09:55.356811 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
[init tag: 3168861995] [rwnd: 131072] [OS: 10] [MIS: 16] [init TSN:
1877695021]
18:09:55.357727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
18:09:55.357788 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
18:09:55.358724 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:09:55.358740 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
18:09:55.379715 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [DATA]
(B)(E) [TSN: 0] [SID: 0] [SSEQ 0] [PPID 0x3]
18:09:55.379735 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [SACK]
[cum ack 0] [a_rwnd 131064] [#gap acks 0] [#dup tsns 0]
18:09:55.657716 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:09:55.657732 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
>From the observations, it seems that the LKSCTP library is not able to
use the original local address when multi-homing is being used. Is
there anyway can be resolved it?
Thanks
PS
^ permalink raw reply
* Re: [PATCH] net: sched: tbf: fix calculation of max_size
From: Yang Yingliang @ 2013-11-26 1:28 UTC (permalink / raw)
To: David Laight; +Cc: Eric Dumazet, netdev, davem, brouer, jpirko, jbrouer
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7443@saturn3.aculab.com>
On 2013/11/25 20:22, David Laight wrote:
>> From: Yang Yingliang <yangyingliang@huawei.com>
>>
>> Current max_size is caluated from rate table. Now, the rate table
>> has been replaced and it's wrong to caculate max_size based on this
>> rate table. It can lead wrong calculation of max_size.
>>
>> The burst in kernel may be lower than user asked, because burst may gets
>> some loss when transform it to buffer(E.g. "burst 40kb rate 30mbit/s")
>> and it seems we cannot avoid this loss. And burst's value(max_size) based
>> on rate table may be equal user asked. If a packet's length is max_size,
>> this packet will be stalled in tbf_dequeue() because its length is above
>> the burst in kernel so that it cannot get enough tokens. The max_size guards
>> against enqueuing packet sizes above q->buffer "time" in tbf_enqueue().
>
> Why not adjust the calculations so that the number of allocated tokens
> can go negative?
>
> So allow the transfer if the number of tokens is +ve and then subtract
> the number needed for the message itself.
Thanks for your advice!
I had considered it before. But, I think that we calculate tokens from ns
but max_size is calculated based on rate table causes the problem. I think we
should make them consistent.
>
> I think this would change the semantics of the configured 'burst' value
> very slightly (to 'at least' from 'at most') but the average would still
> be correct.
Hmm, I'm not sure it is 'at least'. Maybe it could be lower.
Regards,
Yang
>
> FWIW I've done similar rate limiters that run directly in units of 'time'.
> The fact that system time advances automatically generates credit.
>
> David
>
>
^ permalink raw reply
* [PATCH v2 net-next] net: remove outdated comment for ipv4 and ipv6 protocol handler
From: baker.kernel @ 2013-11-26 1:29 UTC (permalink / raw)
To: sergei.shtylyov, davem; +Cc: netdev, Baker Zhang
In-Reply-To: <1385365686-17804-1-git-send-email-baker.kernel@gmail.com>
From: Baker Zhang <Baker.kernel@gmail.com>
since f9242b6b28d61295f2bf7e8adfb1060b382e5381
inet: Sanitize inet{,6} protocol demux.
there are not pretended hash tables for ipv4 or
ipv6 protocol handler.
Signed-off-by: Baker Zhang <Baker.kernel@gmail.com>
---
V1:
inet_add_protocol/inet_del_protocol and inet6_del_protocol
are very simple in current version.
so I remove the outdated comment instead of fixing them,
just like inet6_add_protocol.
V2:
Add summary line in parens.
URL:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9242b6b28d61295f2bf7e8adfb1060b382e5381
net/ipv4/protocol.c | 8 --------
net/ipv6/protocol.c | 4 ----
2 files changed, 12 deletions(-)
diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
index ce84846..46d6a1c 100644
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -31,10 +31,6 @@
const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS] __read_mostly;
-/*
- * Add a protocol handler to the hash tables
- */
-
int inet_add_protocol(const struct net_protocol *prot, unsigned char protocol)
{
if (!prot->netns_ok) {
@@ -55,10 +51,6 @@ int inet_add_offload(const struct net_offload *prot, unsigned char protocol)
}
EXPORT_SYMBOL(inet_add_offload);
-/*
- * Remove a protocol from the hash tables.
- */
-
int inet_del_protocol(const struct net_protocol *prot, unsigned char protocol)
{
int ret;
diff --git a/net/ipv6/protocol.c b/net/ipv6/protocol.c
index 22d1bd4..e048cf1 100644
--- a/net/ipv6/protocol.c
+++ b/net/ipv6/protocol.c
@@ -36,10 +36,6 @@ int inet6_add_protocol(const struct inet6_protocol *prot, unsigned char protocol
}
EXPORT_SYMBOL(inet6_add_protocol);
-/*
- * Remove a protocol from the hash tables.
- */
-
int inet6_del_protocol(const struct inet6_protocol *prot, unsigned char protocol)
{
int ret;
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/5] tg3: Convert to use hwmon_device_register_with_groups
From: Nithin Nayak Sujir @ 2013-11-26 1:52 UTC (permalink / raw)
To: Guenter Roeck, netdev
Cc: David S. Miller, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Michael Chan,
e1000-devel, lm-sensors
In-Reply-To: <1385186881-7931-2-git-send-email-linux@roeck-us.net>
On 11/22/2013 10:07 PM, Guenter Roeck wrote:
> Use new hwmon API to simplify code, provide missing mandatory 'name'
> sysfs attribute, and attach hwmon attributes to hwmon device instead
> of pci device.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 25 ++++++-------------------
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index a9e0684..369b736 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -10629,10 +10629,8 @@ static void tg3_sd_scan_scratchpad(struct tg3 *tp, struct tg3_ocir *ocir)
> static ssize_t tg3_show_temp(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct net_device *netdev = pci_get_drvdata(pdev);
> - struct tg3 *tp = netdev_priv(netdev);
> struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> + struct tg3 *tp = dev_get_drvdata(dev);
Shouldn't this be
struct tg3 *tp = netdev_priv(dev_get_drvdata(dev));
^ permalink raw reply
* [PATCH iproute2] tbf: add 64bit rates support
From: Yang Yingliang @ 2013-11-26 1:55 UTC (permalink / raw)
To: netdev, stephen; +Cc: eric.dumazet
tbf support 64bit rates start from linux-3.13.
Add 64bit rates support in tc tools.
tc qdisc show dev eth0
qdisc tbf 1: root refcnt 2 rate 40000Mbit burst 230000b peakrate 50000Mbit minburst 87500b lat 50.0ms
This is a followup to ("htb: support 64bit rates").
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: Eric Dumazet <edumazet@google.com>
---
tc/q_tbf.c | 58 ++++++++++++++++++++++++++++++++++++++--------------------
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/tc/q_tbf.c b/tc/q_tbf.c
index 34784a4..2fbfd3b 100644
--- a/tc/q_tbf.c
+++ b/tc/q_tbf.c
@@ -47,6 +47,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
unsigned short overhead=0;
unsigned int linklayer = LINKLAYER_ETHERNET; /* Assume ethernet */
struct rtattr *tail;
+ __u64 rate64 = 0, prate64 = 0;
memset(&opt, 0, sizeof(opt));
@@ -121,22 +122,22 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
ok++;
} else if (strcmp(*argv, "rate") == 0) {
NEXT_ARG();
- if (opt.rate.rate) {
+ if (rate64) {
fprintf(stderr, "tbf: duplicate \"rate\" specification\n");
return -1;
}
- if (get_rate(&opt.rate.rate, *argv)) {
+ if (get_rate64(&rate64, *argv)) {
explain1("rate", *argv);
return -1;
}
ok++;
} else if (matches(*argv, "peakrate") == 0) {
NEXT_ARG();
- if (opt.peakrate.rate) {
+ if (prate64) {
fprintf(stderr, "tbf: duplicate \"peakrate\" specification\n");
return -1;
}
- if (get_rate(&opt.peakrate.rate, *argv)) {
+ if (get_rate64(&prate64, *argv)) {
explain1("peakrate", *argv);
return -1;
}
@@ -172,7 +173,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
* one go rather than reveal one more problem when a
* previous one has been fixed.
*/
- if (opt.rate.rate == 0) {
+ if (rate64 == 0) {
fprintf(stderr, "tbf: the \"rate\" parameter is mandatory.\n");
verdict = -1;
}
@@ -180,7 +181,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
fprintf(stderr, "tbf: the \"burst\" parameter is mandatory.\n");
verdict = -1;
}
- if (opt.peakrate.rate) {
+ if (prate64) {
if (!mtu) {
fprintf(stderr, "tbf: when \"peakrate\" is specified, \"mtu\" must also be specified.\n");
verdict = -1;
@@ -197,10 +198,13 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
return verdict;
}
+ opt.rate.rate = (rate64 >= (1ULL << 32)) ? ~0U : rate64;
+ opt.peakrate.rate = (prate64 >= (1ULL << 32)) ? ~0U : prate64;
+
if (opt.limit == 0) {
- double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC + buffer;
- if (opt.peakrate.rate) {
- double lim2 = opt.peakrate.rate*(double)latency/TIME_UNITS_PER_SEC + mtu;
+ double lim = rate64*(double)latency/TIME_UNITS_PER_SEC + buffer;
+ if (prate64) {
+ double lim2 = prate64*(double)latency/TIME_UNITS_PER_SEC + mtu;
if (lim2 < lim)
lim = lim2;
}
@@ -228,20 +232,26 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
tail = NLMSG_TAIL(n);
addattr_l(n, 1024, TCA_OPTIONS, NULL, 0);
addattr_l(n, 2024, TCA_TBF_PARMS, &opt, sizeof(opt));
+ if (rate64 >= (1ULL << 32))
+ addattr_l(n, 2124, TCA_TBF_RATE64, &rate64, sizeof(rate64));
addattr_l(n, 3024, TCA_TBF_RTAB, rtab, 1024);
- if (opt.peakrate.rate)
+ if (opt.peakrate.rate) {
+ if (prate64 >= (1ULL << 32))
+ addattr_l(n, 3124, TCA_TBF_PRATE64, &prate64, sizeof(prate64));
addattr_l(n, 4096, TCA_TBF_PTAB, ptab, 1024);
+ }
tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
}
static int tbf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
{
- struct rtattr *tb[TCA_TBF_PTAB+1];
+ struct rtattr *tb[TCA_TBF_MAX+1];
struct tc_tbf_qopt *qopt;
unsigned int linklayer;
double buffer, mtu;
double latency;
+ __u64 rate64 = 0, prate64 = 0;
SPRINT_BUF(b1);
SPRINT_BUF(b2);
SPRINT_BUF(b3);
@@ -249,7 +259,7 @@ static int tbf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
if (opt == NULL)
return 0;
- parse_rtattr_nested(tb, TCA_TBF_PTAB, opt);
+ parse_rtattr_nested(tb, TCA_TBF_MAX, opt);
if (tb[TCA_TBF_PARMS] == NULL)
return -1;
@@ -257,8 +267,12 @@ static int tbf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
qopt = RTA_DATA(tb[TCA_TBF_PARMS]);
if (RTA_PAYLOAD(tb[TCA_TBF_PARMS]) < sizeof(*qopt))
return -1;
- fprintf(f, "rate %s ", sprint_rate(qopt->rate.rate, b1));
- buffer = tc_calc_xmitsize(qopt->rate.rate, qopt->buffer);
+ rate64 = qopt->rate.rate;
+ if (tb[TCA_TBF_RATE64] &&
+ RTA_PAYLOAD(tb[TCA_TBF_RATE64]) >= sizeof(rate64))
+ rate64 = rta_getattr_u64(tb[TCA_TBF_RATE64]);
+ fprintf(f, "rate %s ", sprint_rate(rate64, b1));
+ buffer = tc_calc_xmitsize(rate64, qopt->buffer);
if (show_details) {
fprintf(f, "burst %s/%u mpu %s ", sprint_size(buffer, b1),
1<<qopt->rate.cell_log, sprint_size(qopt->rate.mpu, b2));
@@ -267,10 +281,14 @@ static int tbf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
}
if (show_raw)
fprintf(f, "[%08x] ", qopt->buffer);
- if (qopt->peakrate.rate) {
- fprintf(f, "peakrate %s ", sprint_rate(qopt->peakrate.rate, b1));
+ prate64 = qopt->peakrate.rate;
+ if (tb[TCA_TBF_PRATE64] &&
+ RTA_PAYLOAD(tb[TCA_TBF_PRATE64]) >= sizeof(prate64))
+ prate64 = rta_getattr_u64(tb[TCA_TBF_PRATE64]);
+ if (prate64) {
+ fprintf(f, "peakrate %s ", sprint_rate(prate64, b1));
if (qopt->mtu || qopt->peakrate.mpu) {
- mtu = tc_calc_xmitsize(qopt->peakrate.rate, qopt->mtu);
+ mtu = tc_calc_xmitsize(prate64, qopt->mtu);
if (show_details) {
fprintf(f, "mtu %s/%u mpu %s ", sprint_size(mtu, b1),
1<<qopt->peakrate.cell_log, sprint_size(qopt->peakrate.mpu, b2));
@@ -285,9 +303,9 @@ static int tbf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
if (show_raw)
fprintf(f, "limit %s ", sprint_size(qopt->limit, b1));
- latency = TIME_UNITS_PER_SEC*(qopt->limit/(double)qopt->rate.rate) - tc_core_tick2time(qopt->buffer);
- if (qopt->peakrate.rate) {
- double lat2 = TIME_UNITS_PER_SEC*(qopt->limit/(double)qopt->peakrate.rate) - tc_core_tick2time(qopt->mtu);
+ latency = TIME_UNITS_PER_SEC*(qopt->limit/(double)rate64) - tc_core_tick2time(qopt->buffer);
+ if (prate64) {
+ double lat2 = TIME_UNITS_PER_SEC*(qopt->limit/(double)prate64) - tc_core_tick2time(qopt->mtu);
if (lat2 > latency)
latency = lat2;
}
--
1.8.0
^ permalink raw reply related
* Re: BCM5720 transmit queue 1 timed out
From: Nithin Nayak Sujir @ 2013-11-26 2:10 UTC (permalink / raw)
To: Atif Faheem; +Cc: netdev@vger.kernel.org
In-Reply-To: <E26A7505-D0D3-4C63-8CB9-E334F523623B@btisystems.com>
On 11/24/2013 12:44 AM, Atif Faheem wrote:
> Hi Nithin. I can get the RDMA change to trigger / resolve, however, I have one Q. Are the RDMA length registers 16 bit or 32 bit? The code seems to imply they are 32-bit, however, my understanding is that the length registers are 16-bit at 4be0, 4be2, 4be4, 4be6.
>
Glad to know that resolves the problem.
> if (tr32(TG3_RDMA_LENGTH + (i << 2)) > TG3_MAX_MTU(tp))
>
The RDMA registers are 32 bit.
Note - the loop adds (i << 2) and not i * 2. Adding (i << 2) gives 4be0, 4be4,
4be8 and 4bec.
> The change gets executed when the value of 0x4be0 is e.g., 0x00960096, or 0x00a200a2. Just wanted to confirm that the lengths are indeed 32-bit in the register map.
>
> Thanks.
> - Atif
>
> On Nov 11, 2013, at 1:52 PM, Nithin Nayak Sujir <nsujir@broadcom.com> wrote:
>
>>
>>
>> On 11/08/2013 09:24 PM, Atif Faheem wrote:
>>> 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.
>>>
>> Hi Atif,
>>
>> The symptom you're describing matches the fixes that went in for the DMA workaround.
>>
>>> -- 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.
>>>
>>
>> This commit id is for the 5719 fix. The 5720 fix is
>> 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8.
>>
>>
>>> 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.
>>>
>>
>> No, these two patches should fix the issue. Are you certain both patches are
>> applied and being used? Also, would you mind trying the latest stable 3.11.x kernel?
>>
>> Please make sure to *power cycle* the system after a previous timeout. A reboot
>> may not be enough once the hardware is already in a bad state for this issue.
>> Pull the plug and power down and wait a few seconds before powering on.
>>
>> Thanks,
>> Nithin.
>>
>>
>>
>>> 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
>>> --
>>> 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: BCM5720 'no firmware running'
From: Nithin Nayak Sujir @ 2013-11-26 2:12 UTC (permalink / raw)
To: Atif Faheem, netdev@vger.kernel.org
In-Reply-To: <4CB236AC-8330-4270-A218-A5697E965203@btisystems.com>
On 11/24/2013 01:39 AM, Atif Faheem wrote:
> Hi. I am observing a strange problem with the 5720. Sometimes during the boot up of the 5720, after both interfaces have been added to a bond, tg3 throws the error ‘no firmware running’ and all registers are -1. This happens on both interfaces. A power cycle is needed in order to recover the device. We are using kernel 3.4.34 - I haven’t tried to build the driver from the latest kernel (I will have to back-port). Any input will be great.
>
Isn't this the same issue you brought up in the other thread? There is a tx
timeout here too. Do you have the fixes from the other thread?
> Thanks - Atif
>
> ---
>
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> rx-vlan-offload: on
> tx-vlan-offload: on
> ntuple-filters: off
> receive-hashing: off
>
> ----
>
> 2013-11-20T02:06:02.659773-05:00 pld0112 kernel: bonding: bond0: enslaving eth0 as an active interface with a down link.
> 2013-11-20T02:06:02.659806-05:00 pld0112 kernel: bonding: bond0: enslaving eth1 as an active interface with a down link.
> 2013-11-20T02:06:02.659809-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: Link is up at 1000 Mbps, full duplex
> 2013-11-20T02:06:02.659812-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: Flow control is off for TX and off for RX
> 2013-11-20T02:06:02.659815-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: EEE is disabled
> 2013-11-20T02:06:02.659818-05:00 pld0112 kernel: bonding: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex.
> 2013-11-20T02:06:02.659821-05:00 pld0112 kernel: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
> 2013-11-20T02:06:02.659832-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Link is up at 1000 Mbps, full duplex
> 2013-11-20T02:06:02.659837-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Flow control is off for TX and off for RX
> 2013-11-20T02:06:02.659840-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: EEE is disabled
> 2013-11-20T02:06:02.659843-05:00 pld0112 kernel: bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex.
> 2013-11-20T02:06:22.465353-05:00 pld0112 kernel: nfs: server 100.100.0.6 not responding, still trying
> 2013-11-20T02:06:25.937609-05:00 pld0112 kernel: ------------[ cut here ]------------
> 2013-11-20T02:06:25.937642-05:00 pld0112 kernel: 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()
> 2013-11-20T02:06:25.937649-05:00 pld0112 kernel: Hardware name: To be filled by O.E.M.
> 2013-11-20T02:06:25.937653-05:00 pld0112 kernel: NETDEV WATCHDOG: eth1 (tg3): transmit queue 1 timed out
> 2013-11-20T02:06:25.937657-05:00 pld0112 kernel: Modules linked in: firmware_class hwmon libphy tg3 x_tables ip_tables iptable_filter exportfs coretemp minix ipmi_devintf bonding nfsd ipmi_msghandler ipmi_si [last unloaded: bonding]
> 2013-11-20T02:06:25.937662-05:00 pld0112 kernel: Pid: 0, comm: swapper/0 Not tainted 3.4.34-WR5.0.1.3_standard #1
> 2013-11-20T02:06:25.937668-05:00 pld0112 kernel: Call Trace:
> 2013-11-20T02:06:25.937728-05:00 pld0112 kernel: <IRQ> [<ffffffff81030c84>] warn_slowpath_common+0x84/0xc0
> 2013-11-20T02:06:25.937734-05:00 pld0112 kernel: [<ffffffff81030d77>] warn_slowpath_fmt+0x47/0x50
> 2013-11-20T02:06:25.937739-05:00 pld0112 kernel: [<ffffffff816799f7>] dev_watchdog+0x277/0x280
> 2013-11-20T02:06:25.937744-05:00 pld0112 kernel: [<ffffffff81040784>] run_timer_softirq+0x134/0x420
> 2013-11-20T02:06:25.937747-05:00 pld0112 kernel: [<ffffffff8134f5ee>] ? timerqueue_add+0x6e/0xc0
> 2013-11-20T02:06:25.937751-05:00 pld0112 kernel: [<ffffffff81679780>] ? qdisc_reset+0x50/0x50
> 2013-11-20T02:06:25.937756-05:00 pld0112 kernel: [<ffffffff8103811d>] __do_softirq+0xbd/0x280
> 2013-11-20T02:06:25.937760-05:00 pld0112 kernel: [<ffffffff81079375>] ? clockevents_program_event+0x75/0xf0
> 2013-11-20T02:06:25.937765-05:00 pld0112 kernel: [<ffffffff8107a7b4>] ? tick_program_event+0x24/0x30
> 2013-11-20T02:06:25.937769-05:00 pld0112 kernel: [<ffffffff81777b8c>] call_softirq+0x1c/0x30
> 2013-11-20T02:06:25.937773-05:00 pld0112 kernel: [<ffffffff810037b5>] do_softirq+0x55/0x90
> 2013-11-20T02:06:25.937778-05:00 pld0112 kernel: [<ffffffff810385ee>] irq_exit+0x8e/0xb0
> 2013-11-20T02:06:25.937783-05:00 pld0112 kernel: [<ffffffff817781e9>] smp_apic_timer_interrupt+0x99/0x1cd
> 2013-11-20T02:06:25.937788-05:00 pld0112 kernel: [<ffffffff817773c7>] apic_timer_interrupt+0x67/0x70
> 2013-11-20T02:06:25.937791-05:00 pld0112 kernel: <EOI> [<ffffffff813c2689>] ? acpi_idle_enter_bm+0x240/0x281
> 2013-11-20T02:06:25.937796-05:00 pld0112 kernel: [<ffffffff813c2684>] ? acpi_idle_enter_bm+0x23b/0x281
> 2013-11-20T02:06:25.937800-05:00 pld0112 kernel: [<ffffffff815cc58f>] ? menu_select+0xff/0x3c0
> 2013-11-20T02:06:25.937804-05:00 pld0112 kernel: [<ffffffff815ca8d8>] cpuidle_enter+0x18/0x20
> 2013-11-20T02:06:25.937808-05:00 pld0112 kernel: [<ffffffff815caf59>] cpuidle_idle_call+0xc9/0x3b0
> 2013-11-20T02:06:25.937813-05:00 pld0112 kernel: [<ffffffff8100b59f>] cpu_idle+0x7f/0xd0
> 2013-11-20T02:06:25.937817-05:00 pld0112 kernel: [<ffffffff8174b3a7>] rest_init+0x7b/0x84
> 2013-11-20T02:06:25.937821-05:00 pld0112 kernel: [<ffffffff81cd3b76>] start_kernel+0x35b/0x369
> 2013-11-20T02:06:25.937826-05:00 pld0112 kernel: [<ffffffff81cd3616>] ? repair_env_string+0x5a/0x5a
> 2013-11-20T02:06:25.937830-05:00 pld0112 kernel: [<ffffffff81cd3321>] x86_64_start_reservations+0x131/0x135
> 2013-11-20T02:06:25.937834-05:00 pld0112 kernel: [<ffffffff81cd3416>] x86_64_start_kernel+0xf1/0xf9
> 2013-11-20T02:06:25.937839-05:00 pld0112 kernel: ---[ end trace e28305a78a341f61 ]---
> 2013-11-20T02:06:25.937843-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: transmit timed out, resetting
> 2013-11-20T02:06:25.960660-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000000: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-20T02:06:25.960689-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000010: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-20T02:06:25.960698-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000020: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-20T02:06:25.960703-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000030: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-20T02:06:25.960707-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000040: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> 2013-11-20T02:06:25.960712-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000050: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> ….
> ….
> 2013-11-20T02:06:26.081578-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
> 2013-11-20T02:06:26.081583-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(0402:0000:0000:0000)]
> 2013-11-20T02:06:26.081588-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 1: Host status block [00000001:00000097:(0000:0000:0000):(01f9:0007)]
> 2013-11-20T02:06:26.081606-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 1: NAPI info [00000097:00000097:(0007:0007:01ff):01f9:(01f9:01f9:0000:0000)]
> 2013-11-20T02:06:26.081613-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 2: Host status block [00000001:000000e2:(0028:0000:0000):(0000:00f5)]
> 2013-11-20T02:06:26.081618-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 2: NAPI info [000000e2:000000e2:(0101:00f5:01ff):0028:(0028:0028:0000:0000)]
> 2013-11-20T02:06:26.081623-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 3: Host status block [00000001:000000f0:(0000:0000:0000):(0000:0066)]
> 2013-11-20T02:06:26.081627-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 3: NAPI info [000000f0:000000f0:(0069:0066:01ff):08b6:(00b6:00b6:0000:0000)]
> 2013-11-20T02:06:26.081632-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 4: Host status block [00000001:0000004b:(0000:0000:0063):(0000:0002)]
> 2013-11-20T02:06:26.081638-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 4: NAPI info [0000004b:0000004b:(0002:0002:01ff):0063:(0063:0063:0000:0000)]
> 2013-11-20T02:06:26.095286-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2c00 enable_bit=2
> 2013-11-20T02:06:26.197287-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2000 enable_bit=2
> 2013-11-20T02:06:26.300286-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2400 enable_bit=2
> 2013-11-20T02:06:26.402277-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2800 enable_bit=2
> 2013-11-20T02:06:26.504264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=3000 enable_bit=2
> 2013-11-20T02:06:26.606267-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1400 enable_bit=2
> 2013-11-20T02:06:26.708264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1800 enable_bit=2
> 2013-11-20T02:06:26.810264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=c00 enable_bit=2
> 2013-11-20T02:06:26.912259-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=4800 enable_bit=2
> 2013-11-20T02:06:27.014273-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1000 enable_bit=2
> 2013-11-20T02:06:27.116264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1c00 enable_bit=2
> 2013-11-20T02:06:27.218282-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
> 2013-11-20T02:06:27.320264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=3c00 enable_bit=2
> 2013-11-20T02:06:27.422240-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=4c00 enable_bit=2
> 2013-11-20T02:06:28.964261-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: No firmware running
> 2013-11-20T02:06:30.188256-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
> 2013-11-20T02:06:44.447246-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Link is down
> 2013-11-20T02:06:44.458245-05:00 pld0112 kernel: bonding: bond0: link status definitely down for interface eth1, disabling it
> 2013-11-20T02:06:44.507338-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: transmit timed out, resetting
> 2013-11-20T02:06:44.507375-05:00 pld0112 kernel: nfs: server 100.100.0.6 not responding, still trying--
> 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: sched: tbf: fix calculation of max_size
From: Yang Yingliang @ 2013-11-26 2:35 UTC (permalink / raw)
To: David Laight; +Cc: Eric Dumazet, netdev, davem, brouer, jpirko, jbrouer
In-Reply-To: <5293F92F.606@huawei.com>
On 2013/11/26 9:28, Yang Yingliang wrote:
> On 2013/11/25 20:22, David Laight wrote:
>>> From: Yang Yingliang <yangyingliang@huawei.com>
>>>
>>> Current max_size is caluated from rate table. Now, the rate table
>>> has been replaced and it's wrong to caculate max_size based on this
>>> rate table. It can lead wrong calculation of max_size.
>>>
>>> The burst in kernel may be lower than user asked, because burst may gets
>>> some loss when transform it to buffer(E.g. "burst 40kb rate 30mbit/s")
>>> and it seems we cannot avoid this loss. And burst's value(max_size) based
>>> on rate table may be equal user asked. If a packet's length is max_size,
>>> this packet will be stalled in tbf_dequeue() because its length is above
>>> the burst in kernel so that it cannot get enough tokens. The max_size guards
>>> against enqueuing packet sizes above q->buffer "time" in tbf_enqueue().
>>
>> Why not adjust the calculations so that the number of allocated tokens
>> can go negative?
>>
>> So allow the transfer if the number of tokens is +ve and then subtract
>> the number needed for the message itself.
>
> Thanks for your advice!
> I had considered it before. But, I think that we calculate tokens from ns
> but max_size is calculated based on rate table causes the problem. I think we
> should make them consistent.
>
Forgot to say, fixing calculation of max_size is also needed by 64bit rates.
Regards,
Yang
^ permalink raw reply
* Re: [PATCH] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST
From: Shawn Landden @ 2013-11-26 2:43 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-fsdevel, viro, Shawn Landden,
linux-crypto, netdev, Herbert Xu, Tom Herbert, David S. Miller,
stable, Richard Weinberger
On Mon, Nov 25, 2013 at 7:36 AM, Shawn Landden <shawn@churchofgit.com> wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> MSG_MORE.
>
> algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
> and need to see the new flag as identical to MSG_MORE.
>
> This fixes sendfile() on AF_ALG.
>
> v3: also fix udp
>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: <stable@vger.kernel.org> # 3.4.x + 3.2.x
> Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
> Original-patch: Richard Weinberger <richard@nod.at>
> Signed-off-by: Shawn Landden <shawn@churchofgit.com>
>May I ask why you took over the my patch without even CC'in me nor
>replying to the original
>thread "[PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we
>set MSG_SENDPAGE_NOTLAST"?
>You are acting very rude.
Not CCing you was an oversight.
>The discussion at the original thread is not done.
>Does skcipher_sendpage() really also need fixing? or UDP?
UDP needs it or it will send out packets mid-sendfile. skcipher needs
it or it will produce incorrect
output like hash.
>I didn't send another patch because I'm waiting for Eric's answer first.
Eric forgot to update consumers internal consumers of MSG_MORE when he created
this distinction in sendpage. That became clear when he first
responded. Changing this where the consumers are makes sense. I just
want this bug fixed, feel free to send your next version.
>Thanks,
>//richard
-Shawn
^ permalink raw reply
* Re: [PATCH 1/5] tg3: Convert to use hwmon_device_register_with_groups
From: Guenter Roeck @ 2013-11-26 2:47 UTC (permalink / raw)
To: Nithin Nayak Sujir, netdev
Cc: e1000-devel, Bruce Allan, Jesse Brandeburg, lm-sensors,
Michael Chan, David S. Miller
In-Reply-To: <5293FEFA.4000700@broadcom.com>
On 11/25/2013 05:52 PM, Nithin Nayak Sujir wrote:
>
>
> On 11/22/2013 10:07 PM, Guenter Roeck wrote:
>> Use new hwmon API to simplify code, provide missing mandatory 'name'
>> sysfs attribute, and attach hwmon attributes to hwmon device instead
>> of pci device.
>>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> drivers/net/ethernet/broadcom/tg3.c | 25 ++++++-------------------
>> 1 file changed, 6 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
>> index a9e0684..369b736 100644
>> --- a/drivers/net/ethernet/broadcom/tg3.c
>> +++ b/drivers/net/ethernet/broadcom/tg3.c
>> @@ -10629,10 +10629,8 @@ static void tg3_sd_scan_scratchpad(struct tg3 *tp, struct tg3_ocir *ocir)
>> static ssize_t tg3_show_temp(struct device *dev,
>> struct device_attribute *devattr, char *buf)
>> {
>> - struct pci_dev *pdev = to_pci_dev(dev);
>> - struct net_device *netdev = pci_get_drvdata(pdev);
>> - struct tg3 *tp = netdev_priv(netdev);
>> struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
>> + struct tg3 *tp = dev_get_drvdata(dev);
>
>
> Shouldn't this be
> struct tg3 *tp = netdev_priv(dev_get_drvdata(dev));
>
'struct tg3 *tp' is attached to the hwmon device in
hwmon_device_register_with_groups(), so it can be retrieved
with dev_get_drvdata() from there. Keep in mind that 'dev'
is no longer the pci device but the hwmon device.
Guenter
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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