* [PATCH 1/4] e1000e: save skb counts in TX to avoid cache misses
From: Tom Herbert @ 2010-04-24 0:25 UTC (permalink / raw)
To: davem, netdev
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 12648a1..d6da75b 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -188,6 +188,8 @@ struct e1000_buffer {
unsigned long time_stamp;
u16 length;
u16 next_to_watch;
+ unsigned int segs;
+ unsigned int bytecount;
u16 mapped_as_page;
};
/* Rx */
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 5f70c43..4f5034a 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -646,14 +635,8 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter)
cleaned = (i == eop);
if (cleaned) {
- struct sk_buff *skb = buffer_info->skb;
- unsigned int segs, bytecount;
- segs = skb_shinfo(skb)->gso_segs ?: 1;
- /* multiply data chunks by size of headers */
- bytecount = ((segs - 1) * skb_headlen(skb)) +
- skb->len;
- total_tx_packets += segs;
- total_tx_bytes += bytecount;
+ total_tx_packets += buffer_info->segs;
+ total_tx_bytes += buffer_info->bytecount;
}
e1000_put_txbuf(adapter, buffer_info);
@@ -3906,7 +3889,7 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
struct e1000_buffer *buffer_info;
unsigned int len = skb_headlen(skb);
unsigned int offset = 0, size, count = 0, i;
- unsigned int f;
+ unsigned int f, bytecount, segs;
i = tx_ring->next_to_use;
@@ -3965,7 +3948,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
}
}
+ segs = skb_shinfo(skb)->gso_segs ?: 1;
+ /* multiply data chunks by size of headers */
+ bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;
+
tx_ring->buffer_info[i].skb = skb;
+ tx_ring->buffer_info[i].segs = segs;
+ tx_ring->buffer_info[i].bytecount = bytecount;
tx_ring->buffer_info[first].next_to_watch = i;
return count;
^ permalink raw reply related
* [RFC net-next-2.6 PATCH] ixgbe: Example usage of new IRQ affinity_hints for FCoE
From: John Fastabend @ 2010-04-24 0:21 UTC (permalink / raw)
To: bhutchings, peter.p.waskiewicz.jr, netdev, arjan, davem, tglx
Cc: john.r.fastabend, linux-kernel
If the fcoe protocol handler fcoe_rcv() is already executing
on the correct CPU, SCSI-FCP frames can avoid context switching
from the NET_RX softirq to the receive processing thread.
To avoid this context switch this patch uses the affinity_hint
callback to align the interrupt with the FCoE receive processing
threads.
To properly align interrupts for FCoE knowledge of how the
FCoE receive processing threads are setup as well as which
rx rings are dedicated to FCoE and their associated vectors
is needed. Additionally if the FCoE application TLV moves
the FCoE priority this alignment will also need to change.
Handling this in irqbalance alone would required irqbalance
to be aware of DCB, the tx/rx ring mapping for FCoE in
ixgbe and FCoE recv thread CPU mappings. For these reasons
allowing irqbalance to accept hints from ixgbe is ideal for
this case.
Some quick investigative performance numbers show that by
aligning the interrupt correctly an increase in ~50k IOPS
and a decrease in ~10-15% CPU usage can be seen from a
standard default configuration setup by todays irqbalance.
This is a test patch to illustrate how using irq
affininty_hints in ixgbe can benifit FCoE. This patch does
not consider the case where multiple CPU threads can map
to the same queue this case would need further work.
However, I think it does show the benefit of having
an interface to provide affinity_hints.
This patch applies on top of Peter P Waskiewicz Jr previous
series of two patches to implement the affinity hint callback
framework and sample implementation in ixgbe.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index e4cff48..a680424 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -1420,6 +1420,7 @@ static void ixgbe_configure_msix(struct ixgbe_adapter *adapter)
struct ixgbe_q_vector *q_vector;
int i, j, q_vectors, v_idx, r_idx;
u32 mask;
+ struct ixgbe_ring_feature *f = &adapter->ring_feature[RING_F_FCOE];
q_vectors = adapter->num_msix_vectors - NON_Q_VECTORS;
@@ -1463,9 +1464,22 @@ static void ixgbe_configure_msix(struct ixgbe_adapter *adapter)
/*
* Allocate the affinity_hint cpumask, assign the mask for
* this vector, and register our affinity_hint callback.
+ *
+ * JF: Add a check for FCoE enabled adapter to catch rings
+ * that are enabled for FCoE and align them to their
+ * corresponding FCoE recv processing thread.
*/
alloc_cpumask_var(&q_vector->affinity_mask, GFP_KERNEL);
- cpumask_set_cpu(v_idx, q_vector->affinity_mask);
+
+ r_idx = find_first_bit(q_vector->rxr_idx,
+ adapter->num_rx_queues);
+ if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED &&
+ (r_idx >= f->mask) && (r_idx < f->mask + f->indices))
+ cpumask_set_cpu(r_idx - f->mask,
+ q_vector->affinity_mask);
+ else
+ cpumask_set_cpu(v_idx, q_vector->affinity_mask);
+
irq_register_affinity_hint(adapter->msix_entries[v_idx].vector,
adapter,
&ixgbe_irq_affinity_callback);
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2010-04-23 23:52 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Incorrect ERR_PTR handling in rtnetlink and rdma, from
Dan Carpenter.
2) New IPHONE ipheth driver from Diego Giagio.
3) ipv6 ipsec grabs wrong device when bundling. Fix from Nicolas Dichtel.
4) ipv6 TCP code fixes transport header of wrong SKB, from Herbert Xu.
5) Bridge igmp snooping code missing ntohs(), from Eric Dumazet.
6) TCP bind can croak when many ports are bound, effects are exasperated
when there are several local IP addresses. Also from Eric Dumazet.
7) Fix cxgb3 link-up regression with certain chips, from Hiroshi Shimamoto.
8) ipv6 doesn't respect bind-to-device settings properly, fix from Jiri Olsa.
9) Races in KS8851 TX handling can result in an OOPS, from Abraham Arce.
10) Debugging build breaks due to typo in hex dump function name,
fix from Alexander Kuznetsov.
11) gianfar/fsl_pq_mdio can OOPS due to buggy device trees which do
exist in the real world, fix from Anton Vorontsov.
12) Fix RCU warning in dev_pick_tx(), from David Howells.
13) A few small wireless fixes (iwlwifi scanning races, bad
aggregation handling, wrong regulatory bits checked in iwlwifi
EEPROM) from Reinette Chatre, Johannes Berg, and Shanyu Zhao.
14) Fix mishandling of dead unaccepted sockets in x25, from Andrew
Hendry.
Please pull, thanks a lot!
The following changes since commit 33eaf788345c0311ab48ae62673c05f59fb09bb3:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Abraham Arce (1):
KS8851: NULL pointer dereference if list is empty
Alexander Kurz (1):
net: 3c574_cs fix stats.tx_bytes counter
Alexander Kuznetsov (1):
8139too: Fix a typo in the function name.
Anton Vorontsov (2):
fsl_pq_mdio: Fix kernel oops during OF address translation
gianfar: Fix potential oops during OF address translation
Dan Carpenter (2):
rtnetlink: potential ERR_PTR dereference
rdma: potential ERR_PTR dereference
David Howells (1):
net: Fix an RCU warning in dev_pick_tx()
David S. Miller (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Diego Giagio (1):
drivers/net/usb: Add new driver ipheth
Eric Dumazet (2):
bridge: add a missing ntohs()
tcp: bind() fix when many ports are bound
Hans J. Koch (1):
can: Fix possible NULL pointer dereference in ems_usb.c
Herbert Xu (1):
ipv6: Fix tcp_v6_send_response transport header setting.
Hiroshi Shimamoto (1):
cxgb3: fix linkup issue
Jiri Olsa (1):
net: ipv6 bind to device issue
Johannes Berg (2):
iwlwifi: fix scan races
mac80211: remove bogus TX agg state assignment
Nicolas Dichtel (1):
xfrm6: ensure to use the same dev when building a bundle
Reinette Chatre (1):
mac80211: pass HT changes to driver when off channel
Shan Wei (1):
ipv6: allow to send packet after receiving ICMPv6 Too Big message with MTU field less than IPV6_MIN_MTU
Shanyu Zhao (1):
iwlwifi: correct 6000 EEPROM regulatory address
andrew hendry (1):
X25 fix dead unaccepted sockets
drivers/net/8139too.c | 2 +-
drivers/net/Makefile | 1 +
drivers/net/can/usb/ems_usb.c | 8 +-
drivers/net/cxgb3/ael1002.c | 2 +-
drivers/net/fsl_pq_mdio.c | 20 +-
drivers/net/gianfar.c | 6 +-
drivers/net/ks8851.c | 12 +-
drivers/net/pcmcia/3c574_cs.c | 7 +-
drivers/net/usb/Kconfig | 12 +
drivers/net/usb/Makefile | 1 +
drivers/net/usb/ipheth.c | 568 +++++++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 4 +
drivers/net/wireless/iwlwifi/iwl-scan.c | 31 +-
net/bridge/br_multicast.c | 2 +-
net/core/dev.c | 2 +-
net/core/rtnetlink.c | 5 +-
net/ipv4/inet_connection_sock.c | 16 +-
net/ipv6/inet6_connection_sock.c | 15 +-
net/ipv6/ip6_output.c | 2 +-
net/ipv6/route.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
net/ipv6/xfrm6_policy.c | 2 +-
net/mac80211/agg-tx.c | 1 -
net/mac80211/mlme.c | 2 +
net/rds/rdma_transport.c | 2 +-
net/x25/af_x25.c | 1 +
31 files changed, 678 insertions(+), 59 deletions(-)
create mode 100644 drivers/net/usb/ipheth.c
^ permalink raw reply
* Re: [PATCH net-next-2.6] l2tp_eth: fix memory allocation
From: David Miller @ 2010-04-23 23:37 UTC (permalink / raw)
To: jpirko; +Cc: netdev, kleptog, jchapman
In-Reply-To: <20100423110151.GB2853@psychotron.lab.eng.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 23 Apr 2010 13:01:52 +0200
> Since .size is set properly in "struct pernet_operations l2tp_eth_net_ops",
> allocating space for "struct l2tp_eth_net" by hand is not correct, even causes
> memory leakage.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Also applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net-next-2.6] l2tp: fix memory allocation
From: David Miller @ 2010-04-23 23:37 UTC (permalink / raw)
To: jpirko; +Cc: netdev, kleptog, jchapman
In-Reply-To: <20100423105338.GA2853@psychotron.lab.eng.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 23 Apr 2010 12:53:39 +0200
> Since .size is set properly in "struct pernet_operations l2tp_net_ops",
> allocating space for "struct l2tp_net" by hand is not correct, even causes
> memory leakage.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] e100: Fix the TX workqueue race
From: David Miller @ 2010-04-23 23:35 UTC (permalink / raw)
To: alan; +Cc: netdev, e1000-devel
In-Reply-To: <20100423.163127.62645049.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 23 Apr 2010 16:31:27 -0700 (PDT)
> I'll apply this to net-2.6, thanks Alan.
Nevermind...
Doesn't apply to net-2.6, but even when I fix that up it doesn't
even compile. There is no 'dev' variable present etc.
You even use a combination of "dev" and "netdev" in the resulting
code block.
If it doesn't even build, I doubt it's been tested either.
Please resolve this and get some testing on it, thanks.
^ permalink raw reply
* Re: [PATCH] e100: Fix the TX workqueue race
From: David Miller @ 2010-04-23 23:31 UTC (permalink / raw)
To: alan; +Cc: netdev, e1000-devel
In-Reply-To: <20100423143356.7092.45260.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Date: Fri, 23 Apr 2010 15:34:43 +0100
> I'd assumed someone would have picked up on this and fixed it using rtnl_lock
> as was suggested but it seems to have fallen through the cracks ?
>
> Anyway this is I assume what was meant ?
I hope this doesn't deadlock with linkwatch, as that's generally
a problem we hit with trying to take RTNL from workqueues in
the networking.
Linkwatch takes the RTNL lock, and then can make calls into the driver
in it's main work loop.
But since you don't hold any driver locks here (you can't as if we did
we couldn't take the RTNL lock here at all) so it should be OK.
I'll apply this to net-2.6, thanks Alan.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-04-23
From: David Miller @ 2010-04-23 23:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100423190139.GA7276@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Apr 2010 15:01:40 -0400
> Yet another huge batch of updates intended for 2.6.35. The ath9k driver
> in particular gets a lot of attention, and the iwlwifi team continues
> its usual strong showing.
>
> Please let me know if there are problems! Again, this is for the
> 'for-davem' branch where I have pre-resolved some merge conflicts.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 2/2] gianfar: Fix potential oops during OF address translation
From: David Miller @ 2010-04-23 23:20 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, netdev, linuxppc-dev
In-Reply-To: <20100423171244.GB2140@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Fri, 23 Apr 2010 21:12:44 +0400
> gianfar driver may pass NULL pointer to the of_translate_address(),
> which may lead to a kernel oops. Fix this by using of_iomap(), which
> is also much simpler and shorter.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Also applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] fsl_pq_mdio: Fix kernel oops during OF address translation
From: David Miller @ 2010-04-23 23:20 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, netdev, linuxppc-dev
In-Reply-To: <20100423171235.GA2140@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Fri, 23 Apr 2010 21:12:35 +0400
> Old P1020RDB device trees were not specifing tbipa address for
> MDIO nodes, which is now causing this kernel oops:
>
> ...
> eth2: TX BD ring size for Q[6]: 256
> eth2: TX BD ring size for Q[7]: 256
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0015504
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c0015504] memcpy+0x3c/0x9c
> LR [c000a9f8] __of_translate_address+0xfc/0x21c
> Call Trace:
> [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable)
> [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0
> ...
>
> The old device trees are buggy, though having a dead ethernet is
> better than a dead kernel, so fix the issue by using of_iomap().
>
> Also, a somewhat similar issue exist in the probe() routine, though
> there the oops is only a possibility. Nonetheless, fix it too.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Seems reasonable, applied to net-2.6 thanks!
^ permalink raw reply
* Re: eSwitch management
From: Chris Wright @ 2010-04-23 23:04 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Chris Wright, Scott Feldman, David Miller, netdev@vger.kernel.org,
Arnd Bergmann, Ameen Rahman, Amit Salecha, Rajesh Borundia,
shemminger@vyatta.com
In-Reply-To: <193C9C72-488F-4543-9BC1-F9938F189E91@qlogic.com>
* Anirban Chakraborty (anirban.chakraborty@qlogic.com) wrote:
>
> On Apr 23, 2010, at 12:44 PM, Chris Wright wrote:
>
> > * Anirban Chakraborty (anirban.chakraborty@qlogic.com) wrote:
> >> On Apr 23, 2010, at 9:23 AM, Chris Wright wrote:
> >>> * Anirban Chakraborty (anirban.chakraborty@qlogic.com) wrote:
> >>>> It looks like ifla_vf_info does contain most of the data set. But if I use it, what NETLINK protocol family should I use in my driver to receive netlink messages? Do I need to create a private protocol family?
> >>>
> >>> No, you don't need to use netlink in your driver. You just need to fill
> >>> in the relevant net_device_ops in your driver init. Specifically:
> >>>
> >>> * SR-IOV management functions.
> >>> * int (*ndo_set_vf_mac)(struct net_device *dev, int vf, u8* mac);
> >>> * int (*ndo_set_vf_vlan)(struct net_device *dev, int vf, u16 vlan, u8 qos);
> >>> * int (*ndo_set_vf_tx_rate)(struct net_device *dev, int vf, int rate);
> >>> * int (*ndo_get_vf_config)(struct net_device *dev,
> >>> * int vf, struct ifla_vf_info *ivf);
> >>>
> >>> These are all operating on a VF indexed internally w/in the driver, so it's
> >>> a little cumbersome to use from userspace.
> >>
> >> These are all intended for VFs and are configureable from PF.
> >
> > Yes, and while the set of callbacks can change, they are always tied to
> > some net_device (typically the PF) that knows how to make hardware
> > settings on behalf of a VF.
> >
> >> However, in our case, there are multiple physical NIC function on a
> >> port which are configureable by the eswitch.
> >
> > Is there a PCI function that represents the switch? Or a special PCI
> > NIC function that has VEB mgmt plane access? And do you have examples
> > of configuration that you'll do here?
>
> There is no PCI function that represents the switch. However, one
> of the NIC functions can act as a privileged function to configure the
> eswitch. Typically the first NIC function that is enumerated in the bus
> manages the eswitch. Typical configurations would be to set tx bandwidth,
> VLAN ID, MAC address, promiscuous mode setting for each of these ports
> at the start of the day. This is useful in virtualization scenario where
> we can do PCI passthru of the functions to the guest and these settings
> for the guest are configured via the driver in the host.
(btw, this is not uncommon, there other adapters that have multiple
functions for a single physical port that is not SR-IOV based)
How does the privileged function identify the other functions? IOW, the
existing SR-IOV ndo callbacks have most of the above (tx bw control, mac,
vlan id), and have an 'int vf' which is basically just a driver specific
identifier to a non-privileged function or set of hw resources. It looks
like you can use the existing bits (just need to expand a little).
So far we have only:
- tx bw control
- set mac addr
- set vlan id
You've additionally identified:
- set promiscuous mode
I'm also aware of:
- setting port aggregation
- issuing a function reset
- setting port mirroring or bcast/mcast replication
- setting anti-spoofing (mac/vlan..)
- setting security/filtering
- getting port statistics
- ...whatever else I'm forgetting
> <snip>
> >
> > One idea that has been discussed in the past is to create essentially
> > a pluggable set of bridge_ops. The first step would be purely internal
> > shuffling, to make the existing sw bridge code go through the bridge_ops.
> > The second step would be making your driver for whichever PCI function
> > you have that supports managing the bridge create a net_device which is
> > a bridge during driver init. And now normal brctl can call into your
> > VEB via the bridge_ops callbacks. </handwave>
> >
> I liked the idea of iovnl as it works by utilizing port profile. That way the eswitch can be configured with the same port profile that a vswitch in a hypervisor has.
I don't quite follow you here.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] RCU: don't turn off lockdep when find suspicious rcu_dereference_check() usage
From: Miles Lane @ 2010-04-23 22:59 UTC (permalink / raw)
To: paulmck
Cc: Vivek Goyal, Eric Paris, Lai Jiangshan, Ingo Molnar,
Peter Zijlstra, LKML, nauman, eric.dumazet, netdev, Jens Axboe,
Gui Jianfeng, Li Zefan
In-Reply-To: <20100423194255.GE2589@linux.vnet.ibm.com>
On Fri, Apr 23, 2010 at 3:42 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Fri, Apr 23, 2010 at 08:50:59AM -0400, Miles Lane wrote:
>> Hi Paul,
>> There has been a bit of back and forth, and I am not sure what patches
>> I should test now.
>> Could you send me a bundle of whatever needs testing now?
>
> Hello, Miles,
>
> I am posting my set as replies to this message. There are a couple
> of KVM fixes that are going up via Avi's tree, and a number of networking
> fixes that are going up via Dave Miller's tree -- a number of these
> are against quickly changing code, so it didn't make sense for me to
> keep them separately.
>
> I believe that the two splats below are addressed by this patch set
> carried in the networking tree:
>
> https://patchwork.kernel.org/patch/90754/
With your twelve patches and the one linked to above applied to
2.6.34-rc5-git3, here are the warnings I see:
[ 0.173969] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 0.174097] ---------------------------------------------------
[ 0.174226] include/linux/cgroup.h:534 invoked
rcu_dereference_check() without protection!
[ 0.174429]
[ 0.174430] other info that might help us debug this:
[ 0.174431]
[ 0.174792]
[ 0.174793] rcu_scheduler_active = 1, debug_locks = 1
[ 0.175037] no locks held by watchdog/0/5.
[ 0.175162]
[ 0.175163] stack backtrace:
[ 0.175405] Pid: 5, comm: watchdog/0 Not tainted 2.6.34-rc5-git3 #22
[ 0.175534] Call Trace:
[ 0.175666] [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
[ 0.175799] [<ffffffff8102d678>] task_subsys_state+0x59/0x70
[ 0.175931] [<ffffffff810328fa>] __sched_setscheduler+0x19d/0x300
[ 0.176064] [<ffffffff8102b477>] ? need_resched+0x1e/0x28
[ 0.176196] [<ffffffff813cd401>] ? schedule+0x5c3/0x66e
[ 0.176327] [<ffffffff81091943>] ? watchdog+0x0/0x8c
[ 0.176457] [<ffffffff81032a78>] sched_setscheduler+0xe/0x10
[ 0.176587] [<ffffffff8109196d>] watchdog+0x2a/0x8c
[ 0.176677] [<ffffffff81091943>] ? watchdog+0x0/0x8c
[ 0.176808] [<ffffffff81057152>] kthread+0x89/0x91
[ 0.176939] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
[ 0.177073] [<ffffffff81003994>] kernel_thread_helper+0x4/0x10
[ 0.177204] [<ffffffff813cfc40>] ? restore_args+0x0/0x30
[ 0.177334] [<ffffffff810570c9>] ? kthread+0x0/0x91
[ 0.177463] [<ffffffff81003990>] ? kernel_thread_helper+0x0/0x10
[ 3.173419] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 3.173419] ---------------------------------------------------
[ 3.173419] kernel/cgroup.c:4438 invoked rcu_dereference_check()
without protection!
[ 3.173419]
[ 3.173419] other info that might help us debug this:
[ 3.173419]
[ 3.173419]
[ 3.173419] rcu_scheduler_active = 1, debug_locks = 1
[ 3.173419] 2 locks held by async/0/668:
[ 3.173419] #0: (&shost->scan_mutex){+.+.+.}, at:
[<ffffffff812df020>] __scsi_add_device+0x83/0xe4
[ 3.173419] #1: (&(&blkcg->lock)->rlock){......}, at:
[<ffffffff811f2df9>] blkiocg_add_blkio_group+0x29/0x7f
[ 3.173419]
[ 3.173419] stack backtrace:
[ 3.173419] Pid: 668, comm: async/0 Not tainted 2.6.34-rc5-git3 #22
[ 3.173419] Call Trace:
[ 3.173419] [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
[ 3.173419] [<ffffffff8107f9ad>] css_id+0x3f/0x51
[ 3.173419] [<ffffffff811f2e08>] blkiocg_add_blkio_group+0x38/0x7f
[ 3.173419] [<ffffffff811f4dd0>] cfq_init_queue+0xdf/0x2dc
[ 3.173419] [<ffffffff811e33b1>] elevator_init+0xba/0xf5
[ 3.173419] [<ffffffff812dbfaa>] ? scsi_request_fn+0x0/0x451
[ 3.173419] [<ffffffff811e68d7>] blk_init_queue_node+0x12f/0x135
[ 3.173419] [<ffffffff811e68e9>] blk_init_queue+0xc/0xe
[ 3.173419] [<ffffffff812dc41c>] __scsi_alloc_queue+0x21/0x111
[ 3.173419] [<ffffffff812dc524>] scsi_alloc_queue+0x18/0x64
[ 3.173419] [<ffffffff812de520>] scsi_alloc_sdev+0x19e/0x256
[ 3.173419] [<ffffffff812de6be>] scsi_probe_and_add_lun+0xe6/0x9c5
[ 3.173419] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
[ 3.173419] [<ffffffff813ce056>] ? __mutex_lock_common+0x3e4/0x43a
[ 3.173419] [<ffffffff812df020>] ? __scsi_add_device+0x83/0xe4
[ 3.173419] [<ffffffff812d09dc>] ? transport_setup_classdev+0x0/0x17
[ 3.173419] [<ffffffff812df020>] ? __scsi_add_device+0x83/0xe4
[ 3.173419] [<ffffffff812df055>] __scsi_add_device+0xb8/0xe4
[ 3.173419] [<ffffffff812ea945>] ata_scsi_scan_host+0x74/0x16e
[ 3.173419] [<ffffffff81057699>] ? autoremove_wake_function+0x0/0x34
[ 3.173419] [<ffffffff812e8de4>] async_port_probe+0xab/0xb7
[ 3.173419] [<ffffffff8105e1b1>] ? async_thread+0x0/0x1f4
[ 3.173419] [<ffffffff8105e2b6>] async_thread+0x105/0x1f4
[ 3.173419] [<ffffffff81033d8e>] ? default_wake_function+0x0/0xf
[ 3.173419] [<ffffffff8105e1b1>] ? async_thread+0x0/0x1f4
[ 3.173419] [<ffffffff81057152>] kthread+0x89/0x91
[ 3.173419] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
[ 3.173419] [<ffffffff81003994>] kernel_thread_helper+0x4/0x10
[ 3.173419] [<ffffffff813cfc40>] ? restore_args+0x0/0x30
[ 3.173419] [<ffffffff810570c9>] ? kthread+0x0/0x91
[ 3.173419] [<ffffffff81003990>] ? kernel_thread_helper+0x0/0x10
[ 32.905446] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 32.905449] ---------------------------------------------------
[ 32.905453] net/core/dev.c:1993 invoked rcu_dereference_check()
without protection!
[ 32.905456]
[ 32.905457] other info that might help us debug this:
[ 32.905458]
[ 32.905461]
[ 32.905462] rcu_scheduler_active = 1, debug_locks = 1
[ 32.905466] 2 locks held by canberra-gtk-pl/4182:
[ 32.905469] #0: (sk_lock-AF_INET){+.+.+.}, at:
[<ffffffff81394f7d>] inet_stream_connect+0x3a/0x24d
[ 32.905483] #1: (rcu_read_lock_bh){.+....}, at:
[<ffffffff8134a789>] dev_queue_xmit+0x14e/0x4b8
[ 32.905495]
[ 32.905496] stack backtrace:
[ 32.905500] Pid: 4182, comm: canberra-gtk-pl Not tainted 2.6.34-rc5-git3 #22
[ 32.905504] Call Trace:
[ 32.905512] [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
[ 32.905518] [<ffffffff8134a894>] dev_queue_xmit+0x259/0x4b8
[ 32.905524] [<ffffffff8134a789>] ? dev_queue_xmit+0x14e/0x4b8
[ 32.905531] [<ffffffff81041c66>] ? _local_bh_enable_ip+0xcd/0xda
[ 32.905538] [<ffffffff813536da>] neigh_resolve_output+0x234/0x285
[ 32.905544] [<ffffffff8136f69f>] ip_finish_output2+0x257/0x28c
[ 32.905549] [<ffffffff8136f73c>] ip_finish_output+0x68/0x6a
[ 32.905554] [<ffffffff81370433>] T.866+0x52/0x59
[ 32.905559] [<ffffffff8137067e>] ip_output+0xaa/0xb4
[ 32.905565] [<ffffffff8136eb38>] ip_local_out+0x20/0x24
[ 32.905571] [<ffffffff8136f184>] ip_queue_xmit+0x309/0x368
[ 32.905578] [<ffffffff810e4226>] ? __kmalloc_track_caller+0x111/0x155
[ 32.905585] [<ffffffff8138316f>] ? tcp_connect+0x223/0x3d3
[ 32.905591] [<ffffffff813818f1>] tcp_transmit_skb+0x707/0x745
[ 32.905597] [<ffffffff813832c2>] tcp_connect+0x376/0x3d3
[ 32.905604] [<ffffffff81268a43>] ? secure_tcp_sequence_number+0x55/0x6f
[ 32.905610] [<ffffffff81387270>] tcp_v4_connect+0x3df/0x455
[ 32.905617] [<ffffffff8133cb59>] ? lock_sock_nested+0xf3/0x102
[ 32.905623] [<ffffffff81394fe7>] inet_stream_connect+0xa4/0x24d
[ 32.905629] [<ffffffff8133b398>] sys_connect+0x90/0xd0
[ 32.905636] [<ffffffff81002b9c>] ? sysret_check+0x27/0x62
[ 32.905642] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
[ 32.905649] [<ffffffff813cec80>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 32.905655] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b
[ 51.912282] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 51.912285] ---------------------------------------------------
[ 51.912289] net/mac80211/sta_info.c:886 invoked
rcu_dereference_check() without protection!
[ 51.912293]
[ 51.912293] other info that might help us debug this:
[ 51.912295]
[ 51.912298]
[ 51.912298] rcu_scheduler_active = 1, debug_locks = 1
[ 51.912302] no locks held by wpa_supplicant/3951.
[ 51.912305]
[ 51.912306] stack backtrace:
[ 51.912310] Pid: 3951, comm: wpa_supplicant Not tainted 2.6.34-rc5-git3 #22
[ 51.912314] Call Trace:
[ 51.912317] <IRQ> [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
[ 51.912345] [<ffffffffa014f9ae>]
ieee80211_find_sta_by_hw+0x46/0x10f [mac80211]
[ 51.912358] [<ffffffffa014fa8e>] ieee80211_find_sta+0x17/0x19 [mac80211]
[ 51.912373] [<ffffffffa01e50f2>] iwl_tx_queue_reclaim+0xdb/0x1b1 [iwlcore]
[ 51.912380] [<ffffffff8106842b>] ? mark_lock+0x2d/0x235
[ 51.912391] [<ffffffffa0252f1c>] iwl5000_rx_reply_tx+0x4a9/0x556 [iwlagn]
[ 51.912399] [<ffffffff8120a353>] ? is_swiotlb_buffer+0x2e/0x3b
[ 51.912407] [<ffffffffa024bbf4>] iwl_rx_handle+0x163/0x2b5 [iwlagn]
[ 51.912414] [<ffffffff81068904>] ? trace_hardirqs_on_caller+0xfa/0x13f
[ 51.912422] [<ffffffffa024c3ac>] iwl_irq_tasklet+0x2bb/0x3c0 [iwlagn]
[ 51.912429] [<ffffffff810411f3>] tasklet_action+0xa7/0x10f
[ 51.912435] [<ffffffff81042205>] __do_softirq+0x144/0x252
[ 51.912442] [<ffffffff81003a8c>] call_softirq+0x1c/0x34
[ 51.912447] [<ffffffff810050e4>] do_softirq+0x38/0x80
[ 51.912452] [<ffffffff81041cd2>] irq_exit+0x45/0x94
[ 51.912457] [<ffffffff81004829>] do_IRQ+0xad/0xc4
[ 51.912463] [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
[ 51.912470] [<ffffffff813cfb93>] ret_from_intr+0x0/0xf
[ 51.912474] <EOI> [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
[ 51.912484] [<ffffffff8106a75d>] ? lock_release+0x208/0x215
[ 51.912490] [<ffffffff810cbc1c>] might_fault+0xac/0xb3
[ 51.912495] [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
[ 51.912501] [<ffffffff812025e3>] __clear_user+0x15/0x59
[ 51.912508] [<ffffffff8100b2bc>] save_i387_xstate+0x9c/0x1bc
[ 51.912515] [<ffffffff81002276>] do_signal+0x240/0x686
[ 51.912521] [<ffffffff81002b9c>] ? sysret_check+0x27/0x62
[ 51.912527] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
[ 51.912533] [<ffffffff813cec80>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 51.912539] [<ffffffff810026e3>] do_notify_resume+0x27/0x5f
[ 51.912545] [<ffffffff813cec80>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 51.912551] [<ffffffff81002e86>] int_signal+0x12/0x17
[ 51.929529] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 51.929532] ---------------------------------------------------
[ 51.929536] net/mac80211/sta_info.c:886 invoked
rcu_dereference_check() without protection!
[ 51.929540]
[ 51.929541] other info that might help us debug this:
[ 51.929542]
[ 51.929545]
[ 51.929546] rcu_scheduler_active = 1, debug_locks = 1
[ 51.929550] 1 lock held by Xorg/4013:
[ 51.929553] #0: (clock-AF_UNIX){++.+..}, at: [<ffffffff8133cebd>]
sock_def_readable+0x19/0x62
[ 51.929567]
[ 51.929568] stack backtrace:
[ 51.929573] Pid: 4013, comm: Xorg Not tainted 2.6.34-rc5-git3 #22
[ 51.929576] Call Trace:
[ 51.929579] <IRQ> [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
[ 51.929603] [<ffffffffa014f9fe>]
ieee80211_find_sta_by_hw+0x96/0x10f [mac80211]
[ 51.929615] [<ffffffffa014fa8e>] ieee80211_find_sta+0x17/0x19 [mac80211]
[ 51.929631] [<ffffffffa01e50f2>] iwl_tx_queue_reclaim+0xdb/0x1b1 [iwlcore]
[ 51.929642] [<ffffffffa0252f1c>] iwl5000_rx_reply_tx+0x4a9/0x556 [iwlagn]
[ 51.929649] [<ffffffff81068685>] ? mark_held_locks+0x52/0x70
[ 51.929656] [<ffffffff813cf46c>] ? _raw_spin_unlock_irqrestore+0x3a/0x69
[ 51.929662] [<ffffffff8120a353>] ? is_swiotlb_buffer+0x2e/0x3b
[ 51.929671] [<ffffffffa024bbf4>] iwl_rx_handle+0x163/0x2b5 [iwlagn]
[ 51.929680] [<ffffffffa024c3ac>] iwl_irq_tasklet+0x2bb/0x3c0 [iwlagn]
[ 51.929687] [<ffffffff810411f3>] tasklet_action+0xa7/0x10f
[ 51.929693] [<ffffffff81042205>] __do_softirq+0x144/0x252
[ 51.929700] [<ffffffff81003a8c>] call_softirq+0x1c/0x34
[ 51.929705] [<ffffffff810050e4>] do_softirq+0x38/0x80
[ 51.929711] [<ffffffff81041cd2>] irq_exit+0x45/0x94
[ 51.929717] [<ffffffff81019b10>] smp_apic_timer_interrupt+0x87/0x95
[ 51.929724] [<ffffffff81003553>] apic_timer_interrupt+0x13/0x20
[ 51.929727] <EOI> [<ffffffff813cf46e>] ?
_raw_spin_unlock_irqrestore+0x3c/0x69
[ 51.929739] [<ffffffff8102d3fb>] __wake_up_sync_key+0x49/0x52
[ 51.929745] [<ffffffff8133cee7>] sock_def_readable+0x43/0x62
[ 51.929751] [<ffffffff813b1c61>] unix_stream_sendmsg+0x243/0x2e2
[ 51.929758] [<ffffffff8133b912>] ? sock_aio_write+0x0/0xcf
[ 51.929764] [<ffffffff81339342>] __sock_sendmsg+0x59/0x64
[ 51.929770] [<ffffffff8133b9cd>] sock_aio_write+0xbb/0xcf
[ 51.929777] [<ffffffff810e9909>] do_sync_readv_writev+0xbc/0xfb
[ 51.929785] [<ffffffff811c1792>] ? selinux_file_permission+0xa2/0xaf
[ 51.929790] [<ffffffff810e9690>] ? copy_from_user+0x2a/0x2c
[ 51.929797] [<ffffffff811baff1>] ? security_file_permission+0x11/0x13
[ 51.929804] [<ffffffff810ea6a6>] do_readv_writev+0xa2/0x122
[ 51.929810] [<ffffffff810ead93>] ? fcheck_files+0x8f/0xc9
[ 51.929816] [<ffffffff810ea764>] vfs_writev+0x3e/0x49
[ 51.929821] [<ffffffff810ea84a>] sys_writev+0x45/0x8e
[ 51.929828] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH net-2.6 1/9] sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
From: David Miller @ 2010-04-23 22:58 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272063270.5520.39.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 23 Apr 2010 23:54:30 +0100
> This makes no sense. You want to put a quota on bug fixes? I could
> arbitrarily pick some but I'm still going to want to get the other fixes
> into distributions.
It's not a quota. It's a request that only the most catastropic
bugs get fixed this late in the RC.
You don't have 9 catastropic bugs to fix in your driver.
^ permalink raw reply
* Re: [PATCH net-2.6 1/9] sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
From: Ben Hutchings @ 2010-04-23 22:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <20100423.153633.45897185.davem@davemloft.net>
On Fri, 2010-04-23 at 15:36 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Fri, 23 Apr 2010 23:33:28 +0100
>
> > All of these 9 patches should also be applicable to 2.6.33.y, except
> > that one hunk of "sfc: Consistently report short MCDI responses as EIO"
> > is not applicable and should be dropped.
> >
> > Some of the bug fixes are applicable to 2.6.32.y and maybe to 2.6.27.y,
> > but the patches will need some adjustment. I intend to send backported
> > patches to stable@kernel.org separately.
>
> There is zero way I'm applying 9 patches this late in the RC
> series.
>
> If you want this stuff to go into net-2.6 and get backported
> to -stable, pick a very small (2 or 3) set of the most important
> fixes.
This makes no sense. You want to put a quota on bug fixes? I could
arbitrarily pick some but I'm still going to want to get the other fixes
into distributions.
> Consistent -EIO error code returns and junk like that are
> not appropriate this late in the RC, and definitely not -stable
> material.
The important part of that change is that functions were returning 0 in
a failure case. I should have made that the first sentence in the
commit message. I didn't see the point in making a separate commit to
fix the wrong error codes, but I can split this up if you prefer.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 net-2.6 1/9] sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
From: David Miller @ 2010-04-23 22:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272062009.5520.27.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 23 Apr 2010 23:33:28 +0100
> All of these 9 patches should also be applicable to 2.6.33.y, except
> that one hunk of "sfc: Consistently report short MCDI responses as EIO"
> is not applicable and should be dropped.
>
> Some of the bug fixes are applicable to 2.6.32.y and maybe to 2.6.27.y,
> but the patches will need some adjustment. I intend to send backported
> patches to stable@kernel.org separately.
There is zero way I'm applying 9 patches this late in the RC
series.
If you want this stuff to go into net-2.6 and get backported
to -stable, pick a very small (2 or 3) set of the most important
fixes.
Consistent -EIO error code returns and junk like that are
not appropriate this late in the RC, and definitely not -stable
material.
^ permalink raw reply
* Re: [PATCH net-2.6 1/9] sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
From: Ben Hutchings @ 2010-04-23 22:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sf-linux-drivers
In-Reply-To: <1272061439.5520.14.camel@achroite.uk.solarflarecom.com>
All of these 9 patches should also be applicable to 2.6.33.y, except
that one hunk of "sfc: Consistently report short MCDI responses as EIO"
is not applicable and should be dropped.
Some of the bug fixes are applicable to 2.6.32.y and maybe to 2.6.27.y,
but the patches will need some adjustment. I intend to send backported
patches to stable@kernel.org separately.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 net-2.6 9/9] sfc: Extend the legacy interrupt workarounds
From: Ben Hutchings @ 2010-04-23 22:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
From: Steve Hodgson <shodgson@solarflare.com>
Siena has two problems with legacy interrupts:
1. There is no synchronisation between the ISR read completion,
and the interrupt deassert message.
2. A downstream read at the "wrong" moment can return 0, and
suppress generating the next interrupt.
Falcon should suffer from both of these, and it appears it does.
Enable EFX_WORKAROUND_15783 on Falcon as well.
Also, when we see queues == 0, ensure we always schedule or rearm
every event queue.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/nic.c | 23 +++++++++--------------
drivers/net/sfc/workarounds.h | 2 +-
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index 23738f8..b61674c 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1356,33 +1356,28 @@ static irqreturn_t efx_legacy_interrupt(int irq, void *dev_id)
}
result = IRQ_HANDLED;
- } else if (EFX_WORKAROUND_15783(efx) &&
- efx->irq_zero_count++ == 0) {
+ } else if (EFX_WORKAROUND_15783(efx)) {
efx_qword_t *event;
- /* Ensure we rearm all event queues */
+ /* We can't return IRQ_HANDLED more than once on seeing ISR=0
+ * because this might be a shared interrupt. */
+ if (efx->irq_zero_count++ == 0)
+ result = IRQ_HANDLED;
+
+ /* Ensure we schedule or rearm all event queues */
efx_for_each_channel(channel, efx) {
event = efx_event(channel, channel->eventq_read_ptr);
if (efx_event_present(event))
efx_schedule_channel(channel);
+ else
+ efx_nic_eventq_read_ack(channel);
}
-
- result = IRQ_HANDLED;
}
if (result == IRQ_HANDLED) {
efx->last_irq_cpu = raw_smp_processor_id();
EFX_TRACE(efx, "IRQ %d on CPU %d status " EFX_DWORD_FMT "\n",
irq, raw_smp_processor_id(), EFX_DWORD_VAL(reg));
- } else if (EFX_WORKAROUND_15783(efx)) {
- /* We can't return IRQ_HANDLED more than once on seeing ISR0=0
- * because this might be a shared interrupt, but we do need to
- * check the channel every time and preemptively rearm it if
- * it's idle. */
- efx_for_each_channel(channel, efx) {
- if (!channel->work_pending)
- efx_nic_eventq_read_ack(channel);
- }
}
return result;
diff --git a/drivers/net/sfc/workarounds.h b/drivers/net/sfc/workarounds.h
index acd9c73..518f7fc 100644
--- a/drivers/net/sfc/workarounds.h
+++ b/drivers/net/sfc/workarounds.h
@@ -37,7 +37,7 @@
/* Truncated IPv4 packets can confuse the TX packet parser */
#define EFX_WORKAROUND_15592 EFX_WORKAROUND_FALCON_AB
/* Legacy ISR read can return zero once */
-#define EFX_WORKAROUND_15783 EFX_WORKAROUND_SIENA
+#define EFX_WORKAROUND_15783 EFX_WORKAROUND_ALWAYS
/* Legacy interrupt storm when interrupt fifo fills */
#define EFX_WORKAROUND_17213 EFX_WORKAROUND_SIENA
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 8/9] sfc: Reconfigure the XAUI serdes after an EM reset
From: Ben Hutchings @ 2010-04-23 22:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
From: Steve Hodgson <shodgson@solarflare.com>
Fix a regression introduced in d3245b28ef2a45ec4e115062a38100bd06229289
"sfc: Refactor link configuration".
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/falcon.c | 3 +++
drivers/net/sfc/falcon_xmac.c | 2 +-
drivers/net/sfc/nic.h | 1 +
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index e783b0a..655b697 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -507,6 +507,9 @@ static void falcon_reset_macs(struct efx_nic *efx)
/* Ensure the correct MAC is selected before statistics
* are re-enabled by the caller */
efx_writeo(efx, &mac_ctrl, FR_AB_MAC_CTRL);
+
+ /* This can run even when the GMAC is selected */
+ falcon_setup_xaui(efx);
}
void falcon_drain_tx_fifo(struct efx_nic *efx)
diff --git a/drivers/net/sfc/falcon_xmac.c b/drivers/net/sfc/falcon_xmac.c
index 3d65abf..c84a2ce 100644
--- a/drivers/net/sfc/falcon_xmac.c
+++ b/drivers/net/sfc/falcon_xmac.c
@@ -26,7 +26,7 @@
*************************************************************************/
/* Configure the XAUI driver that is an output from Falcon */
-static void falcon_setup_xaui(struct efx_nic *efx)
+void falcon_setup_xaui(struct efx_nic *efx)
{
efx_oword_t sdctl, txdrv;
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 3166baf..bcf1ac4 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -203,6 +203,7 @@ extern void falcon_irq_ack_a1(struct efx_nic *efx);
extern int efx_nic_flush_queues(struct efx_nic *efx);
extern void falcon_start_nic_stats(struct efx_nic *efx);
extern void falcon_stop_nic_stats(struct efx_nic *efx);
+extern void falcon_setup_xaui(struct efx_nic *efx);
extern int falcon_reset_xaui(struct efx_nic *efx);
extern void efx_nic_init_common(struct efx_nic *efx);
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 7/9] sfc: Stop masking out XGMII faults over reconfigures
From: Ben Hutchings @ 2010-04-23 22:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
From: Steve Hodgson <shodgson@solarflare.com>
The aim of this code was to avoid a spurious XGMII fault over a MAC
reconfigure. It's less relevant now that the PHY reconfigure isn't
called from the MAC reconfigure.
After applying this patch, our link stress test passed 48 hours of
testing without ever resetting the PHY.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/falcon_xmac.c | 20 +++++---------------
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/net/sfc/falcon_xmac.c b/drivers/net/sfc/falcon_xmac.c
index 8ccab2c..3d65abf 100644
--- a/drivers/net/sfc/falcon_xmac.c
+++ b/drivers/net/sfc/falcon_xmac.c
@@ -85,14 +85,14 @@ int falcon_reset_xaui(struct efx_nic *efx)
return -ETIMEDOUT;
}
-static void falcon_mask_status_intr(struct efx_nic *efx, bool enable)
+static void falcon_ack_status_intr(struct efx_nic *efx)
{
efx_oword_t reg;
if ((efx_nic_rev(efx) != EFX_REV_FALCON_B0) || LOOPBACK_INTERNAL(efx))
return;
- /* We expect xgmii faults if the wireside link is up */
+ /* We expect xgmii faults if the wireside link is down */
if (!EFX_WORKAROUND_5147(efx) || !efx->link_state.up)
return;
@@ -101,14 +101,7 @@ static void falcon_mask_status_intr(struct efx_nic *efx, bool enable)
if (efx->xmac_poll_required)
return;
- /* Flush the ISR */
- if (enable)
- efx_reado(efx, ®, FR_AB_XM_MGT_INT_MSK);
-
- EFX_POPULATE_OWORD_2(reg,
- FRF_AB_XM_MSK_RMTFLT, !enable,
- FRF_AB_XM_MSK_LCLFLT, !enable);
- efx_writeo(efx, ®, FR_AB_XM_MGT_INT_MASK);
+ efx_reado(efx, ®, FR_AB_XM_MGT_INT_MSK);
}
static bool falcon_xgxs_link_ok(struct efx_nic *efx)
@@ -283,15 +276,13 @@ static bool falcon_xmac_check_fault(struct efx_nic *efx)
static int falcon_reconfigure_xmac(struct efx_nic *efx)
{
- falcon_mask_status_intr(efx, false);
-
falcon_reconfigure_xgxs_core(efx);
falcon_reconfigure_xmac_core(efx);
falcon_reconfigure_mac_wrapper(efx);
efx->xmac_poll_required = !falcon_xmac_link_ok_retry(efx, 5);
- falcon_mask_status_intr(efx, true);
+ falcon_ack_status_intr(efx);
return 0;
}
@@ -362,9 +353,8 @@ void falcon_poll_xmac(struct efx_nic *efx)
!efx->xmac_poll_required)
return;
- falcon_mask_status_intr(efx, false);
efx->xmac_poll_required = !falcon_xmac_link_ok_retry(efx, 1);
- falcon_mask_status_intr(efx, true);
+ falcon_ack_status_intr(efx);
}
struct efx_mac_operations falcon_xmac_operations = {
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 6/9] sfc: Handle serious errors in exactly one interrupt handler
From: Ben Hutchings @ 2010-04-23 22:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
From: Steve Hodgson <shodgson@solarflare.com>
'Fatal' errors set an interrupt flag associated with a specific event
queue; only read the syndrome vector if we see that queue's flag set
(legacy interrupts) or in the interrupt handler for that queue (MSI).
Do not ignore an interrupt if the fatal error flag is set but specific
error flags are all zero. Even if we don't schedule a reset, we must
respect the queue mask and rearm the appropriate event queues.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/falcon.c | 13 ++++++++-----
drivers/net/sfc/net_driver.h | 2 ++
drivers/net/sfc/nic.c | 35 +++++++++++++++++++----------------
3 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 08278e7..e783b0a 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -175,16 +175,19 @@ irqreturn_t falcon_legacy_interrupt_a1(int irq, void *dev_id)
EFX_TRACE(efx, "IRQ %d on CPU %d status " EFX_OWORD_FMT "\n",
irq, raw_smp_processor_id(), EFX_OWORD_VAL(*int_ker));
- /* Check to see if we have a serious error condition */
- syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
- if (unlikely(syserr))
- return efx_nic_fatal_interrupt(efx);
-
/* Determine interrupting queues, clear interrupt status
* register and acknowledge the device interrupt.
*/
BUILD_BUG_ON(FSF_AZ_NET_IVEC_INT_Q_WIDTH > EFX_MAX_CHANNELS);
queues = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_INT_Q);
+
+ /* Check to see if we have a serious error condition */
+ if (queues & (1U << efx->fatal_irq_level)) {
+ syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
+ if (unlikely(syserr))
+ return efx_nic_fatal_interrupt(efx);
+ }
+
EFX_ZERO_OWORD(*int_ker);
wmb(); /* Ensure the vector is cleared before interrupt ack */
falcon_irq_ack_a1(efx);
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index cb018e2..70aea3a 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -672,6 +672,7 @@ union efx_multicast_hash {
* This register is written with the SMP processor ID whenever an
* interrupt is handled. It is used by efx_nic_test_interrupt()
* to verify that an interrupt has occurred.
+ * @fatal_irq_level: IRQ level (bit number) used for serious errors
* @spi_flash: SPI flash device
* This field will be %NULL if no flash device is present (or for Siena).
* @spi_eeprom: SPI EEPROM device
@@ -756,6 +757,7 @@ struct efx_nic {
struct efx_buffer irq_status;
volatile signed int last_irq_cpu;
unsigned long irq_zero_count;
+ unsigned fatal_irq_level;
struct efx_spi_device *spi_flash;
struct efx_spi_device *spi_eeprom;
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index 664fd6c..23738f8 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1229,15 +1229,9 @@ static inline void efx_nic_interrupts(struct efx_nic *efx,
bool enabled, bool force)
{
efx_oword_t int_en_reg_ker;
- unsigned int level = 0;
-
- if (EFX_WORKAROUND_17213(efx) && !EFX_INT_MODE_USE_MSI(efx))
- /* Set the level always even if we're generating a test
- * interrupt, because our legacy interrupt handler is safe */
- level = 0x1f;
EFX_POPULATE_OWORD_3(int_en_reg_ker,
- FRF_AZ_KER_INT_LEVE_SEL, level,
+ FRF_AZ_KER_INT_LEVE_SEL, efx->fatal_irq_level,
FRF_AZ_KER_INT_KER, force,
FRF_AZ_DRV_INT_EN_KER, enabled);
efx_writeo(efx, &int_en_reg_ker, FR_AZ_INT_EN_KER);
@@ -1291,8 +1285,6 @@ irqreturn_t efx_nic_fatal_interrupt(struct efx_nic *efx)
EFX_OWORD_FMT ": %s\n", EFX_OWORD_VAL(*int_ker),
EFX_OWORD_VAL(fatal_intr),
error ? "disabling bus mastering" : "no recognised error");
- if (error == 0)
- goto out;
/* If this is a memory parity error dump which blocks are offending */
mem_perr = EFX_OWORD_FIELD(fatal_intr, FRF_AZ_MEM_PERR_INT_KER);
@@ -1324,7 +1316,7 @@ irqreturn_t efx_nic_fatal_interrupt(struct efx_nic *efx)
"NIC will be disabled\n");
efx_schedule_reset(efx, RESET_TYPE_DISABLE);
}
-out:
+
return IRQ_HANDLED;
}
@@ -1346,9 +1338,11 @@ static irqreturn_t efx_legacy_interrupt(int irq, void *dev_id)
queues = EFX_EXTRACT_DWORD(reg, 0, 31);
/* Check to see if we have a serious error condition */
- syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
- if (unlikely(syserr))
- return efx_nic_fatal_interrupt(efx);
+ if (queues & (1U << efx->fatal_irq_level)) {
+ syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
+ if (unlikely(syserr))
+ return efx_nic_fatal_interrupt(efx);
+ }
if (queues != 0) {
if (EFX_WORKAROUND_15783(efx))
@@ -1413,9 +1407,11 @@ static irqreturn_t efx_msi_interrupt(int irq, void *dev_id)
irq, raw_smp_processor_id(), EFX_OWORD_VAL(*int_ker));
/* Check to see if we have a serious error condition */
- syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
- if (unlikely(syserr))
- return efx_nic_fatal_interrupt(efx);
+ if (channel->channel == efx->fatal_irq_level) {
+ syserr = EFX_OWORD_FIELD(*int_ker, FSF_AZ_NET_IVEC_FATAL_INT);
+ if (unlikely(syserr))
+ return efx_nic_fatal_interrupt(efx);
+ }
/* Schedule processing of the channel */
efx_schedule_channel(channel);
@@ -1553,6 +1549,13 @@ void efx_nic_init_common(struct efx_nic *efx)
FRF_AZ_INT_ADR_KER, efx->irq_status.dma_addr);
efx_writeo(efx, &temp, FR_AZ_INT_ADR_KER);
+ if (EFX_WORKAROUND_17213(efx) && !EFX_INT_MODE_USE_MSI(efx))
+ /* Use an interrupt level unused by event queues */
+ efx->fatal_irq_level = 0x1f;
+ else
+ /* Use a valid MSI-X vector */
+ efx->fatal_irq_level = 0;
+
/* Enable all the genuinely fatal interrupts. (They are still
* masked by the overall interrupt mask, controlled by
* falcon_interrupts()).
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 5/9] sfc: Change falcon_probe_board() to fail for unsupported boards
From: Ben Hutchings @ 2010-04-23 22:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
The driver needs specific PHY and board support code for each SFC4000
board; there is no point trying to continue if it is missing.
Currently unsupported boards can trigger an 'oops'.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/falcon.c | 4 +++-
drivers/net/sfc/falcon_boards.c | 13 +++----------
drivers/net/sfc/nic.h | 2 +-
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index d294d66..08278e7 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -1320,7 +1320,9 @@ static int falcon_probe_nvconfig(struct efx_nic *efx)
EFX_LOG(efx, "PHY is %d phy_id %d\n", efx->phy_type, efx->mdio.prtad);
- falcon_probe_board(efx, board_rev);
+ rc = falcon_probe_board(efx, board_rev);
+ if (rc)
+ goto fail2;
kfree(nvconfig);
return 0;
diff --git a/drivers/net/sfc/falcon_boards.c b/drivers/net/sfc/falcon_boards.c
index 5712fdd..c7a933a 100644
--- a/drivers/net/sfc/falcon_boards.c
+++ b/drivers/net/sfc/falcon_boards.c
@@ -728,15 +728,7 @@ static const struct falcon_board_type board_types[] = {
},
};
-static const struct falcon_board_type falcon_dummy_board = {
- .init = efx_port_dummy_op_int,
- .init_phy = efx_port_dummy_op_void,
- .fini = efx_port_dummy_op_void,
- .set_id_led = efx_port_dummy_op_set_id_led,
- .monitor = efx_port_dummy_op_int,
-};
-
-void falcon_probe_board(struct efx_nic *efx, u16 revision_info)
+int falcon_probe_board(struct efx_nic *efx, u16 revision_info)
{
struct falcon_board *board = falcon_board(efx);
u8 type_id = FALCON_BOARD_TYPE(revision_info);
@@ -754,8 +746,9 @@ void falcon_probe_board(struct efx_nic *efx, u16 revision_info)
(efx->pci_dev->subsystem_vendor == EFX_VENDID_SFC)
? board->type->ref_model : board->type->gen_type,
'A' + board->major, board->minor);
+ return 0;
} else {
EFX_ERR(efx, "unknown board type %d\n", type_id);
- board->type = &falcon_dummy_board;
+ return -ENODEV;
}
}
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 9351c03..3166baf 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -156,7 +156,7 @@ extern struct efx_nic_type siena_a0_nic_type;
**************************************************************************
*/
-extern void falcon_probe_board(struct efx_nic *efx, u16 revision_info);
+extern int falcon_probe_board(struct efx_nic *efx, u16 revision_info);
/* TX data path */
extern int efx_nic_probe_tx(struct efx_tx_queue *tx_queue);
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 4/9] sfc: Consistently report short MCDI responses as EIO
From: Ben Hutchings @ 2010-04-23 22:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
EMSGSIZE means 'Message too large' whereas these are too short.
EINVAL means 'Invalid argument' whereas this is a response.
In some cases failing functions were returning 0 which is obviously wrong.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/mcdi.c | 22 ++++++++++++++--------
drivers/net/sfc/mcdi_phy.c | 6 +++---
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/sfc/mcdi.c b/drivers/net/sfc/mcdi.c
index c48669c..1344afa 100644
--- a/drivers/net/sfc/mcdi.c
+++ b/drivers/net/sfc/mcdi.c
@@ -613,7 +613,7 @@ int efx_mcdi_fwver(struct efx_nic *efx, u64 *version, u32 *build)
}
if (outlength < MC_CMD_GET_VERSION_V1_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
@@ -647,8 +647,10 @@ int efx_mcdi_drv_attach(struct efx_nic *efx, bool driver_operating,
outbuf, sizeof(outbuf), &outlen);
if (rc)
goto fail;
- if (outlen < MC_CMD_DRV_ATTACH_OUT_LEN)
+ if (outlen < MC_CMD_DRV_ATTACH_OUT_LEN) {
+ rc = -EIO;
goto fail;
+ }
if (was_attached != NULL)
*was_attached = MCDI_DWORD(outbuf, DRV_ATTACH_OUT_OLD_STATE);
@@ -676,7 +678,7 @@ int efx_mcdi_get_board_cfg(struct efx_nic *efx, u8 *mac_address,
goto fail;
if (outlen < MC_CMD_GET_BOARD_CFG_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
@@ -738,8 +740,10 @@ int efx_mcdi_nvram_types(struct efx_nic *efx, u32 *nvram_types_out)
outbuf, sizeof(outbuf), &outlen);
if (rc)
goto fail;
- if (outlen < MC_CMD_NVRAM_TYPES_OUT_LEN)
+ if (outlen < MC_CMD_NVRAM_TYPES_OUT_LEN) {
+ rc = -EIO;
goto fail;
+ }
*nvram_types_out = MCDI_DWORD(outbuf, NVRAM_TYPES_OUT_TYPES);
return 0;
@@ -765,8 +769,10 @@ int efx_mcdi_nvram_info(struct efx_nic *efx, unsigned int type,
outbuf, sizeof(outbuf), &outlen);
if (rc)
goto fail;
- if (outlen < MC_CMD_NVRAM_INFO_OUT_LEN)
+ if (outlen < MC_CMD_NVRAM_INFO_OUT_LEN) {
+ rc = -EIO;
goto fail;
+ }
*size_out = MCDI_DWORD(outbuf, NVRAM_INFO_OUT_SIZE);
*erase_size_out = MCDI_DWORD(outbuf, NVRAM_INFO_OUT_ERASESIZE);
@@ -968,7 +974,7 @@ static int efx_mcdi_read_assertion(struct efx_nic *efx)
if (rc)
return rc;
if (outlen < MC_CMD_GET_ASSERTS_OUT_LEN)
- return -EINVAL;
+ return -EIO;
/* Print out any recorded assertion state */
flags = MCDI_DWORD(outbuf, GET_ASSERTS_OUT_GLOBAL_FLAGS);
@@ -1086,7 +1092,7 @@ int efx_mcdi_wol_filter_set(struct efx_nic *efx, u32 type,
goto fail;
if (outlen < MC_CMD_WOL_FILTER_SET_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
@@ -1121,7 +1127,7 @@ int efx_mcdi_wol_filter_get_magic(struct efx_nic *efx, int *id_out)
goto fail;
if (outlen < MC_CMD_WOL_FILTER_GET_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
diff --git a/drivers/net/sfc/mcdi_phy.c b/drivers/net/sfc/mcdi_phy.c
index 2f23546..5d34487 100644
--- a/drivers/net/sfc/mcdi_phy.c
+++ b/drivers/net/sfc/mcdi_phy.c
@@ -48,7 +48,7 @@ efx_mcdi_get_phy_cfg(struct efx_nic *efx, struct efx_mcdi_phy_cfg *cfg)
goto fail;
if (outlen < MC_CMD_GET_PHY_CFG_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
@@ -111,7 +111,7 @@ static int efx_mcdi_loopback_modes(struct efx_nic *efx, u64 *loopback_modes)
goto fail;
if (outlen < MC_CMD_GET_LOOPBACK_MODES_OUT_LEN) {
- rc = -EMSGSIZE;
+ rc = -EIO;
goto fail;
}
@@ -587,7 +587,7 @@ static int efx_mcdi_phy_test_alive(struct efx_nic *efx)
return rc;
if (outlen < MC_CMD_GET_PHY_STATE_OUT_LEN)
- return -EMSGSIZE;
+ return -EIO;
if (MCDI_DWORD(outbuf, GET_PHY_STATE_STATE) != MC_CMD_PHY_STATE_OK)
return -EINVAL;
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 3/9] sfc: Always close net device at the end of a disabling reset
From: Ben Hutchings @ 2010-04-23 22:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1272061459.5520.15.camel@achroite.uk.solarflarecom.com>
This fixes a regression introduced by commit
eb9f6744cbfa97674c13263802259b5aa0034594 "sfc: Implement ethtool
reset operation".
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 6486657..649a264 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1861,6 +1861,7 @@ out:
}
if (disabled) {
+ dev_close(efx->net_dev);
EFX_ERR(efx, "has been disabled\n");
efx->state = STATE_DISABLED;
} else {
@@ -1884,8 +1885,7 @@ static void efx_reset_work(struct work_struct *data)
}
rtnl_lock();
- if (efx_reset(efx, efx->reset_pending))
- dev_close(efx->net_dev);
+ (void)efx_reset(efx, efx->reset_pending);
rtnl_unlock();
}
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 2/9] sfc: Ignore parity errors in the other port's SRAM
From: Ben Hutchings @ 2010-04-23 22:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <0998e2e60655106abde76dcb4b7bac1136d1a11f.1272061382.git.bhutchings@solarflare.com>
From: Steve Hodgson <shodgson@solarflare.com>
Siena has a separate SRAM bank for each port. On single-port boards
these can be merged together, so each port has an interrupt flag for
parity errors in the other port's SRAM. Currently we do not enable
such merging and should mask this interrupt source.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/nic.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index b06f8e3..664fd6c 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1563,6 +1563,8 @@ void efx_nic_init_common(struct efx_nic *efx)
FRF_AZ_ILL_ADR_INT_KER_EN, 1,
FRF_AZ_RBUF_OWN_INT_KER_EN, 1,
FRF_AZ_TBUF_OWN_INT_KER_EN, 1);
+ if (efx_nic_rev(efx) >= EFX_REV_SIENA_A0)
+ EFX_SET_OWORD_FIELD(temp, FRF_CZ_SRAM_PERR_INT_P_KER_EN, 1);
EFX_INVERT_OWORD(temp);
efx_writeo(efx, &temp, FR_AZ_FATAL_INTR_KER);
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH net-2.6 1/9] sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
From: Ben Hutchings @ 2010-04-23 22:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
From: Steve Hodgson <shodgson@solarflare.com>
The original code would wait indefinitely if MAC stats DMA failed.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/siena.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sfc/siena.c b/drivers/net/sfc/siena.c
index 38dcc42..e0c46f5 100644
--- a/drivers/net/sfc/siena.c
+++ b/drivers/net/sfc/siena.c
@@ -456,8 +456,17 @@ static int siena_try_update_nic_stats(struct efx_nic *efx)
static void siena_update_nic_stats(struct efx_nic *efx)
{
- while (siena_try_update_nic_stats(efx) == -EAGAIN)
- cpu_relax();
+ int retry;
+
+ /* If we're unlucky enough to read statistics wduring the DMA, wait
+ * up to 10ms for it to finish (typically takes <500us) */
+ for (retry = 0; retry < 100; ++retry) {
+ if (siena_try_update_nic_stats(efx) == 0)
+ return;
+ udelay(100);
+ }
+
+ /* Use the old values instead */
}
static void siena_start_nic_stats(struct efx_nic *efx)
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 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