I can also inform you that once again my network interface is showing high
loads.
I'll reboot it sometime during Saturday - Monday, and I'll keep you posted
with the new status. Hopefully the network will work better, but we'll know
for sure in 14 days or so.
Regards,
Andreas
-
To unsubscribe fro
On 12/22/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Eric Dumazet <[EMAIL PROTECTED]>
> Date: Sat, 17 Dec 2005 11:55:06 +0100
>
> > This patch makes sure a 'struct proto_ops' can be declared as const, so that
> > all cpus can share all parts of it without false sharing.
> ...
> > This s
> fail-over has occured the other server does break - so my simplistic
I'am very sorry but I should have stated:
doesnt(!) break
-
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/majordom
> Yes, let the server act as usual, it just starts happening out of the blue.
> No new hardware has been added or removed, no new programs has been
> installed.
"Me too"
[2.] Full description of the problem/report:
Last week I had the same issue twice. In short: load goes through the
roof from 2
From: Stephen Hemminger <[EMAIL PROTECTED]>
The max growth of BIC TCP is too large. Original code was based on
BIC 1.0 and the default there was 32. Later code (2.6.13) included
compensation for delayed acks, and should have reduced the default
value to 16; since normally TCP gets one ack for ever
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch creates a file airo.h containing prototypes of the global
functions in airo.c used by airo_cs.c .
If you got strange problems with either airo_cs devices or in any other
completely unrelated part of the kernel shortly or long after a airo_cs
device
From: Herbert Xu <[EMAIL PROTECTED]>
The recent rewrite of skb_copy_datagram_iovec broke the reception of
zero-size datagrams. This patch fixes it.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/core/datagram.c |4
1 file ch
SangOg Na <[EMAIL PROTECTED]> :
[executive summary: the 2.6.x driver works, where is the 2.4.x one ?]
Completely untested (it compiles though) instant-backport:
http://www.zoreil.com/~romieu/via-velocity/20051223-2.4.31-via-velocity-test.patch
The patch applies to 2.4.32 with minor
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Sat, 24 Dec 2005 00:17:33 +0900 (JST)
> Sorry, I introduced a dead-lock by the latest NETDEV_CHANGE patch.
> We need to relesae ifp->lock before we call addrconf_dad_stop(),
> which will hold ifp->lock.
>
> Please apply this.
>
> Signed-off-by: Y
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Sat, 24 Dec 2005 01:48:43 +0900 (JST)
> From: Hiroyuki YAMAMORI <[EMAIL PROTECTED]>
>
> Since regen_count is stored in the public address, we need to reset it
> when we start renewing temporary address.
>
> Signed-off-by: YOSHIFUJI Hideaki <[EMAI
Andi Kleen wrote:
On Fri, Dec 23, 2005 at 03:15:24PM +0100, Manfred Spraul wrote:
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus with a 4
From: Hiroyuki YAMAMORI <[EMAIL PROTECTED]>
Since regen_count is stored in the public address, we need to reset it
when we start renewing temporary address.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 510220f..745aa43 100644
-
On Fri, Dec 23, 2005 at 03:15:24PM +0100, Manfred Spraul wrote:
> Andi Kleen wrote:
>
> >It's more than 82 bytes but less than 86. I didn't run the binary
> >search further.
> >
> >
> >
> My guess: with 86 byte additional padding, you end up doing
> kmalloc(2049), and thus with a 4 kB allocation
Hello.
Sorry, I introduced a dead-lock by the latest NETDEV_CHANGE patch.
We need to relesae ifp->lock before we call addrconf_dad_stop(),
which will hold ifp->lock.
Please apply this.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
in
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus with a 4 kB allocation.
On my setup, padding 64 results in a 1984 byte kmalloc call:
dev_kfree_skb for 162
On Fri, Dec 23, 2005 at 01:42:52PM +0100, Manfred Spraul wrote:
> Hi,
>
> Andi Kleen wrote:
>
> >It shouldn't make any difference on !SLAB_DEBUG kernels because kmalloc
> >will pad typical mtus (1.5k, 9k) to 2k or 16k. But at least the
> >network driver is usable now again with slab debugging e
Hi,
Andi Kleen wrote:
It shouldn't make any difference on !SLAB_DEBUG kernels because kmalloc
will pad typical mtus (1.5k, 9k) to 2k or 16k. But at least the
network driver is usable now again with slab debugging enabled.
Very odd. slab debugging doesn't affect the padding. Even with sla
I finally tracked down what caused the red zone failures with forcedeth
on my test system. It's only related to me starting to use CONFIG_SLAB_DEBUG
instead of any driver changes and probably was always broken.
I have not done too heavy testing with this yet, but the simple
tests where it failed
18 matches
Mail list logo
