* Re: [PATCH net-next v3] packet: tx_ring: allow the user to choose tx data offset
From: David Miller @ 2012-11-07 23:55 UTC (permalink / raw)
To: Paul.Chavent; +Cc: netdev
In-Reply-To: <1352279447-2980-1-git-send-email-paul.chavent@onera.fr>
From: Paul Chavent <Paul.Chavent@onera.fr>
Date: Wed, 7 Nov 2012 10:10:47 +0100
> The tx data offset of packet mmap tx ring used to be :
> (TPACKET2_HDRLEN - sizeof(struct sockaddr_ll))
>
> The problem is that, with SOCK_RAW socket, the payload (14 bytes after
> the beginning of the user data) is misaligned.
>
> This patch allows to let the user gives an offset for it's tx data if
> he desires.
>
> Set sock option PACKET_TX_HAS_OFF to 1, then specify in each frame of
> your tx ring tp_net for SOCK_DGRAM, or tp_mac for SOCK_RAW.
>
> Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
Applied, thanks.
^ permalink raw reply
* Re: [net-next patch 0/2] bnx2x: Enable cnic at run-time
From: David Miller @ 2012-11-07 23:57 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong
In-Reply-To: <1352285148-21784-1-git-send-email-meravs@broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Wed, 7 Nov 2012 12:45:46 +0200
> This patch series removes the BCM_CNIC bnx2x define, and eliminates the use of
> the CONFIG_CNIC kconfig option.
> The define removal is mainly important for SR-IOV, as the VF driver will use the
> same code as the PF/hypervisor driver. Since storage is not supported in
> SR-IOV (while is usually enabled in the non SR-IOV driver), we don't want to
> waste resources on it.
> After this change, cnic-related resources are allocated only when the cnic
> module registers with bnx2x (which means that the user asked for storage
> services). Also only at this stage the HW is configured to non-NIC (offload)
> mode.
> The first patch is the driver-FW HSI addition to change the 'update' ramrod for
> offload mode configuration at run-time.
> The second patch is for the removal of the BCM_CNIC define, and for separating
> the load flow to two stages, one for L2 and one for cnic-related stuff.
>
> Please consider applying this patch series to net-next.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES
From: David Miller @ 2012-11-07 23:59 UTC (permalink / raw)
To: lee.jones; +Cc: linux-kernel, isdn, netdev
In-Reply-To: <1352282103-13665-1-git-send-email-lee.jones@linaro.org>
From: Lee Jones <lee.jones@linaro.org>
Date: Wed, 7 Nov 2012 10:55:03 +0100
> It doesn't make much sense to enable ISDN services if you don't
> intend to connect to a network. Therefore insisting that ISDN
> depends on NETDEVICES seems logical. We can then remove any
> guards mentioning NETDEVICES inside all subordinate drivers.
>
> This also has the nice side-effect of fixing the warning below
> when ISDN_I4L && !CONFIG_NETDEVICES at compile time.
>
> This patch fixes:
> drivers/isdn/i4l/isdn_common.c: In function ‘isdn_ioctl’:
> drivers/isdn/i4l/isdn_common.c:1278:8: warning: unused variable ‘s’ [-Wunused-variable]
>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH -next] ksz884x: use module_pci_driver to simplify the code
From: David Miller @ 2012-11-08 0:01 UTC (permalink / raw)
To: weiyj.lk; +Cc: yongjun_wei, netdev
In-Reply-To: <CAPgLHd8mrDXyiJ4rNFLHsYWEreVRiKXwqqr7umtSY36RkzXjUA@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 7 Nov 2012 20:54:30 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Use the module_pci_driver() macro to make the code simpler
> by eliminating module_init and module_exit calls.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Fix initialization of SGE_CONTROL register
From: David Miller @ 2012-11-08 0:02 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, jay
In-Reply-To: <1352295946-32146-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Wed, 7 Nov 2012 19:15:46 +0530
> INGPADBOUNDARY_MASK is already shifted. No need to shift it again. On reloading
> a driver it was resulting in a bad SGE FL MTU sizes [1536, 9088] error. This
> only causes an issue on systems that have L1 cache size of 32B, 128B, 512B,
> 2048B or 4096B.
>
> Signed-off-by: Jay Hernandez <jay@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH trivial] ndisc: fix a typo in a comment in ndisc_recv_na()
From: David Miller @ 2012-11-08 0:03 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1352300738-3851-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 7 Nov 2012 16:05:38 +0100
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: pull request: batman-adv 2012-11-07
From: David Miller @ 2012-11-08 0:10 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1352315502-20324-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Wed, 7 Nov 2012 20:11:30 +0100
> Hello David,
>
> first of all thank you for having made us aware of the packet format problem in
> batman-adv! The impact of __packed on performances was not entirely known to me,
> in particular for what concerns the RISC arch.
>
> We have to change a number of packet formats before we can remove __packed
> everywhere which will obviously break compatibility.
>
> However we already scheduled a compatibility break because we want to
> heavily improve our packet formats and to provide a more flexible framework that
> would allow us to add new types and features while reducing the probability of
> breaking compatibility again and again as happened in the past (we are
> implementing TypeLengthValue (TLV) containers among other things).
>
> To avoid breaking compatibility (at least) twice we decided to fix now (in this
> patchset) what is fixable with no consequences to compatibility while we would
> ilike to defer the remaining changes for the scheduled compatibility break.
>
> In this patchset you have the two new features intended for net-next/linux-3.8:
> 1) the new UNICAST_4ADDR packet type
> 2) the Distributed ARP Table (DAT) component
>
> The new packet type has been reviewed to entirely address the alignment issue.
> At the same time we also reviewed the other packet types but as I told you
> before, we will send these changes later.
>
> Other than that you have patch 02/12 that removes the __packed attribute from
> the structures where it was not really needed.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Ben Hutchings @ 2012-11-08 0:23 UTC (permalink / raw)
To: Brian Haley
Cc: Pavel Emelyanov, David Miller, Eric Dumazet,
netdev@vger.kernel.org
In-Reply-To: <50988BAE.6020602@hp.com>
On Mon, 2012-11-05 at 21:01 -0700, Brian Haley wrote:
> On 11/02/2012 05:34 PM, Ben Hutchings wrote:
> > On Fri, 2012-11-02 at 11:02 -0400, Brian Haley wrote:
> >> On 11/02/2012 05:36 AM, Pavel Emelyanov wrote:
> >>>> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> >>>> + int __user *optlen, int len)
> >>>> +{
> >>>> + int ret = -ENOPROTOOPT;
> >>>> +#ifdef CONFIG_NETDEVICES
> >>>> + struct net *net = sock_net(sk);
> >>>> + struct net_device *dev;
> >>>> + char devname[IFNAMSIZ];
> >>>> +
> >>>> + if (sk->sk_bound_dev_if == 0) {
> >>>> + len = 0;
> >>>> + goto zero;
> >>>> + }
> >>>> +
> >>>> + ret = -EINVAL;
> >>>> + if (len < IFNAMSIZ)
> >>>> + goto out;
> >>>> +
> >>>> + rcu_read_lock();
> >>>> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
> >>>> + if (dev)
> >>>> + strcpy(devname, dev->name);
> >>>
> >>> This still races with the device name change, potentially providing
> >>> a name which never existed in the system, doesn't it?
> >>
> >> My only argument here is that SIOCGIFNAME has had this same code forever, and
> >> noone has ever complained about that returning a garbled name. Even
> >> dev_get_by_name() only holds an rcu lock when doing a strncmp().
> >>
> >> We'd need to audit the whole kernel to catch all the places where we potentially
> >> look at dev->name while it could change. Is it really worth it?
> >
> > A net device name can't be changed while the device is up, or while
> > another task holds the RTNL lock. I think that covers almost all uses.
> > I don't know whether it's worth going out to look for exceptions, but we
> > might as well fix the cases we know about.
>
> So do you think we can fix these corner cases later and get the API
> right first?
Well you can avoid the problem here by using rtnl_{,un}lock() and
__dev_get_by_index(). But if that's too heavyweight (it depends on how
often you think this might need to be called) then I suppose it can be
left until we have a general solution for races with renaming.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2 2/2] net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi, linux-usb, netdev; +Cc: Ian Coolidge
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge@gmail.com>
cdc_eem frames might need to contain 802.1Q VLAN Ethernet frames.
URB/skb sizing from usbnet will default to the hard_mtu,
so account for the VLAN header by expanding that via hard_header_len
Signed-off-by: Ian Coolidge <iancoolidge@gmail.com>
---
drivers/net/usb/cdc_eem.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index c81e278..08d55b6 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -31,6 +31,7 @@
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
#include <linux/gfp.h>
+#include <linux/if_vlan.h>
/*
@@ -92,7 +93,7 @@ static int eem_bind(struct usbnet *dev, struct usb_interface *intf)
/* no jumbogram (16K) support for now */
- dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN;
+ dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN + VLAN_HLEN;
dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
return 0;
--
1.7.6.5
^ permalink raw reply related
* [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Ian Coolidge
cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
case while using 802.1Q VLANs. In both cases, this is due to the
assumption of standard Ethernet frame length.
v2: rebase against Dave Miller's 'net/master' tree
Ian Coolidge (2):
usb: gadget: g_ether: fix frame size check for 802.1Q
net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
drivers/net/usb/cdc_eem.c | 3 ++-
drivers/usb/gadget/u_ether.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.7.6.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
^ permalink raw reply
* [PATCH v2 1/2] usb: gadget: g_ether: fix frame size check for 802.1Q
From: Ian Coolidge @ 2012-11-08 0:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Ian Coolidge
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Checking skb->len against ETH_FRAME_LEN assumes a 1514
ethernet frame size. With an 802.1Q VLAN header, ethernet
frame length can now be 1518. Validate frame length against that.
Signed-off-by: Ian Coolidge <iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/usb/gadget/u_ether.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 6458764..4ec3c0d 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -20,6 +20,7 @@
#include <linux/ctype.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
+#include <linux/if_vlan.h>
#include "u_ether.h"
@@ -295,7 +296,7 @@ static void rx_complete(struct usb_ep *ep, struct usb_request *req)
while (skb2) {
if (status < 0
|| ETH_HLEN > skb2->len
- || skb2->len > ETH_FRAME_LEN) {
+ || skb2->len > VLAN_ETH_FRAME_LEN) {
dev->net->stats.rx_errors++;
dev->net->stats.rx_length_errors++;
DBG(dev, "rx length %d\n", skb2->len);
--
1.7.6.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
^ permalink raw reply related
* Re: Optics (SFP) monitoring on ixgbe and igbe
From: Aurélien @ 2012-11-08 0:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1352318339.2725.34.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, Nov 7, 2012 at 8:58 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2012-11-07 at 13:27 +0100, Aurélien wrote:
>
> We just added the ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPROM
> interface for this purpose. The diagnostics obviously aren't really an
> EEPROM but I don't think that matters.
>
> These drivers should report a type of ETH_MODULE_SFF_8472 (assuming a
> module is present) and expose an 'EEPROM' with the real EEPROM in the
> first 256 bytes and the diagnostic registers in the next 256 bytes.
>
> Decoding of the diagnostic registers can be done in ethtool itself.
>
Hi Ben,
Thanks for this reply.
I did not see these interfaces in my searches, but from what I gather
from the code, the missing part is the actual decoding of the data in
ethtool.
As soon as I get my card installed in a test server, I'll reboot on a
kernel issued from the davem/net-next master, and will do some tests
to see if ethtool correctly sees an SFF-8472 compliant module, and has
the correct diagnostic data after the eeprom.
Then I will port the decoding part from the kernel-side patches I to
code in ethtool, and will do some basic tests.
Thanks,
Best regards,
--
Aurélien Guillaume
^ permalink raw reply
* [PATCH net-next 1/2] ARM: net: bpf_jit_32: add XOR instruction for BPF JIT
From: Daniel Borkmann @ 2012-11-08 1:28 UTC (permalink / raw)
To: davem; +Cc: Mircea Gherzan, Arnd Bergmann, netdev, linux-arm-kernel
This patch is a follow-up for patch "filter: add XOR instruction for use
with X/K" that implements BPF ARM JIT parts for the BPF XOR operation.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/net/bpf_jit_32.c | 15 ++++++++++-----
arch/arm/net/bpf_jit_32.h | 2 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index c641fb6..8be702d 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -646,6 +646,16 @@ load_ind:
update_on_xread(ctx);
emit(ARM_ORR_R(r_A, r_A, r_X), ctx);
break;
+ case BPF_S_ALU_XOR_K:
+ /* A ^= K; */
+ OP_IMM3(ARM_EOR, r_A, r_A, k, ctx);
+ break;
+ case BPF_S_ANC_ALU_XOR_X:
+ case BPF_S_ALU_XOR_X:
+ /* A ^= X */
+ update_on_xread(ctx);
+ emit(ARM_EOR_R(r_A, r_A, r_X), ctx);
+ break;
case BPF_S_ALU_AND_K:
/* A &= K */
OP_IMM3(ARM_AND, r_A, r_A, k, ctx);
@@ -762,11 +772,6 @@ b_epilogue:
update_on_xread(ctx);
emit(ARM_MOV_R(r_A, r_X), ctx);
break;
- case BPF_S_ANC_ALU_XOR_X:
- /* A ^= X */
- update_on_xread(ctx);
- emit(ARM_EOR_R(r_A, r_A, r_X), ctx);
- break;
case BPF_S_ANC_PROTOCOL:
/* A = ntohs(skb->protocol) */
ctx->seen |= SEEN_SKB;
diff --git a/arch/arm/net/bpf_jit_32.h b/arch/arm/net/bpf_jit_32.h
index 7fa2f7d..afb8462 100644
--- a/arch/arm/net/bpf_jit_32.h
+++ b/arch/arm/net/bpf_jit_32.h
@@ -69,6 +69,7 @@
#define ARM_INST_CMP_I 0x03500000
#define ARM_INST_EOR_R 0x00200000
+#define ARM_INST_EOR_I 0x02200000
#define ARM_INST_LDRB_I 0x05d00000
#define ARM_INST_LDRB_R 0x07d00000
@@ -135,6 +136,7 @@
#define ARM_CMP_I(rn, imm) _AL3_I(ARM_INST_CMP, 0, rn, imm)
#define ARM_EOR_R(rd, rn, rm) _AL3_R(ARM_INST_EOR, rd, rn, rm)
+#define ARM_EOR_I(rd, rn, imm) _AL3_I(ARM_INST_EOR, rd, rn, imm)
#define ARM_LDR_I(rt, rn, off) (ARM_INST_LDR_I | (rt) << 12 | (rn) << 16 \
| (off))
^ permalink raw reply related
* [PATCH net-next 2/2] ARM: net: bpf_jit_32: add VLAN instructions for BPF JIT
From: Daniel Borkmann @ 2012-11-08 1:31 UTC (permalink / raw)
To: davem; +Cc: Mircea Gherzan, Arnd Bergmann, netdev, linux-arm-kernel
This patch is a follow-up for patch "net: filter: add vlan tag access"
to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/net/bpf_jit_32.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 8be702d..9af9a69 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -16,6 +16,7 @@
#include <linux/netdevice.h>
#include <linux/string.h>
#include <linux/slab.h>
+#include <linux/if_vlan.h>
#include <asm/cacheflush.h>
#include <asm/hwcap.h>
@@ -168,6 +169,8 @@ static inline bool is_load_to_a(u16 inst)
case BPF_S_ANC_MARK:
case BPF_S_ANC_PROTOCOL:
case BPF_S_ANC_RXHASH:
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
case BPF_S_ANC_QUEUE:
return true;
default:
@@ -815,6 +818,17 @@ b_epilogue:
off = offsetof(struct sk_buff, rxhash);
emit(ARM_LDR_I(r_A, r_skb, off), ctx);
break;
+ case BPF_S_ANC_VLAN_TAG:
+ case BPF_S_ANC_VLAN_TAG_PRESENT:
+ ctx->seen |= SEEN_SKB;
+ BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
+ off = offsetof(struct sk_buff, vlan_tci);
+ emit(ARM_LDRH_I(r_A, r_skb, off), ctx);
+ if (inst->code == BPF_S_ANC_VLAN_TAG)
+ OP_IMM3(ARM_AND, r_A, r_A, VLAN_VID_MASK, ctx);
+ else
+ OP_IMM3(ARM_AND, r_A, r_A, VLAN_TAG_PRESENT, ctx);
+ break;
case BPF_S_ANC_QUEUE:
ctx->seen |= SEEN_SKB;
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
^ permalink raw reply related
* Re: Lower wake up time when phy enter lower mode
From: Frank Li @ 2012-11-08 2:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Richard Cochran, netdev
In-Reply-To: <1352315183.2725.17.camel@bwh-desktop.uk.solarflarecom.com>
2012/11/8 Ben Hutchings <bhutchings@solarflare.com>:
> On Wed, 2012-11-07 at 10:52 +0800, Frank Li wrote:
>> Richard:
>>
>> Recently, I found out the path delay will increase about
>> 20us suddenly in something when connect two iMX6 board and Ethernet
>> work on 1G mode.
>> The reason is that the PHY enter lower mode automatically
>> when no package send and receive. It takes some time to recover and
>> send out package by PHY but MAC think package have sent and sample
>> time stamper.
>> Do you meet such case? I can workaround it by two method
>> 1. disable phy lower power feature.
>> 2. add some dummy package before SYNC package.
>
> If this low power mode is related to EEE (Energy Efficient Ethernet)
> then there are ethtool operations defined for configuring it, and you
> could implement those.
Yes, it is phy specific, called smart EEE, which compatible with IEEE 802.3az
and can be used in legacy MAC without EEE.
Do you have example about ethtool operations?
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: [PATCH 1/2] net: fec: default select FEC_PTP at mx6 platform
From: Frank Li @ 2012-11-08 2:15 UTC (permalink / raw)
To: David Miller
Cc: Frank.Li, richardcochran, shawn.guo, linux-arm-kernel, netdev,
bhutchings
In-Reply-To: <20121107.185246.1330887590098677807.davem@davemloft.net>
>
> But please be explicit about which tree your patches are for in the
> subject line in the future.
Okay.
best regards
Frank Li
^ permalink raw reply
* Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug
From: Julius Werner @ 2012-11-08 2:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Dave Jones,
Sameer Nanda, Mandeep Singh Baines
In-Reply-To: <1352331754.2748.14.camel@edumazet-glaptop>
> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.
Thanks for the hint. Unfortunately, we have not pulled c8628 into our
tree yet, so that's not it. Is there another point where the cloned
skb or the faked truesize might make it break? We have been running
this test with that hardware some 30 times in the last months and only
seen it once, so it cannot be that common.
I have noticed that you have already proposed a patch to repair
smsc95xx (replacing the clone with a copy) on this list a few times...
what's the status on that? Will it be committed eventually or did you
abandon that approach?
Regardless of that, I still think that the bug handling in tcp_recvmsg
should be updated in one way or the other.
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: David Miller @ 2012-11-08 2:27 UTC (permalink / raw)
To: iancoolidge-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, balbi-l0cyMroinI0,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Ian Coolidge <iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 7 Nov 2012 16:39:17 -0800
> cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
> case while using 802.1Q VLANs. In both cases, this is due to the
> assumption of standard Ethernet frame length.
>
> v2: rebase against Dave Miller's 'net/master' tree
>
> Ian Coolidge (2):
> usb: gadget: g_ether: fix frame size check for 802.1Q
> net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
Applied, thanks.
--
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
* Messenger from Administrator
From: Webmail Admin @ 2012-11-08 5:29 UTC (permalink / raw)
Your E-mail® Account needs to be updated with our 2013 F-Secure R-HTK4S new version anti-spam/anti-virus/anti-spyware. Please click this link below
http://www.contactme.com/509b2c7e59d3f1000202406a
We Are Sorry For Any Inconvenience.
Regards,
WEBMAIL ADMINISTRATOR
Copyright© 2012 All rights reserved®.ABN 31 088 377 860 All Rights Reserved
^ permalink raw reply
* 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-11-08 6:24 UTC (permalink / raw)
To: e1000-devel@lists.sf.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Mary Mcgrath
Hi list,
IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant DL360 G6, and
have to reboot the server to recover:
e1000e 0000:06:00.1: eth3: Detected Hardware Unit Hang:
TDH <1a>
TDT <1a>
next_to_use <1a>
next_to_clean <18>
buffer_info[next_to_clean]:
time_stamp <10047a74e>
next_to_watch <18>
jiffies <10047a88c>
next_to_watch.status <1>
MAC Status <80383>
PHY Status <792d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
With newer kernel 2.0.0.1 the issue still reproducible.
Device info:
06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
06:00.1 0200: 8086:10bc (rev 06)
I compared lspci output before and after the issue, different as below:
06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port Gigabit Server Adapter
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-
+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Would you please help to it?
Thanks in advance,
Joe
--
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing
^ permalink raw reply
* Re: net/smsc911x: problems after commit 3ac3546e [Always wait for the chip to be ready]
From: David Miller @ 2012-11-08 6:57 UTC (permalink / raw)
To: kamlakant.patel; +Cc: steve, linus.walleij, robert.marklund, netdev
In-Reply-To: <20121108064627.GA25027@patelk@broadcom.com>
From: "Kamlakant Patel" <kamlakant.patel@broadcom.com>
Date: Thu, 8 Nov 2012 12:16:28 +0530
> smsc driver is disabled in our bootloader and it is not changing the
> state of the smsc registers at any stage, so it is not a bootloader
> issue.
What puts that chip into a non-default byte swapping mode then?
^ permalink raw reply
* Re: mmap RX_RING socket issue 32b application running on 64b kernel.
From: Ronny Meeus @ 2012-11-08 7:32 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev
In-Reply-To: <CAMJ=MEdjyJ8+Y_ZaHkcizy_Y8gdWFoSbz+PdVbYkRDTKyMzT1Q@mail.gmail.com>
On Wed, Nov 7, 2012 at 7:54 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
> On Wed, Nov 7, 2012 at 7:26 PM, Daniel Borkmann
> <danborkmann@iogearbox.net> wrote:
>> On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
>>> I have an application using raw Ethernet sockets in combination with
>>> the mmaped RX_RING.
>>> The application is running on a Cavium MIPS processor (64bit) and the
>>> application code is compiled with the N32 ABI.
>>>
>>> Since the ring buffer is shared between the Linux kernel and the
>>> application there is a conflict in the way the data is presented.
>>> Each buffer in the ring has a header that has following structure:
>>> (File http://lxr.free-electrons.com/source/include/linux/if_packet.h )
>>> 103 struct tpacket_hdr {
>>> 104 unsigned long tp_status;
>>> 105 unsigned int tp_len;
>>> 106 unsigned int tp_snaplen;
>>> 107 unsigned short tp_mac;
>>> 108 unsigned short tp_net;
>>> 109 unsigned int tp_sec;
>>> 110 unsigned int tp_usec;
>>> 111 };
>>>
>>> The status field indicates that the buffer belongs to the kernel or to
>>> the user. Note that an unsigned long is used to represent the field.
>>> In the kernel the long is 64 bit while in application space the long
>>> is only 32bit, so the bits do not match.
>>>
>>> After adapting the code to take this into account my program works well.
>>> In my test program I have defined a new struct where I change the
>>> “unsigned long” into an “unsigned long long”:
>>>
>>> struct tpacket_hdr_64 {
>>> unsigned long long tp_status;
>>> unsigned int tp_len;
>>> unsigned int tp_snaplen;
>>> unsigned short tp_mac;
>>> unsigned short tp_net;
>>> unsigned int tp_sec;
>>> unsigned int tp_usec;
>>> };
>>>
>>> In my opinion this is not a correct solution. It should be solved
>>> somewhere in the include file I used so that it is transparent for the
>>> application.
>>> Please comment.
>>
>> Have you tried to use packet_mmap with TPACKET version 2 [1]?
>>
>> In my understanding, it was introduced because of such issues that you
>> described.
>>
>> [1] E.g. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=bbd6ef87c544d88c30e4b762b1b61ef267a7d279
>
> I did not try this. I will do it tomorrow.
> Thanks for the quick response.
With the code below it indeed works.
req.tp_block_size = FRAME_SIZE * NR_FRAMES_PER_BLOCK;
req.tp_frame_size = FRAME_SIZE;
req.tp_block_nr = NR_FRAMES / NR_FRAMES_PER_BLOCK;
req.tp_frame_nr = NR_FRAMES;
val = TPACKET_V2;
setsockopt(eth_sock, SOL_PACKET,PACKET_VERSION, &val, sizeof(val));
setsockopt(eth_sock,SOL_PACKET,PACKET_RX_RING,(char *)&req,sizeof(req));
packet_mem = mmap(NULL,req.tp_block_size * req.tp_block_nr,
PROT_READ|PROT_WRITE|PROT_EXEC,MAP_SHARED,eth_sock, 0);
I wonder why there are so many examples available on the Internet that
either do not set the version or set the version to 1.
I would assume that the only correct usage of this interface is to use
version 2 since this is working on all platforms.
Is this correct?
---
Ronny
^ permalink raw reply
* [PATCH 1/2] irda: sh-irda: Remove SH7367 support
From: Nobuhiro Iwamatsu @ 2012-11-08 7:44 UTC (permalink / raw)
To: netdev; +Cc: samuel, Nobuhiro Iwamatsu
The shmobile SH7367 already was removed from source tree.
This remove SH7367 support for sh-irda.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/irda/sh_irda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index 4b746d9..ca49bbf 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -33,7 +33,7 @@
#define DRIVER_NAME "sh_irda"
-#if defined(CONFIG_ARCH_SH7367) || defined(CONFIG_ARCH_SH7377)
+#if defined(CONFIG_ARCH_SH7377)
#define __IRDARAM_LEN 0x13FF
#else
#define __IRDARAM_LEN 0x1039
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] irda: sh-irda: Remove SH7377 support
From: Nobuhiro Iwamatsu @ 2012-11-08 7:44 UTC (permalink / raw)
To: netdev; +Cc: samuel, Nobuhiro Iwamatsu
In-Reply-To: <1352360667-9341-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
The shmobile SH7377 already was removed from source tree.
This remove SH7377 support for sh-irda.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/irda/sh_irda.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index ca49bbf..945360a 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -33,11 +33,7 @@
#define DRIVER_NAME "sh_irda"
-#if defined(CONFIG_ARCH_SH7377)
-#define __IRDARAM_LEN 0x13FF
-#else
#define __IRDARAM_LEN 0x1039
-#endif
#define IRTMR 0x1F00 /* Transfer mode */
#define IRCFR 0x1F02 /* Configuration */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
From: Li Yu @ 2012-11-08 7:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1352286264.3140.3575.camel@edumazet-glaptop>
于 2012年11月07日 19:04, Eric Dumazet 写道:
> On Wed, 2012-11-07 at 16:35 +0800, Li Yu wrote:
>> 于 2012年11月07日 16:20, Li Yu 写道:
>>> 于 2012年04月27日 18:33, Eric Dumazet 写道:
>>>> From: Eric Dumazet <edumazet@google.com>
>>>>
>>>> skb->head is currently allocated from kmalloc(). This is convenient but
>>>> has the drawback the data cannot be converted to a page fragment if
>>>> needed.
>>>>
>>>
>>> Hi, Eric,
>>>
>>> I have a question about this patch, why data are allocated from
>>> kmalloc() can not be converted to page fragment ? We have its kernel
>>> mapped address and length, so we can get its page and offset in the
>>> page. If the skb is not cloned (shared with others), such page and its
>>> offset should be can use safely, in my words.
>>>
>>> I suspected that I may lost important something in slab internals, is
>>> right?
>>>
>>> Thanks
>>>
>>> Yu
>>>
>>
>> Or since slab allocated object may be across multiple pages?
>> I saw __netdev_alloc_skb() only use build_skb() with non-zero
>> fragsz if it is less than PAGE_SIZE.
>>
>
> SLAB allocators have their own way to handle a page, we cant interfere
> with it.
>
> So no, a kmalloced() object cannot be converted to a page fragment.
>
I think that all kmalloced() objects are continuous on both virtual
and physical address space, so such page fragment converting should be
safe until we use slab allocator to free them.
I ask this question since I am working on a patch to try to directly
forward the data from rx queue of a socket to tx queue of another
socket. We noticed that the splice itself still has visible costs when
forwarding small messages, and hope such direct forwarding optimization
can improve this, this idea comes from TCP friends.
Thanks
Yu
>
>
>
^ 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