* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Ron Mercer @ 2010-10-25 19:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Jitendra Kalsaria, Ying Ping Lok
In-Reply-To: <20101025.120739.104054830.davem@davemloft.net>
>From 4981e8d94411b282040bcee89f08e16eef5c608c Mon Sep 17 00:00:00 2001
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 25 Oct 2010 12:38:33 -0700
Subject: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index ba0053d..5077d38 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -2382,6 +2382,20 @@ static void qlge_vlan_rx_kill_vid(struct net_device *ndev, u16 vid)
}
+static void qlge_restore_vlan(struct ql_adapter *qdev)
+{
+ qlge_vlan_rx_register(qdev->ndev, qdev->vlgrp);
+
+ if (qdev->vlgrp) {
+ u16 vid;
+ for (vid = 0; vid < VLAN_N_VID; vid++) {
+ if (!vlan_group_get_device(qdev->vlgrp, vid))
+ continue;
+ qlge_vlan_rx_add_vid(qdev->ndev, vid);
+ }
+ }
+}
+
/* MSI-X Multiple Vector Interrupt Handler for inbound completions. */
static irqreturn_t qlge_msix_rx_isr(int irq, void *dev_id)
{
@@ -3957,6 +3971,9 @@ static int ql_adapter_up(struct ql_adapter *qdev)
clear_bit(QL_PROMISCUOUS, &qdev->flags);
qlge_set_multicast_list(qdev->ndev);
+ /* Restore vlan setting. */
+ qlge_restore_vlan(qdev);
+
ql_enable_interrupts(qdev);
ql_enable_all_completion_interrupts(qdev);
netif_tx_start_all_queues(qdev->ndev);
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] net: b43legacy: fix compile error
From: Eric Dumazet @ 2010-10-25 19:56 UTC (permalink / raw)
To: Larry Finger
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless
In-Reply-To: <4CC5C863.9070801@lwfinger.net>
Le lundi 25 octobre 2010 à 13:11 -0500, Larry Finger a écrit :
> I have no idea why that header was included - likely historical in the
> transformation from bcm43xx to b43legacy. For completeness, there are 2 more
> places to change:
Anyway, Arnd patch is fine by me, I didnt want to supply an alternate
patch.
I only was wondering why the include was in this driver...
^ permalink raw reply
* Re: Nested GRE locking bug
From: David Miller @ 2010-10-25 19:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <1287478956.2676.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Oct 2010 11:02:36 +0200
> Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 14 Oct 2010 06:11:59 +0200
>>
>> > net-next-2.6 contains a fix for this, adding the perc_cpu
>> > xmit_recursion limit. We might push it to net-2.6
>>
>> We need to think a bit more about this.
>>
>> We are essentially now saying that one can only configure
>> tunnels 3 levels deep, and no more.
>>
>> I can guarentee you someone out there uses at least 4,
>> perhaps more.
>>
>> And those people will be broken by the new limit.
>>
>> So putting this into net-2.6 with such a low limit will
>> be quite dangerous.
>
> Well limit is actually 4, but I get your point ;)
I'll commit the following to upstream, and submit a combined
patch to -stable.
--------------------
net: Increase xmit RECURSION_LIMIT to 10.
Three is definitely too low, and we know from reports that GRE tunnels
stacked as deeply as 37 levels cause stack overflows, so pick some
reasonable value between those two.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 78b5a89..2c7da3a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
}
static DEFINE_PER_CPU(int, xmit_recursion);
-#define RECURSION_LIMIT 3
+#define RECURSION_LIMIT 10
/**
* dev_queue_xmit - transmit a buffer
--
1.7.3.2
^ permalink raw reply related
* Re: [RFC] ixgbe: v3 normalize frag_list usage
From: David Miller @ 2010-10-25 19:47 UTC (permalink / raw)
To: alexander.h.duyck
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan, netdev
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25BC8DEC85@orsmsx501.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Fri, 8 Oct 2010 16:57:40 -0700
> Below is the new and improved version of the RSC chaining approach. Basically
> I am holding off on merging the SKB into the frame until the SKB has data in
> order to make it take a more standard approach.
>
> Let me know if this will work with the new pointer structure.
This variant looks great, thanks Alexander!
^ permalink raw reply
* Re: [PATCH] mlx4_en: Fix out of bounds array access
From: David Miller @ 2010-10-25 19:16 UTC (permalink / raw)
To: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: yevgenyp-VPRAkNaXOzVS1MOuV/RT9w, rdreier-FYB4Gu1CFyUAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101025125647.GA7710@mtldesk30>
From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Mon, 25 Oct 2010 14:56:47 +0200
> When searching for a free entry in either mlx4_register_vlan() or
> mlx4_register_mac(), and there is no free entry, the loop terminates without
> updating the local variable free thus causing out of array bounds access. Fix
> this by adding a proper check outside the loop.
>
> Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
Applied.
--
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] macb: Don't re-enable interrupts while in polling mode
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: Joshua.Hoke
Cc: nicolas.ferre, jpirko, peter.korsgaard, eric.dumazet,
haavard.skinnemoen, netdev, linux-kernel, akpm
In-Reply-To: <C8F551D39A7C724E987CF8DD11D3178304D7CC86@svr3.sixnetio.com>
From: "Joshua Hoke" <Joshua.Hoke@sixnet.com>
Date: Mon, 25 Oct 2010 07:44:22 -0400
> [PATCH] macb: Don't re-enable interrupts while in polling mode
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb3: fix device opening error path
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20101025173502.27055.847.stgit@speedy5.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Mon, 25 Oct 2010 10:35:02 -0700
> From: Divy Le Ray <divy@chelsio.com>
>
> Only negative return from bind_qsets() should be considered an error and
> propagated.
> It fixes an issue reported by IBM on P Series platform.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] be2net: Fix CSO for UDP packets
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111158.GA2009@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:58 +0530
> We're setting skb->ip_summed to CHECKSUM_NONE for all non-TCP pkts, making the stack
> recompute checksum.This is a bug for UDP pkts for which cso must be used.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] be2net: Call netif_carier_off() after register_netdev()
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111110.GA1990@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:10 +0530
> Calling netif_carrier_off before register_netdev was causing the network interface
> to miss a linkwatch pending event leading to an inconsistent state if the link
> is not up when interface is initialized.This is now invoked after register_netdev.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: David Miller @ 2010-10-25 19:14 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC4EC38.2040208-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Mon, 25 Oct 2010 11:32:24 +0900
> @@ -255,21 +255,21 @@ static void pch_can_set_optmode(struct
> pch_can_priv *priv)
This patch has been corrupted by your email client.
^ permalink raw reply
* Quota de courriel
From: System Administrator @ 2010-10-25 18:59 UTC (permalink / raw)
Sie haben die Lagerung für Ihr Postfach überschritten wird.
Sie werden nicht in der Lage zu senden oder zu empfangen, bis Sie neue
E-Mail Ihre E-Mail Quote zu aktualisieren.
Kopieren Sie den untenstehenden Link und füllen Sie das Formular, um Ihr
Konto zu aktualisieren.
http://www.do.my/e-mailaccountactivation/
System-Administrator
192.168.0.1
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: David Miller @ 2010-10-25 19:09 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111235.GA2024@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:42:35 +0530
> By default, be2net uses MSIx wherever possible.
> Adding a module parameter to use INTx for users who do not want to use MSIx.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Either add a new ethtool flag, or use the PCI subsystem facilities
for tweaking things to implement this.
Do not use a module option, otherwise every other networking driver
author will get the same "cool" idea, give the module option
different names, and the resulting user experience is terrible.
^ permalink raw reply
* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: David Miller @ 2010-10-25 19:07 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288023473-31490-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 25 Oct 2010 09:17:51 -0700
> + if (qdev->vlgrp) {
> + u16 vid;
> + for (vid = 0; vid < VLAN_N_VID; vid++) {
> + if (!vlan_group_get_device(qdev->vlgrp, vid))
> + continue;
> + qlge_vlan_rx_add_vid(qdev->ndev, vid);
> + }
> + }
> +}
Please fix the indentation in this code block.
^ permalink raw reply
* [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: nhorman @ 2010-10-25 19:06 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, jpirko, Neil Horman
From: Neil Horman <nhorman@tuxdriver.com>
It was shown to me recently that systems under high load were driven very deep
into swap when tcpdump was run. The reason this happened was because the
AF_PACKET protocol has a SET_RINGBUFFER socket option that allows the user space
application to specify how many entries an AF_PACKET socket will have and how
large each entry will be. It seems the default setting for tcpdump is to set
the ring buffer to 32 entries of 64 Kb each, which implies 32 order 5
allocation. Thats difficult under good circumstances, and horrid under memory
pressure.
I thought it would be good to make that a bit more usable. I was going to do a
simple conversion of the ring buffer from contigous pages to iovecs, but
unfortunately, the metadata which AF_PACKET places in these buffers can easily
span a page boundary, and given that these buffers get mapped into user space,
and the data layout doesn't easily allow for a change to padding between frames
to avoid that, a simple iovec change is just going to break user space ABI
consistency.
So instead I've done this. This patch does the aforementioned change,
allocating an array of pages instead of one contiguous chunk, and then vmaps the
array into a contiguous memory space, so that it can still be accessed in the
same way it was before. This allows for a consisten user and kernel space
behavior for memory mapped AF_PACKET sockets, which at the same time relieving
the memory pressure placed on a system when tcpdump defaults are used.
Tested successfully by me.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
net/packet/af_packet.c | 94 +++++++++++++++++++++++++++++++++++++----------
1 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3616f27..fad3891 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -163,8 +163,14 @@ struct packet_mreq_max {
static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
int closing, int tx_ring);
+struct pkt_page_list {
+ unsigned int num_pages;
+ char *vmap_area;
+ unsigned long pages[0];
+};
+
struct packet_ring_buffer {
- char **pg_vec;
+ struct pkt_page_list **pg_vec;
unsigned int head;
unsigned int frames_per_block;
unsigned int frame_size;
@@ -283,7 +289,8 @@ static void *packet_lookup_frame(struct packet_sock *po,
pg_vec_pos = position / rb->frames_per_block;
frame_offset = position % rb->frames_per_block;
- h.raw = rb->pg_vec[pg_vec_pos] + (frame_offset * rb->frame_size);
+ h.raw = rb->pg_vec[pg_vec_pos]->vmap_area +
+ (frame_offset * rb->frame_size);
if (status != __packet_get_status(po, h.raw))
return NULL;
@@ -2322,41 +2329,86 @@ static const struct vm_operations_struct packet_mmap_ops = {
.close = packet_mm_close,
};
-static void free_pg_vec(char **pg_vec, unsigned int order, unsigned int len)
+static void free_one_pkt_list(struct pkt_page_list *pglist)
+{
+ int i;
+
+ if ((pglist->num_pages > 1) && (pglist->vmap_area))
+ vunmap(pglist->vmap_area);
+ for (i = 0; i < pglist->num_pages; i++)
+ free_pages(pglist->pages[i], 0);
+}
+
+static void free_pg_vec(struct pkt_page_list **pg_vec, unsigned int order,
+ unsigned int len)
{
int i;
- for (i = 0; i < len; i++) {
+ for (i = 0; i < len; i++)
if (likely(pg_vec[i]))
- free_pages((unsigned long) pg_vec[i], order);
- }
+ free_one_pkt_list(pg_vec[i]);
+
kfree(pg_vec);
}
-static inline char *alloc_one_pg_vec_page(unsigned long order)
+static inline struct pkt_page_list *alloc_one_pg_page_list(unsigned long order)
{
+ int i;
+ struct pkt_page_list *newlist;
gfp_t gfp_flags = GFP_KERNEL | __GFP_COMP | __GFP_ZERO | __GFP_NOWARN;
- return (char *) __get_free_pages(gfp_flags, order);
+
+ newlist = kzalloc(sizeof(struct pkt_page_list)+
+ (sizeof(void *)*(1<<order)), GFP_KERNEL);
+ if (!newlist)
+ return NULL;
+ newlist->num_pages = (1<<order);
+
+ for (i = 0; i < newlist->num_pages; i++) {
+ newlist->pages[i] = __get_free_pages(gfp_flags, 0);
+ if (!newlist->pages[i])
+ goto out_free;
+ }
+
+ return newlist;
+out_free:
+ free_one_pkt_list(newlist);
+ kfree(newlist);
+ return NULL;
}
-static char **alloc_pg_vec(struct tpacket_req *req, int order)
+static struct pkt_page_list **alloc_pg_vec(struct tpacket_req *req, int order)
{
unsigned int block_nr = req->tp_block_nr;
- char **pg_vec;
- int i;
+ struct pkt_page_list **pg_vec;
+ struct page **pages;
+ int i, j;
- pg_vec = kzalloc(block_nr * sizeof(char *), GFP_KERNEL);
- if (unlikely(!pg_vec))
+ pg_vec = kzalloc(block_nr * sizeof(struct pkt_page_list *), GFP_KERNEL);
+ pages = kzalloc(block_nr * sizeof(struct page *), GFP_KERNEL);
+
+ if (unlikely(!pg_vec || !pages))
goto out;
for (i = 0; i < block_nr; i++) {
- pg_vec[i] = alloc_one_pg_vec_page(order);
- if (unlikely(!pg_vec[i]))
- goto out_free_pgvec;
+ pg_vec[i] = alloc_one_pg_page_list(order);
+
+ if (order > 0) {
+ for (j = 0; j < pg_vec[i]->num_pages; j++)
+ pages[j] = virt_to_page(pg_vec[i]->pages[j]);
+
+ if (unlikely(!pg_vec[i]))
+ goto out_free_pgvec;
+ pg_vec[i]->vmap_area = vmap(pages, pg_vec[i]->num_pages,
+ VM_MAP, PAGE_KERNEL);
+ if (!pg_vec[i]->vmap_area)
+ goto out_free_pgvec;
+ } else
+ pg_vec[i]->vmap_area = (void *)pg_vec[i]->pages[0];
}
out:
+ kfree(pages);
return pg_vec;
out_free_pgvec:
@@ -2368,7 +2420,7 @@ out_free_pgvec:
static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
int closing, int tx_ring)
{
- char **pg_vec = NULL;
+ struct pkt_page_list **pg_vec = NULL;
struct packet_sock *po = pkt_sk(sk);
int was_running, order = 0;
struct packet_ring_buffer *rb;
@@ -2530,11 +2582,13 @@ static int packet_mmap(struct file *file, struct socket *sock,
continue;
for (i = 0; i < rb->pg_vec_len; i++) {
- struct page *page = virt_to_page(rb->pg_vec[i]);
+ struct pkt_page_list *plist = rb->pg_vec[i];
int pg_num;
+ struct page *page;
- for (pg_num = 0; pg_num < rb->pg_vec_pages;
- pg_num++, page++) {
+ for (pg_num = 0; pg_num < plist->num_pages;
+ pg_num++) {
+ page = virt_to_page(plist->pages[pg_num]);
err = vm_insert_page(vma, start, page);
if (unlikely(err))
goto out;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:59 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <4CC5D01C.20804-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]
On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
> Am 25.10.2010 20:36, schrieb Larry Finger:
>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>>> On todays linus tree the following compile error happened to me:
>>>>>
>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>>> In file included from include/net/dst.h:11,
>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>>> make[1]: *** [drivers/net] Error 2
>>>>> make: *** [drivers] Error 2
>>>>>
>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>>> "include/net/dst_ops.h".
>>>>
>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>>
>>> Exactly the same git describe here.
>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>>
>> That probably makes the difference. Using Eric's fix that removes the #include
>> <linux/dst.h> should be better. Does it work for you?
>>
>> There are probably a lot more of the system includes that may not be needed. If
>> I send you a patch removing them, could you test?
>
> As it turns out my card is not supported by b43legacy, but compilation testing,
> sure I can test that.
If it is a Broadcom card, it is likely handled by b43.
Attached is a trial removal of a number of include statements. Does it compile?
Larry
[-- Attachment #2: b43legacy_remove_dst_h --]
[-- Type: text/plain, Size: 3134 bytes --]
Index: linux-2.6/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/dma.c
+++ linux-2.6/drivers/net/wireless/b43legacy/dma.c
@@ -33,13 +33,6 @@
#include "debugfs.h"
#include "xmit.h"
-#include <linux/dma-mapping.h>
-#include <linux/pci.h>
-#include <linux/delay.h>
-#include <linux/skbuff.h>
-#include <linux/slab.h>
-#include <net/dst.h>
-
/* 32bit DMA ops. */
static
struct b43legacy_dmadesc_generic *op32_idx2desc(
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -29,20 +29,8 @@
*
*/
-#include <linux/delay.h>
-#include <linux/init.h>
-#include <linux/moduleparam.h>
-#include <linux/if_arp.h>
#include <linux/etherdevice.h>
#include <linux/firmware.h>
-#include <linux/wireless.h>
-#include <linux/workqueue.h>
-#include <linux/sched.h>
-#include <linux/skbuff.h>
-#include <linux/dma-mapping.h>
-#include <linux/slab.h>
-#include <net/dst.h>
-#include <asm/unaligned.h>
#include "b43legacy.h"
#include "main.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/xmit.c
+++ linux-2.6/drivers/net/wireless/b43legacy/xmit.c
@@ -28,8 +28,6 @@
*/
-#include <net/dst.h>
-
#include "xmit.h"
#include "phy.h"
#include "dma.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/phy.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/phy.c
+++ linux-2.6/drivers/net/wireless/b43legacy/phy.c
@@ -29,12 +29,6 @@
*/
-#include <linux/delay.h>
-#include <linux/pci.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-#include <linux/types.h>
-
#include "b43legacy.h"
#include "phy.h"
#include "main.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/pio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/pio.c
+++ linux-2.6/drivers/net/wireless/b43legacy/pio.c
@@ -28,10 +28,6 @@
#include "main.h"
#include "xmit.h"
-#include <linux/delay.h>
-#include <linux/slab.h>
-
-
static void tx_start(struct b43legacy_pioqueue *queue)
{
b43legacy_pio_write(queue, B43legacy_PIO_TXCTL,
Index: linux-2.6/drivers/net/wireless/b43legacy/radio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/radio.c
+++ linux-2.6/drivers/net/wireless/b43legacy/radio.c
@@ -29,8 +29,6 @@
*/
-#include <linux/delay.h>
-
#include "b43legacy.h"
#include "main.h"
#include "phy.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/sysfs.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/sysfs.c
+++ linux-2.6/drivers/net/wireless/b43legacy/sysfs.c
@@ -29,8 +29,6 @@
#include "phy.h"
#include "radio.h"
-#include <linux/capability.h>
^ permalink raw reply
* Re: [PATCH 1/2 v3] xps: Improvements in TX queue selection
From: David Miller @ 2010-10-25 18:56 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <AANLkTi=Pzxnf=bJXANwz8Rmd8GOUu9oxpO_YF6udJE01@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 25 Oct 2010 10:02:05 -0700
> Would this be sufficient:
>
> @@ -825,7 +825,8 @@ static int tcp_transmit_skb(struct sock *sk,
> struct sk_buff *skb
> if (tcp_packets_in_flight(tp) == 0) {
> tcp_ca_event(sk, CA_EVENT_TX_START);
> skb->ooo_okay = 1;
> - }
> + } else
> + skb->ooo_okay = 0;
Or, alternatively, you could clear it at the point it's tested in
the device transmit path.
This might make the changes for SCTP and other protocols much
easier.
For now, either way is fine with me.
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Arnd Hannemann @ 2010-10-25 18:44 UTC (permalink / raw)
To: Larry Finger
Cc: David S. Miller, netdev, linux-kernel, linux-wireless,
Eric Dumazet
In-Reply-To: <4CC5CE47.2020607@lwfinger.net>
Am 25.10.2010 20:36, schrieb Larry Finger:
> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>> On todays linus tree the following compile error happened to me:
>>>>
>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>> In file included from include/net/dst.h:11,
>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>> make[1]: *** [drivers/net] Error 2
>>>> make: *** [drivers] Error 2
>>>>
>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>> "include/net/dst_ops.h".
>>>
>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>
>> Exactly the same git describe here.
>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>
> That probably makes the difference. Using Eric's fix that removes the #include
> <linux/dst.h> should be better. Does it work for you?
>
> There are probably a lot more of the system includes that may not be needed. If
> I send you a patch removing them, could you test?
As it turns out my card is not supported by b43legacy, but compilation testing,
sure I can test that.
Regards,
Arnd
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:36 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David S. Miller, netdev, linux-kernel, linux-wireless,
Eric Dumazet
In-Reply-To: <4CC5CBC4.7060308@arndnet.de>
On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
> Am 25.10.2010 17:32, schrieb Larry Finger:
>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>> On todays linus tree the following compile error happened to me:
>>>
>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>> In file included from include/net/dst.h:11,
>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>> make[2]: *** [drivers/net/wireless] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>> "include/net/dst_ops.h".
>>
>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>
> Exactly the same git describe here.
> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
That probably makes the difference. Using Eric's fix that removes the #include
<linux/dst.h> should be better. Does it work for you?
There are probably a lot more of the system includes that may not be needed. If
I send you a patch removing them, could you test?
Larry
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Arnd Hannemann @ 2010-10-25 18:26 UTC (permalink / raw)
To: Larry Finger; +Cc: David S. Miller, netdev, linux-kernel, linux-wireless
In-Reply-To: <4CC5A301.1080606@lwfinger.net>
Am 25.10.2010 17:32, schrieb Larry Finger:
> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>> On todays linus tree the following compile error happened to me:
>>
>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>> In file included from include/net/dst.h:11,
>> from drivers/net/wireless/b43legacy/xmit.c:31:
>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_add':
>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_init':
>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>> make[2]: *** [drivers/net/wireless] Error 2
>> make[1]: *** [drivers/net] Error 2
>> make: *** [drivers] Error 2
>>
>> This patch fixes this issue by adding "linux/cache.h" as an include to
>> "include/net/dst_ops.h".
>
> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
Exactly the same git describe here.
Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
Regards
Arnd
^ permalink raw reply
* Re: TCP always advertises zero window.
From: Andi Kleen @ 2010-10-25 18:18 UTC (permalink / raw)
To: Li Yu; +Cc: netdev@vger.kernel.org
In-Reply-To: <4CBFE924.2060103@gmail.com>
Li Yu <raise.sail@gmail.com> writes:
>
> According to source code, only MTU probing success and receive some non-zero length of L7 payload could grow tcp_sock->rcv_ssthresh. Because of we turn off MTU probing and TCP only received some zero-window probe from another end, so it seem that we have not any chance to update tcp_sock->rcv_ssthresh at all, so a dead loop come here.
The question is why are you turning off MTU probing?
-Andi
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arnd Hannemann, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1288021905.2826.142.camel@edumazet-laptop>
On 10/25/2010 10:51 AM, Eric Dumazet wrote:
> Le lundi 25 octobre 2010 à 10:32 -0500, Larry Finger a écrit :
>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>> On todays linus tree the following compile error happened to me:
>>>
>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>> In file included from include/net/dst.h:11,
>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>> make[2]: *** [drivers/net/wireless] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>> "include/net/dst_ops.h".
>>
>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>
> Well, x86_64 must include cache.h, this is probably why I missed it in
> my build tests.
>
> I wonder also why #include <net/dst.h> is needed at all in this
> driver...
>
> diff --git a/drivers/net/wireless/b43legacy/xmit.c
> b/drivers/net/wireless/b43legacy/xmit.c
> index 7d177d9..a261aec 100644
> --- a/drivers/net/wireless/b43legacy/xmit.c
> +++ b/drivers/net/wireless/b43legacy/xmit.c
> @@ -28,8 +28,6 @@
>
> */
>
> -#include <net/dst.h>
> -
> #include "xmit.h"
> #include "phy.h"
> #include "dma.h"
I have no idea why that header was included - likely historical in the
transformation from bcm43xx to b43legacy. For completeness, there are 2 more
places to change:
Index: linux-2.6/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/dma.c
+++ linux-2.6/drivers/net/wireless/b43legacy/dma.c
@@ -38,7 +38,6 @@
#include <linux/delay.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
-#include <net/dst.h>
/* 32bit DMA ops. */
static
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -41,7 +41,6 @@
#include <linux/skbuff.h>
#include <linux/dma-mapping.h>
#include <linux/slab.h>
-#include <net/dst.h>
#include <asm/unaligned.h>
#include "b43legacy.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/xmit.c
+++ linux-2.6/drivers/net/wireless/b43legacy/xmit.c
@@ -28,8 +28,6 @@
*/
-#include <net/dst.h>
^ permalink raw reply
* Re: [PATCH] drivers: rtl818x: request DMA-able memory
From: Larry Finger @ 2010-10-25 18:01 UTC (permalink / raw)
To: htl10-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f
Cc: John W. Linville, Serafeim Zanikolas,
herton-4qZELD6Fgxg39yzSjRtAkw, joe-6d6DIl74uiNBDgjK7y7TUQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <902045.66378.qm-gyycVyw5OoDyX4RqAA4FmIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
On 10/25/2010 10:39 AM, Hin-Tak Leung wrote:
>
> okay - sorry about the confusion - I was grep'ing for GFP_DMA and only b43/b43lagacy have it and it is relatively rare. AFAIK none of the rtl8187 devices are non-USB... probably a NACK then, but I should ask Serafeim if there is a reason for him to submit this patch? (other than "it says dma"...)
There are some devices driven by b43/b43legacy that implement only 24-bit DMA.
For that reason, they need to allocate DMA buffers in the low 16 MB of RAM. For
rtl8187, that consideration does not apply.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Reproducible VLAN/e1000e crash in 2.6.36 vanilla.
From: Ben Greear @ 2010-10-25 17:57 UTC (permalink / raw)
To: NetDev
To re-create, setup 2 802.1q vlans on different physical interfaces on the same system,
set up routing rules such that send-to-self works, and pass traffic (UDP/IPv4 in this case,
but doesn't seem to matter).
Stop traffic, then attempt to create additional 802.1q vlans on the same physical interfaces.
The crash only appears to happen after having sent traffic on the interface.
Likely it will also crash if one system is sending to another, but so far we've
just tested sending-to-self.
This appears very reproducible for us, and appears to be the same problem that
I had reported against our hacked kernel here:
http://www.spinics.net/lists/netdev/msg144748.html
[root@ct503-60 ~]# general protection fault: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/net/eth2.103/type
CPU 2
Modules linked in: 8021q garp bridge stp llc veth arc4 michael_mic macvlan pktgen fuse nfs lockd fscach]
Pid: 0, comm: kworker/0:1 Not tainted 2.6.36 #32 X8DTU/X8DTU
RIP: 0010:[<ffffffff813cada1>] [<ffffffff813cada1>] vlan_hwaccel_do_receive+0x64/0xca
RSP: 0018:ffff880001a43c10 EFLAGS: 00010287
RAX: 0000000000000002 RBX: ffff88031d1b0200 RCX: ffff88032d600000
RDX: ffff880001a43c00 RSI: ffff88031d1b0200 RDI: 0000000000000001
RBP: ffff880001a43c30 R08: 0000000000000067 R09: ffff8803217268c0
R10: ffff88031d1b0228 R11: 00000000000005f2 R12: ffff88032d600000
R13: ffff10032f040890 R14: 0000000000000000 R15: ffff880330b6ae00
FS: 0000000000000000(0000) GS:ffff880001a40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000001d07be8 CR3: 0000000001642000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/0:1 (pid: 0, threadinfo ffff8803321f0000, task ffff88033209f700)
Stack:
ffff880001a43c30 ffff88031d1b0200 ffff88032d600908 ffff88031d1b0208
<0> ffff880001a43c90 ffffffff81344313 ffff88031d1b0200 ffff88032d600908
<0> ffff880001a43c70 ffffffff81061d07 000000004cc5bf73 ffff88031d1b0200
Call Trace:
<IRQ>
[<ffffffff81344313>] __netif_receive_skb+0x36/0x3b3
[<ffffffff81061d07>] ? ktime_get_real+0x11/0x3e
[<ffffffff813454a5>] netif_receive_skb+0x67/0x6e
[<ffffffff81345b8c>] napi_skb_finish+0x24/0x3b
[<ffffffff813cb07f>] vlan_gro_receive+0x7b/0x80
[<ffffffffa016d5b9>] e1000_receive_skb+0x51/0x6d [e1000e]
[<ffffffffa016eeb0>] e1000_clean_rx_irq+0x1ed/0x292 [e1000e]
[<ffffffffa016f287>] e1000_clean+0x75/0x221 [e1000e]
[<ffffffff81345690>] net_rx_action+0xad/0x19c
[<ffffffff81048926>] __do_softirq+0xa8/0x135
[<ffffffff8100a99c>] call_softirq+0x1c/0x30
[<ffffffff8100c085>] do_softirq+0x41/0x7e
[<ffffffff81048ab8>] irq_exit+0x36/0x85
[<ffffffff8100b7bf>] do_IRQ+0xad/0xc4
[<ffffffff813ed4d3>] ret_from_intr+0x0/0x11
<EOI>
[<ffffffff8120dab2>] ? intel_idle+0xe6/0x112
[<ffffffff8120da95>] ? intel_idle+0xc9/0x112
[<ffffffff8131d121>] cpuidle_idle_call+0xab/0xe6
[<ffffffff81008dd5>] cpu_idle+0x59/0xb5
[<ffffffff813e6da8>] start_secondary+0x1a9/0x1ae
Code: 0d 0f b7 c0 41 8b 44 85 04 66 c7 83 bc 00 00 00 00 00 89 43 78 4d 8b ad d8 00 00 00 e8 c1 95 e0 f
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] drivers: rtl818x: request DMA-able memory
From: Serafeim Zanikolas @ 2010-10-25 17:44 UTC (permalink / raw)
To: John W. Linville
Cc: Hin-Tak Leung, Larry Finger, herton, joe, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20101025142232.GC2414@tuxdriver.com>
On Mon, Oct 25, 2010 at 10:22:32AM -0400, John W. Linville wrote:
> On Mon, Oct 25, 2010 at 03:11:22PM +0100, Hin-Tak Leung wrote:
> >
> >
> > Larry Finger wrote:
> > >On 10/24/2010 03:32 PM, Serafeim Zanikolas wrote:
> > >>Despite the indicated intention in comment, the kmalloc() call was not
> > >>explicitly requesting memory from ZONE_DMA.
> > >>
> > >>Signed-off-by: Serafeim Zanikolas <sez@debian.org>
> > >>---
> > >> drivers/net/wireless/rtl818x/rtl8187_dev.c | 3 ++-
> > >> 1 files changed, 2 insertions(+), 1 deletions(-)
> > >>
> > >>diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>index 38fa824..771794d 100644
> > >>--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>@@ -1343,7 +1343,8 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
> > >> priv->is_rtl8187b = (id->driver_info == DEVICE_RTL8187B);
> > >> /* allocate "DMA aware" buffer for register accesses */
> > >>- priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf), GFP_KERNEL);
> > >>+ priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf),
> > >>+ GFP_DMA | GFP_KERNEL);
> > >> if (!priv->io_dmabuf) {
> > >> err = -ENOMEM;
> > >> goto err_free_dev;
> > >
> > >ACK.
> > >
> > >Larry
> >
> > Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
> >
> > I had a quick look for similiar constructs and AFAIK only the
> > b43/b43legacy drivers uses DMA buffers. Seems to be a rare practice.
> > Is that something we should or should not do?
>
> It doesn't mean what you think it means. It is a relic of the past,
> used to indicate memory below 16MB so that ISA devices could do DMA.
Right. Sorry for the noise.
-S
^ permalink raw reply
* Re: [PATCH v2 10/14] ixgbe: Update ixgbe to use new vlan accleration.
From: Peter P Waskiewicz Jr @ 2010-10-25 17:50 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jesse Gross, David Miller, netdev@vger.kernel.org,
Tantilov, Emil S, Kirsher, Jeffrey T
In-Reply-To: <AANLkTindxJD1a5UPV+6vWbDEeMUTy1QgPs1X8pT-b69D@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]
On Fri, 2010-10-22 at 06:24 -0700, Michał Mirosław wrote:
> 2010/10/21 Jesse Gross <jesse@nicira.com>:
> > Make the ixgbe driver use the new vlan accleration model.
> [...]
> > --- a/drivers/net/ixgbe/ixgbe_main.c
> > +++ b/drivers/net/ixgbe/ixgbe_main.c
> > @@ -954,17 +954,13 @@ static void ixgbe_receive_skb(struct ixgbe_q_vector *q_vector,
> > bool is_vlan = (status & IXGBE_RXD_STAT_VP);
> > u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
> >
> > - if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL)) {
> > - if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
> > - vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
> > - else
> > - napi_gro_receive(napi, skb);
> > - } else {
> > - if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
> > - vlan_hwaccel_rx(skb, adapter->vlgrp, tag);
> > - else
> > - netif_rx(skb);
> > - }
> > + if (is_vlan && (tag & VLAN_VID_MASK))
> > + __vlan_hwaccel_put_tag(skb, tag);
>
> I know that this is carried over from the driver, but why tag == 0 is
> treated differently here? VID0 is somewhat special, as normally it
> means 802.1p packet, but i.e. in embedded world people are using it as
> normal VID. It would be nice to have this handled consistently in the
> VLAN core - deliver to base dev (tag stripped) if vlan 0 is not
> configured and to vlan dev if it is.
ixgbe handles VLAN 0 differently because that's the tag that's used when
DCB is enabled, and no VLAN is configured. We have to insert the 802.1p
tag for DCB to work, but the OS won't know about the 802.1q tag, and
ends up dropping the frame. So we enable VLAN ID 0 in the HW and tell
it to strip the tag, so we can still pass the frame up the stack.
>
> > +
> > + if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL))
> > + napi_gro_receive(napi, skb);
> > + else
> > + netif_rx(skb);
> > }
> >
> > /**
>
> Best Regards,
> Michał Mirosław
--
-----------------------------------------------------------
Peter P Waskiewicz Jr LAN Access Division
peter.p.waskiewicz.jr@intel.com Intel Corp.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4394 bytes --]
^ 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