Sorry for the delay.
On Friday 27 October 2006 05:58, Herbert Xu wrote:
I am using an AMD64 box with 32bit userspace / 64bit kernel.
Kernels 2.6.18 and 2.6.18.1 semi-randomly hang when I upload stuff
over the net - for example, svn commit, scp are affected.
2.6.17.11 does not seem to
This patchset fixes three issues in ep93xx_eth. The first fix is for
an RX/TX lockup bug due to mishandling of the RX/TXstatus rings in the
driver, and is a showstopper. The second and third aren't really
showstopper bugs, but real issues nevertheless, and easy enough to fix.
Please apply for
Ray Lehtiniemi reported that an incoming UDP packet flood can lock up
the ep93xx ethernet driver. Herbert Valerio Riedel noted that due to
the way ep93xx_eth manages the RX/TXstatus rings, it cannot distinguish
a full ring from an empty one, and correctly suggested that this was
likely to be
On Sun, Oct 29, 2006 at 01:55:56PM +0100, Denis Vlasenko wrote:
With echo 1 /proc/sys/kernel/panic_on_oops I've got
what you're requested. See screenshot:
http://busybox.net/~vda/gso_panic/forcedeth_gso_panic2.jpg
Thanks!
Please let me know if this patch fixes it:
[NET]: Fix segmentation
Daniel Drake wrote:
Holden Karau wrote:
I've changed the patch based on your suggestions :-)
Thanks, looks fine. Let's just wait for an OK from Ulrich, then you can
send it to John, without broken tabs/lines, with signoff and description.
Daniel
I'm not so sure about this. This patching
On Sunday 29 October 2006 06:06, Lennert Buytenhek wrote:
Flooding the console with an RX FIFO overrun error for every single
dropped packet isn't very sensible. The hardware is very underpowered
according to today's standards, and RX FIFO overrun errors can be
triggered quite easily, so
On Sun, Oct 29, 2006 at 11:15:28AM -0700, Ray Lehtiniemi wrote:
Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
On Sunday 29 October 2006 11:22, Lennert Buytenhek wrote:
Also, is it possible for any other error bits to be set at the same
time as OE? such bits would not be printed to the log in this case.
Not sure, but arguably, this wouldn't be very interesting. Actually,
now I'm wondering whether
On Sunday 29 October 2006 15:10, Herbert Xu wrote:
On Sun, Oct 29, 2006 at 01:55:56PM +0100, Denis Vlasenko wrote:
With echo 1 /proc/sys/kernel/panic_on_oops I've got
what you're requested. See screenshot:
http://busybox.net/~vda/gso_panic/forcedeth_gso_panic2.jpg
Thanks!
Please
On Sunday 29 October 2006 22:45, Denis Vlasenko wrote:
On Sunday 29 October 2006 15:10, Herbert Xu wrote:
On Sun, Oct 29, 2006 at 01:55:56PM +0100, Denis Vlasenko wrote:
With echo 1 /proc/sys/kernel/panic_on_oops I've got
what you're requested. See screenshot:
From: Randy Dunlap [EMAIL PROTECTED]
Fix printk format warnings:
build2.out:net/dccp/ccids/ccid2.c:355: warning: long long unsigned int format,
u64 arg (arg 3)
build2.out:net/dccp/ccids/ccid2.c:360: warning: long long unsigned int format,
u64 arg (arg 3)
build2.out:net/dccp/ccids/ccid2.c:482:
From: Randy Dunlap [EMAIL PROTECTED]
Date: Sun, 29 Oct 2006 13:24:40 -0800
Fix printk format warnings:
build2.out:net/dccp/ccids/ccid2.c:355: warning: long long unsigned int
format, u64 arg (arg 3)
build2.out:net/dccp/ccids/ccid2.c:360: warning: long long unsigned int
format, u64 arg (arg
Hi Dave:
[SCTP]: Always linearise packet on input
I was looking at a RHEL5 bug report involving Xen and SCTP
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550).
It turns out that SCTP wasn't written to handle skb fragments at
all. The absence of any calls to skb_may_pull is testament
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 30 Oct 2006 18:11:28 +1100
[SCTP]: Always linearise packet on input
...
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
I'll apply this, thanks a lot.
Sridhar, could you please organise an audit of SCTP to make sure
that it deals with skb fragments
14 matches
Mail list logo
