* Re: [PATCH 0/4] netfilter fixes
From: David Miller @ 2010-03-25 18:49 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 25 Mar 2010 18:54:42 +0100
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: [PATCHv1 3/4] netxen: added sanity check for pci map
From: David Miller @ 2010-03-25 19:04 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-4-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 25 Mar 2010 00:06:45 -0700
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Return value of ioremap is not checked, NULL check added.
You're not even thinking when you make these changes.
Let's try again ok?
These ioremap() calls store the pointers into local variables.
So it doesn't work at all to just jump to err_out to clean
them up and iounmap them.
The unamp code you end up calling in netxen_pci_map() only does an
iounmap() on pointers stored in the netxen_adapter struct. At this
point they haven't been stored there yet.
So they still leak.
Can you tell my patience on this patch set is very much running
out? If you put half of the effort writing these patches as I
am putting into reviewing them, we wouldn't have to go back
and forth on this so many times.
Double check your work, and resubmit this whole patch set once you've
fixed this one, I think the other ones look fine.
Thanks.
^ permalink raw reply
* Re: rps: add CONFIG_RPS
From: David Miller @ 2010-03-25 19:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Ok, this default boolean version looks fine.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH RFC 1/2] flow: virtualize get and entry deletion methods
From: David Miller @ 2010-03-25 19:26 UTC (permalink / raw)
To: timo.teras; +Cc: netdev, herbert
In-Reply-To: <1269509091-6440-2-git-send-email-timo.teras@iki.fi>
From: Timo Teras <timo.teras@iki.fi>
Date: Thu, 25 Mar 2010 11:24:50 +0200
> This allows to validate the cached object before returning it.
> It also allows to destruct object properly, if the last reference
> was held in flow cache. This is also a prepartion for caching
> bundles in the flow cache.
>
> In return for virtualizing the methods, we save on:
> - not having to regenerate the whole flow cache on policy removal:
> each flow matching a killed policy gets refreshed as the getter
> function notices it smartly.
> - we do not have to call flow_cache_flush from policy gc, since the
> flow cache now properly deletes the object if it had any references
>
> This also means the flow cache entry deletion does more work. If
> it's too slow now, may have to implement delayed deletion of flow
> cache entries. But this is a save because this enables immediate
> deletion of policies and bundles.
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
I'm concerned about the new costs being added here.
We have to now take the policy lock as a reader every time the flow
cache wants to grab a reference. So we now have this plus the
indirect function call new overhead.
Maybe we can make the dead state check safe to do asynchronously
somehow? I wonder if the policy layer is overdue for an RCU
conversion or similar.
Anyways, something to think about. Otherwise I don't mind these
changes.
^ permalink raw reply
* Re: [PATCH 1/1] [TIPC] Removed inactive maintainer
From: David Miller @ 2010-03-25 19:40 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1269531343-27569-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Paul Maloy <jon.maloy@ericsson.com>
Date: Thu, 25 Mar 2010 11:35:43 -0400
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* [PATCH] netfilter: CLUSTERIP: clusterip_seq_stop() fix
From: Eric Dumazet @ 2010-03-25 19:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev, David Miller
In-Reply-To: <1269539686-3885-3-git-send-email-kaber@trash.net>
If clusterip_seq_start() memory allocation fails, we crash later in
clusterip_seq_start(), trying to kfree(ERR_PTR(-ENOMEM))
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 0886f96..afa937b 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -600,7 +600,8 @@ static void *clusterip_seq_next(struct seq_file *s, void *v, loff_t *pos)
static void clusterip_seq_stop(struct seq_file *s, void *v)
{
- kfree(v);
+ if (!IS_ERR(v))
+ kfree(v);
}
static int clusterip_seq_show(struct seq_file *s, void *v)
^ permalink raw reply related
* [GIT]: Networking
From: David Miller @ 2010-03-25 19:58 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) ISDN driver section mismatch fixes from Henrik Kretzschmar.
2) xt_hashlimit netfilter fixes (leaks, missing break in IPV6
header parsing switch statement) from Eric Dumazet.
3) netpoll silently sets dport to zero when spaces are in
kernel command line parameters, at least warn about this.
From Amerigo Wang.
4) IGB crashes in promisc mode when VLAN packet is received
without any vlans registered, fix from Alexander Duyck.
5) skb_shared_info causes all packets to use 4K SLABs instead
of 2K ones, due to completely unused dma_head and dma_maps
fields which we removed all references to recently. Kill
them, also from Alexander Duyck.
6) Via Andrew Morton, allow nls_cls to be modular.
7) netpoll crashes in bnx2 because it invokes wrong interrupt
handler, fix from Benjamin Li. Also, need to invoke
netif_napi_add() after we know exactly how many irq vectors
will be used, also from Benjamin Li.
8) af_key loses errors and returns zero on some memory allocation
failures, fix from Dan Carpenter.
9) VIA Velocity programs advertisement MII registers incorrectly
when both RX and TX flow control are enabled, from your's truly.
Noticed by Roel Kluin.
10) Update TIPC maintainers entry, from Jon Maloy.
11) VLANs do not do TX queue selection properly when the device
has a ->select_queue() override. Also add some validation
to make sure we do not choose a queue larger than the number
the device actually has. From Vasu Dev.
12) RXRPX protocol does not check for allocation failures in
incomping call accept code, fix from Tetsuo Handa.
13) Fix regression in xt_recent netfilter module wrt. zero hit_count
rules. From Thomas Jarosch.
14) blackfin CAN driver register definitions moved to asm/bfin_can.h,
from Mike Frysinger.
15) Disallow acceptance of NX_P3_B1 rev chips by the netxen driver,
these are preproduction chips and the driver doesn't work properly
right now with them. From Eric W. Biederman and ack'd by
Qlogic folks, although another solution to this problem might be
forthcoming.
16) ksz884x driver returns bogus error code from netdev_set_eeprom,
fix from Jens Rottmann.
17) IGB mishandled RX FIFO errors and incorrectly changes TX queue
len on link changes, fixes from Mitch Williams and Emil
Tantilov.
18) IPV6 RAW netfilter table priority is set wrong, fix from
Jozsef Kadlecsik.
Please pull, thanks a lot!
The following changes since commit 01e77706cdde7c0b47e5ca1f4284a795504c7c40:
Linus Torvalds (1):
Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alexander Duyck (2):
igb: only use vlan_gro_receive if vlans are registered
skbuff: remove unused dma_head & dma_maps fields
Amerigo Wang (1):
netpoll: warn when there are spaces in parameters
Ben Blum (1):
cgroups: net_cls as module
Benjamin Li (1):
bnx2: Fix netpoll crash.
Dan Carpenter (1):
af_key: return error if pfkey_xfrm_policy2msg_prep() fails
David S. Miller (3):
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
via-velocity: Fix FLOW_CNTL_TX_RX handling in set_mii_flow_control()
Emil Tantilov (1):
igb: do not modify tx_queue_len on link speed change
Eric Dumazet (2):
netfilter: xt_hashlimit: dl_seq_stop() fix
netfilter: xt_hashlimit: IPV6 bugfix
Eric W. Biederman (1):
netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
Henrik Kretzschmar (4):
isdn: Cleanup Sections in PCMCIA driver sedlbauer
isdn: Cleanup Sections in PCMCIA driver teles
isdn: Cleanup Sections in PCMCIA driver avma1
isdn: Cleanup Sections in PCMCIA driver elsa
Jens Rottmann (1):
ksz884x: fix return value of netdev_set_eeprom
Jon Maloy (1):
TIPC: Removed inactive maintainer
Jozsef Kadlecsik (1):
netfilter: ip6table_raw: fix table priority
Michael Chan (1):
bnx2: Use proper handler during netpoll.
Mike Frysinger (1):
can: bfin_can: switch to common Blackfin can header
Mitch Williams (1):
igb: count Rx FIFO errors correctly
Patrick McHardy (1):
netfilter: xt_recent: fix regression in rules using a zero hit_count
Tetsuo Handa (1):
rxrpc: Check allocation failure.
Vasu Dev (2):
vlan: adds vlan_dev_select_queue
vlan: updates vlan real_num_tx_queues
MAINTAINERS | 1 -
drivers/isdn/hisax/avma1_cs.c | 12 ++--
drivers/isdn/hisax/elsa_cs.c | 12 ++--
drivers/isdn/hisax/sedlbauer_cs.c | 12 ++--
drivers/isdn/hisax/teles_cs.c | 12 ++--
drivers/net/bnx2.c | 14 +++--
drivers/net/can/bfin_can.c | 97 +++-------------------------------
drivers/net/igb/igb.h | 1 -
drivers/net/igb/igb_main.c | 22 +++-----
drivers/net/ksz884x.c | 2 +-
drivers/net/netxen/netxen_nic_main.c | 4 +-
drivers/net/via-velocity.c | 2 +-
include/linux/netfilter_ipv6.h | 1 +
include/linux/skbuff.h | 6 --
net/8021q/vlan.c | 2 +
net/8021q/vlan_dev.c | 71 ++++++++++++++++++++++++-
net/core/netpoll.c | 7 ++-
net/ipv6/netfilter/ip6table_raw.c | 2 +-
net/key/af_key.c | 8 +--
net/netfilter/xt_hashlimit.c | 4 +-
net/netfilter/xt_recent.c | 2 +-
net/sched/Kconfig | 5 ++-
net/sched/cls_cgroup.c | 36 +++++++++---
23 files changed, 166 insertions(+), 169 deletions(-)
^ permalink raw reply
* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Jan Ceuleers @ 2010-03-25 20:02 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoab2m$kc0$1@dough.gmane.org>
Markus Feldmann wrote:
> i am thinking about buying a Mini-ITX Server with some Realtek Cips on
> the PCI Network Devices. These are
> Realtek RTL8110S
> Realtek RTL8100C
>
> The Mini-ITX is a Jetway JNF92.
> Does anybody know whether they work good or should i keep the hands off
> these?
I've got a Jetway J7F4 which has two Realtek RTL8110S devices. They look like this:
# lshw
(...)
*-network:0
description: Ethernet interface
product: RTL-8110SC/8169SC Gigabit Ethernet
vendor: Realtek Semiconductor Co., Ltd.
physical id: 9
bus info: pci@0000:00:09.0
logical name: eth0
version: 10
serial: 00:30:18:a4:e4:a4
size: 1GB/s
capacity: 1GB/s
width: 32 bits
clock: 66MHz
capabilities: bus_master ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.11 latency=64 link=yes maxlatency=64 mingnt=32 module=r8169 multicast=yes port=MII speed=1GB/s
*-network:1
description: Ethernet interface
product: RTL-8110SC/8169SC Gigabit Ethernet
vendor: Realtek Semiconductor Co., Ltd.
physical id: b
bus info: pci@0000:00:0b.0
logical name: eth1
version: 10
serial: 00:30:18:a4:e4:a5
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 66MHz
capabilities: bus_master ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=10.20.0.3 latency=64 link=yes maxlatency=64 mingnt=32 module=r8169 multicast=yes port=MII speed=100MB/s
(...)
eth1 has auto-negotiated 100Mbit/s because it is hard-wired to a device which isn't gigabit-capable.
Cheers, Jan
^ permalink raw reply
* Re: mmotm 2010-03-23 - IPv6 warnings...
From: David Miller @ 2010-03-25 20:25 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <4788.1269535530@localhost>
From: Valdis.Kletnieks@vt.edu
Date: Thu, 25 Mar 2010 12:45:30 -0400
> On Wed, 24 Mar 2010 18:42:26 EDT, Andrew Morton said:
>> On Wed, 24 Mar 2010 21:36:41 -0400 Valdis.Kletnieks@vt.edu wrote:
>>
>> > On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
>> > > The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
>> > >
>> > > http://userweb.kernel.org/~akpm/mmotm/
>> >
>> > Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
>> > prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
>> > after I launched pppd.
>>
>> Yes, thanks, I get the same - it doesn't seem to break anything. It
>> also happens some time after boot has completed.
>
> Just doing an 'ifup eth0' on a network with IPv6 on it is sufficient.
I'm going to look into this more deeply tonight.
^ permalink raw reply
* [net-2.6 PATCH] ixgbe: fix bug with vlan strip in promsic mode
From: Jeff Kirsher @ 2010-03-25 21:34 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Jesse Brandeburg, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
The ixgbe driver was setting up 82598 hardware correctly, so that
when promiscuous mode was enabled hardware stripping was turned
off. But on 82599 the logic to disable/enable hardware stripping
is different, and the code was not updated correctly when the
hardware vlan stripping was enabled as default.
This change comprises the creation of two new helper functions
and calling them from the right locations to disable and enable
hardware stripping of vlan tags at appropriate times.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 115 +++++++++++++++++++++++++---------------
1 files changed, 72 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 997d997..3c86707 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2481,12 +2481,74 @@ static void ixgbe_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
hw->mac.ops.set_vfta(&adapter->hw, vid, pool_ndx, false);
}
+/**
+ * ixgbe_vlan_filter_disable - helper to disable hw vlan filtering
+ * @adapter: driver data
+ */
+static void ixgbe_vlan_filter_disable(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
+ int i, j;
+
+ switch (hw->mac.type) {
+ case ixgbe_mac_82598EB:
+ vlnctrl &= ~(IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE);
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ break;
+ case ixgbe_mac_82599EB:
+ vlnctrl &= ~IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ for (i = 0; i < adapter->num_rx_queues; i++) {
+ j = adapter->rx_ring[i]->reg_idx;
+ vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
+ vlnctrl &= ~IXGBE_RXDCTL_VME;
+ IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
+ }
+ break;
+ default:
+ break;
+ }
+}
+
+/**
+ * ixgbe_vlan_filter_enable - helper to enable hw vlan filtering
+ * @adapter: driver data
+ */
+static void ixgbe_vlan_filter_enable(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
+ int i, j;
+
+ switch (hw->mac.type) {
+ case ixgbe_mac_82598EB:
+ vlnctrl |= IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ break;
+ case ixgbe_mac_82599EB:
+ vlnctrl |= IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ for (i = 0; i < adapter->num_rx_queues; i++) {
+ j = adapter->rx_ring[i]->reg_idx;
+ vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
+ vlnctrl |= IXGBE_RXDCTL_VME;
+ IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
+ }
+ break;
+ default:
+ break;
+ }
+}
+
static void ixgbe_vlan_rx_register(struct net_device *netdev,
struct vlan_group *grp)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
- u32 ctrl;
- int i, j;
if (!test_bit(__IXGBE_DOWN, &adapter->state))
ixgbe_irq_disable(adapter);
@@ -2497,25 +2559,7 @@ static void ixgbe_vlan_rx_register(struct net_device *netdev,
* still receive traffic from a DCB-enabled host even if we're
* not in DCB mode.
*/
- ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_VLNCTRL);
-
- /* Disable CFI check */
- ctrl &= ~IXGBE_VLNCTRL_CFIEN;
-
- /* enable VLAN tag stripping */
- if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
- ctrl |= IXGBE_VLNCTRL_VME;
- } else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
- for (i = 0; i < adapter->num_rx_queues; i++) {
- u32 ctrl;
- j = adapter->rx_ring[i]->reg_idx;
- ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_RXDCTL(j));
- ctrl |= IXGBE_RXDCTL_VME;
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_RXDCTL(j), ctrl);
- }
- }
-
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_VLNCTRL, ctrl);
+ ixgbe_vlan_filter_enable(adapter);
ixgbe_vlan_rx_add_vid(netdev, 0);
@@ -2550,17 +2594,17 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
- u32 fctrl, vlnctrl;
+ u32 fctrl;
/* Check for Promiscuous and All Multicast modes */
fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
if (netdev->flags & IFF_PROMISC) {
hw->addr_ctrl.user_set_promisc = 1;
fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
- vlnctrl &= ~IXGBE_VLNCTRL_VFE;
+ /* don't hardware filter vlans in promisc mode */
+ ixgbe_vlan_filter_disable(adapter);
} else {
if (netdev->flags & IFF_ALLMULTI) {
fctrl |= IXGBE_FCTRL_MPE;
@@ -2568,12 +2612,11 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
} else {
fctrl &= ~(IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
}
- vlnctrl |= IXGBE_VLNCTRL_VFE;
+ ixgbe_vlan_filter_enable(adapter);
hw->addr_ctrl.user_set_promisc = 0;
}
IXGBE_WRITE_REG(hw, IXGBE_FCTRL, fctrl);
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
/* reprogram secondary unicast list */
hw->mac.ops.update_uc_addr_list(hw, netdev);
@@ -2640,7 +2683,7 @@ static void ixgbe_napi_disable_all(struct ixgbe_adapter *adapter)
static void ixgbe_configure_dcb(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- u32 txdctl, vlnctrl;
+ u32 txdctl;
int i, j;
ixgbe_dcb_check_config(&adapter->dcb_cfg);
@@ -2658,22 +2701,8 @@ static void ixgbe_configure_dcb(struct ixgbe_adapter *adapter)
IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(j), txdctl);
}
/* Enable VLAN tag insert/strip */
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
- if (hw->mac.type == ixgbe_mac_82598EB) {
- vlnctrl |= IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE;
- vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
- } else if (hw->mac.type == ixgbe_mac_82599EB) {
- vlnctrl |= IXGBE_VLNCTRL_VFE;
- vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
- for (i = 0; i < adapter->num_rx_queues; i++) {
- j = adapter->rx_ring[i]->reg_idx;
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
- vlnctrl |= IXGBE_RXDCTL_VME;
- IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
- }
- }
+ ixgbe_vlan_filter_enable(adapter);
+
hw->mac.ops.set_vfta(&adapter->hw, 0, 0, true);
}
^ permalink raw reply related
* [net-2.6 PATCH] bonding: fix broken multicast with round-robin mode
From: Andy Gospodarek @ 2010-03-25 21:40 UTC (permalink / raw)
To: netdev; +Cc: lhh, fubar, bonding-devel
Round-robin (mode 0) does nothing to ensure that any multicast traffic
originally destined for the host will continue to arrive at the host when
the link that sent the IGMP join or membership report goes down. One of
the benefits of absolute round-robin transmit.
Keeping track of subscribed multicast groups for each slave did not seem
like a good use of resources, so I decided to simply send on the
curr_active slave of the bond (typically the first enslaved device that
is up). This makes failover management simple as IGMP membership
reports only need to be sent when the curr_active_slave changes. I
tested this patch and it appears to work as expected.
Originally reported by Lon Hohberger <lhh@redhat.com>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Lon Hohberger <lhh@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_main.c | 34 ++++++++++++++++++++++++++--------
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 430c022..0b38455 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
write_lock_bh(&bond->curr_slave_lock);
}
}
+
+ /* resend IGMP joins since all were sent on curr_active_slave */
+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
+ bond_resend_igmp_join_requests(bond);
+ }
}
/**
@@ -4138,22 +4143,35 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
struct bonding *bond = netdev_priv(bond_dev);
struct slave *slave, *start_at;
int i, slave_no, res = 1;
+ struct iphdr *iph = ip_hdr(skb);
read_lock(&bond->lock);
if (!BOND_IS_OK(bond))
goto out;
-
/*
- * Concurrent TX may collide on rr_tx_counter; we accept that
- * as being rare enough not to justify using an atomic op here
+ * Start with the curr_active_slave that joined the bond as the
+ * default for sending IGMP traffic. For failover purposes one
+ * needs to maintain some consistency for the interface that will
+ * send the join/membership reports. The curr_active_slave found
+ * will send all of this type of traffic.
*/
- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
+ if ((skb->protocol == htons(ETH_P_IP)) &&
+ (iph->protocol == htons(IPPROTO_IGMP))) {
+ slave = bond->curr_active_slave;
+ } else {
+ /*
+ * Concurrent TX may collide on rr_tx_counter; we accept
+ * that as being rare enough not to justify using an
+ * atomic op here.
+ */
+ slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
- bond_for_each_slave(bond, slave, i) {
- slave_no--;
- if (slave_no < 0)
- break;
+ bond_for_each_slave(bond, slave, i) {
+ slave_no--;
+ if (slave_no < 0)
+ break;
+ }
}
start_at = slave;
^ permalink raw reply related
* [net-2.6 PATCH] igbvf: do not modify tx_queue_len on link speed change
From: Jeff Kirsher @ 2010-03-25 22:11 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Franco Fichtner, Emil Tantilov, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Previously the driver tweaked txqueuelen to avoid false Tx hang reports seen at half duplex.
This had the effect of overriding user set values on link change/reset. Testing shows that
adjusting only the timeout factor is sufficient to prevent Tx hang reports at half duplex.
Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igbvf/igbvf.h | 1 -
drivers/net/igbvf/netdev.c | 11 +----------
2 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/igbvf/igbvf.h b/drivers/net/igbvf/igbvf.h
index a1774b2..debeee2 100644
--- a/drivers/net/igbvf/igbvf.h
+++ b/drivers/net/igbvf/igbvf.h
@@ -198,7 +198,6 @@ struct igbvf_adapter {
struct igbvf_ring *tx_ring /* One per active queue */
____cacheline_aligned_in_smp;
- unsigned long tx_queue_len;
unsigned int restart_queue;
u32 txd_cmd;
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index a77afd8..b41037e 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -1304,8 +1304,6 @@ static void igbvf_configure_tx(struct igbvf_adapter *adapter)
/* enable Report Status bit */
adapter->txd_cmd |= E1000_ADVTXD_DCMD_RS;
-
- adapter->tx_queue_len = adapter->netdev->tx_queue_len;
}
/**
@@ -1524,7 +1522,6 @@ void igbvf_down(struct igbvf_adapter *adapter)
del_timer_sync(&adapter->watchdog_timer);
- netdev->tx_queue_len = adapter->tx_queue_len;
netif_carrier_off(netdev);
/* record the stats before reset*/
@@ -1857,21 +1854,15 @@ static void igbvf_watchdog_task(struct work_struct *work)
&adapter->link_duplex);
igbvf_print_link_info(adapter);
- /*
- * tweak tx_queue_len according to speed/duplex
- * and adjust the timeout factor
- */
- netdev->tx_queue_len = adapter->tx_queue_len;
+ /* adjust timeout factor according to speed/duplex */
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
case SPEED_10:
txb2b = 0;
- netdev->tx_queue_len = 10;
adapter->tx_timeout_factor = 16;
break;
case SPEED_100:
txb2b = 0;
- netdev->tx_queue_len = 100;
/* maybe add some timeout factor ? */
break;
}
^ permalink raw reply related
* Re: [net-2.6 PATCH] bonding: fix broken multicast with round-robin mode
From: Jay Vosburgh @ 2010-03-25 22:31 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, lhh, bonding-devel
In-Reply-To: <20100325214033.GA28741@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>Round-robin (mode 0) does nothing to ensure that any multicast traffic
>originally destined for the host will continue to arrive at the host when
>the link that sent the IGMP join or membership report goes down. One of
>the benefits of absolute round-robin transmit.
>
>Keeping track of subscribed multicast groups for each slave did not seem
>like a good use of resources, so I decided to simply send on the
>curr_active slave of the bond (typically the first enslaved device that
>is up). This makes failover management simple as IGMP membership
>reports only need to be sent when the curr_active_slave changes. I
>tested this patch and it appears to work as expected.
>
>Originally reported by Lon Hohberger <lhh@redhat.com>.
>
>Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Seems reasonable, modulo a couple of minor things (see below).
I checked, and the link failover logic appears to maintain
curr_active_slave even for round robin mode, which, prior to this patch,
didn't use it.
>CC: Lon Hohberger <lhh@redhat.com>
>CC: Jay Vosburgh <fubar@us.ibm.com>
>
>---
> drivers/net/bonding/bond_main.c | 34 ++++++++++++++++++++++++++--------
> 1 files changed, 26 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 430c022..0b38455 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
> write_lock_bh(&bond->curr_slave_lock);
> }
> }
>+
>+ /* resend IGMP joins since all were sent on curr_active_slave */
>+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
>+ bond_resend_igmp_join_requests(bond);
>+ }
> }
>
> /**
>@@ -4138,22 +4143,35 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
> struct bonding *bond = netdev_priv(bond_dev);
> struct slave *slave, *start_at;
> int i, slave_no, res = 1;
>+ struct iphdr *iph = ip_hdr(skb);
>
> read_lock(&bond->lock);
>
> if (!BOND_IS_OK(bond))
> goto out;
>-
> /*
>- * Concurrent TX may collide on rr_tx_counter; we accept that
>- * as being rare enough not to justify using an atomic op here
>+ * Start with the curr_active_slave that joined the bond as the
>+ * default for sending IGMP traffic. For failover purposes one
>+ * needs to maintain some consistency for the interface that will
>+ * send the join/membership reports. The curr_active_slave found
>+ * will send all of this type of traffic.
> */
>- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
>+ if ((skb->protocol == htons(ETH_P_IP)) &&
>+ (iph->protocol == htons(IPPROTO_IGMP))) {
>+ slave = bond->curr_active_slave;
Technically, this should acquire bond->curr_slave_lock for read
around the inspection of curr_active_slave.
I believe you'll also want a test for curr_active_slave == NULL,
and free the skb if so (or do something else). There's a race window in
bond_release: when releasing the curr_active_slave, the field is left
momentarily NULL with the bond unlocked. This occurs after the
bond_change_active_slave(bond, NULL) call, during the lock dance prior
to the call bond_select_active_slave:
bond_main.c:bond_release():
[...]
if (oldcurrent == slave)
bond_change_active_slave(bond, NULL);
[...]
if (oldcurrent == slave) {
/*
* Note that we hold RTNL over this sequence, so there
* is no concern that another slave add/remove event
* will interfere.
*/
write_unlock_bh(&bond->lock);
[ race window is here ]
read_lock(&bond->lock);
write_lock_bh(&bond->curr_slave_lock);
bond_select_active_slave(bond);
write_unlock_bh(&bond->curr_slave_lock);
read_unlock(&bond->lock);
write_lock_bh(&bond->lock);
}
I'm reasonably sure the other TX functions (that need to) will
handle the case that curr_active_slave is NULL.
>+ } else {
>+ /*
>+ * Concurrent TX may collide on rr_tx_counter; we accept
>+ * that as being rare enough not to justify using an
>+ * atomic op here.
>+ */
>+ slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
>
>- bond_for_each_slave(bond, slave, i) {
>- slave_no--;
>- if (slave_no < 0)
>- break;
>+ bond_for_each_slave(bond, slave, i) {
>+ slave_no--;
>+ if (slave_no < 0)
>+ break;
>+ }
> }
>
> start_at = slave;
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 1/3] mfd: add support for Janz CMOD-IO PCI MODULbus Carrier Board
From: Samuel Ortiz @ 2010-03-25 22:59 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linux-kernel, netdev, socketcan-core
In-Reply-To: <20100319182209.GD13672@ovro.caltech.edu>
Hi Ira,
First of all, sorry for the late reply. Then my answers:
On Fri, Mar 19, 2010 at 11:22:09AM -0700, Ira W. Snyder wrote:
>
> > > +/*
> > > + * Subdevice Support
> > > + */
> > Please use the mfd-core API for building and registering platform sub devices.
> > The pieces of code below should shrink significantly.
> >
>
> Using this framework, how is it possible to create the devices that I
> do down below. For each subdevice, I need three resources:
>
> 1) MODULbus registers -- PCI BAR3 + (0x200 * module_num)
> 2) PLX Control Registers -- PCI BAR4
> 3) IRQ
>
> Specifically, the way IORESOURCE_MEM resources are copied seems wrong.
> They start at the base address of only one resource and use the offsets
> provided in the struct mfd_cell. See the if-statement at
> drivers/mfd/mfd-core.c line 48.
>
> I need two use two different parent resources. The mfd_add_devices()
> function doesn't support this.
I would still like you to use the mfd-core API. Here is my proposal:
1) I modify mfd_add_device() to support a NULL mem_base argument. When
mem_base is NULL, we would have:
res[r].parent = NULL and res[r].start = cell->resources[r].start;
The platform code will use iomem_resource as the parent for this resource.
2) Your mfd_cell cells would have 3 resources, and you just need to set the
IORESOURCE_MEM ones at probe time, with pci->resource[n]->start + offset as
the start field.
Would that make sense to you ?
> > > + /* Onboard configuration registers */
> > > + priv->ctrl = pci_ioremap_bar(dev, 4);
> > Why 4 ?
> >
> >
>
> Because that is how the device works ;) There is a comment up above that
> describes them as the "PLX control registers". Are you suggesting that I
> add a comment here too?
No, that's ok, I missed the comment.
> > > +#define PCI_VENDOR_ID_JANZ 0x13c3
> > That probably belongs to pci_ids.h
> >
>
> Should I add a patch to the series for this?
Either that or merge the pci_ids.h changes with this patch.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH] igb: update hw_debug macro to make use of netdev_dbg call
From: Jeff Kirsher @ 2010-03-25 23:10 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change updates the igb driver to make use of the netdev_dbg function
macros now provided in netdevice.h
This is meant to be provided as an alternative to the patch provided by
Joe Perches.
It also removes igb_get_time_str since I found that it is unused code that
is no longer used even in debug.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_hw.h | 12 +++++-------
drivers/net/igb/igb_main.c | 32 +++-----------------------------
2 files changed, 8 insertions(+), 36 deletions(-)
diff --git a/drivers/net/igb/e1000_hw.h b/drivers/net/igb/e1000_hw.h
index 82a533f..fbaff4d 100644
--- a/drivers/net/igb/e1000_hw.h
+++ b/drivers/net/igb/e1000_hw.h
@@ -31,6 +31,7 @@
#include <linux/types.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/netdevice.h>
#include "e1000_regs.h"
#include "e1000_defines.h"
@@ -502,14 +503,11 @@ struct e1000_hw {
u8 revision_id;
};
-#ifdef DEBUG
-extern char *igb_get_hw_dev_name(struct e1000_hw *hw);
+extern struct net_device *igb_get_hw_dev(struct e1000_hw *hw);
#define hw_dbg(format, arg...) \
- printk(KERN_DEBUG "%s: " format, igb_get_hw_dev_name(hw), ##arg)
-#else
-#define hw_dbg(format, arg...)
-#endif
-#endif
+ netdev_dbg(igb_get_hw_dev(hw), format, ##arg)
+
/* These functions must be implemented by drivers */
s32 igb_read_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value);
s32 igb_write_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value);
+#endif /* _E1000_HW_H_ */
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 01c65c7..1e4d5a6 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -222,43 +222,17 @@ static cycle_t igb_read_clock(const struct cyclecounter *tc)
return stamp;
}
-#ifdef DEBUG
/**
- * igb_get_hw_dev_name - return device name string
+ * igb_get_hw_dev - return device
* used by hardware layer to print debugging information
**/
-char *igb_get_hw_dev_name(struct e1000_hw *hw)
+struct net_device *igb_get_hw_dev(struct e1000_hw *hw)
{
struct igb_adapter *adapter = hw->back;
- return adapter->netdev->name;
+ return adapter->netdev;
}
/**
- * igb_get_time_str - format current NIC and system time as string
- */
-static char *igb_get_time_str(struct igb_adapter *adapter,
- char buffer[160])
-{
- cycle_t hw = adapter->cycles.read(&adapter->cycles);
- struct timespec nic = ns_to_timespec(timecounter_read(&adapter->clock));
- struct timespec sys;
- struct timespec delta;
- getnstimeofday(&sys);
-
- delta = timespec_sub(nic, sys);
-
- sprintf(buffer,
- "HW %llu, NIC %ld.%09lus, SYS %ld.%09lus, NIC-SYS %lds + %09luns",
- hw,
- (long)nic.tv_sec, nic.tv_nsec,
- (long)sys.tv_sec, sys.tv_nsec,
- (long)delta.tv_sec, delta.tv_nsec);
-
- return buffer;
-}
-#endif
-
-/**
* igb_init_module - Driver Registration Routine
*
* igb_init_module is the first routine called when the driver is
^ permalink raw reply related
* Re: [PATCH 1/3] mfd: add support for Janz CMOD-IO PCI MODULbus Carrier Board
From: Ira W. Snyder @ 2010-03-25 23:22 UTC (permalink / raw)
To: Samuel Ortiz
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100325225929.GA20618-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
On Thu, Mar 25, 2010 at 11:59:30PM +0100, Samuel Ortiz wrote:
> Hi Ira,
>
> First of all, sorry for the late reply. Then my answers:
>
> On Fri, Mar 19, 2010 at 11:22:09AM -0700, Ira W. Snyder wrote:
> >
> > > > +/*
> > > > + * Subdevice Support
> > > > + */
> > > Please use the mfd-core API for building and registering platform sub devices.
> > > The pieces of code below should shrink significantly.
> > >
> >
> > Using this framework, how is it possible to create the devices that I
> > do down below. For each subdevice, I need three resources:
> >
> > 1) MODULbus registers -- PCI BAR3 + (0x200 * module_num)
> > 2) PLX Control Registers -- PCI BAR4
> > 3) IRQ
> >
> > Specifically, the way IORESOURCE_MEM resources are copied seems wrong.
> > They start at the base address of only one resource and use the offsets
> > provided in the struct mfd_cell. See the if-statement at
> > drivers/mfd/mfd-core.c line 48.
> >
> > I need two use two different parent resources. The mfd_add_devices()
> > function doesn't support this.
> I would still like you to use the mfd-core API. Here is my proposal:
>
> 1) I modify mfd_add_device() to support a NULL mem_base argument. When
> mem_base is NULL, we would have:
>
> res[r].parent = NULL and res[r].start = cell->resources[r].start;
>
> The platform code will use iomem_resource as the parent for this resource.
>
I don't know the implications of using iomem_resource as the parent
resource. If you think it is ok, I have no objections.
If it helps, I can provide the PCI resource as a parent resource in my
resources. Then, when mem_base is NULL, the mfd-core could do this:
res[r].parent = cell->resources[r].parent
This is basically what I did in my patch. I used the PCI resource as the
parent of all child resources. I don't know if that is safe, but it
works. :)
The mfd_add_device() function does this for IORESOURCE_IO resources. It
only tries to be smart for IORESOURCE_MEM and IORESOURCE_IRQ resources.
> 2) Your mfd_cell cells would have 3 resources, and you just need to set the
> IORESOURCE_MEM ones at probe time, with pci->resource[n]->start + offset as
> the start field.
>
> Would that make sense to you ?
>
Yep, that makes sense.
> > > > + /* Onboard configuration registers */
> > > > + priv->ctrl = pci_ioremap_bar(dev, 4);
> > > Why 4 ?
> > >
> > >
> >
> > Because that is how the device works ;) There is a comment up above that
> > describes them as the "PLX control registers". Are you suggesting that I
> > add a comment here too?
> No, that's ok, I missed the comment.
>
> > > > +#define PCI_VENDOR_ID_JANZ 0x13c3
> > > That probably belongs to pci_ids.h
> > >
> >
> > Should I add a patch to the series for this?
> Either that or merge the pci_ids.h changes with this patch.
>
I guess it is a trivial enough change to merge with this patch.
I'll wait for your patch to the mfd-core API before making changes and
sending out the next round of updates.
Thanks for replying,
Ira
^ permalink raw reply
* Re: [PATCH 1/3] mfd: add support for Janz CMOD-IO PCI MODULbus Carrier Board
From: Samuel Ortiz @ 2010-03-26 0:26 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linux-kernel, netdev, socketcan-core
In-Reply-To: <20100325232244.GG10454@ovro.caltech.edu>
On Thu, Mar 25, 2010 at 04:22:44PM -0700, Ira W. Snyder wrote:
> On Thu, Mar 25, 2010 at 11:59:30PM +0100, Samuel Ortiz wrote:
> > Hi Ira,
> >
> > First of all, sorry for the late reply. Then my answers:
> >
> > On Fri, Mar 19, 2010 at 11:22:09AM -0700, Ira W. Snyder wrote:
> > >
> > > > > +/*
> > > > > + * Subdevice Support
> > > > > + */
> > > > Please use the mfd-core API for building and registering platform sub devices.
> > > > The pieces of code below should shrink significantly.
> > > >
> > >
> > > Using this framework, how is it possible to create the devices that I
> > > do down below. For each subdevice, I need three resources:
> > >
> > > 1) MODULbus registers -- PCI BAR3 + (0x200 * module_num)
> > > 2) PLX Control Registers -- PCI BAR4
> > > 3) IRQ
> > >
> > > Specifically, the way IORESOURCE_MEM resources are copied seems wrong.
> > > They start at the base address of only one resource and use the offsets
> > > provided in the struct mfd_cell. See the if-statement at
> > > drivers/mfd/mfd-core.c line 48.
> > >
> > > I need two use two different parent resources. The mfd_add_devices()
> > > function doesn't support this.
> > I would still like you to use the mfd-core API. Here is my proposal:
> >
> > 1) I modify mfd_add_device() to support a NULL mem_base argument. When
> > mem_base is NULL, we would have:
> >
> > res[r].parent = NULL and res[r].start = cell->resources[r].start;
> >
> > The platform code will use iomem_resource as the parent for this resource.
> >
>
> I don't know the implications of using iomem_resource as the parent
> resource. If you think it is ok, I have no objections.
>
> If it helps, I can provide the PCI resource as a parent resource in my
> resources. Then, when mem_base is NULL, the mfd-core could do this:
>
> res[r].parent = cell->resources[r].parent
>
> This is basically what I did in my patch. I used the PCI resource as the
> parent of all child resources. I don't know if that is safe, but it
> works. :)
>
> The mfd_add_device() function does this for IORESOURCE_IO resources. It
> only tries to be smart for IORESOURCE_MEM and IORESOURCE_IRQ resources.
I pushed an mfd-core change that basically falls back to the default resource
copying when mem_base is NULL. That should allow you to use the API now.
> > > > > +#define PCI_VENDOR_ID_JANZ 0x13c3
> > > > That probably belongs to pci_ids.h
> > > >
> > >
> > > Should I add a patch to the series for this?
> > Either that or merge the pci_ids.h changes with this patch.
> >
>
> I guess it is a trivial enough change to merge with this patch.
>
> I'll wait for your patch to the mfd-core API before making changes and
> sending out the next round of updates.
Very nice. The above mentioned change in my for-next branch, commit
6802a325f541bbea3168cf61ba239443193e1f9a.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* UDP path MTU discovery
From: Glen Turner @ 2010-03-26 0:02 UTC (permalink / raw)
To: netdev
[This is a second attempt to report this bug.]
Path MTU Discovery for UDP underperforms for IPv4 and fails
for IPv6 in Linux for transactional services like DHCP and
RADIUS running on jumbo frame interfaces.
These servers send packets with exponential back-off. UDP
Path MTU Discovery probes for the path MTU each time the
application sends a packet. So if you start with a high
enough interface MTU then the server application backoff
times get huge and the client gives up before the path
MTU is discovered.
This differs from TCP, where it is the kernel -- and not
the application -- which organises retransmission. On
receiving a ICMP Fragmentation Needed the kernel can
immediately re-probe the path MTU wiht no waiting for
an exponential timer to expire.
In IPv4 there is a work-around for the server, turn off
Path MTU Discovery and allow routers to fragment the packet
as needed. Looking at the code for the various transactional
servers (ISC DHCP, FreeRADIUS, RADIATOR, radsecproxy) they
all disable Path MTU Discovery on Linux. This workaround has
the side effect of hiding the problem, misleading people into
thinking that UDP Path MTU Discovery actually works for these
transactional servers.
In IPv6 routers do not fragment packets, so there is no work
around. Transactional servers which use UDP over IPv6 encounter
exponential backoffs within the application and the client
abandons the transaction. There is no way for the server to
know that the packet was lost due to Path MTU Discovery and
to immediately re-transmit it (without an exponential penalty)
so that the MTU can be probed again.
This can be viewed as a flaw in the RFC and in the sockets API
for which IPv6 has removed the common work-around.
Thank you, Glen
--
Glen Turner
www.gdt.id.au/~gdt
^ permalink raw reply
* Re: [net-2.6 PATCH v2] bonding: fix broken multicast with round-robin mode
From: Andy Gospodarek @ 2010-03-26 0:49 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, lhh, bonding-devel
In-Reply-To: <24080.1269556271@death.nxdomain.ibm.com>
On Thu, Mar 25, 2010 at 03:31:11PM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> >Round-robin (mode 0) does nothing to ensure that any multicast traffic
> >originally destined for the host will continue to arrive at the host when
> >the link that sent the IGMP join or membership report goes down. One of
> >the benefits of absolute round-robin transmit.
> >
> >Keeping track of subscribed multicast groups for each slave did not seem
> >like a good use of resources, so I decided to simply send on the
> >curr_active slave of the bond (typically the first enslaved device that
> >is up). This makes failover management simple as IGMP membership
> >reports only need to be sent when the curr_active_slave changes. I
> >tested this patch and it appears to work as expected.
> >
> >Originally reported by Lon Hohberger <lhh@redhat.com>.
> >
> >Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>
> Seems reasonable, modulo a couple of minor things (see below).
>
> I checked, and the link failover logic appears to maintain
> curr_active_slave even for round robin mode, which, prior to this patch,
> didn't use it.
Correct. I initially didn't plan to use that, but when I saw that it
was maintained for round-robin mode as well I decided it would be good
to use it rather than wasting space with another pointer.
>
> >CC: Lon Hohberger <lhh@redhat.com>
> >CC: Jay Vosburgh <fubar@us.ibm.com>
> >
> >---
> > drivers/net/bonding/bond_main.c | 34 ++++++++++++++++++++++++++--------
> > 1 files changed, 26 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >index 430c022..0b38455 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
> > write_lock_bh(&bond->curr_slave_lock);
> > }
> > }
> >+
> >+ /* resend IGMP joins since all were sent on curr_active_slave */
> >+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
> >+ bond_resend_igmp_join_requests(bond);
> >+ }
> > }
> >
> > /**
> >@@ -4138,22 +4143,35 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
> > struct bonding *bond = netdev_priv(bond_dev);
> > struct slave *slave, *start_at;
> > int i, slave_no, res = 1;
> >+ struct iphdr *iph = ip_hdr(skb);
> >
> > read_lock(&bond->lock);
> >
> > if (!BOND_IS_OK(bond))
> > goto out;
> >-
> > /*
> >- * Concurrent TX may collide on rr_tx_counter; we accept that
> >- * as being rare enough not to justify using an atomic op here
> >+ * Start with the curr_active_slave that joined the bond as the
> >+ * default for sending IGMP traffic. For failover purposes one
> >+ * needs to maintain some consistency for the interface that will
> >+ * send the join/membership reports. The curr_active_slave found
> >+ * will send all of this type of traffic.
> > */
> >- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
> >+ if ((skb->protocol == htons(ETH_P_IP)) &&
> >+ (iph->protocol == htons(IPPROTO_IGMP))) {
> >+ slave = bond->curr_active_slave;
>
> Technically, this should acquire bond->curr_slave_lock for read
> around the inspection of curr_active_slave.
>
> I believe you'll also want a test for curr_active_slave == NULL,
> and free the skb if so (or do something else). There's a race window in
> bond_release: when releasing the curr_active_slave, the field is left
> momentarily NULL with the bond unlocked. This occurs after the
> bond_change_active_slave(bond, NULL) call, during the lock dance prior
> to the call bond_select_active_slave:
>
> bond_main.c:bond_release():
> [...]
> if (oldcurrent == slave)
> bond_change_active_slave(bond, NULL);
> [...]
> if (oldcurrent == slave) {
> /*
> * Note that we hold RTNL over this sequence, so there
> * is no concern that another slave add/remove event
> * will interfere.
> */
> write_unlock_bh(&bond->lock);
>
> [ race window is here ]
>
> read_lock(&bond->lock);
> write_lock_bh(&bond->curr_slave_lock);
>
> bond_select_active_slave(bond);
>
> write_unlock_bh(&bond->curr_slave_lock);
> read_unlock(&bond->lock);
> write_lock_bh(&bond->lock);
> }
>
> I'm reasonably sure the other TX functions (that need to) will
> handle the case that curr_active_slave is NULL.
>
Good catch, Jay. Thanks for looking at this.
Here is an updated and tested patch:
[net-2.6 PATCH] bonding: fix broken multicast with round-robin mode
Round-robin (mode 0) does nothing to ensure that any multicast traffic
originally destined for the host will continue to arrive at the host when
the link that sent the IGMP join or membership report goes down. One of
the benefits of absolute round-robin transmit.
Keeping track of subscribed multicast groups for each slave did not seem
like a good use of resources, so I decided to simply send on the
curr_active slave of the bond (typically the first enslaved device that
is up). This makes failover management simple as IGMP membership
reports only need to be sent when the curr_active_slave changes. I
tested this patch and it appears to work as expected.
Originally reported by Lon Hohberger <lhh@redhat.com>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Lon Hohberger <lhh@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_main.c | 40 +++++++++++++++++++++++++++++++-------
1 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 430c022..5b92fbf 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
write_lock_bh(&bond->curr_slave_lock);
}
}
+
+ /* resend IGMP joins since all were sent on curr_active_slave */
+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
+ bond_resend_igmp_join_requests(bond);
+ }
}
/**
@@ -4138,22 +4143,41 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
struct bonding *bond = netdev_priv(bond_dev);
struct slave *slave, *start_at;
int i, slave_no, res = 1;
+ struct iphdr *iph = ip_hdr(skb);
read_lock(&bond->lock);
if (!BOND_IS_OK(bond))
goto out;
-
/*
- * Concurrent TX may collide on rr_tx_counter; we accept that
- * as being rare enough not to justify using an atomic op here
+ * Start with the curr_active_slave that joined the bond as the
+ * default for sending IGMP traffic. For failover purposes one
+ * needs to maintain some consistency for the interface that will
+ * send the join/membership reports. The curr_active_slave found
+ * will send all of this type of traffic.
*/
- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
+ if ((iph->protocol == htons(IPPROTO_IGMP)) &&
+ (skb->protocol == htons(ETH_P_IP))) {
- bond_for_each_slave(bond, slave, i) {
- slave_no--;
- if (slave_no < 0)
- break;
+ read_lock(&bond->curr_slave_lock);
+ slave = bond->curr_active_slave;
+ read_unlock(&bond->curr_slave_lock);
+
+ if (!slave)
+ goto out;
+ } else {
+ /*
+ * Concurrent TX may collide on rr_tx_counter; we accept
+ * that as being rare enough not to justify using an
+ * atomic op here.
+ */
+ slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
+
+ bond_for_each_slave(bond, slave, i) {
+ slave_no--;
+ if (slave_no < 0)
+ break;
+ }
}
start_at = slave;
^ permalink raw reply related
* Re: UDP path MTU discovery
From: Rick Jones @ 2010-03-26 0:53 UTC (permalink / raw)
To: Glen Turner; +Cc: netdev
In-Reply-To: <1269561751.2891.8.camel@ilion>
Glen Turner wrote:
> [This is a second attempt to report this bug.]
Bugzilla somewhere?
> Path MTU Discovery for UDP underperforms for IPv4 and fails for IPv6 in Linux
> for transactional services like DHCP and RADIUS running on jumbo frame
> interfaces.
>
> These servers send packets with exponential back-off. UDP Path MTU Discovery
> probes for the path MTU each time the application sends a packet. So if you
> start with a high enough interface MTU then the server application backoff
> times get huge and the client gives up before the path MTU is discovered.
>
> This differs from TCP, where it is the kernel -- and not the application --
> which organises retransmission. On receiving a ICMP Fragmentation Needed the
> kernel can immediately re-probe the path MTU wiht no waiting for an
> exponential timer to expire.
>
> In IPv4 there is a work-around for the server, turn off Path MTU Discovery
> and allow routers to fragment the packet as needed. Looking at the code for
> the various transactional servers (ISC DHCP, FreeRADIUS, RADIATOR,
> radsecproxy) they all disable Path MTU Discovery on Linux. This workaround
> has the side effect of hiding the problem, misleading people into thinking
> that UDP Path MTU Discovery actually works for these transactional servers.
>
> In IPv6 routers do not fragment packets, so there is no work around.
> Transactional servers which use UDP over IPv6 encounter exponential backoffs
> within the application and the client abandons the transaction. There is no
> way for the server to know that the packet was lost due to Path MTU Discovery
> and to immediately re-transmit it (without an exponential penalty) so that
> the MTU can be probed again.
>
> This can be viewed as a flaw in the RFC and in the sockets API
> for which IPv6 has removed the common work-around.
So, presuming it is indeed a bug what form might a fix take? Are you suggesting
there should be a way for an application to say "Please let me see/know about
the ICMP messages?" Is that option available on other platforms as a
platform-specific extension? I don't have the details, but the HP-UX 11i v3
(11.31) netinet/udp.h file contains these:
#define UDP_RX_ICMP 0x02 /* boolean; get/set ICMP packets reception */
/* Set to 1 if ICMP packets are to be received*/
#define UDP_RX_ICMP6 0x03 /* boolean; get/set ICMPv6 packets reception */
/* Set to 1 if ICMPv6 packets are to be
received */
and it does appear that they are in more places than just HP-UX - there are some
hits for that for the old Apple Open Transport - which makes sense - it too had
Mentat origins.
rick jones
^ permalink raw reply
* Re: [net-2.6 PATCH v2] bonding: fix broken multicast with round-robin mode
From: Jay Vosburgh @ 2010-03-26 0:55 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, lhh, bonding-devel
In-Reply-To: <20100326004905.GB28741@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
[...]
>Here is an updated and tested patch:
>
>[net-2.6 PATCH] bonding: fix broken multicast with round-robin mode
>
>Round-robin (mode 0) does nothing to ensure that any multicast traffic
>originally destined for the host will continue to arrive at the host when
>the link that sent the IGMP join or membership report goes down. One of
>the benefits of absolute round-robin transmit.
>
>Keeping track of subscribed multicast groups for each slave did not seem
>like a good use of resources, so I decided to simply send on the
>curr_active slave of the bond (typically the first enslaved device that
>is up). This makes failover management simple as IGMP membership
>reports only need to be sent when the curr_active_slave changes. I
>tested this patch and it appears to work as expected.
>
>Originally reported by Lon Hohberger <lhh@redhat.com>.
>
>Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>CC: Lon Hohberger <lhh@redhat.com>
>CC: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>---
> drivers/net/bonding/bond_main.c | 40 +++++++++++++++++++++++++++++++-------
> 1 files changed, 32 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 430c022..5b92fbf 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
> write_lock_bh(&bond->curr_slave_lock);
> }
> }
>+
>+ /* resend IGMP joins since all were sent on curr_active_slave */
>+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
>+ bond_resend_igmp_join_requests(bond);
>+ }
> }
>
> /**
>@@ -4138,22 +4143,41 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
> struct bonding *bond = netdev_priv(bond_dev);
> struct slave *slave, *start_at;
> int i, slave_no, res = 1;
>+ struct iphdr *iph = ip_hdr(skb);
>
> read_lock(&bond->lock);
>
> if (!BOND_IS_OK(bond))
> goto out;
>-
> /*
>- * Concurrent TX may collide on rr_tx_counter; we accept that
>- * as being rare enough not to justify using an atomic op here
>+ * Start with the curr_active_slave that joined the bond as the
>+ * default for sending IGMP traffic. For failover purposes one
>+ * needs to maintain some consistency for the interface that will
>+ * send the join/membership reports. The curr_active_slave found
>+ * will send all of this type of traffic.
> */
>- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
>+ if ((iph->protocol == htons(IPPROTO_IGMP)) &&
>+ (skb->protocol == htons(ETH_P_IP))) {
>
>- bond_for_each_slave(bond, slave, i) {
>- slave_no--;
>- if (slave_no < 0)
>- break;
>+ read_lock(&bond->curr_slave_lock);
>+ slave = bond->curr_active_slave;
>+ read_unlock(&bond->curr_slave_lock);
>+
>+ if (!slave)
>+ goto out;
>+ } else {
>+ /*
>+ * Concurrent TX may collide on rr_tx_counter; we accept
>+ * that as being rare enough not to justify using an
>+ * atomic op here.
>+ */
>+ slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
>+
>+ bond_for_each_slave(bond, slave, i) {
>+ slave_no--;
>+ if (slave_no < 0)
>+ break;
>+ }
> }
>
> start_at = slave;
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: Robert Hancock @ 2010-03-26 0:56 UTC (permalink / raw)
To: Jörn Engel; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <51f3faa71003161630g69160ea9tc1a2d448682632e5@mail.gmail.com>
On Tue, Mar 16, 2010 at 5:30 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:35 AM, Jörn Engel <joern@dublin.logfs.org> wrote:
>> On Mon, 15 March 2010 17:28:45 -0600, Robert Hancock wrote:
>>>
>>> What are the symptoms?
>>
>> No more network. :)
>>
>> According to ifconfig the interface is up and running. If I read
>> /sys/class/net/eth0 correctly, two packets have been sent and none
>> received. LED on network card and switch is off. mii-tool is
>> unhappy.
>>
>> With patch in:
>> Bikini:~# mii-tool
>> No MII transceiver present!.
>>
>> With patch reverted:
>> Bikini:~# mii-tool
>> eth0: negotiated 100baseTx-FD flow-control, link ok
>>
>> I just noticed lspci is also unhappy.
>>
>> With patch in:
>> Bikini:~# lspci -vv > lspci
>> pcilib: sysfs_read_vpd: read failed: Connection timed out.
>>
>> With patch reverted:
>> Bikini:~# lspci -vv > lspci2
>> Bikini:~# diff -u lspci*
>> --- lspci 2010-03-16 09:03:02.000000000 +0100
>> +++ lspci2 2010-03-16 09:09:36.000000000 +0100
>> @@ -246,7 +246,7 @@
>> Vector table: BAR=4 offset=00000000
>> PBA: BAR=4 offset=00000800
>> Capabilities: [cc] Vital Product Data
>> - Not readable
>> + Unknown small resource type 00, will not decode more.
>> Capabilities: [100] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>
>> As you might expect, delta is part of the ethernet controller.
>>
>> All "With patch in" output above is typed off the screen. Beware of
>> typos.
>>
>>> Does setting use_dac=0 in the module options
>>> for r8169 also resolve the problem?
>>
>> /sys/modules/r8169 does not exist. How odd. Anyway, simply changing
>> the default in r8169.c to 0 fixes the problems for me. Good call.
>
>
> I can't really explain how the MII and lspci output is being
> affected.. However, it's possible that some of the chips supported by
> this driver don't actually support 64-bit DMA. Your chip is quite a
> bit older than mine (RTL8102E seems to be one of the older, if not the
> oldest, PCI-E chipset supported by the driver).
>
> Francois, do you know if that's the case, or do you have any active
> contacts at Realtek who can say?
>
> In the meantime, I don't object to reverting the patch for now unless
> we get this sorted out quickly..
Francois, ping? Is there anyone else that has access to this kind of
information about these chips?
It's kind of interesting that there's only been one report of this
though. Either the affected chips are rare among people testing
2.6.34-rc or there's something more to this. Maybe something
wierd/unusual about Jörn's system?
Jörn, are any other devices on your system working with 64-bit
addressing? Try doing this:
find /sys -name "*dma_mask_bits*" | xargs cat
Does anything show more than 32?
^ permalink raw reply
* Re: [PATCH RFC] fix problems with NETIF_F_HIGHDMA in networking drivers v2
From: Robert Hancock @ 2010-03-26 1:03 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linux-kernel, netdev, linux-usb, davem, bzolnier
In-Reply-To: <20100304135738C.fujita.tomonori@lab.ntt.co.jp>
On Wed, Mar 3, 2010 at 10:58 PM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Wed, 03 Mar 2010 20:55:55 -0600
> Robert Hancock <hancockrwd@gmail.com> wrote:
>
>> Many networking drivers have issues with the use of the NETIF_F_HIGHDMA flag.
>> This flag actually indicates whether or not the device/driver can handle
>> skbs located in high memory (as opposed to lowmem). If the flag isn't set and
>> the skb is located in highmem, it needs to be copied.
>> There are two problems with this flag:
>>
>> -Many drivers only set the flag when they detect they can use 64-bit DMA,
>> since otherwise they could receive DMA addresses that they can't handle
>> (which on platforms without IOMMU/SWIOTLB support is fatal). This means that if
>> 64-bit support isn't available, even buffers located below 4GB will get copied
>> unnecessarily.
>>
>> -Some drivers set the flag even though they can't actually handle 64-bit DMA,
>> which would mean that on platforms without IOMMU/SWIOTLB they would get a DMA
>> mapping error if the memory they received happened to be located above 4GB.
>>
>> In order to fix this problem, the existing NETIF_F_HIGHDMA flag is split into
>> two new flags:
>>
>> NETIF_F_DMA_HIGH - indicates if the driver can do DMA to highmem at all
>> NETIF_F_DMA_64BIT - indicates the driver can do DMA to 64-bit memory
>
> Why can't you use dev->dma_mask here like the following?
>
> Then you can fix drivers that use the NETIF_F_HIGHDMA flag to indicate
> that they don't support 64bit DMA.
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index bcc490c..b15f94b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -129,6 +129,7 @@
> #include <linux/jhash.h>
> #include <linux/random.h>
> #include <trace/events/napi.h>
> +#include <linux/pci.h>
>
> #include "net-sysfs.h"
>
> @@ -1787,14 +1788,21 @@ static inline int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
> {
> #ifdef CONFIG_HIGHMEM
> int i;
> + if (!(dev->features & NETIF_F_HIGHDMA)) {
> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> + if (PageHighMem(skb_shinfo(skb)->frags[i].page))
> + return 1;
> + }
>
> - if (dev->features & NETIF_F_HIGHDMA)
> - return 0;
> -
> - for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> - if (PageHighMem(skb_shinfo(skb)->frags[i].page))
> - return 1;
> + if (PCI_DMA_BUS_IS_PHYS) {
> + struct device *pdev = dev->dev.parent;
>
> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> + dma_addr_t addr = page_to_phys(skb_shinfo(skb)->frags[i].page);
> + if (!pdev->dma_mask || addr + PAGE_SIZE - 1 > *pdev->dma_mask)
> + return 1;
> + }
> + }
> #endif
> return 0;
> }
>
This seems like it could be a reasonable approach. The only thing is
that in this code you're returning 1 if the parent device has no DMA
mask set. Wouldn't it make more sense to return 0 in this case? I'm
assuming that in that situation it's a virtual device not backed by
any hardware and there should be no DMA mask restriction...
^ permalink raw reply
* [net-2.6 PATCH] ixgbe: Do not run all Diagnostic offline tests when VFs are active
From: Jeff Kirsher @ 2010-03-26 3:06 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
From: Greg Rose <gregory.v.rose@intel.com>
When running the offline diagnostic tests check to see if any VFs are
online. If so then only run the link test. This is necessary because
the VFs running in guest VMs aren't aware of when the PF is taken
offline for a diagnostic test. Also put a message to the system log
telling the system administrator to take the VFs offline manually if
(s)he wants to run a full diagnostic. Return 1 on each of the tests
not run to alert the user of the condition.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 7949a44..1959ef7 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -1853,6 +1853,26 @@ static void ixgbe_diag_test(struct net_device *netdev,
if (ixgbe_link_test(adapter, &data[4]))
eth_test->flags |= ETH_TEST_FL_FAILED;
+ if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
+ int i;
+ for (i = 0; i < adapter->num_vfs; i++) {
+ if (adapter->vfinfo[i].clear_to_send) {
+ netdev_warn(netdev, "%s",
+ "offline diagnostic is not "
+ "supported when VFs are "
+ "present\n");
+ data[0] = 1;
+ data[1] = 1;
+ data[2] = 1;
+ data[3] = 1;
+ eth_test->flags |= ETH_TEST_FL_FAILED;
+ clear_bit(__IXGBE_TESTING,
+ &adapter->state);
+ goto skip_ol_tests;
+ }
+ }
+ }
+
if (if_running)
/* indicate we're in test mode */
dev_close(netdev);
@@ -1908,6 +1928,7 @@ skip_loopback:
clear_bit(__IXGBE_TESTING, &adapter->state);
}
+skip_ol_tests:
msleep_interruptible(4 * 1000);
}
^ permalink raw reply related
* [net-2.6 PATCH] igb: use correct bits to identify if managability is enabled
From: Jeff Kirsher @ 2010-03-26 3:15 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
igb was previously checking the wrong bits in the MANC register to determine
if managability was enabled. As a result it was incorrectly powering down and
resetting the phy when it didn't need to.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_mac.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/igb/e1000_mac.c b/drivers/net/igb/e1000_mac.c
index 2a8a886..be8d010 100644
--- a/drivers/net/igb/e1000_mac.c
+++ b/drivers/net/igb/e1000_mac.c
@@ -1367,7 +1367,8 @@ out:
* igb_enable_mng_pass_thru - Enable processing of ARP's
* @hw: pointer to the HW structure
*
- * Verifies the hardware needs to allow ARPs to be processed by the host.
+ * Verifies the hardware needs to leave interface enabled so that frames can
+ * be directed to and from the management interface.
**/
bool igb_enable_mng_pass_thru(struct e1000_hw *hw)
{
@@ -1380,8 +1381,7 @@ bool igb_enable_mng_pass_thru(struct e1000_hw *hw)
manc = rd32(E1000_MANC);
- if (!(manc & E1000_MANC_RCV_TCO_EN) ||
- !(manc & E1000_MANC_EN_MAC_ADDR_FILTER))
+ if (!(manc & E1000_MANC_RCV_TCO_EN))
goto out;
if (hw->mac.arc_subsystem_valid) {
^ permalink raw reply related
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