Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem is
advertising a window and then shrinking it faster than it is naturally
reduced by incoming data, essentially granting credit to transmit x
bytes, and then revoking that credit. The net result is the
On Sun, Apr 09, 2006 at 10:44:24PM -0700, David S. Miller wrote:
I got tired of waiting for Zach to cook up a patch so I tossed
the following into my tree :-)
Thanks David :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page:
Johannes Berg wrote:
Seems we forgot to stop the queue while scanning. Better do that so we
don't transmit packets all the time during background scanning.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- a/net/ieee80211/softmac/ieee80211softmac_scan.c
+++
On Mon, Apr 10, 2006 at 06:28:00AM +0200, Michael Buesch wrote:
To summerize: I actually added these messages, because people were
hitting this does not work with 1G issues and did not get an error message.
So I decided to insert warnings until the issue is fixed inside the arch code.
I will
Hi there,
The patch attached.
Cheers,
Vlad.
Signed-off-by: Vlad Drukker [EMAIL PROTECTED]
---
[PATCH] fix 802.3ad multicast frame handling
when bridging two 802.3ad bonds there is a bug.
core netif code does handle_bridge before calling protocol handler for
ETH_P_SLOW packet_type. when bridge
Andy Furniss wrote:
Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem
is advertising a window and then shrinking it faster than it is
naturally reduced by incoming data, essentially granting credit to
transmit x bytes, and then revoking that credit. The
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
resolves the problem: sapgui clients can connect to sap
servers while tcpdump is running on mimosa.
Is this a bug?
Very strange. Could you perhaps move
I got tired of waiting for Zach to cook up a patch so I tossed
the following into my tree :-)
Haha, sorry, I didn't realize I was racing the clock :). We disappeared
this weekend.
That matches what I came up with, but did we miss the IPv6 part? Here's
that half if you still need it.
Hi Vlad,
Vlad Drukker wrote:
diff --git a/net/core/dev.c b/net/core/dev.c
index 434220d..a351687 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1614,6 +1614,8 @@ static __inline__ int handle_bridge(stru
struct net_bridge_port *port;
if ((*pskb)-pkt_type ==
On Mon, 10 Apr 2006 19:28:39 +0200
Ingo Oeser [EMAIL PROTECTED] wrote:
Hi Vlad,
Vlad Drukker wrote:
diff --git a/net/core/dev.c b/net/core/dev.c
index 434220d..a351687 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1614,6 +1614,8 @@ static __inline__ int handle_bridge(stru
Mark Butler wrote:
Andy Furniss wrote:
Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem
is advertising a window and then shrinking it faster than it is
naturally reduced by incoming data, essentially granting credit to
transmit x bytes, and then
Stephen and Andrew,
Many thanks for your comments! Will incorporate your suggestions and
resubmit.
thanks,
Catherine
Stephen Smalley [EMAIL PROTECTED] wrote on 04/10/2006 09:11:47 AM:
On Fri, 2006-04-07 at 19:30 -0400, Catherine Zhang wrote:
Hi, James, Stephen, Dave and Chris,
On Mon, 2006-04-10 at 11:06 -0700, Stephen Hemminger wrote:
On Mon, 10 Apr 2006 19:28:39 +0200
Ingo Oeser [EMAIL PROTECTED] wrote:
Hi Vlad,
Vlad Drukker wrote:
diff --git a/net/core/dev.c b/net/core/dev.c
index 434220d..a351687 100644
--- a/net/core/dev.c
+++
Andy Furniss wrote:
Mark Butler wrote:
Andy Furniss wrote:
Mark Butler wrote:
There is no problem manipulating the TCP window per se. The problem
is advertising a window and then shrinking it faster than it is
naturally reduced by incoming data, essentially granting credit to
transmit x
From: Zach Brown [EMAIL PROTECTED]
Date: Mon, 10 Apr 2006 09:49:34 -0700
I got tired of waiting for Zach to cook up a patch so I tossed
the following into my tree :-)
Haha, sorry, I didn't realize I was racing the clock :). We disappeared
this weekend.
No worries. Linus came back
On Mon, 10 Apr 2006 22:57:45 +0300
Vlad Drukker [EMAIL PROTECTED] wrote:
On Mon, 2006-04-10 at 11:06 -0700, Stephen Hemminger wrote:
On Mon, 10 Apr 2006 19:28:39 +0200
Ingo Oeser [EMAIL PROTECTED] wrote:
Hi Vlad,
Vlad Drukker wrote:
diff --git a/net/core/dev.c
On Mon, Apr 10, 2006 at 09:46:30AM -0400, John W. Linville wrote:
On Mon, Apr 10, 2006 at 06:28:00AM +0200, Michael Buesch wrote:
To summerize: I actually added these messages, because people were
hitting this does not work with 1G issues and did not get an error
message.
So I decided
From: Benoit Boissinot [EMAIL PROTECTED]
Date: Tue, 11 Apr 2006 00:13:59 +0200
On Mon, Apr 10, 2006 at 09:46:30AM -0400, John W. Linville wrote:
On Mon, Apr 10, 2006 at 06:28:00AM +0200, Michael Buesch wrote:
To summerize: I actually added these messages, because people were
hitting
Hi,
On Friday 07 April 2006 15:15, jamal wrote:
Ok, I built on Herbert's suggestion and tried to be a little
clever/accurate. Instead of a flag i introduce a variable that stores
the jiffy point when the timer is killed. If we fall anywhere to the
right or at exact point of the next point
signed off by:
S. P. [EMAIL PROTECTED]
redundant_include_patch
Description: 3142717620-redundant_include_patch
S P wrote:
signed off by:
S. P. [EMAIL PROTECTED]
without a real name this shouldn't be accepted. Also try not to send base-64
encoded, it really looks like spam to me. Even no-brainers should include a
decent signed-off line.
Auke
-
To unsubscribe from this list: send the line
Stephen Hemminger [EMAIL PROTECTED] wrote:
consider the flow:
netif_receive_skb() { // occures on eth0 at your picture
...
skb_bond() // changes dev to dev-master
...
handle_bridge() // bridge got the frame
...
deliver_skb() // ETH_P_SLOW bonding handler from ptype_base[]
...
}
notice
Sorry.
I don't have much control of attachment type with
web-based mail.
Will having the patch saved in .txt file help?
In plain text, the patch should read:
sonar 15:30:37 ~/private/linux-2.6.16 $ diff -up
linux-2.6.16/kernel/profile.c~
linux-2.6.16/kernel/profile.c
---
This change allows link local packets (like 802.3ad and Spanning Tree
Protocol) to be processed even when the bridge is not using the port.
It fixes the chicken-egg problem for bridging a bonded device, and
may also fix problems with spanning tree failover.
Signed-off-by: Stephen Hemminger [EMAIL
From: Ingo Oeser [EMAIL PROTECTED]
general:
- endian annotation of the ring descriptors
nv_getlen():
- use htons() instead of __constant_htons()
to improvde readability and let the compiler constant fold it.
nv_rx_process():
- use a real for() loop in
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 10 Apr 2006 16:24:29 -0700
This change allows link local packets (like 802.3ad and Spanning Tree
Protocol) to be processed even when the bridge is not using the port.
It fixes the chicken-egg problem for bridging a bonded device, and
may
On Mon, 2006-04-10 at 09:46 -0400, John W. Linville wrote:
On Mon, Apr 10, 2006 at 06:28:00AM +0200, Michael Buesch wrote:
To summerize: I actually added these messages, because people were
hitting this does not work with 1G issues and did not get an error
message.
So I decided to
Hi,
I am trying to install a proprietary qdisc made for research, it is not
publically released yet, however its been used several times so i know it works.
The files included are:
q_xcp.c:
static int xcp_parse_opt()
static int xcp_print_opt()
static int xcp_print_xstats()
struct
Yes, I know they hit the message, that's from a message in some forum
that i got interested in the issue. It probably comes from an allocation
from:
http://www.linux-m32r.org/lxr/http/source/arch/powerpc/kernel/pci_direct_iommu.c#L32
Either the ppc code is wrong (it doesn't enforce
The hacks i see there is reallocating a buffer with GFP_DMA, so that
means that if the ppc dma_alloc_coherent did the same thing as the i386
counterpart (adding GFP_DMA if dma_mask is less than 32bits) it should
work, no ?
Except that GFP_DMA covers the whole address space on ppc64...
Ben.
On Tue, Apr 11, 2006 at 03:53:51AM +0200, Michael Buesch wrote:
On Tuesday 11 April 2006 03:46, you wrote:
Now, for ppc32, it should still sort-of work because all of lowmem is
below 1Gb and people generally don't hack their lowmem size (well, I do
but heh, that doesn't count :) and I
On Tue, 2006-11-04 at 00:34 +0200, KOVACS Krisztian wrote:
[..]
But I still perfer the flag.
Ok, so consensus is to use a flag.
Another thing still present is the possible xfrm_state leak. I think we
need to call xfrm_state_put() as the last statement of
xfrm_replay_timer_handler() to
SO This patch integrates the smcinit code into the smsc-ircc driver.
SO Some laptops have their smsc-ircc chip not properly configured by the BIOS
and needs some preconfiguration. Currently, this can be done from userspace
with smcinit, a utility that comes with the irda-utils package. It messes
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 11 Apr 2006 11:46:12 +1000
But ppc64 hits the problem and at this point, there is nothing
I can do other than either implementing a split zone allocation mecanism
in the ppc64 architecture for the sole sake of bcm43xx (ick !) or doing
34 matches
Mail list logo
