Dear Rick,
Thank you for your reply.
I am sorry that I don't quite understand your point. As far as I know, the
function call udp_flush_pending_frames() in net/ipv4/udp.c is invoked
regardless of whether the socket is set to either a blocking mode or a
non-blocking mode. Do you mean that the
Matthias Urlichs wrote:
Hi,
Herbert Xu:
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and t
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
>
> The stuff I see in there doesn't look stupid to me.
>
> accept(...) = 216
> setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0
> setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> followed by a bunch
Hi,
Herbert Xu:
> Matthias Urlichs <[EMAIL PROTECTED]> wrote:
> >
> > Any ideas? Is the sending program doing something stupid? If so, what?
>
> Probably. Since you're on the sender's side (192.109.x.x I presume) why
> don't you do a strace on the sending process and tell us?
>
The stuff I see
Paul Aviles wrote:
I am getting "e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang"
using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3.
The server is a Tyan GS10 and is connected to a Netgear GS724T Gig
switch. I can easily reproduce the problem by trying to do a large ftp
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
>
> Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and tell us?
Cheers,
--
Visit Openswan at http://www.opens
Marco Berizzi <[EMAIL PROTECTED]> wrote:
> I kindly would like to know why linux reply to ICMP
> echo request packets with the DF bit set always to 0.
We do that because that's the only sensible thing to do if you
actually want ICMP messages to reach the destination host. PMTU
on ICMP does not ma
thanks for your response!
Yes, The code is under net/sched in the source tree.
The file act_police.c in the directoy net/sched don't exist. there is
police.c that have a very similar code act_police.c (that i have found on
internet)
however i have doon 'make menuconfig', i have gone to traffic
On Saturday 02 September 2006 00:10, Jean Tourrilhes wrote:
> On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote:
> >
> > > Note that one thing that worry me with your approach is
> > > footprint. I've used various embedded devices over the years, such as
> > > the Gumstix (4MB Flash
On 9/2/06, Franco <[EMAIL PROTECTED]> wrote:
I thought that this code was police.c but seem that it isn't
i must implement a proc file in the code and recompiling the kernel.
I'm not sure I understand your question. Please tell me if I answer wrong!
The code is under net/sched in the source tr
Change to use new netdev_alloc_skb interface for 2.6.18.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -818,8 +818,9 @@ static void skge_rx_clean(struct skge_po
/* Allocate buffers for receive ring
* For receive: t
The driver needs to access the IRQ status inside of lock to avoid
races with other places changing IRQ mask etc. This may be related
to some of the SMP bugs reported against skge in kernel bugzilla.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- netdev-2.6.orig/drivers/net/skge.c
+++ ne
The skge driver has much better performance if transmit done is handled in
NAPI softirq. Change from doing transmit locking in driver (LLTX) and
use device lock.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- netdev-2.6.orig/drivers/net/skge.c
+++ netdev-2.6/drivers/net/skge.c
@@ -91,7
Because of the NAPI and other SMP fixes, let's call
this a version.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -43,7 +43,7 @@
#include "skge.h"
#define DRV_NAME "skge"
-#define DRV_VERSION
There are several places where this driver needs to ensure that
PCI accesses have completed before releasing locks. These maybe related
to the problem (not verified):
http://bugzilla.kernel.org/show_bug.cgi?id=6142
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- netdev-2.6.orig
This set fixes several races and performance problems related
to bug reports.
--
VGER BF report: H 0.437515
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
e1000: Typo fix.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
diff --git a/e1000.c b/e1000.c
index 6de27ca..6741323 100644
--- a/e1000.c
+++ b/e1000.c
@@ -372,7 +372,7 @@ e1000_dump_regs(struct ethtool_drvinfo *
" Descriptor minimum threshold size: %s\n"
" Broadcast accept mode:
I modified the sky2 driver to do fragmented receive for large MTU.
The hardware supports breaking receive into chunks, so this version allocates
some header space in the skb data up to two pages (assuming 4K page size) for
the extra data.
It doesn't go into fragmented mode until it thinks the allo
Jay Vosburgh wrote:
Patch 1: Add 10 Gig support
Patch 2: Convert delay value from s16 to int
Patch 3: Format fix in seq_printf call
Patch 4: Remove unneeded NULL test
Patch 5: Handle large hard_header_len
Patch 6: Add priv_flag to avoid event mishan
On 06-09-01 20:55 Michael Buesch wrote:
> > > The real
> > > problem with WE is, as I previously said, the ill-defined semantics of
> > > both the user-space API and the in-kernel API.
> >
> > I don't understand why you say it's ill defined, it 100%
> > documented in the iwconfig man page.
>
Hello,
I have a problem with a TCP connection here which just doesn't
want to have multiple packets on the wire.
I have verified that the sender has enough buffered data (netstat -t
shows 8..10k send buffer). There's no packet loss. The tcpdump
(attached) shows that the receiver increases its win
From: jamal <[EMAIL PROTECTED]>
When a bonding netdevice is admin-ed down it loses the slaves
attributes (set via ifenslave). This is not consistent with other
behavior of netdevices (example a qdisc attached to a netdevice doesnt
disappear or an attached IP address etc).
The included patch fixes
Add priv_flag to specifically identify bonding-involved devices. Needed
because IFF_MASTER is an unreliable identifier (vlan interfaces above bonding
will inherit IFF_MASTER). Misidentification of devices would cause
notifier events for other devices to be erroneously processed by bonding,
causi
The bonding driver fails to adjust its hard_header_len when enslaving
interfaces. Whenever an interface with a hard_header_len greater than the
ETH_HLEN default is enslaved, the potential for an oops exists, and if the
oops happens while responding to an arp request, for example, the system
panic
On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote:
>
> > Note that one thing that worry me with your approach is
> > footprint. I've used various embedded devices over the years, such as
> > the Gumstix (4MB Flash), and this is why WE was optimised for
> > footprint.
>
> Can you
Remove unneeded test for NULL. Reported by Thomas Dillig
<[EMAIL PROTECTED]> and Isil Dillig <[EMAIL PROTECTED]> via Stephen
Hemminger <[EMAIL PROTECTED]>.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
--- netdev-2.6.git-upstream/drivers/net/bonding/bond_sysfs.c2006/08/19
10:22:17 1
From: Kenzo Iwami <[EMAIL PROTECTED]>
Though link_failure_count is type unsigned int, this value is outputted to
/proc/net/bonding/bondX file using "%d" instead of "%u".
The attached patch fixes this problem.
Signed-off-by: Kenzo Iwami <[EMAIL PROTECTED]>
Acked-by: Jay Vosburgh <[EMAIL PROTECTE
From: Kenzo Iwami <[EMAIL PROTECTED]>
The value of "downdelay/miimon" and "updelay/miimon" are stored in
slave->delay. The type of downdelay, updelay, and miimon are all int.
However, slave->delay is type short, and it is not possible to store the
value of "downdelay/miimon" or "updelay/miimon" i
Allow channel bonding to enslave a 10 Gig adapter without errors.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
diff -urpN -X linux-2.6.18-rc4-clean/Documentation/dontdiff
linux-2.6.18-rc4-clean/drivers/net/bonding/bond_3ad.c
linux-2.6.18-rc4/dri
Patch 1: Add 10 Gig support
Patch 2: Convert delay value from s16 to int
Patch 3: Format fix in seq_printf call
Patch 4: Remove unneeded NULL test
Patch 5: Handle large hard_header_len
Patch 6: Add priv_flag to avoid event mishandling
Patch 7
Some more Marvell device id's, these are from the latest SysKonnect
vendor driver version of sk98lin (8.36).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |3 +++
1 file changed, 3 insertions(+)
--- sky2.orig/drivers/net/sky2.c2006-09-01 14:49:49.00
Replaces INET6_IFADDR_RTA_SPACE with a new function calculating
the total required message size for all address messages.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/ne
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:19.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:21.0
iproute2 doesn't provide the NLM_F_CREATE flag when adding addresses,
it is assumed to be implied. The existing code issues a check on
said flag when the modify operation fails (likely due to ENOENT)
before continueing to create it, this leads to a hard to predict
result, therefore the NLM_F_CREATE
Same behaviour as IPv4, using IFF_UP is a no-no anyway.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:24.0 +0200
+++ net-2.6.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:21.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:22.0
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:14:47.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:14.0
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:18.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:19.0
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:14.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:18.0
Converts all of the IPv6 address configuration code to the new
netlink api and removes a bogus check on IFF_UP when adding
new addresses.
--
VGER BF report: U 0.467674
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Turn Appropriate Byte Count off by default because it unfairly penalizes
applications that do small writes.
Add better documentation to describe what it is so users will understand
why they might want to turn it on.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Documentation/networki
On 06-08-30 15:06 Michael Buesch wrote:
> Because this clearly is a workaround for broken compilers to me,
> I would rather do the following:
>
> +} /* __attribute__((packed)) */;
>
>
> This way it's still clear to the reader, that these structs
> must be packed and are most likely for communic
On Friday 01 September 2006 17:28, Larry Finger wrote:
> Michael,
>
> This patch includes the board revision in the chip_id printk for the ssb
> version of bcm43xx-d80211
> and is meant to be applied to wireless-dev. As we have seen, behavior of the
> chips can be dependent
> on the rev level,
On Friday 01 September 2006 18:35, Jean Tourrilhes wrote:
> On Fri, Sep 01, 2006 at 08:54:00AM +0200, Johannes Berg wrote:
> > On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote:
> >
> > > And I strongly disagree with your disagrement ;-)
> >
> > You're of course free to do that :) But le
Hello.
Following patch is for linux-2.6.
I think it is appropriate to push this to -stable.
---
[IPV6]: Fix tclass setting for raw sockets.
np->cork.tclass is used only in cork'ed context.
Otherwise, np->tclass should be used.
Bug#7096 reported by Remi Denis-Courmont <[EMAIL PROTECTED]>.
Sign
Hi,
This entire patch is available at,
http://www.netxen.com/products/downloads/netxen-2.6.17.patch.zip
Thanks,
pradeep
On Thu, 31 Aug 2006, Amit S. Kale wrote:
Hi All,
Thank you Stephen, Don and Wendy.
We have incorporated feedbacks which have received since after last post.
I'll be resend
Patrick McHardy wrote:
Patrick McHardy wrote:
Brian Haley wrote:
Change some netfilter tunables to __read_mostly. Also fixed some
incorrect file reference comments while I was in there.
Please send these kind of patches for netfilter to me so I can
make sure they don't clash with other pend
Patrick McHardy wrote:
> Brian Haley wrote:
>
>>Change some netfilter tunables to __read_mostly. Also fixed some
>>incorrect file reference comments while I was in there.
>
>
> Please send these kind of patches for netfilter to me so I can
> make sure they don't clash with other pending patches
Brian Haley wrote:
> Change some netfilter tunables to __read_mostly. Also fixed some
> incorrect file reference comments while I was in there.
Please send these kind of patches for netfilter to me so I can
make sure they don't clash with other pending patches.
> (this will be my last __read_mos
On Fri, Sep 01, 2006 at 08:54:00AM +0200, Johannes Berg wrote:
> On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote:
>
> > And I strongly disagree with your disagrement ;-)
>
> You're of course free to do that :) But let me explain.
And my explanation is even more simple : let'
Joerg Roedel wrote:
> diff -uprN linux-2.6.17.11-vanilla/net/ipv4/etherip.c
> linux-2.6.17.11/net/ipv4/etherip.c
> --- linux-2.6.17.11-vanilla/net/ipv4/etherip.c1970-01-01
> 01:00:00.0 +0100
> +++ linux-2.6.17.11/net/ipv4/etherip.c2006-09-01 16:22:54.0
> +0200
>
On Fri, Sep 01, 2006 at 05:05:57PM +1000, Herbert Xu wrote:
> On Thu, Aug 31, 2006 at 05:12:43PM +0200, cagri coltekin wrote:
> >
> > It took a while to find equipment for test environment, but now I
> > have a test environment that I can test.
> >
> > Here is the result:
> >
> > ---
Change sctp globals to __read_mostly.
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 5692ef5..d9dd4c4 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -61,7 +61,7 @@
#include
/* Global data structures. */
-struct sctp_
Change some bridge sysctl tunables to __read_mostly.
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index cf80dd0..ac181be 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -53,10 +53,10 @@
#ifdef CONFIG
Change some netfilter tunables to __read_mostly. Also fixed some
incorrect file reference comments while I was in there.
(this will be my last __read_mostly patch unless someone points out
something else that needs it)
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/netfilter
Michael,
This patch includes the board revision in the chip_id printk for the ssb version of bcm43xx-d80211
and is meant to be applied to wireless-dev. As we have seen, behavior of the chips can be dependent
on the rev level, thus a need to have it in the log.
Signed-off-by: Larry Finger <[EM
Greetings,
Upon request of a BSD user I wrote an EtherIP tunnel driver for the
Linux Kernel. With this driver it is possible to tunnel Ethernet packets
over IPv4 networks using the EtherIP protocol defined in RFC 3378.
This RFC defines the EtherIP header to be a 16 bit field with the first
4 bit
I kindly would like to know why linux reply to ICMP
echo request packets with the DF bit set always to 0.
I have googled the internet but I have only found
this pretty old message:
http://www.ussg.iu.edu/hypermail/linux/kernel/9804.2/0334.html
I also have found these messages that document this
Hi!,
I'm not able to subscrive at this list. My server mail don't send the mail
and consider it a spam mail...
For this, please send eventual response to this mail address
([EMAIL PROTECTED])
The problem is this:
I'm searching, in kernel code, the code that implement thi command:
tc filter ad
On Fri, 2006-01-09 at 23:04 +1000, Herbert Xu wrote:
> Yes, I suppose you could even replace x->mode directly.
>
> > I am probably better off going back to creating a dummy dst with just
> > those two fields when in tunnel mode;->
>
> Probably. Although if you write your own output function you
On Fri, Sep 01, 2006 at 08:56:18AM -0400, jamal wrote:
>
> Thats one idea i havent thought of.
>
> i.e the code would look like:
> -
> if (mode == tunnel)
> err = mytunneloutput (x, skb);
> else
> err = x->mode->output(x, skb);
> if (err)
>
On Fri, 2006-01-09 at 14:25 +0200, Johannes Berg wrote:
> On Fri, 2006-09-01 at 08:22 -0400, jamal wrote:
>
> > Sorry, I havent had time to look at that code (is it in Daves tree?);
>
> No, it's not in any tree yet.
>
Could you point me to it? I can look at it over the weekend.
> > if
> > i
On Fri, 2006-01-09 at 22:22 +1000, Herbert Xu wrote:
> Right, you're testing the receiver side.
both in/out sides (on the receiver); i just count and drop all packets
coming back to the sender (the pktgenerator)
> In that case I suggest that
> you replicate the IPsec transport mode logic in th
On Fri, 2006-09-01 at 08:22 -0400, jamal wrote:
> Seems you may be talking about capabilities more than filtering?
yes, I had sort of thought filtering would be that, but now that you say
it I get the point :)
> Sorry, I havent had time to look at that code (is it in Daves tree?);
No, it's not
On Fri, Sep 01, 2006 at 08:17:14AM -0400, jamal wrote:
>
> In the case of traffic generation, if i could shave even more cycles the
> better since i want to generate high speed. In this case the cycles
> would be in creating a fake dst and attaching it some fake values.
Right, you're testing the
On Fri, 2006-01-09 at 14:07 +1000, Herbert Xu wrote:
> On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote:
> >
> > Would it be reasonable to do a check so that incase a skb->dst doesnt
> > exist, the inner headers values can be used i.e something along
> > xfrm4_tunnel_output()::
>
> If you d
On 01/09/06, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 01/09/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
> >
> > I've just encountered the problem on a different server with an
> > identical vlan setup. That server is running 2.6.13.4
>
> Do you have a simpl
Francois Romieu wrote:
> Pierre Ossman <[EMAIL PROTECTED]> :
>
>> Ehm... why am I included in this? :)
>>
>
> To preserve an happy 8139cp user :o)
>
>
A noble endeavor. Carry on. ;)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
Pierre Ossman <[EMAIL PROTECTED]> :
> Ehm... why am I included in this? :)
To preserve an happy 8139cp user :o)
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-inf
On Fri, Sep 01, 2006 at 01:47:15PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
> Hello!
>
> > problem. The problem is really at the receiver because we only
> > ACK every other full sized frame. I had the idea to ACK every 2
> > frames, regardless of size,
>
> This would solve lots of p
On 01/09/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> I've just encountered the problem on a different server with an
> identical vlan setup. That server is running 2.6.13.4
Do you have a simple recipe to reproduce this? Ideally it'd be a
script that anyon
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> I've just encountered the problem on a different server with an
> identical vlan setup. That server is running 2.6.13.4
Do you have a simple recipe to reproduce this? Ideally it'd be a
script that anyone can execute in a freshly booted system that
exhibit
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
I'm not sure if documenting this here is appropriate, but
if it is, here is some text to put there.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/Documentation/kernel-parameters.txt
===
--- linux-2.6.orig/Documentat
This patch makes the debuging behaviour of this code more consistent
with the rest of IPVS.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c
Fill in a help message for the ports option to ip_vs_ftp
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:02:38.0
+09
Hi,
This series of four patches has several minor cleanups for the options to
the ip_vs_ftp modules.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
On 31/08/06, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 31/08/06, Ben Greear <[EMAIL PROTECTED]> wrote:
> Jesper Juhl wrote:
> > Hi,
> >
> > I've got a small problem with 2.6.18-rc5-git2.
> >
> > I've got a vlan setup on eth0.20, eth0 does not have an IP.
> >
> > When I attempt to reboot or halt t
From: Pekka Savola <[EMAIL PROTECTED]>
Date: Fri, 1 Sep 2006 12:44:48 +0300 (EEST)
> On Thu, 31 Aug 2006, David Miller wrote:
> ...
> >> Probably, aspect 1 of ABC just should be disabled. And the first my
> >> suggestion looks working too.
> >
> > I'm ready to rip out ABC entirely, to be honest.
Hello!
> problem. The problem is really at the receiver because we only
> ACK every other full sized frame. I had the idea to ACK every 2
> frames, regardless of size,
This would solve lots of problems.
>but that might have other problems.
BSD used to do this, everyon
On Thu, 31 Aug 2006, David Miller wrote:
...
Probably, aspect 1 of ABC just should be disabled. And the first my
suggestion looks working too.
I'm ready to rip out ABC entirely, to be honest. Or at least
turn it off by default.
Just as a curious observer: do you think these issues are due t
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 12:28:56 +0400
> neigh_table_clear() doesn't free tbl->stats.
> Found by Alexey Kuznetsov. Though Alexey considers this
> leak minor for mainstream, I still believe that cleanup
> code should not forget to free some of the resources
neigh_table_clear() doesn't free tbl->stats.
Found by Alexey Kuznetsov. Though Alexey considers this
leak minor for mainstream, I still believe that cleanup
code should not forget to free some of the resources :)
At least, this is critical for OpenVZ with virtualized
neighbour tables.
Signed-Off
On Fri, 2006-09-01 at 14:41, Johannes Berg wrote:
> On Fri, 2006-09-01 at 11:37 +0800, Hong Liu wrote:
> >
> > + local->sta_scanning = 1;
> > + if (local->hw->hw_scan)
> > + return local->hw->hw_scan(dev, ssid, ssid_len);
> > +
>
> My question still stands, is it proper to ass
From: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 16:15:39 +0900
> James Morris wrote:
> > It seems that during the MIPv6 respin, some code which was originally
> > conditionally compiled around CONFIG_XFRM_ADVANCED was accidently left in
> > after the config option was removed.
James Morris wrote:
It seems that during the MIPv6 respin, some code which was originally
conditionally compiled around CONFIG_XFRM_ADVANCED was accidently left in
after the config option was removed.
This patch removes an extraneous pointer (xerr_idxp) which is no longer
needed.
Please re
On Thu, Aug 31, 2006 at 05:12:43PM +0200, cagri coltekin wrote:
>
> It took a while to find equipment for test environment, but now I
> have a test environment that I can test.
>
> Here is the result:
>
> ---
> [17180051.768
87 matches
Mail list logo
