* Re: Difficulties to get 1Gbps on be2net ethernet card
From: Eric Dumazet @ 2012-06-08 6:08 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: Sathya.Perla, netdev
In-Reply-To: <CAL8zT=i2EkZLz3J5ib1tLnOuXt=Buf0sCwr7UbQWRE3B4oB+JQ@mail.gmail.com>
On Thu, 2012-06-07 at 14:54 +0200, Jean-Michel Hautbois wrote:
> eth1 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d4
> UP BROADCAST RUNNING SLAVE MULTICAST MTU:4096 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:15215387 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:61476524359 (57.2 GiB)
> qdisc mq 0: dev eth1 root
> Sent 61476524359 bytes 15215387 pkt (dropped 45683472, overlimits 0
> requeues 17480)
OK, and "tc -s -d cl show dev eth1"
(How many queues are really used)
^ permalink raw reply
* Re: [PATCH] bonding: Fix corrupted queue_mapping
From: David Miller @ 2012-06-08 6:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <1339135057.6001.20.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 08 Jun 2012 07:57:37 +0200
> On Thu, 2012-06-07 at 22:05 -0700, Tom Herbert wrote:
>> In the transmit path of the bonding driver, skb->cb is used to
>> stash the skb->queue_mapping so that the bonding device can set its
>> own queue mapping. This value becomes corrupted since the skb->cb is
>> also used in __dev_xmit_skb.
>>
>> When transmitting through bonding driver, bond_select_queue is
>> called from dev_queue_xmit. In bond_select_queue the original
>> skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
>> and skb->queue_mapping is overwritten with the bond driver queue.
>> Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
>> the packet length into skb->cb, thereby overwriting the stashed
>> queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
>> the queue mapping for the skb is set to the stashed value which is now
>> the skb length and hence is an invalid queue for the slave device.
>>
>> Fix is to set bond_queue_mapping to skb->cb +
>> sizeof((struct qdisc_skb_cb)
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> drivers/net/bonding/bond_main.c | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 2ee8cf9..044c1c0 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -76,6 +76,7 @@
>> #include <net/route.h>
>> #include <net/net_namespace.h>
>> #include <net/netns/generic.h>
>> +#include <net/sch_generic.h>
>> #include "bonding.h"
>> #include "bond_3ad.h"
>> #include "bond_alb.h"
>> @@ -381,7 +382,8 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
>> return next;
>> }
>>
>> -#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb))
>> +#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb + \
>> + sizeof(struct qdisc_skb_cb)))
>>
>> /**
>> * bond_dev_queue_xmit - Prepare skb for xmit.
>
>
> Sorry this wont work in all cases.
>
> Some qdisc also use skb->cb[]
Hmmm, isn't that what qdisc_skb_cb is for? And even private data is
explicitly allocated:
> unsigned char data[24];
there. :-)
^ permalink raw reply
* Re: [PATCH] bonding: Fix corrupted queue_mapping
From: Eric Dumazet @ 2012-06-08 5:57 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1206072201200.13686@pokey.mtv.corp.google.com>
On Thu, 2012-06-07 at 22:05 -0700, Tom Herbert wrote:
> In the transmit path of the bonding driver, skb->cb is used to
> stash the skb->queue_mapping so that the bonding device can set its
> own queue mapping. This value becomes corrupted since the skb->cb is
> also used in __dev_xmit_skb.
>
> When transmitting through bonding driver, bond_select_queue is
> called from dev_queue_xmit. In bond_select_queue the original
> skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
> and skb->queue_mapping is overwritten with the bond driver queue.
> Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
> the packet length into skb->cb, thereby overwriting the stashed
> queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
> the queue mapping for the skb is set to the stashed value which is now
> the skb length and hence is an invalid queue for the slave device.
>
> Fix is to set bond_queue_mapping to skb->cb +
> sizeof((struct qdisc_skb_cb)
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/bonding/bond_main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 2ee8cf9..044c1c0 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -76,6 +76,7 @@
> #include <net/route.h>
> #include <net/net_namespace.h>
> #include <net/netns/generic.h>
> +#include <net/sch_generic.h>
> #include "bonding.h"
> #include "bond_3ad.h"
> #include "bond_alb.h"
> @@ -381,7 +382,8 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
> return next;
> }
>
> -#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb))
> +#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb + \
> + sizeof(struct qdisc_skb_cb)))
>
> /**
> * bond_dev_queue_xmit - Prepare skb for xmit.
Sorry this wont work in all cases.
Some qdisc also use skb->cb[]
maybe :
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 55ce96b..47cbfa2 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -220,6 +220,7 @@ struct tcf_proto {
struct qdisc_skb_cb {
unsigned int pkt_len;
+ unsigned int bond_queue_mapping;
unsigned char data[24];
};
^ permalink raw reply related
* [PATCH] net/sh-eth: Add support selecting MII function for SH7734 and R8A7740
From: Nobuhiro Iwamatsu @ 2012-06-08 6:01 UTC (permalink / raw)
To: netdev; +Cc: Nobuhiro Iwamatsu
Ethernet IP of SH7734 and R8A7740 has selecting MII register.
The user needs to change a value according to MII to be used.
This adds the function to change the value of this register.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 105 ++++++++++++++++++++-------------
drivers/net/ethernet/renesas/sh_eth.h | 1 +
2 files changed, 64 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index be3c221..e3d03c8 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -49,6 +49,33 @@
NETIF_MSG_RX_ERR| \
NETIF_MSG_TX_ERR)
+#if defined(CONFIG_CPU_SUBTYPE_SH7734) || defined(CONFIG_CPU_SUBTYPE_SH7763) || \
+ defined(CONFIG_ARCH_R8A7740)
+static void sh_eth_select_mii(struct net_device *ndev)
+{
+ u32 value = 0x0;
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+
+ switch (mdp->phy_interface) {
+ case PHY_INTERFACE_MODE_GMII:
+ value = 0x2;
+ break;
+ case PHY_INTERFACE_MODE_MII:
+ value = 0x1;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ value = 0x0;
+ break;
+ default:
+ pr_warn("PHY interface mode was not setup. Set to MII.\n");
+ value = 0x1;
+ break;
+ }
+
+ sh_eth_write(ndev, value, RMII_MII);
+}
+#endif
+
/* There is CPU dependent code */
#if defined(CONFIG_CPU_SUBTYPE_SH7724)
#define SH_ETH_RESET_DEFAULT 1
@@ -283,6 +310,7 @@ static struct sh_eth_cpu_data *sh_eth_get_cpu_data(struct sh_eth_private *mdp)
#elif defined(CONFIG_CPU_SUBTYPE_SH7734) || defined(CONFIG_CPU_SUBTYPE_SH7763)
#define SH_ETH_HAS_TSU 1
static void sh_eth_reset_hw_crc(struct net_device *ndev);
+
static void sh_eth_chip_reset(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
@@ -292,35 +320,6 @@ static void sh_eth_chip_reset(struct net_device *ndev)
mdelay(1);
}
-static void sh_eth_reset(struct net_device *ndev)
-{
- int cnt = 100;
-
- sh_eth_write(ndev, EDSR_ENALL, EDSR);
- sh_eth_write(ndev, sh_eth_read(ndev, EDMR) | EDMR_SRST_GETHER, EDMR);
- while (cnt > 0) {
- if (!(sh_eth_read(ndev, EDMR) & 0x3))
- break;
- mdelay(1);
- cnt--;
- }
- if (cnt == 0)
- printk(KERN_ERR "Device reset fail\n");
-
- /* Table Init */
- sh_eth_write(ndev, 0x0, TDLAR);
- sh_eth_write(ndev, 0x0, TDFAR);
- sh_eth_write(ndev, 0x0, TDFXR);
- sh_eth_write(ndev, 0x0, TDFFR);
- sh_eth_write(ndev, 0x0, RDLAR);
- sh_eth_write(ndev, 0x0, RDFAR);
- sh_eth_write(ndev, 0x0, RDFXR);
- sh_eth_write(ndev, 0x0, RDFFR);
-
- /* Reset HW CRC register */
- sh_eth_reset_hw_crc(ndev);
-}
-
static void sh_eth_set_duplex(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
@@ -377,9 +376,43 @@ static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
.tsu = 1,
#if defined(CONFIG_CPU_SUBTYPE_SH7734)
.hw_crc = 1,
+ .select_mii = 1,
#endif
};
+static void sh_eth_reset(struct net_device *ndev)
+{
+ int cnt = 100;
+
+ sh_eth_write(ndev, EDSR_ENALL, EDSR);
+ sh_eth_write(ndev, sh_eth_read(ndev, EDMR) | EDMR_SRST_GETHER, EDMR);
+ while (cnt > 0) {
+ if (!(sh_eth_read(ndev, EDMR) & 0x3))
+ break;
+ mdelay(1);
+ cnt--;
+ }
+ if (cnt == 0)
+ printk(KERN_ERR "Device reset fail\n");
+
+ /* Table Init */
+ sh_eth_write(ndev, 0x0, TDLAR);
+ sh_eth_write(ndev, 0x0, TDFAR);
+ sh_eth_write(ndev, 0x0, TDFXR);
+ sh_eth_write(ndev, 0x0, TDFFR);
+ sh_eth_write(ndev, 0x0, RDLAR);
+ sh_eth_write(ndev, 0x0, RDFAR);
+ sh_eth_write(ndev, 0x0, RDFXR);
+ sh_eth_write(ndev, 0x0, RDFFR);
+
+ /* Reset HW CRC register */
+ sh_eth_reset_hw_crc(ndev);
+
+ /* Select MII mode */
+ if (sh_eth_my_cpu_data.hw_crc)
+ sh_eth_select_mii(ndev);
+}
+
static void sh_eth_reset_hw_crc(struct net_device *ndev)
{
if (sh_eth_my_cpu_data.hw_crc)
@@ -397,19 +430,7 @@ static void sh_eth_chip_reset(struct net_device *ndev)
sh_eth_tsu_write(mdp, ARSTR_ARSTR, ARSTR);
mdelay(1);
- switch (mdp->phy_interface) {
- case PHY_INTERFACE_MODE_GMII:
- mii = 2;
- break;
- case PHY_INTERFACE_MODE_MII:
- mii = 1;
- break;
- case PHY_INTERFACE_MODE_RMII:
- default:
- mii = 0;
- break;
- }
- sh_eth_write(ndev, mii, RMII_MII);
+ sh_eth_select_mii(ndev);
}
static void sh_eth_reset(struct net_device *ndev)
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index 57b8e1f..d6763b1392 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -757,6 +757,7 @@ struct sh_eth_cpu_data {
unsigned no_trimd:1; /* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1; /* E-DMAC DO NOT have ADE bit in EESR */
unsigned hw_crc:1; /* E-DMAC have CSMR */
+ unsigned select_mii:1; /* EtherC have RMII_MII (MII select register) */
};
struct sh_eth_private {
--
1.7.10
^ permalink raw reply related
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Eric Dumazet @ 2012-06-08 5:47 UTC (permalink / raw)
To: Francois Romieu; +Cc: Denys Fedoryshchenko, davem, netdev, linux-kernel
In-Reply-To: <20120607223752.GA4475@electric-eye.fr.zoreil.com>
On Fri, 2012-06-08 at 00:37 +0200, Francois Romieu wrote:
> Eric Dumazet <eric.dumazet@gmail.com> :
> [...]
> > If LLTX is used, this means several cpus can execute this code at the
> > same time.
> >
> > You need percpu stats, or use atomic primitives.
>
> Would adding percpu stats not be frown upon ?
>
I have no idea how many l2tp_eth devices are setup at once in typical
conf.
> As atomic will defeat the 64 bits stats on 32 bits, I should probably stick
> to plain bh disabling lock.
>
Not sure what you mean by "atomic will defeat the 64 bits stats on 32
bits", since you also need atomic for "32 bits stats" or "64 bits stats
on 64 bit arches"
I personally would just use "unsigned long". If people want 64bit stats
for their l2tp_eth, they certainly can use a 64bit host.
^ permalink raw reply
* Re: [PATCH (net.git) V3] stmmac: fix driver built w/ w/o both pci and platf modules
From: David Miller @ 2012-06-08 5:47 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, wfg
In-Reply-To: <1339133107-29098-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 8 Jun 2012 07:25:07 +0200
> The commit ba27ec66ffeb78cbf fixes the Kconfig of the
> driver when built as module allowing to select/unselect
> the PCI and Platform modules that are not anymore mutually
> exclusive. This patch fixes and guarantees that the driver
> builds on all the platforms w/ w/o PCI and when select/unselect
> the two stmmac supports. In case of there are some problems
> on both the configuration and the pci/pltf registration the
> module_init will fail.
>
> v2: set the CONFIG_STMMAC_PLATFORM enabled by default.
> I've just noticed that this can actually help on
> some configurations that don't enable any STMMAC
> options by default (e.g. SPEAr).
>
> v3: change printk level when do not register the driver.
>
> Reported-by: Fengguang Wu <wfg@linux.intel.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: Fix corrupted queue_mapping
From: David Miller @ 2012-06-08 5:46 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.2.00.1206072201200.13686@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Thu, 7 Jun 2012 22:05:42 -0700 (PDT)
> @@ -381,7 +382,8 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
> return next;
> }
>
> -#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb))
> +#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb + \
> + sizeof(struct qdisc_skb_cb)))
>
> /**
> * bond_dev_queue_xmit - Prepare skb for xmit.
I know it's a little bit more work, but please declare a proper
datastructure which shows explicitly what's going on, like Infiniband
does in drivers/infiniband/ulp/ipoib/ipoib.h
struct bond_skb_cb {
struct qdisc_skb_cb qdisc_cb;
u16 queue_mapping;
};
Actually, this probably means there is also a conflict and thus
queue mapping corruption possible for bonded infiniband. :-/
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: Gao feng @ 2012-06-08 5:27 UTC (permalink / raw)
To: David Miller
Cc: steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w
In-Reply-To: <20120607.205348.913373847915721607.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
于 2012年06月08日 11:53, David Miller 写道:
> From: Gao feng <gaofeng@cn.fujitsu.com>
> Date: Fri, 08 Jun 2012 09:44:04 +0800
>
>> Sorry for my pool english, I don't understand this.
>> Can you explain it for me?
>
> Look at the end of the parts of the patch that change
> net/ipv4/inetpeer.c:
>
> @@ -586,3 +617,3 @@ out:
> write_sequnlock_bh(&base->lock);
> }
> EXPORT_SYMBOL(inetpeer_invalidate_tree);
>
> That makes no sense, it's a patch hunk with no "+" or "-"
> lines.
Thanks David,got it.
>
> Your patch was corrupted by something.
>
> This is extremely irritating. I would recommend that you email
> patches to yourself, and try to apply the copies you receive
> in those emails. Because that's what the people trying to use
> your patch are going to do.
>
Sorry, I will try it myself next time. ;)
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* [PATCH (net.git) V3] stmmac: fix driver built w/ w/o both pci and platf modules
From: Giuseppe CAVALLARO @ 2012-06-08 5:25 UTC (permalink / raw)
To: netdev; +Cc: wfg, davem, Giuseppe Cavallaro
In-Reply-To: <20120607.110130.1448306195184899614.davem@davemloft.net>
The commit ba27ec66ffeb78cbf fixes the Kconfig of the
driver when built as module allowing to select/unselect
the PCI and Platform modules that are not anymore mutually
exclusive. This patch fixes and guarantees that the driver
builds on all the platforms w/ w/o PCI and when select/unselect
the two stmmac supports. In case of there are some problems
on both the configuration and the pci/pltf registration the
module_init will fail.
v2: set the CONFIG_STMMAC_PLATFORM enabled by default.
I've just noticed that this can actually help on
some configurations that don't enable any STMMAC
options by default (e.g. SPEAr).
v3: change printk level when do not register the driver.
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 60 ++++++++++++++++++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++----
3 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 0076f77..9f44827 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -15,6 +15,7 @@ if STMMAC_ETH
config STMMAC_PLATFORM
bool "STMMAC Platform bus support"
depends on STMMAC_ETH
+ default y
---help---
This selects the platform specific bus support for
the stmmac device driver. This is the driver used
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 6d07ba2..e8afe7b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -26,6 +26,7 @@
#include <linux/clk.h>
#include <linux/stmmac.h>
#include <linux/phy.h>
+#include <linux/pci.h>
#include "common.h"
#ifdef CONFIG_STMMAC_TIMER
#include "stmmac_timer.h"
@@ -95,8 +96,6 @@ extern int stmmac_mdio_register(struct net_device *ndev);
extern void stmmac_set_ethtool_ops(struct net_device *netdev);
extern const struct stmmac_desc_ops enh_desc_ops;
extern const struct stmmac_desc_ops ndesc_ops;
-extern struct pci_driver stmmac_pci_driver;
-extern struct platform_driver stmmac_pltfr_driver;
int stmmac_freeze(struct net_device *ndev);
int stmmac_restore(struct net_device *ndev);
int stmmac_resume(struct net_device *ndev);
@@ -144,3 +143,60 @@ static inline int stmmac_clk_get(struct stmmac_priv *priv)
return 0;
}
#endif /* CONFIG_HAVE_CLK */
+
+
+#ifdef CONFIG_STMMAC_PLATFORM
+extern struct platform_driver stmmac_pltfr_driver;
+static inline int stmmac_register_platform(void)
+{
+ int err;
+
+ err = platform_driver_register(&stmmac_pltfr_driver);
+ if (err)
+ pr_err("stmmac: failed to register the platform driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_platform(void)
+{
+ platform_driver_register(&stmmac_pltfr_driver);
+}
+#else
+static inline int stmmac_register_platform(void)
+{
+ pr_debug("stmmac: do not register the platf driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_platform(void)
+{
+}
+#endif /* CONFIG_STMMAC_PLATFORM */
+
+#ifdef CONFIG_STMMAC_PCI
+extern struct pci_driver stmmac_pci_driver;
+static inline int stmmac_register_pci(void)
+{
+ int err;
+
+ err = pci_register_driver(&stmmac_pci_driver);
+ if (err)
+ pr_err("stmmac: failed to register the PCI driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_pci(void)
+{
+ pci_unregister_driver(&stmmac_pci_driver);
+}
+#else
+static inline int stmmac_register_pci(void)
+{
+ pr_debug("stmmac: do not register the PCI driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_pci(void)
+{
+}
+#endif /* CONFIG_STMMAC_PCI */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3638569..51b3b68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -42,7 +42,6 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/prefetch.h>
-#include <linux/pci.h>
#ifdef CONFIG_STMMAC_DEBUG_FS
#include <linux/debugfs.h>
#include <linux/seq_file.h>
@@ -2094,25 +2093,29 @@ int stmmac_restore(struct net_device *ndev)
}
#endif /* CONFIG_PM */
+/* Driver can be configured w/ and w/ both PCI and Platf drivers
+ * depending on the configuration selected.
+ */
static int __init stmmac_init(void)
{
- int err = 0;
+ int err_plt = 0;
+ int err_pci = 0;
- err = platform_driver_register(&stmmac_pltfr_driver);
+ err_plt = stmmac_register_platform();
+ err_pci = stmmac_register_pci();
- if (!err) {
- err = pci_register_driver(&stmmac_pci_driver);
- if (err)
- platform_driver_unregister(&stmmac_pltfr_driver);
+ if ((err_pci) && (err_plt)) {
+ pr_err("stmmac: driver registration failed\n");
+ return -EINVAL;
}
- return err;
+ return 0;
}
static void __exit stmmac_exit(void)
{
- pci_unregister_driver(&stmmac_pci_driver);
- platform_driver_unregister(&stmmac_pltfr_driver);
+ stmmac_unregister_platform();
+ stmmac_unregister_pci();
}
module_init(stmmac_init);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] usbnet: Activate the halt interrupt endpoint to fix endless "XactErr" error
From: Ming Lei @ 2012-06-08 5:22 UTC (permalink / raw)
To: Huajun Li; +Cc: David S. Miller, linux-usb, netdev
In-Reply-To: <CA+v9cxYvvRVWAUHX=b-P022pFbG1M7S=SZtOo2zfJnhAx5_+sQ@mail.gmail.com>
On Fri, Jun 8, 2012 at 1:04 PM, Huajun Li <huajun.li.lee@gmail.com> wrote:
> Ming, thanks for your comments.
Welcome, :-)
>
> On Fri, Jun 8, 2012 at 11:29 AM, Ming Lei <tom.leiming@gmail.com> wrote:
>> On Tue, Jun 5, 2012 at 10:12 PM, Huajun Li <huajun.li.lee@gmail.com> wrote:
>>> There prints endless "XactErr" error msg once switch my device to the
>>
>> The "XactErr" error msg means that there are some transfer error in the bus,
>> such as timeout, bad CRC, wrong PID, etc. Generally, -EPROTO is returned
>> to driver if this kind of error happened.
>>
> Yes, you pointed out the why there printed the error.
> However, how can this error(-EPROTO) happen? Actually, maybe it is
> caused by malfunction device, bad usb cable, or other issues. In my
> case, it is because the endpoint halts.
If so, looks mistaken value is returned from the host controller driver,
but not sure if your device is buggy. What is your host controller?
Also suppose your device is buggy, and the correct solution should
be addding quirk for the driver to clear halt before the 1st submit status
urb.
>
>>> configuration
>>> which needs cdc_ether driver, the root cause is the interrupt endpoint halts.
>>
>> How do you switch your configuration? by writing to
>> /sys/.../bConfigurationValue?
>>
>
> Maybe.
> I were using a third party application to switch the configurations,
> so I think it should use this way to do it unless there is other
> approach.
I just have tried to switch configuration by sysfs interface on the g_multi
and don't trigger the error.
>
>> Is the "XactErr" msg printed just after switching to cdc_ether interface
>> by changing configuration?
>>
>
> Yes, just as I mentioned in my original email.
> And it did not work even I removed the driver and re-installed it.
>
>>> Maybe this is a common issue, so fix it by activating the endpoint
>>> once the error occurs.
>>>
>>> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
>>> ---
>>> drivers/net/usb/usbnet.c | 33 +++++++++++++++++++++++++++++++++
>>> include/linux/usb/usbnet.h | 15 ++++++++-------
>>> 2 files changed, 41 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>>> index 9f58330..f13922b 100644
>>> --- a/drivers/net/usb/usbnet.c
>>> +++ b/drivers/net/usb/usbnet.c
>>> @@ -537,6 +537,11 @@ static void intr_complete (struct urb *urb)
>>> "intr shutdown, code %d\n", status);
>>> return;
>>>
>>> + case -EPIPE:
>>> + case -EPROTO:
>>
>> It is good to handle EPIPE error here, but looks it is no sense to
>> clear halt for
>> bus transfer failure. At least, no clear halt is done for returning -EPROTO from
>> rx/tx transfer currently.
>
> Just as I said above, there is different issue can cause -EPROTO, at
> least, for my case it is because the interrupt endpoint is not active.
> If the error occurs, the driver need try to fix it instead of just
> printing an error msg.
One problem in your patch is that if the -EPROTO is caused by bad cable
or interference, clean halt may not be sent to device successfully, and will
cause -EPROTO further.
>
>>
>>> + usbnet_defer_kevent(dev, EVENT_STS_HALT);
>>> + return;
>>> +
>>> /* NOTE: not throttling like RX/TX, since this endpoint
>>> * already polls infrequently
>>> */
>>> @@ -967,6 +972,34 @@ fail_halt:
>>> }
>>> }
>>>
>>> + if (test_bit(EVENT_STS_HALT, &dev->flags)) {
>>> + unsigned pipe;
>>> + struct usb_endpoint_descriptor *desc;
>>> +
>>> + desc = &dev->status->desc;
>>> + pipe = usb_rcvintpipe(dev->udev,
>>> + desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
>>> + status = usb_autopm_get_interface(dev->intf);
>>> + if (status < 0)
>>> + goto fail_sts;
>>> + status = usb_clear_halt(dev->udev, pipe);
>>> + usb_autopm_put_interface(dev->intf);
>>> +
>>> + if (status < 0 && status != -EPIPE && status != -ESHUTDOWN) {
>>> +fail_sts:
>>> + netdev_err(dev->net,
>>> + "can't clear intr halt, status %d\n", status);
>>> + } else {
>>> + clear_bit(EVENT_STS_HALT, &dev->flags);
>>> + memset(dev->interrupt->transfer_buffer, 0,
>>> + dev->interrupt->transfer_buffer_length);
>>
>> The above is not necessary.
>
> Ming, do you mean the above one line, or others ?
Yes, it is the above line.
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH] bonding: Fix corrupted queue_mapping
From: Tom Herbert @ 2012-06-08 5:05 UTC (permalink / raw)
To: davem, netdev
In the transmit path of the bonding driver, skb->cb is used to
stash the skb->queue_mapping so that the bonding device can set its
own queue mapping. This value becomes corrupted since the skb->cb is
also used in __dev_xmit_skb.
When transmitting through bonding driver, bond_select_queue is
called from dev_queue_xmit. In bond_select_queue the original
skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
and skb->queue_mapping is overwritten with the bond driver queue.
Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
the packet length into skb->cb, thereby overwriting the stashed
queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
the queue mapping for the skb is set to the stashed value which is now
the skb length and hence is an invalid queue for the slave device.
Fix is to set bond_queue_mapping to skb->cb +
sizeof((struct qdisc_skb_cb)
Signed-off-by: Tom Herbert <therbert@google.com>
---
drivers/net/bonding/bond_main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 2ee8cf9..044c1c0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -76,6 +76,7 @@
#include <net/route.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
+#include <net/sch_generic.h>
#include "bonding.h"
#include "bond_3ad.h"
#include "bond_alb.h"
@@ -381,7 +382,8 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
return next;
}
-#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb))
+#define bond_queue_mapping(skb) (*(u16 *)((skb)->cb + \
+ sizeof(struct qdisc_skb_cb)))
/**
* bond_dev_queue_xmit - Prepare skb for xmit.
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] usbnet: Activate the halt interrupt endpoint to fix endless "XactErr" error
From: Huajun Li @ 2012-06-08 5:04 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CACVXFVMwhoYyJHAsK0xF0poZxoZv8ENHhquPVAiGnsow5-FH8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ming, thanks for your comments.
On Fri, Jun 8, 2012 at 11:29 AM, Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Jun 5, 2012 at 10:12 PM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> There prints endless "XactErr" error msg once switch my device to the
>
> The "XactErr" error msg means that there are some transfer error in the bus,
> such as timeout, bad CRC, wrong PID, etc. Generally, -EPROTO is returned
> to driver if this kind of error happened.
>
Yes, you pointed out the why there printed the error.
However, how can this error(-EPROTO) happen? Actually, maybe it is
caused by malfunction device, bad usb cable, or other issues. In my
case, it is because the endpoint halts.
>> configuration
>> which needs cdc_ether driver, the root cause is the interrupt endpoint halts.
>
> How do you switch your configuration? by writing to
> /sys/.../bConfigurationValue?
>
Maybe.
I were using a third party application to switch the configurations,
so I think it should use this way to do it unless there is other
approach.
> Is the "XactErr" msg printed just after switching to cdc_ether interface
> by changing configuration?
>
Yes, just as I mentioned in my original email.
And it did not work even I removed the driver and re-installed it.
>> Maybe this is a common issue, so fix it by activating the endpoint
>> once the error occurs.
>>
>> Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/net/usb/usbnet.c | 33 +++++++++++++++++++++++++++++++++
>> include/linux/usb/usbnet.h | 15 ++++++++-------
>> 2 files changed, 41 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>> index 9f58330..f13922b 100644
>> --- a/drivers/net/usb/usbnet.c
>> +++ b/drivers/net/usb/usbnet.c
>> @@ -537,6 +537,11 @@ static void intr_complete (struct urb *urb)
>> "intr shutdown, code %d\n", status);
>> return;
>>
>> + case -EPIPE:
>> + case -EPROTO:
>
> It is good to handle EPIPE error here, but looks it is no sense to
> clear halt for
> bus transfer failure. At least, no clear halt is done for returning -EPROTO from
> rx/tx transfer currently.
Just as I said above, there is different issue can cause -EPROTO, at
least, for my case it is because the interrupt endpoint is not active.
If the error occurs, the driver need try to fix it instead of just
printing an error msg.
>
>> + usbnet_defer_kevent(dev, EVENT_STS_HALT);
>> + return;
>> +
>> /* NOTE: not throttling like RX/TX, since this endpoint
>> * already polls infrequently
>> */
>> @@ -967,6 +972,34 @@ fail_halt:
>> }
>> }
>>
>> + if (test_bit(EVENT_STS_HALT, &dev->flags)) {
>> + unsigned pipe;
>> + struct usb_endpoint_descriptor *desc;
>> +
>> + desc = &dev->status->desc;
>> + pipe = usb_rcvintpipe(dev->udev,
>> + desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
>> + status = usb_autopm_get_interface(dev->intf);
>> + if (status < 0)
>> + goto fail_sts;
>> + status = usb_clear_halt(dev->udev, pipe);
>> + usb_autopm_put_interface(dev->intf);
>> +
>> + if (status < 0 && status != -EPIPE && status != -ESHUTDOWN) {
>> +fail_sts:
>> + netdev_err(dev->net,
>> + "can't clear intr halt, status %d\n", status);
>> + } else {
>> + clear_bit(EVENT_STS_HALT, &dev->flags);
>> + memset(dev->interrupt->transfer_buffer, 0,
>> + dev->interrupt->transfer_buffer_length);
>
> The above is not necessary.
Ming, do you mean the above one line, or others ?
>
>> + status = usb_submit_urb(dev->interrupt, GFP_KERNEL);
>
> Before submitting urb, usb_autopm_get_interface is required to wakeup device.
>
Got it. Will check its context, thanks.
>> + if (status != 0)
>> + netif_err(dev, timer, dev->net,
>> + "intr resubmit --> %d\n", status);
>> + }
>> + }
>> +
>> /* tasklet could resubmit itself forever if memory is tight */
>> if (test_bit (EVENT_RX_MEMORY, &dev->flags)) {
>> struct urb *urb = NULL;
>> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
>> index 76f4396..c0bcb61 100644
>> --- a/include/linux/usb/usbnet.h
>> +++ b/include/linux/usb/usbnet.h
>> @@ -62,13 +62,14 @@ struct usbnet {
>> unsigned long flags;
>> # define EVENT_TX_HALT 0
>> # define EVENT_RX_HALT 1
>> -# define EVENT_RX_MEMORY 2
>> -# define EVENT_STS_SPLIT 3
>> -# define EVENT_LINK_RESET 4
>> -# define EVENT_RX_PAUSED 5
>> -# define EVENT_DEV_WAKING 6
>> -# define EVENT_DEV_ASLEEP 7
>> -# define EVENT_DEV_OPEN 8
>> +# define EVENT_STS_HALT 2
>> +# define EVENT_RX_MEMORY 3
>> +# define EVENT_STS_SPLIT 4
>> +# define EVENT_LINK_RESET 5
>> +# define EVENT_RX_PAUSED 6
>> +# define EVENT_DEV_WAKING 7
>> +# define EVENT_DEV_ASLEEP 8
>> +# define EVENT_DEV_OPEN 9
>> };
>>
>> static inline struct usb_driver *driver_of(struct usb_interface *intf)
>> --
>> 1.7.9.5
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the net-next tree
From: Stephen Rothwell @ 2012-06-08 3:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, AnilKumar Ch, David Miller, netdev,
Marc Kleine-Budde, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/net/can/c_can/c_can_platform.c between commit 33f810097769 ("can:
c_can: Move overlay structure to array with offset as index") from the
net-next tree and commit "net/c_can: remove conditional compilation of
clk code" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/can/c_can/c_can_platform.c
index f0921d1,7ec9316..0000000
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@@ -71,10 -71,8 +71,9 @@@ static int __devinit c_can_plat_probe(s
void __iomem *addr;
struct net_device *dev;
struct c_can_priv *priv;
+ const struct platform_device_id *id;
struct resource *mem;
int irq;
- #ifdef CONFIG_HAVE_CLK
struct clk *clk;
/* get the appropriate clk */
@@@ -138,18 -129,8 +136,16 @@@
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
break;
+ default:
+ ret = -EINVAL;
+ goto exit_free_device;
}
+ dev->irq = irq;
+ priv->base = addr;
- #ifdef CONFIG_HAVE_CLK
+ priv->can.clock.freq = clk_get_rate(clk);
+ priv->priv = clk;
- #endif
+
platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: David Miller @ 2012-06-08 3:53 UTC (permalink / raw)
To: gaofeng
Cc: serge.hallyn, ebiederm, herbert, steffen.klassert, eric.dumazet,
netdev, containers
In-Reply-To: <4FD158E4.1080701@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Fri, 08 Jun 2012 09:44:04 +0800
> Sorry for my pool english, I don't understand this.
> Can you explain it for me?
Look at the end of the parts of the patch that change
net/ipv4/inetpeer.c:
@@ -586,3 +617,3 @@ out:
write_sequnlock_bh(&base->lock);
}
EXPORT_SYMBOL(inetpeer_invalidate_tree);
That makes no sense, it's a patch hunk with no "+" or "-"
lines.
Your patch was corrupted by something.
This is extremely irritating. I would recommend that you email
patches to yourself, and try to apply the copies you receive
in those emails. Because that's what the people trying to use
your patch are going to do.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Jason Wang @ 2012-06-08 3:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20120607221911.GD16235@redhat.com>
On 06/08/2012 06:19 AM, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2012 at 03:52:17PM +0800, Jason Wang wrote:
>> > Satistics counters is useful for debugging and performance optimization, so this
>> > patch lets virtio_net driver collect following and export them to userspace
>> > through "ethtool -S":
>> >
>> > - number of packets sent/received
>> > - number of bytes sent/received
>> > - number of callbacks for tx/rx
>> > - number of kick for tx/rx
>> > - number of bytes/packets queued for tx
>> >
>> > As virtnet_stats were per-cpu, so both per-cpu and gloabl satistics were
>> > collected like:
>> >
>> > NIC statistics:
>> > tx_bytes[0]: 1731209929
>> > tx_packets[0]: 60685
>> > tx_kicks[0]: 63
>> > tx_callbacks[0]: 73
>> > tx_queued_bytes[0]: 1935749360
>> > tx_queued_packets[0]: 80652
>> > rx_bytes[0]: 2695648
>> > rx_packets[0]: 40767
>> > rx_kicks[0]: 1
>> > rx_callbacks[0]: 2077
>> > tx_bytes[1]: 9105588697
>> > tx_packets[1]: 344150
>> > tx_kicks[1]: 162
>> > tx_callbacks[1]: 905
>> > tx_queued_bytes[1]: 8901049412
>> > tx_queued_packets[1]: 324184
>> > rx_bytes[1]: 23679828
>> > rx_packets[1]: 358770
>> > rx_kicks[1]: 6
>> > rx_callbacks[1]: 17717
>> > tx_bytes: 10836798626
>> > tx_packets: 404835
>> > tx_kicks: 225
>> > tx_callbacks: 978
>> > tx_queued_bytes: 10836798772
>> > tx_queued_packets: 404836
>> > rx_bytes: 26375476
>> > rx_packets: 399537
>> > rx_kicks: 7
>> > rx_callbacks: 19794
>> >
>> > TODO:
>> >
>> > - more statistics
>> > - calculate the pending bytes/pkts
>> >
>> > Signed-off-by: Jason Wang<jasowang@redhat.com>
>> >
>> > ---
>> > Changes from v1:
>> >
>> > - style& typo fixs
>> > - convert the statistics fields to array
>> > - use unlikely()
>> > ---
>> > drivers/net/virtio_net.c | 115 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 files changed, 113 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> > index 6e4aa6f..909a0a7 100644
>> > --- a/drivers/net/virtio_net.c
>> > +++ b/drivers/net/virtio_net.c
>> > @@ -44,8 +44,14 @@ module_param(gso, bool, 0444);
>> > enum virtnet_stats_type {
>> > VIRTNET_TX_BYTES,
>> > VIRTNET_TX_PACKETS,
>> > + VIRTNET_TX_KICKS,
>> > + VIRTNET_TX_CBS,
>> > + VIRTNET_TX_Q_BYTES,
>> > + VIRTNET_TX_Q_PACKETS,
>> > VIRTNET_RX_BYTES,
>> > VIRTNET_RX_PACKETS,
>> > + VIRTNET_RX_KICKS,
>> > + VIRTNET_RX_CBS,
>> > VIRTNET_NUM_STATS,
>> > };
>> >
>> > @@ -54,6 +60,21 @@ struct virtnet_stats {
>> > u64 data[VIRTNET_NUM_STATS];
>> > };
>> >
>> > +static struct {
>> > + char string[ETH_GSTRING_LEN];
>> > +} virtnet_stats_str_attr[] = {
>> > + { "tx_bytes" },
>> > + { "tx_packets" },
>> > + { "tx_kicks" },
>> > + { "tx_callbacks" },
>> > + { "tx_queued_bytes" },
>> > + { "tx_queued_packets" },
>> > + { "rx_bytes" },
>> > + { "rx_packets" },
>> > + { "rx_kicks" },
>> > + { "rx_callbacks" },
>> > +};
>> > +
>> > struct virtnet_info {
>> > struct virtio_device *vdev;
>> > struct virtqueue *rvq, *svq, *cvq;
>> > @@ -146,6 +167,11 @@ static struct page *get_a_page(struct virtnet_info *vi, gfp_t gfp_mask)
>> > static void skb_xmit_done(struct virtqueue *svq)
>> > {
>> > struct virtnet_info *vi = svq->vdev->priv;
>> > + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>> > +
>> > + u64_stats_update_begin(&stats->syncp);
>> > + stats->data[VIRTNET_TX_CBS]++;
>> > + u64_stats_update_end(&stats->syncp);
>> >
>> > /* Suppress further interrupts. */
>> > virtqueue_disable_cb(svq);
>> > @@ -465,6 +491,7 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
>> > {
>> > int err;
>> > bool oom;
>> > + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>> >
>> > do {
>> > if (vi->mergeable_rx_bufs)
>> > @@ -481,13 +508,24 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
>> > } while (err> 0);
>> > if (unlikely(vi->num> vi->max))
>> > vi->max = vi->num;
>> > - virtqueue_kick(vi->rvq);
>> > + if (virtqueue_kick_prepare(vi->rvq)) {
>> > + virtqueue_notify(vi->rvq);
>> > + u64_stats_update_begin(&stats->syncp);
>> > + stats->data[VIRTNET_RX_KICKS]++;
>> > + u64_stats_update_end(&stats->syncp);
>> > + }
>> > return !oom;
>> > }
>> >
>> > static void skb_recv_done(struct virtqueue *rvq)
>> > {
>> > struct virtnet_info *vi = rvq->vdev->priv;
>> > + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>> > +
>> > + u64_stats_update_begin(&stats->syncp);
>> > + stats->data[VIRTNET_RX_CBS]++;
>> > + u64_stats_update_end(&stats->syncp);
>> > +
>> > /* Schedule NAPI, Suppress further interrupts if successful. */
>> > if (napi_schedule_prep(&vi->napi)) {
>> > virtqueue_disable_cb(rvq);
>> > @@ -630,7 +668,9 @@ static int xmit_skb(struct virtnet_info *vi, struct sk_buff *skb)
>> > static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
>> > {
>> > struct virtnet_info *vi = netdev_priv(dev);
>> > + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>> > int capacity;
>> > + bool kick;
>> >
>> > /* Free up any pending old buffers before queueing new ones. */
>> > free_old_xmit_skbs(vi);
>> > @@ -655,7 +695,17 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
>> > kfree_skb(skb);
>> > return NETDEV_TX_OK;
>> > }
>> > - virtqueue_kick(vi->svq);
>> > +
>> > + kick = virtqueue_kick_prepare(vi->svq);
>> > + if (unlikely(kick))
>> > + virtqueue_notify(vi->svq);
>> > +
>> > + u64_stats_update_begin(&stats->syncp);
>> > + if (unlikely(kick))
>> > + stats->data[VIRTNET_TX_KICKS]++;
>> > + stats->data[VIRTNET_TX_Q_BYTES] += skb->len;
>> > + stats->data[VIRTNET_TX_Q_PACKETS]++;
> is this statistic interesting?
> how about decrementing when we free?
> this way we see how many are pending..
>
Currently we didn't have per-vq statistics but per-cpu, so the skb could
be sent by one vcpu and freed by another.
Pehaps another reason to use per-queue satistics.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Jason Wang @ 2012-06-08 3:33 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rick Jones, mst, netdev, linux-kernel, virtualization,
David Miller
In-Reply-To: <1339102567.2770.25.camel@bwh-desktop.uk.solarflarecom.com>
On 06/08/2012 04:56 AM, Ben Hutchings wrote:
> On Thu, 2012-06-07 at 13:39 -0700, Rick Jones wrote:
>> On 06/07/2012 01:24 PM, Ben Hutchings wrote:
>>> On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
>>>> From: Ben Hutchings<bhutchings@solarflare.com>
>>>> Date: Thu, 7 Jun 2012 18:15:06 +0100
>>>>
>>>>> I would really like to see some sort of convention for presenting
>>>>> per-queue statistics through ethtool. At the moment we have a complete
>>>>> mess of different formats:
>>>> Indeed. Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
>>>> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
>>>> etc.
>>> I think we should leave the type names open-ended, as there are other
>>> useful groupings like per-virtual-port. In that case the separator
>>> should be chosen to allow arbitrary type names without ambiguity.
>> So you mean like something along the lines of the presence of say '.'
>> indicating indent a level:
>>
>> rx_bytes: 1234
>> myqueue1.rx_bytes: 234
>> myqueue2.rx_bytes: 345
>> ...
> Most drivers seem to want this sort of ordering/grouping:
>
> group0.foo
> group0.bar
> ...
> group1.foo
> group1.bar
> ...
>
> but if we have a standard way of indicating groups of statistics then
> the user can choose whether they want to reorder by type name.
>
> Ben.
>
Yes, it looks to me that the per-queue satistics were better:
- Simple and less synchronization.
- Good for future virtio-net multiqueue merging.
^ permalink raw reply
* Re: [PATCH] usbnet: Activate the halt interrupt endpoint to fix endless "XactErr" error
From: Ming Lei @ 2012-06-08 3:29 UTC (permalink / raw)
To: Huajun Li
Cc: David S. Miller, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+v9cxYHq4gcy11SDmsuHUhTSdLJM-G0sugYnOjSthbYWA+1Yg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jun 5, 2012 at 10:12 PM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> There prints endless "XactErr" error msg once switch my device to the
The "XactErr" error msg means that there are some transfer error in the bus,
such as timeout, bad CRC, wrong PID, etc. Generally, -EPROTO is returned
to driver if this kind of error happened.
> configuration
> which needs cdc_ether driver, the root cause is the interrupt endpoint halts.
How do you switch your configuration? by writing to
/sys/.../bConfigurationValue?
Is the "XactErr" msg printed just after switching to cdc_ether interface
by changing configuration?
> Maybe this is a common issue, so fix it by activating the endpoint
> once the error occurs.
>
> Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/usb/usbnet.c | 33 +++++++++++++++++++++++++++++++++
> include/linux/usb/usbnet.h | 15 ++++++++-------
> 2 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 9f58330..f13922b 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -537,6 +537,11 @@ static void intr_complete (struct urb *urb)
> "intr shutdown, code %d\n", status);
> return;
>
> + case -EPIPE:
> + case -EPROTO:
It is good to handle EPIPE error here, but looks it is no sense to
clear halt for
bus transfer failure. At least, no clear halt is done for returning -EPROTO from
rx/tx transfer currently.
> + usbnet_defer_kevent(dev, EVENT_STS_HALT);
> + return;
> +
> /* NOTE: not throttling like RX/TX, since this endpoint
> * already polls infrequently
> */
> @@ -967,6 +972,34 @@ fail_halt:
> }
> }
>
> + if (test_bit(EVENT_STS_HALT, &dev->flags)) {
> + unsigned pipe;
> + struct usb_endpoint_descriptor *desc;
> +
> + desc = &dev->status->desc;
> + pipe = usb_rcvintpipe(dev->udev,
> + desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
> + status = usb_autopm_get_interface(dev->intf);
> + if (status < 0)
> + goto fail_sts;
> + status = usb_clear_halt(dev->udev, pipe);
> + usb_autopm_put_interface(dev->intf);
> +
> + if (status < 0 && status != -EPIPE && status != -ESHUTDOWN) {
> +fail_sts:
> + netdev_err(dev->net,
> + "can't clear intr halt, status %d\n", status);
> + } else {
> + clear_bit(EVENT_STS_HALT, &dev->flags);
> + memset(dev->interrupt->transfer_buffer, 0,
> + dev->interrupt->transfer_buffer_length);
The above is not necessary.
> + status = usb_submit_urb(dev->interrupt, GFP_KERNEL);
Before submitting urb, usb_autopm_get_interface is required to wakeup device.
> + if (status != 0)
> + netif_err(dev, timer, dev->net,
> + "intr resubmit --> %d\n", status);
> + }
> + }
> +
> /* tasklet could resubmit itself forever if memory is tight */
> if (test_bit (EVENT_RX_MEMORY, &dev->flags)) {
> struct urb *urb = NULL;
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index 76f4396..c0bcb61 100644
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -62,13 +62,14 @@ struct usbnet {
> unsigned long flags;
> # define EVENT_TX_HALT 0
> # define EVENT_RX_HALT 1
> -# define EVENT_RX_MEMORY 2
> -# define EVENT_STS_SPLIT 3
> -# define EVENT_LINK_RESET 4
> -# define EVENT_RX_PAUSED 5
> -# define EVENT_DEV_WAKING 6
> -# define EVENT_DEV_ASLEEP 7
> -# define EVENT_DEV_OPEN 8
> +# define EVENT_STS_HALT 2
> +# define EVENT_RX_MEMORY 3
> +# define EVENT_STS_SPLIT 4
> +# define EVENT_LINK_RESET 5
> +# define EVENT_RX_PAUSED 6
> +# define EVENT_DEV_WAKING 7
> +# define EVENT_DEV_ASLEEP 8
> +# define EVENT_DEV_OPEN 9
> };
>
> static inline struct usb_driver *driver_of(struct usb_interface *intf)
> --
> 1.7.9.5
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Greg KH @ 2012-06-08 2:15 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, tarbal, rkagan, stable, jesse.brandeburg,
bruce.w.allan, carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak, dnelson,
e1000-devel, netdev, linux-kernel
In-Reply-To: <20120607.144358.1732928576389957779.davem@davemloft.net>
On Thu, Jun 07, 2012 at 02:43:58PM -0700, David Miller wrote:
> From: Jeff Kirsher <tarbal@gmail.com>
> Date: Thu, 07 Jun 2012 14:38:17 -0700
>
> > Thanks! I have applied the patch to my queue
>
> Why?
>
> My impression is that this is a patch already in the tree, and it's
> being submitted for -stable but such minor performance hacks are
> absolutely not appropriate for -stable submission.
The patch description says it is fixing reported oopses, but the
Subject: isn't all that helpful there.
So which is this? Should I accept it for a stable release or not?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: Gao feng @ 2012-06-08 1:44 UTC (permalink / raw)
To: David Miller
Cc: steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w
In-Reply-To: <20120607.144301.1259354794384347085.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
于 2012年06月08日 05:43, David Miller 写道:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 06 Jun 2012 10:43:23 -0700 (PDT)
>
>> So I'm dropping these two patches and will work on the mentioned
>> approach to this fix.
>
> It turns out that even if I move the inetpeer roots into the FIB rules
> layer, we still need your changes Gao.
>
> But your patches are corrupted. For example, in this patch,
> the final hunk for net/ipv4/inetpeer.c has no differences only
> context. That's an extremely corrupted patch.
Sorry for my pool english, I don't understand this.
Can you explain it for me?
>
> Please resolve this, and add the NULL pointer settings during network
> namespace shutdown that Eric Dumazet asked for.
OK, I will do it.
Thanks.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: tg3: transmit timed out, resetting
From: Ethan Zhao @ 2012-06-08 1:24 UTC (permalink / raw)
To: Matt Carlson; +Cc: Eric Dumazet, Christian Kujau, LKML, netdev
In-Reply-To: <20120607225654.GA14247@mcarlson.broadcom.com>
Matt,
I notice there are some AER errors ( UnsupReq+,RxErr+) with the tg3
from Christian' lspci output, do you know why and how to clear them ?
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
Thanks,
Ethan
On Fri, Jun 8, 2012 at 6:56 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Wed, Jun 06, 2012 at 12:52:32PM +0800, ethan zhao wrote:
>> Eric,
>> That is ask for confirmation from Matt Carlson of Broadcom.
>>
>> Ethan
>>
>> On Wed, Jun 6, 2012 at 12:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Wed, 2012-06-06 at 10:29 +0800, ethan zhao wrote:
>> >> So no way to fix it via firmware update or Linux driver ? :<
>> >
>> > Yes, but you need to cooperate, or else it might take more time than
>> > necessary.
>> >
>> > Asking questions like that on lkml is not going to help very much.
>> >
>> > So, once again, we kindly ask you try a recent kernel and post
>> > register dump and some additional information when transmit timeouts
>> > happen.
>> >
>> > The 'latest kernel' is either linux-3.5.rc1, or one of David Miller
>> > tree :
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=summary
>> >
>> > or
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=summary
>> >
>> > Thanks
>
> Does the following patch fix your problem?
>
>
> [PATCH] tg3: Apply short DMA frag workaround to 5906
>
> 5906 devices also need the short DMA fragment workaround. This patch
> makes the necessary change.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index d55df32..2db4d70 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -14275,7 +14275,8 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
> }
> }
>
> - if (tg3_flag(tp, 5755_PLUS))
> + if (tg3_flag(tp, 5755_PLUS) ||
> + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
> tg3_flag_set(tp, SHORT_DMA_BUG);
>
> if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719)
> --
> 1.7.3.4
>
>
^ permalink raw reply
* Re: netperf and endianness
From: David Miller @ 2012-06-08 1:20 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <4FD1525E.5020707@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 07 Jun 2012 18:16:14 -0700
> netperf sends things in network byte order. It is all burried in
> send/recv_request and send/recv_response (in src/netlib.c).
Aha, I was grepping for things like ENDIAN when I should have
grepped for htonl() :-)
> Over the years I've run netperf between different endian systems
> with success. Chances are good that there is a netperf version
> mismatch between the sides - at least 99 times out of 10 that is
> what is happening when netperf doesn't work (other than with
> firewalls in place).
Indeed, you are right. I was trying to speak to 2.4.4 using
2.5.0 :-)
Thanks!
^ permalink raw reply
* Re: netperf and endianness
From: Rick Jones @ 2012-06-08 1:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120607.180948.471478622905736125.davem@davemloft.net>
On 06/07/2012 06:09 PM, David Miller wrote:
>
> Rick, I tried to use netperf between my x86-64 and sparc64 systems and
> nothing works.
>
> Does netperf do it's messaging in cpu byte order only?
>
> I don't see anything in netperf-2.5.x that translates into and out of
> network byte order :-/
David -
netperf sends things in network byte order. It is all burried in
send/recv_request and send/recv_response (in src/netlib.c). Over the
years I've run netperf between different endian systems with success.
Chances are good that there is a netperf version mismatch between the
sides - at least 99 times out of 10 that is what is happening when
netperf doesn't work (other than with firewalls in place).
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH] e1000e: disable rxhash when try to enable jumbo frame also rxhash and rxcsum have enabled
From: Allan, Bruce W @ 2012-06-08 1:14 UTC (permalink / raw)
To: David Miller, joe.jin@oracle.com
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Brandeburg, Jesse, adnan.misherfi@oracle.com,
guru.anbalagane@oracle.com, Ronciak, John,
linux-kernel@vger.kernel.org
In-Reply-To: <20120607.181143.231727418873766540.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, June 07, 2012 6:12 PM
> To: joe.jin@oracle.com
> Cc: e1000-devel@lists.sourceforge.net; guru.anbalagane@oracle.com;
> Allan, Bruce W; Brandeburg, Jesse; adnan.misherfi@oracle.com; Ronciak,
> John; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [E1000-devel] [PATCH] e1000e: disable rxhash when try to
> enable jumbo frame also rxhash and rxcsum have enabled
>
> From: Joe Jin <joe.jin@oracle.com>
> Date: Fri, 08 Jun 2012 09:06:40 +0800
>
> > Upstream commit 70495a5 check if both rxhash and rxcsum enabled when
> enabling
> > jumbo frames and disallowed all of them enabled at the same time.
> >
> > Since jumbo frame widely be used in real world, so when try to
> enable jumbo
> > frames but rxhash and rxcsum have enabled, change the default
> behavior to
> > disable receive hashing.
> >
> > Signed-off-by: Joe Jin <joe.jin@oracle.com>
> > Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
> > Acked-by: Adnan Misherfi <adnan.misherfi@oracle.com>
>
> If I were the Intel developers I would not apply this patch, it sets
> a very bad precedence.
>
> The tool tells you that the combination you're attempting to use is
> invalid, and the kernel log message tells you exactly why.
>
> The driver should never automatically change configuration settings
> not actually requested by the user.
I've been working on another patch that removes the issue with disabling
one feature over another altogether, so this patch would be moot. It will
be pushed to our internal testing organization in the next day or two.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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
* Re: [PATCH] e1000e: disable rxhash when try to enable jumbo frame also rxhash and rxcsum have enabled
From: David Miller @ 2012-06-08 1:11 UTC (permalink / raw)
To: joe.jin
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
guru.anbalagane, adnan.misherfi, e1000-devel, linux-kernel,
netdev
In-Reply-To: <4FD15020.7090709@oracle.com>
From: Joe Jin <joe.jin@oracle.com>
Date: Fri, 08 Jun 2012 09:06:40 +0800
> Upstream commit 70495a5 check if both rxhash and rxcsum enabled when enabling
> jumbo frames and disallowed all of them enabled at the same time.
>
> Since jumbo frame widely be used in real world, so when try to enable jumbo
> frames but rxhash and rxcsum have enabled, change the default behavior to
> disable receive hashing.
>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
> Acked-by: Adnan Misherfi <adnan.misherfi@oracle.com>
If I were the Intel developers I would not apply this patch, it sets
a very bad precedence.
The tool tells you that the combination you're attempting to use is
invalid, and the kernel log message tells you exactly why.
The driver should never automatically change configuration settings
not actually requested by the user.
^ permalink raw reply
* netperf and endianness
From: David Miller @ 2012-06-08 1:09 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
Rick, I tried to use netperf between my x86-64 and sparc64 systems and
nothing works.
Does netperf do it's messaging in cpu byte order only?
I don't see anything in netperf-2.5.x that translates into and out of
network byte order :-/
^ 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