On Sat, Feb 23, 2008 at 08:00:18PM -0800, David Miller wrote:
> "da" is kzalloc()'d, how can da->da_synced not be zero?
Because it was originally kmalloc'd, not kzalloc'd. It was
fixed about 2 days prior to my patch submission, here:
http://marc.info/?l=linux-netdev&m=120343348811767&w=2
wh
candidate
for -stable.
Phil
Signed-off-by: Phil Oester <[EMAIL PROTECTED]>
diff --git a/net/core/dev.c b/net/core/dev.c
index 908f07c..999af2e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2905,6 +2905,7 @@ int __dev_addr_add(struct dev_addr_list **list, int
*count,
On Wed, Nov 29, 2006 at 06:15:37PM -0800, David Miller wrote:
> In fact it does, the NDISC code is using MAX_HEADER incorrectly. It
> needs to explicitly allocate space for the struct ipv6hdr in 'len'.
> Luckily the TCP ipv6 code was doing it right.
>
> What a horrible bug, this patch should fix
On Tue, Aug 01, 2006 at 07:10:09PM +0200, Balazs Scheidler wrote:
> Each interface can belong to a single "group" at a time, an interface
> comes up without being a member in any of the groups.
>
> Userspace can assign interfaces to groups after being created, this
> would typically be performed i
On Tue, Aug 01, 2006 at 12:00:59AM -0700, David Miller wrote:
> What we have now is infinitely better than the past,
> wherein all TSO packets were dropped due to corrupt
> checksums as soon at the NAT module was loaded.
At what point did this problem begin? 2.6.18-rc or prior?
Phil
I saw this error (once) in 2.6.13 a few weeks ago:
Jun 23 15:19:01 X kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jun 23 15:19:01 X kernel: TDH <7e>
Jun 23 15:19:01 X kernel: TDT <7f>
Jun 23 15:19:01 X kernel: next_to_use <7f>
Jun
usting for the "from" starting
point. This consequently fixes the netfilter string match's "--to"
handling, which currently is broken.
Phil
Signed-off-by: Phil Oester <[EMAIL PROTECTED]>
diff -ruN linux-orig/net/core/skbuff.c linux-new/net/core/skbuff.c
--- linux-or
On Thu, Apr 06, 2006 at 04:11:58AM +1000, Herbert Xu wrote:
> That's a very interesting observation. Can others please check if they
> have an abnormally large skbuff slab cache?
Mine seem to be reasonably sized:
e1000 with assertion failures (up 14 days, 2:51):
OBJS ACTIVE USE OBJ SIZE SLA
On Mon, Apr 03, 2006 at 04:01:23PM -0500, Mark Nipper wrote:
> After three days and some hours, I finally saw another
> event:
Ack, same here. Looked hopeful, but finally saw the error today.
Phil
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messag
> On 29 Mar 2006, Brandeburg, Jesse wrote:
> What I need from you is a reproducible test, and some information. I
>From all the reports which have come in thus far, it seems everyone
has > 1 e1000. One person even reported that removing one of the two
nics solved the problem for him. Does this
On Wed, Mar 29, 2006 at 06:53:57PM -0800, Brandeburg, Jesse wrote:
> Hi all, I've identified you as people who have at some point in the past
> emailed one of the Linux lists with problems with e1000 and
> sk_forward_alloc. It seems to be fairly widespread, but only seems to
> have appeared with r
David S. Miller wrote:
E1000 has some TSO bug most likely, try reproducing with
"ethtool -K eth0 tso off", replacing "eth0" with your actual
e1000 interface name(s).
That does seem to have solved the problem.
Suggested next steps? Should I leave TSO disabled, or pester the e1000
maintainer
Upgraded a number of heavily used squid boxes to 2.6.16 from 2.6.13
this week, and noticed these errors in the logs:
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (279)
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (148)
but then looked through the
13 matches
Mail list logo
