* RE: [PATCH net-next] iwlwifi: dont pull too much payload in skb head
From: Eric Dumazet @ 2012-05-18 15:21 UTC (permalink / raw)
To: Berg, Johannes; +Cc: David Miller, netdev, Guy, Wey-Yi W
In-Reply-To: <1DC40B07CD6EC041A66726C271A73AE61955AE5D@IRSMSX102.ger.corp.intel.com>
On Fri, 2012-05-18 at 14:59 +0000, Berg, Johannes wrote:
> > Since merge window is now pretty close, I would prefer David applies this
> > directly in net-next, if you dont mind, as this patch is more a core network issue
> > than an iwlwifi one.
> >
> > Thanks !
>
> Sure, good with me, I don't think we have colliding patches.
>
> Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Thanks
> We may want to move this code into mac80211 later though since it also
> has an if (pull in everything, even reallocating if necessary, if it's
> a management frame), but that can wait, I think we're the only driver
> using paged RX.
This is OK, these frames wont be injected in linux IP/TCP stack.
Or maybe you would like an optimized version of skb_header_pointer(),
avoiding the copy if the whole blob can be part of _one_ fragment ?
^ permalink raw reply
* Re: [V2 PATCH 2/9] macvtap: zerocopy: fix truesize underestimation
From: Shirley Ma @ 2012-05-18 15:22 UTC (permalink / raw)
To: Jason Wang; +Cc: eric.dumazet, mst, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <4FB62009.2050900@redhat.com>
On Fri, 2012-05-18 at 18:10 +0800, Jason Wang wrote:
> > On Thu, 2012-05-17 at 10:59 +0800, Jason Wang wrote:
> >> Didn't see how this affact skb->len. And for truesize, I think they
> >> are
> >> different, when the offset were not zero, the data in this vector
> >> were
> >> divided into two parts. First part is copied into skb directly, and
> >> the
> >> second were pinned from a whole userspace page by
> >> get_user_pages_fast(),
> >> so we need count the whole page to the socket limit to prevent evil
> >> application.
> > What I meant that the code for skb->truesize has double added the
> first
> > offset if any left from that vector (partically copied into skb
> > directly, and then count pagesize which includes the offset
> (truesize +=
> > PAGE_SIZE)).
>
> Yes, I get you mean. There's no difference between first frag and
> others: it's also possible for other frags that didn't occupy the
> whole
> page. Since we pin the whole user page, better to count the whole
> page
> size to prevent evil application.
The difference between first frags and others is other frags might not
occupy the whole page, but the first frags extra offset was doubled
added in skb truesize.
So it's ok for skb->truesize to be bigger than all the skb pinned pages
here?
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH net-next v5] be2net: Fix to allow get/set of debug levels in the firmware.
From: Ben Hutchings @ 2012-05-18 15:24 UTC (permalink / raw)
To: Somnath Kotur; +Cc: netdev, Suresh Reddy
In-Reply-To: <66e444e7-aef9-4ce5-a695-10a70fe3b31e@exht1.ad.emulex.com>
On Fri, 2012-05-18 at 14:29 +0530, Somnath Kotur wrote:
> Patch re-spin.
> Incorporated review comments by Ben Hutchings.
>
> Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Shirley Ma @ 2012-05-18 15:29 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, eric.dumazet, netdev, linux-kernel, ebiederm,
davem
In-Reply-To: <4FB61D57.4030103@redhat.com>
On Fri, 2012-05-18 at 17:58 +0800, Jason Wang wrote:
> On 05/17/2012 11:34 PM, Shirley Ma wrote:
> > On Thu, 2012-05-17 at 10:50 +0800, Jason Wang wrote:
> >> The problem is we may stop the tx queue when there no enough
> capacity
> >> to
> >> place packets, at this moment we depends on the tx interrupt to
> >> re-enable the tx queue. So if we didn't poll the vhost during
> >> callback,
> >> guest may lose the tx interrupt to re-enable the tx queue which
> could
> >> stall the whole tx queue.
> > VHOST_MAX_PEND should handle the capacity.
> >
> > Hasn't the above situation been handled in handle_tx() code?:
> > ...
> > if (unlikely(num_pends> VHOST_MAX_PEND)) {
> > tx_poll_start(net, sock);
> >
> set_bit(SOCK_ASYNC_NOSPACE,&sock->flags);
> > break;
> > }
> > ...
> >
> > Thanks
> > Shirley
>
> It may not help in because:
>
> - tx polling depends on skb_orphan() which is often called by device
> driver when it place the packet into the queue of the devices instead
> of when the packets were sent. So it was too early for vhost to be
> notified.
Then do you think it's better to replace with vhost_poll_queue here
instead?
> - it only works when the pending DMAs exceeds VHOST_MAX_PEND, it's
> highly possible that guest needs to be notified when the pending
> packets
> isn't so much.
In which situation the guest needs to be notified when there is no TX
besides buffers run out?
> So this piece of code may not help and could be removed and we need
> to
> poll the virt-queue during zerocopy callback ( through it could be
> further optimized but may not be easy).
Thanks
Shirley
^ permalink raw reply
* [PATCH net-next] ipv6: remove csummode in ip6_append_data()
From: Eric Dumazet @ 2012-05-18 15:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
csummode variable is always CHECKSUM_NONE in ip6_append_data()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/ip6_output.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index be2264e..a254e4b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1198,7 +1198,6 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
int copy;
int err;
int offset = 0;
- int csummode = CHECKSUM_NONE;
__u8 tx_flags = 0;
if (flags&MSG_PROBE)
@@ -1411,7 +1410,7 @@ alloc_new_skb:
/*
* Fill in the control structures
*/
- skb->ip_summed = csummode;
+ skb->ip_summed = CHECKSUM_NONE;
skb->csum = 0;
/* reserve for fragmentation and ipsec header */
skb_reserve(skb, hh_len + sizeof(struct frag_hdr) +
@@ -1454,7 +1453,6 @@ alloc_new_skb:
transhdrlen = 0;
exthdrlen = 0;
dst_exthdrlen = 0;
- csummode = CHECKSUM_NONE;
/*
* Put the packet on the pending queue
^ permalink raw reply related
* Re: TCPBacklogDrops during aggressive bursts of traffic
From: Kieran Mansley @ 2012-05-18 15:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Hutchings, netdev
In-Reply-To: <1337272654.3403.20.camel@edumazet-glaptop>
On Thu, 2012-05-17 at 18:37 +0200, Eric Dumazet wrote:
>
> Hmm, I was not suggesting running production servers with this
> setting, only do an experiment.
OK. I've found a more reliable way to reproduce it (use MSG_WAITALL to
make the recv call wait till the socket buffer will be more full) and
tried with the tcp_adv_win_scale to -2. It's hard to make any confident
assertions about the impact of it, but if it does change the behaviour
it is a small change. There are certainly still plenty of drops with
that setting.
> With net-next and tcp coalescing, I no longer have TCPBacklogDrops /
> collapses, but I dont have sfc card/driver.
I'll try that.
Kieran
^ permalink raw reply
* Re: TCPBacklogDrops during aggressive bursts of traffic
From: Eric Dumazet @ 2012-05-18 15:49 UTC (permalink / raw)
To: Kieran Mansley; +Cc: Ben Hutchings, netdev
In-Reply-To: <1337355955.15044.24.camel@kjm-desktop.uk.level5networks.com>
On Fri, 2012-05-18 at 16:45 +0100, Kieran Mansley wrote:
> On Thu, 2012-05-17 at 18:37 +0200, Eric Dumazet wrote:
> >
> > Hmm, I was not suggesting running production servers with this
> > setting, only do an experiment.
>
> OK. I've found a more reliable way to reproduce it (use MSG_WAITALL to
> make the recv call wait till the socket buffer will be more full) and
> tried with the tcp_adv_win_scale to -2. It's hard to make any confident
> assertions about the impact of it, but if it does change the behaviour
> it is a small change. There are certainly still plenty of drops with
> that setting.
Are you playing with SO_RCVBUF, or let the stack autotune it ?
^ permalink raw reply
* Re: TCPBacklogDrops during aggressive bursts of traffic
From: Kieran Mansley @ 2012-05-18 15:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Hutchings, netdev
In-Reply-To: <1337356176.7029.47.camel@edumazet-glaptop>
On Fri, 2012-05-18 at 17:49 +0200, Eric Dumazet wrote:
>
> Are you playing with SO_RCVBUF, or let the stack autotune it ?
Just letting the stack autotune it.
Kieran
^ permalink raw reply
* Re: [RFC:kvm] export host NUMA info to guest & make emulated device NUMA attr
From: Shirley Ma @ 2012-05-18 16:14 UTC (permalink / raw)
To: Liu Ping Fan
Cc: kvm, netdev, linux-kernel, qemu-devel, Avi Kivity,
Michael S. Tsirkin, Srivatsa Vaddagiri, Rusty Russell,
Anthony Liguori, Ryan Harper, Shirley Ma, Krishna Kumar,
Tom Lendacky
In-Reply-To: <1337246456-30909-1-git-send-email-kernelfans@gmail.com>
On Thu, 2012-05-17 at 17:20 +0800, Liu Ping Fan wrote:
> Currently, the guest can not know the NUMA info of the vcpu, which
> will
> result in performance drawback.
>
> This is the discovered and experiment by
> Shirley Ma <xma@us.ibm.com>
> Krishna Kumar <krkumar2@in.ibm.com>
> Tom Lendacky <toml@us.ibm.com>
> Refer to -
> http://www.mail-archive.com/kvm@vger.kernel.org/msg69868.html
> we can see the big perfermance gap between NUMA aware and unaware.
>
> Enlightened by their discovery, I think, we can do more work -- that
> is to
> export NUMA info of host to guest.
There three problems we've found:
1. KVM doesn't support NUMA load balancer. Even there are no other
workloads in the system, and the number of vcpus on the guest is smaller
than the number of cpus per node, the vcpus could be scheduled on
different nodes.
Someone is working on in-kernel solution. Andrew Theurer has a working
user-space NUMA aware VM balancer, it requires libvirt and cgroups
(which is default for RHEL6 systems).
2. The host scheduler is not aware the relationship between guest vCPUs
and vhost. So it's possible for host scheduler to schedule per-device
vhost thread on the same cpu on which the vCPU kick a TX packet, or
schecule vhost thread on different node than the vCPU for; For RX packet
it's possible for vhost delivers RX packet on the vCPU running on
different node too.
3. per-device vhost thread is not scaled.
So the problems are in host scheduling and vhost thread scalability. I
am not sure how much help from exposing NUMA info from host to guest.
Have you tested these patched? How much performance gain here?
Thanks
Shirley
> So here comes the idea:
> 1. export host numa info through guest's sched domain to its scheduler
> Export vcpu's NUMA info to guest scheduler(I think mem NUMA problem
> has been handled by host). So the guest's lb will consider the
> cost.
> I am still working on this, and my original idea is to export these
> info
> through "static struct sched_domain_topology_level
> *sched_domain_topology"
> to guest.
>
> 2. Do a better emulation of virt mach exported to guest.
> In real world, the devices are limited by kinds of reasons to own
> the NUMA
> property. But as to Qemu, the device is emulated by thread, which
> inherit
> the NUMA attr in nature. We can implement the device as components
> of many
> logic units, each of the unit is backed by a thread in different
> host node.
> Currently, I want to start the work on vhost. But I think, maybe in
> future, the iothread in Qemu can also has such attr.
>
>
> Forgive me, for the limited time, I can not have more better
> understand of
> vhost/virtio_net drivers. These patches are just draft, _FAR_, _FAR_
> from work.
> I will do more detail work for them in future.
>
> To easy the review, the following is the sum up of the 2nd point of
> the idea.
> As for the 1st point of the idea, it is not reflected in the patches.
>
> --spread/shrink the vhost_workers over the host nodes as demanded from
> Qemu.
> And we can consider each vhost_worker as an independent net logic
> device
> embeded in physical device "vhost_net". At the meanwhile, we spread
> vcpu
> threads over the host node.
> The vrings on guest are allocated PAGE_SIZE align separately, so
> they can
> will only be mapped into different host node, so vhost_worker in the
> same
> node can access it with the least cost. So does the vq on guest.
>
> --virtio_net driver will changes and talk with the logic device. And
> which
> logic device it will talk to is determined by on which vcpu it is
> scheduled.
>
> --the binding of vcpus and vhost_worker is implemented by:
> for call direction, vq-a in the node-A will have a dedicated irq-a.
> And
> we set the irq-a's affinity to vcpus in node-A.
> for kick direction, kick register-b trigger different eventfd-b
> which wake up
> vhost_worker-b.
>
>
>
^ permalink raw reply
* RE: [NET_NEXT RFC PATCH 1/3] ixgbe: add debugfs support
From: Sullivan, Catherine @ 2012-05-18 17:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120509161029.4a8f644b@nehalam.linuxnetplumber.net>
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Wednesday, May 09, 2012 4:10 PM
>
> On Wed, 09 May 2012 16:09:40 -0700
> Catherine Sullivan <catherine.sullivan@intel.com> wrote:
>
> > This patch adds debugfs support to the ixgbe driver to give users the
> > ability to access kernel information and to simulate kernel events.
> >
> > The filesystem is set up in the following driver/PCI-instance
> > hierarchy:
> > <debugfs>
> > |-- ixgbe
> > |-- PCI instance
> > | |-- attribute files
> > |-- PCI instance
> > |-- attribute files
> >
> > Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
>
> This should be an optional configuration since it is meant for special
> case usage. See SKY2_DEBUG
After looking through the kernel, there doesn't seem to be a clear precedence for this. As was pointed out, SKY2_DEBUG is an optional configuration on its own. However regmap uses debugfs, and it is only optional based on CONFIG_DEBUG_FS, which is how this patch is currently set up. This patch does not have much overhead and we would prefer that it be enabled with CONFIG_DEBUG_FS.
^ permalink raw reply
* Re: [PATCH net-next] iwlwifi: dont pull too much payload in skb head
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: johannes.berg; +Cc: eric.dumazet, netdev, wey-yi.w.guy
In-Reply-To: <1DC40B07CD6EC041A66726C271A73AE61955AE5D@IRSMSX102.ger.corp.intel.com>
From: "Berg, Johannes" <johannes.berg@intel.com>
Date: Fri, 18 May 2012 14:59:04 +0000
>> Since merge window is now pretty close, I would prefer David applies this
>> directly in net-next, if you dont mind, as this patch is more a core network issue
>> than an iwlwifi one.
>>
>> Thanks !
>
> Sure, good with me, I don't think we have colliding patches.
>
> Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce netdev_alloc_frag()
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337353932.7029.34.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 17:12:12 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Fix two issues introduced in commit a1c7fff7e18f5
> ( net: netdev_alloc_skb() use build_skb() )
>
> - Must be IRQ safe (non NAPI drivers can use it)
> - Must not leak the frag if build_skb() fails to allocate sk_buff
>
> This patch introduces netdev_alloc_frag() for drivers willing to
> use build_skb() instead of __netdev_alloc_skb() variants.
>
> Factorize code so that :
> __dev_alloc_skb() is a wrapper around __netdev_alloc_skb(), and
> dev_alloc_skb() a wrapper around netdev_alloc_skb()
>
> Use __GFP_COLD flag.
>
> Almost all network drivers now benefit from skb->head_frag
> infrastructure.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: remove csummode in ip6_append_data()
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337355476.7029.46.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 17:37:56 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> csummode variable is always CHECKSUM_NONE in ip6_append_data()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: David Miller @ 2012-05-18 17:32 UTC (permalink / raw)
To: vipul-ut6Up61K2wZBDgjK7y7TUQ
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
roland-BHEL68pLQRGGvPXPguhicg, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <1337335173-3226-1-git-send-email-vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 18 May 2012 15:29:23 +0530
> Below is a link where Roland advised to re-post the series.
> http://www.spinics.net/lists/netdev/msg187997.html
Roland, who takes this, you or me?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v5] be2net: Fix to allow get/set of debug levels in the firmware.
From: David Miller @ 2012-05-18 17:33 UTC (permalink / raw)
To: bhutchings; +Cc: somnath.kotur, netdev, suresh.reddy
In-Reply-To: <1337354667.2696.3.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 18 May 2012 16:24:27 +0100
> On Fri, 2012-05-18 at 14:29 +0530, Somnath Kotur wrote:
>> Patch re-spin.
>> Incorporated review comments by Ben Hutchings.
>>
>> Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
>> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
>
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: deprecate CFG80211_WEXT
From: C. McPherson @ 2012-05-18 17:39 UTC (permalink / raw)
To: netdev, Christopher Worsley, Adam
In-Reply-To: <20120516214048.739945597@sipsolutions.net>
Please reconsider this! We still have applications that still use some
CFG80211_WEXT functions. Can't you just disable it as default?
-Clyde
On 05/16/2012 05:40 PM, Johannes Berg wrote:
^ permalink raw reply
* [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-18 17:39 UTC (permalink / raw)
To: davem; +Cc: netdev, Paul Gortmaker, Alan Cox
It was amusing that linux was able to make use of this 1980's
technology on machines long past its intended lifespan, but
it probably should go now -- it is causing issues in some
distros[1], and while that might be fixable, it is just not
worth it.
To set the context, the 3c501 was designed in the 1980's to be
used on 8088 PC-XT 8bit ISA machines. It was built using
discrete TTL components and truly looks like a relic of the past.
But from a functional point of view, the real issue, as stated
in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
only do one thing at a time -- while you are removing one packet
from the single-packet buffer it cannot receive another packet,
nor can it receive a packet while loading a transmit packet."
You know things are not good when the Kconfig help text suggests
you make a cron job doing a ping every minute.
Hardware that old and crippled is simply not going to be used by
anyone in a time where 10 year old 100Mbit PCI cards (that are
still functional) are largely give-away items.
[1] http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-not-detecting-934344/
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Below is "format-patch -D" to omit full line-by-line deletions,
for review only; full patch based on net-next of today is at:
The following changes since commit 92113bfde2f0982daa5a372d67b62f3d55bbc88a:
ipv6: bool conversions phase1 (2012-05-18 02:24:13 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git delete-3c501
for you to fetch changes up to 4a3da8d00afdf701a8ff6880180d234d8da8ab6f:
drivers/net: delete old 8bit ISA 3c501 driver. (2012-05-18 13:10:01 -0400)
----------------------------------------------------------------
Paul Gortmaker (1):
drivers/net: delete old 8bit ISA 3c501 driver.
Documentation/networking/multicast.txt | 1 -
drivers/net/Space.c | 3 -
drivers/net/ethernet/3com/3c501.c | 896 --------------------------------
drivers/net/ethernet/3com/3c501.h | 91 ----
drivers/net/ethernet/3com/Kconfig | 14 -
drivers/net/ethernet/3com/Makefile | 1 -
6 files changed, 0 insertions(+), 1006 deletions(-)
delete mode 100644 drivers/net/ethernet/3com/3c501.c
delete mode 100644 drivers/net/ethernet/3com/3c501.h
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
index b06c8c6..df1a5cf 100644
--- a/Documentation/networking/multicast.txt
+++ b/Documentation/networking/multicast.txt
@@ -15,7 +15,6 @@ IP-MRoute AllMulti hardware filters are of no help
Board Multicast AllMulti Promisc Filter
------------------------------------------------------------------------
-3c501 YES YES YES Software
3c503 YES YES YES Hardware
3c505 YES NO YES Hardware
3c507 NO NO NO N/A
diff --git a/drivers/net/Space.c b/drivers/net/Space.c
index e3f0fac..d108fac 100644
--- a/drivers/net/Space.c
+++ b/drivers/net/Space.c
@@ -198,9 +198,6 @@ static struct devprobe2 isa_probes[] __initdata = {
#if defined(CONFIG_APRICOT) || defined(CONFIG_MVME16x_NET) || defined(CONFIG_BVME6000_NET) /* Intel I82596 */
{i82596_probe, 0},
#endif
-#ifdef CONFIG_EL1 /* 3c501 */
- {el1_probe, 0},
-#endif
#ifdef CONFIG_EL16 /* 3c507 */
{el16_probe, 0},
#endif
diff --git a/drivers/net/ethernet/3com/3c501.c b/drivers/net/ethernet/3com/3c501.c
deleted file mode 100644
index bf73e1a..0000000
diff --git a/drivers/net/ethernet/3com/3c501.h b/drivers/net/ethernet/3com/3c501.h
deleted file mode 100644
index 183fd55..0000000
diff --git a/drivers/net/ethernet/3com/Kconfig b/drivers/net/ethernet/3com/Kconfig
index bad4fa6..854b8fe 100644
--- a/drivers/net/ethernet/3com/Kconfig
+++ b/drivers/net/ethernet/3com/Kconfig
@@ -18,20 +18,6 @@ config NET_VENDOR_3COM
if NET_VENDOR_3COM
-config EL1
- tristate "3c501 \"EtherLink\" support"
- depends on ISA
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>. Also, consider buying a
- new card, since the 3c501 is slow, broken, and obsolete: you will
- have problems. Some people suggest to ping ("man ping") a nearby
- machine every minute ("man cron") when using this card.
-
- To compile this driver as a module, choose M here. The module
- will be called 3c501.
-
config EL3
tristate "3c509/3c529 (MCA)/3c579 \"EtherLink III\" support"
depends on (ISA || EISA || MCA)
diff --git a/drivers/net/ethernet/3com/Makefile b/drivers/net/ethernet/3com/Makefile
index 1e5382a..74046af 100644
--- a/drivers/net/ethernet/3com/Makefile
+++ b/drivers/net/ethernet/3com/Makefile
@@ -2,7 +2,6 @@
# Makefile for the 3Com Ethernet device drivers
#
-obj-$(CONFIG_EL1) += 3c501.o
obj-$(CONFIG_EL3) += 3c509.o
obj-$(CONFIG_3C515) += 3c515.o
obj-$(CONFIG_PCMCIA_3C589) += 3c589_cs.o
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH] pktgen: fix module unload for good
From: David Miller @ 2012-05-18 17:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337334746.3403.114.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 11:52:26 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> commit c57b5468406 (pktgen: fix crash at module unload) did a very poor
> job with list primitives.
>
> 1) list_splice() arguments were in the wrong order
>
> 2) list_splice(list, head) has undefined behavior if head is not
> initialized.
>
> 3) We should use the list_splice_init() variant to clear pktgen_threads
> list.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: Roland Dreier @ 2012-05-18 17:58 UTC (permalink / raw)
To: David Miller
Cc: vipul-ut6Up61K2wZBDgjK7y7TUQ, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <20120518.133246.2299040648312366919.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, May 18, 2012 at 10:32 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
> Date: Fri, 18 May 2012 15:29:23 +0530
>
>> Below is a link where Roland advised to re-post the series.
>> http://www.spinics.net/lists/netdev/msg187997.html
>
> Roland, who takes this, you or me?
I already have a few cxgb4 patches in my tree, I'm happy to grab this today.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Docs bug or argument handling error in iproute2 xt action
From: Robin H. Johnson @ 2012-05-18 18:16 UTC (permalink / raw)
To: netdev, shemminger
(Please CC, not subscribed to netdev)
>From doc/actions/ifb-README in the iproute2 repo:
===================
# redirect all IP packets arriving in eth0 to ifb0
# use mark 1 --> puts them onto class 1:1
$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:1 \
action ipt -j MARK --set-mark 1 \
action mirred egress redirect dev ifb0
===================
Other documentation says 'ipt' has been replaced by 'xt',
but the passing of arguments other than the jump target doesn't seem to work at all with xt.
Running the above with s/ipt/xt/ gets me:
====
xt: unrecognized option '--set-mark'
Killed
====
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Ondrej Zary @ 2012-05-18 18:16 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: davem, netdev, Alan Cox
In-Reply-To: <1337362769-4676-1-git-send-email-paul.gortmaker@windriver.com>
On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> It was amusing that linux was able to make use of this 1980's
> technology on machines long past its intended lifespan, but
> it probably should go now -- it is causing issues in some
> distros[1], and while that might be fixable, it is just not
> worth it.
>
> [1]
> http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-
>not-detecting-934344/
That looks like a bug elsewhere and removing this driver will not fix it.
--
Ondrej Zary
^ permalink raw reply
* Kernel splat with debugging on 3.3.6+ kernel.
From: Ben Greear @ 2012-05-18 18:40 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, netdev
This is a patched kernel, but nothing proprietary loaded.
We're chasing a hard-to-reproduce bug that appears to be stale
memory access related to wifi stations.
So, I enabled a bunch of debugging (memory debugging, lockdep, etc)
and this lockup occurs every time we try to load our
'400 station' test case.
I'm going to poke at this some more, try some smaller test
cases and such, but if anyone has any other suggestions I'm interested!
BUG: soft lockup - CPU#0 stuck for 22s! [iw:21673]
Modules linked in: 8021q garp stp llc macvlan pktgen fuse coretemp hwmon sunrpc ipv6 uinput arc4 ppdev snd_hda_codec_realtek ath9k snd_hda_intel mac80211
snd_hda_codec snd_hwdep snd_seq ath9k_common microcode snd_seq_device ath9k_hw snd_pcm ath iTCO_wdt i2c_i801 serio_raw pcspkr iTCO_vendor_support cfg80211
snd_timer snd e1000e mei(C) soundcore snd_page_alloc parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
irq event stamp: 2249893
hardirqs last enabled at (2249892): [<ffffffff810efeaa>] __slab_alloc+0x402/0x436
hardirqs last disabled at (2249893): [<ffffffff8147d8ae>] apic_timer_interrupt+0x6e/0x80
softirqs last enabled at (8972): [<ffffffff8103e0f2>] __do_softirq+0x13c/0x15b
softirqs last disabled at (8979): [<ffffffff8147e2ac>] call_softirq+0x1c/0x30
CPU 0
Modules linked in: 8021q garp stp llc macvlan pktgen fuse coretemp hwmon sunrpc ipv6 uinput arc4 ppdev snd_hda_codec_realtek ath9k snd_hda_intel mac80211
snd_hda_codec snd_hwdep snd_seq ath9k_common microcode snd_seq_device ath9k_hw snd_pcm ath iTCO_wdt i2c_i801 serio_raw pcspkr iTCO_vendor_support cfg80211
snd_timer snd e1000e mei(C) soundcore snd_page_alloc parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
Pid: 21673, comm: iw Tainted: G C O 3.3.6+ #1 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffff810efeb3>] [<ffffffff810efeb3>] __slab_alloc+0x40b/0x436
RSP: 0018:ffff88022bc03a10 EFLAGS: 00000282
RAX: ffff88021e0ec400 RBX: ffff88022bc039d0 RCX: 0000000000000003
RDX: 0000000000000003 RSI: ffffffff813aff74 RDI: 0000000000000282
RBP: ffff88022bc03ae0 R08: ffff8801fbca33d8 R09: ffff88022bc038f0
R10: 0000000000000046 R11: ffffea0007ef2820 R12: ffff88022bc03988
R13: ffffffff8147d8b3 R14: ffff88022bc03ae0 R15: ffff880223006f40
FS: 00007f498a0b1720(0000) GS:ffff88022bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fff41409330 CR3: 000000020a006000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process iw (pid: 21673, threadinfo ffff880200e62000, task ffff88021e0ec400)
Stack:
0000000000000003 ffff88022bc03b70 ffff88022bc03a60 0000000000000246
ffffffff813aff74 ffff88021e0ed240 ffff88021bb10cd8 ffff88021e0ed240
0000000200000020 0000000000000282 ffff88021bb10cd8 ffff880204232ae0
Call Trace:
<IRQ>
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI>
[<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
Code: ff ff 00 02 00 00 75 15 48 8b bd 78 ff ff ff 57 9d 66 66 90 66 90 e8 c9 65 f8 ff eb 13 e8 4e 8a f8 ff 48 8b bd 78 ff ff ff 57 9d <66> 66 90 66 90 48 81 c4
a8 00 00 00 4c 89 f0 5b 41 5c 41 5d 41
Call Trace:
<IRQ> [<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI> [<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
Kernel panic - not syncing: softlockup: hung tasks
Pid: 21673, comm: iw Tainted: G C O 3.3.6+ #1
Call Trace:
<IRQ> [<ffffffff81474e27>] panic+0xb8/0x1d6
[<ffffffff8109b3ad>] watchdog_timer_fn+0x147/0x16b
[<ffffffff8109b266>] ? __touch_watchdog+0x1f/0x1f
[<ffffffff81055938>] __run_hrtimer+0x66/0xc1
[<ffffffff81055cb7>] hrtimer_interrupt+0xe5/0x1c0
[<ffffffff8102324e>] smp_apic_timer_interrupt+0x80/0x93
[<ffffffff8147d8b3>] apic_timer_interrupt+0x73/0x80
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff810efeb3>] ? __slab_alloc+0x40b/0x436
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI> [<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
panic occurred, switching back to text console
Rebooting in 10 seconds..[greearb@fs3 linux-3.3.dev.y]$
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCPBacklogDrops during aggressive bursts of traffic
From: Eric Dumazet @ 2012-05-18 18:40 UTC (permalink / raw)
To: Kieran Mansley; +Cc: Ben Hutchings, netdev
In-Reply-To: <1337355955.15044.24.camel@kjm-desktop.uk.level5networks.com>
Le vendredi 18 mai 2012 à 16:45 +0100, Kieran Mansley a écrit :
> > With net-next and tcp coalescing, I no longer have TCPBacklogDrops /
> > collapses, but I dont have sfc card/driver.
>
> I'll try that.
By the way, we should get rid of napi_get_frags() & napi_gro_frags() API
and use plain build_skb() instead.
This would save 1024 bytes per skb, and remove lot of GRO code (frag0,
frag0_len, skb_gro_header_fast(), skb_gro_header_hard()...), since by
definition skb->head would point to the frame.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: David Miller @ 2012-05-18 18:53 UTC (permalink / raw)
To: roland-BHEL68pLQRGGvPXPguhicg
Cc: vipul-ut6Up61K2wZBDgjK7y7TUQ, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <CAL1RGDXjekRWkGvZrPF4-B2+kutWRAm-c694vw_D-CqUJXZNMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Date: Fri, 18 May 2012 10:58:55 -0700
> On Fri, May 18, 2012 at 10:32 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>> Date: Fri, 18 May 2012 15:29:23 +0530
>>
>>> Below is a link where Roland advised to re-post the series.
>>> http://www.spinics.net/lists/netdev/msg187997.html
>>
>> Roland, who takes this, you or me?
>
> I already have a few cxgb4 patches in my tree, I'm happy to grab this today.
Great, please do.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net-next] hp100: delete VG/AnyLAN hp100
From: Francois Romieu @ 2012-05-18 19:28 UTC (permalink / raw)
To: Joe Perches
Cc: Joel Soete, Paul Gortmaker, linux-kernel, JBottomley,
David S. Miller, netdev
In-Reply-To: <1337295024.8872.33.camel@joe2Laptop>
Joe Perches <joe@perches.com> :
[...]
> I saw people using TR adapters with Linux as of 2008/9.
>
> That doesn't mean it's common or make it desirable to
> keep TR in the current kernel tree though.
I'll leave token ring PCI drivers where they are for now.
> Is VG/AnyLAN different?
Your own word: "unused". I see nothing wrong asking users if they
still care. If no one cares about the hp100, fine.
--
Ueimor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox