On Sun, Jan 22, 2006 at 05:46:15PM +1100, herbert wrote:
This is due to the fclone patch. On the error path if we allocated an
fclone then we will free it in the wrong pool.
The following patch should fix the problem.
I let an extra blank line sneak in there. Can't have that :)
Patch fixes misplaced (). Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko
On Sunday 22 January 2006 13:08, Denis Vlasenko wrote:
On Sunday 22 January 2006 13:59, Denis Vlasenko wrote:
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that
Denis Vlasenko wrote:
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+
David S. Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Fri, 20 Jan 2006 08:15:39 +0100
Sorry for the delay in testing. Looks good so far. I'm running with SNAT
and the patch and the messages haven't appeared. Will keep it running
for longer, but previously they would have started
Hi,
Carl-Daniel Hailfinger schrieb:
Carl-Daniel Hailfinger schrieb:
Carl-Daniel Hailfinger schrieb:
after sending 259 GB and receiving 25 GB over my SysKonnect SK-9E21
card (sky2 says it is a Yukon-EC (0xb6) rev 1), the card appears
dead. Machine is an Athlon64 3200+ on an Asus A8N-SLI
It's not used. Fix the following on alpha-eb66 as a side effect:
In file included from drivers/net/lp486e.c:75:
include/asm/io.h:20:1: warning: SLOW_DOWN_IO redefined
drivers/net/lp486e.c:59:1: warning: this is the location of the previous
definition
Signed-off-by: Alexey Dobriyan [EMAIL
This patch moves some code only used in this file to net/ipx/af_ipx.c .
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 14 Jan 2006
include/net/p8022.h | 13 -
net/802/Makefile | 14 ++---
net/802/p8022.c | 66
WIRELESS_EXT 18 will never be true in the kernel.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 14 Jan 2006
drivers/net/wireless/tiacx/acx_struct.h |5
drivers/net/wireless/tiacx/common.c |4
drivers/net/wireless/tiacx/conv.c|
On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
Do we really have to wait the three years between stable Debian releases
for removing an obsolete driver that has always been marked as
EXPERIMENTAL?
Please be serious.
I am completely serious. The traditional cycle of obsolete
On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote:
On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
Do we really have to wait the three years between stable Debian releases
for removing an obsolete driver that has always been marked as
EXPERIMENTAL?
Please
On Sun, 2006-01-22 at 19:20 +0100, Adrian Bunk wrote:
On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote:
On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
Do we really have to wait the three years between stable Debian releases
for removing an obsolete driver
You might try adjusting the interrupt coalescing parameters with
ethtool -C eth0 ...
But I can't give you hard guidelines as to what would make it better.
I have a debug patch, but it needs work still.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
Begin forwarded message:
Date: Sun, 22 Jan 2006 12:02:22 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
http://bugzilla.kernel.org/show_bug.cgi?id=5936
Summary: Openswan tunnels + netfilter problem
Stephen Hemminger schrieb:
You might try adjusting the interrupt coalescing parameters with
ethtool -C eth0 ...
But I can't give you hard guidelines as to what would make it better.
I have a debug patch, but it needs work still.
ethtool -C bridgeint1 rx-frames 255 rx-frames-irq 255
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 21 Jan 2006 13:15:49 +0300
On Fri, Jan 20, 2006 at 05:06:36PM -0600, Christopher Friesen ([EMAIL
PROTECTED]) wrote:
I've been asked if there is any way to map a struct socket * in
kernelspace, to the userspace fd that corresponds to
Andrew Morton wrote:
Begin forwarded message:
Date: Sun, 22 Jan 2006 12:02:22 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
http://bugzilla.kernel.org/show_bug.cgi?id=5936
Summary: Openswan
On Sun, Jan 22, 2006 at 07:32:56PM +0100, Arjan van de Ven wrote:
The only supported combinations are distributions with the kernels they
ship.
I think you're being unreasonable here.
Absolutely. The statement is also completely false.
Fedora rebases to a new point release shortly
[NET]: Reduce size of struct sk_buff on 64 bit architectures
Move skb-nf_mark next to skb-tc_index to remove a 4 byte hole between
skb-nfmark and skb-nfct and another one between skb-users and skb-head
when CONFIG_NETFILTER, CONFIG_NET_SCHED and CONFIG_NET_CLS_ACT are enabled.
For all other
Carl-Daniel Hailfinger schrieb:
Stephen Hemminger schrieb:
You might try adjusting the interrupt coalescing parameters with
ethtool -C eth0 ...
But I can't give you hard guidelines as to what would make it better.
I have a debug patch, but it needs work still.
After experimenting
Hi Jesse,
Thanks for your reply. I still have two questions about packet splittng:
Question one: when e1000 does packet splitting, it seems packet data buffer
is splitted into three parts, but how does e1000 decide how many parts
needed to be splitted?
Question two: It seems e1000 does not
23 matches
Mail list logo
