* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Note: Ingo also reports what looks like a memory corruption due to the
> 6b6b6b6b pattern on presumably the same box.
>
> The 6b6b6b6b pattern is POISON_FREE, implying some kind of slab
> misuse, most likely a use-after-free, although possibly just
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
ye
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Sat, 14 Apr 2007 07:31:35 +0200
> When did tg3 model changed exactly ?
June of 2006:
commit 00b7050426da8e7e58c889c5c80a19920d2d41b3
Author: Michael Chan <[EMAIL PROTECTED]>
Date: Sat Jun 17 21:58:45 2006 -0700
[TG3]: Convert to non-LLTX
Herbert Xu a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
dev_queue_xmit_nit() is called before attempting to send packet to device.
If device could not accept the packet (hard_start_xmit() returns an error),
packet is requeued and retried later.
each retry means call ev_queue_xmit_nit() ag
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri, 13 Apr 2007 18:34:23 -0700 (PDT)
Let's see how related these two might actually be.
> On Sat, 14 Apr 2007, Adrian Bunk wrote:
> >
> > Subject: laptops with e1000: lockups
> > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id
On 4/14/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Note: Ingo also reports what looks like a memory corruption due to
the 6b6b6b6b pattern on presumably the same box.
The 6b6b6b6b pattern is POISON_FREE, implying some kind of slab misuse,
most likely a use-after-free, although possibly just
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 14 Apr 2007 14:21:44 +1000
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > dev_queue_xmit_nit() is called before attempting to send packet to device.
> >
> > If device could not accept the packet (hard_start_xmit() returns an error),
> > packet
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri, 13 Apr 2007 18:34:23 -0700 (PDT)
> Davem - have there been network infrastructure changes that migt be
> suspect? Jeff and/or Greg - anything in the generic network driver/device
> driver level? We had some trouble earlier with the transition t
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> dev_queue_xmit_nit() is called before attempting to send packet to device.
>
> If device could not accept the packet (hard_start_xmit() returns an error),
> packet is requeued and retried later.
> each retry means call ev_queue_xmit_nit() again, so tcp
> On Sat, 14 Apr 2007, Adrian Bunk wrote:
>>
>> Subject: laptops with e1000: lockups
>> References :
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
>> Submitter : Dave Jones <[EMAIL PROTECTED]>
>> Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]>
>> Status : problem is be
Note: Ingo also reports what looks like a memory corruption due to
the 6b6b6b6b pattern on presumably the same box.
The 6b6b6b6b pattern is POISON_FREE, implying some kind of slab misuse,
most likely a use-after-free, although possibly just due to overrunning a
slab into the next one or someth
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 22:23:17 +1000
> On Wed, Apr 11, 2007 at 10:15:51PM +1000, Rusty Russell wrote:
> >
> > Actually, I did this precisely because I really didn't want to start
> > exposing bogus stats in /proc/net/dev. An audit might clarify if this
> > i
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Fri, 13 Apr 2007 17:39:48 +0900 (JST)
> A packet which is being discarded because of no routes in the
> forwarding path should not be counted as OutNoRoutes but as
> InNoRoutes.
> Additionally, on this occasion, a packet whose destinaion is
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> Bartek wrote:
> > Hopefully, this time it my bug report should be ok :):
> >
> > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a
From: James Morris <[EMAIL PROTECTED]>
Date: Fri, 13 Apr 2007 13:51:24 -0400 (EDT)
> On Fri, 13 Apr 2007, Joy Latten wrote:
>
> >
> > Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
>
> Acked-by: James Morris <[EMAIL PROTECTED]>
Applied, thanks a lot Joy.
-
To unsubscribe from this list: send th
On Fri, 13 Apr 2007 13:53:12 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8325
>
>Summary: -j REDIRECT --to-ports 1000-1009, always first choosen
> Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4
> Status: NEW
> Severity:
On Fri, 2007-04-13 at 13:00 -0500, Andy Fleming wrote:
>
> >
> > Or are there too many cases where NIC x needs to do these fiddlings
> > with
> > PHY y, where as NIC z has to do different fiddlings with PHY y?
>
>
> I worry about this point, but I believe that a proper abstraction
> must be
From: David Howells <[EMAIL PROTECTED]>
Date: Fri, 13 Apr 2007 19:08:31 +0100
> AF_NETLINK sockets, however, do not do (3). See this bit in
> netlink_recvmsg():
>
> copied = skb->len;
> if (len < copied) {
> msg->msg_flags |= MSG_TRUNC;
> copied = len;
>
Support MSG_TRUNC when passed to recvmsg() as an argument on an AF_NETLINK
socket. In such a case, the full size of the packet at the front of the Rx
queue should be returned, including any of it discarded when MSG_TRUNC is set
by recvmsg() on return.
If MSG_TRUNC is not set, then only the amount
As I understand it, according to the recvmsg() manual page, if the packet
being returned is larger than the buffer provided, and the protocol does not
support piecemeal reception of data, then:
(1) the buffer should be filled,
(2) MSG_TRUNC should be set in msg_flags, and
(3) the length of t
Would it be feasible to make netlink_recvmsg() _not_ truncate message unless
it is asked to by having MSG_TRUNC passed to it?
Unless netlink data packets are limited to PAGE_SIZE or less, it's entirely
possible that the kernel can be in a situation where it can't guarantee to get
a buffer large e
On Fri, 13 Apr 2007, Joy Latten wrote:
>
> Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
>
>
> diff -urpN linux-2.6.20/net/xfrm/xfrm_user.c
> linux-2.6.20.patch/net/xfrm/xfrm_user.c
> --- linux-2.6.20/net/xfrm/xfrm_user.c 2007-04-12 15:12:27.00
Michael Chan wrote:
On Thu, 2007-04-12 at 16:50 +0200, Andi Kleen wrote:
Jamie webb <[EMAIL PROTECTED]> writes:
Hi there
I have a Dell PE860 with built-in BCM5721, which is reported as
working fine with the tg3 driver, however I have been getting sporadic
data corruption, mostly evident as SS
Evgeniy Polyakov wrote:
On Thu, Apr 12, 2007 at 02:36:34PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
I am not sure if the problem is fixed or just harder to hit,
but for now it looks good.
Wasn't default congestion control algo changed between that kernel
releases?
With such small r
On Fri, 13 Apr 2007 18:10:12 +0200
Daniel Schaffrath <[EMAIL PROTECTED]> wrote:
>
> On 2007/04/12 , at 20:19, Eric Dumazet wrote:
> >
> > Warning : tcpdump can lie, telling you packets being transmited
> > several time.
> Maybe you have further pointers how come that tcpdump lies about
> dupl
On 30/03/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
Subject: suspend to disk hangs (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
Caused-By : Stephen Hemminger <[EMAIL PROTECTED]>
commit a504e64ab42bcc27074ea37405d06833
On 2007/04/12 , at 20:19, Eric Dumazet wrote:
On Thu, 12 Apr 2007 10:59:19 -0700
Ben Greear <[EMAIL PROTECTED]> wrote:
Here is a tcpdump of the connection in the stalled state. As you
can see by
the 'time' output, it's running at around 100,000 packets per
second. tcpdump
dropped the v
On Fri, Apr 13, 2007 at 08:42:57AM -0700, Linsys Contractor Mithlesh Thukral
wrote:
> NetXen: Configurable interrupts on PPC architecture
> This patch will add support to add command line argument to specify
> the interrupt type on a PPC machine. Fixes some issues seen on Big endian
> machines.
>
NetXen: Fix vmalloc errors on seen on some X86 high end machines.
Signed-off by: Milan Bag <[EMAIL PROTECTED]>
Acked-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxe
NetXen: Configurable interrupts on PPC architecture
This patch will add support to add command line argument to specify
the interrupt type on a PPC machine. Fixes some issues seen on Big endian
machines.
Signed-off by: Milan Bag <[EMAIL PROTECTED]>
Acked-by: Mithlesh Thukral <[EMAIL PROTECTED]>
NetXen: Port Swap feature
This patch will allow a port numbers on the card to be swapped in
host driver. This feature is applicable to cards having more than
1 port.
Signed-off by: Milan Bag <[EMAIL PROTECTED]>
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_
NetXen: Remove 2 redundant macro definitions from header file.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_phan_reg.h |2 --
1 files changed, 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_phan_reg.h
b/drivers/net/netxen/netxen_nic_phan
NetXen: Fix the multi PCI function for cards with more than 2 ports.
This patch fixes the working of multi PCI capable driver on cards with
more than 2 ports by adding the addresses for their rings and sizes.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic
NetXen: Removal of redundant function call parameters and bug fixes.
This patch will remove the redundant paramters which were being passed to
many functions since now adapter->portnum can be used.
Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |
hi All,
I will be sending patches for NetXen 1/10G Ethernet driver in subsequent mails.
These patches are with respect to netdev#upstream and we wish their inclusion
in 2.6.22 kernel.
Out of these the first 2 patches were already accepted into the netdev tree,
but we have requested them to be d
When sending a security context of 50+ characters in an ACQUIRE
message, following kernel panic occurred.
kernel BUG in xfrm_send_acquire at net/xfrm/xfrm_user.c:1781!
cpu 0x3: Vector: 700 (Program Check) at [c000421bb2e0]
pc: c033b074: .xfrm_send_acquire+0x240/0x2c8
lr: c
On Wed, 2007-04-11 at 16:42 -0500, Kim Phillips wrote:
> On Wed, 11 Apr 2007 03:03:56 +0200
> Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
> >
> > > (note I'm coming from an embedded world here.)
> >
> > Please read this:
> >
>
SACKED_ACKED and LOST are mutually exclusive with SACK, thus
having their sum larger than packets_out is bug with SACK.
Eventually these bugs trigger traps in the tcp_clean_rtx_queue
with SACK but it's much more informative to do this here.
Non-SACK TCP, however, could get more than packets_out du
Hi everyone,
I found on this mailinglist the thread from chunkeey who added WPA support for
prism54 fullmac cards
http://www.spinics.net/lists/netdev/msg16224.html
The last days I tried to get this driver working, but I was not able to. After
"googling" and reading the mails I found that Jim Fau
Since you did update the abstraction part too (which I wasn't
expecting). Here's the update version so that you don't have to resolve
it.
[PATCH] [TCP] FRTO: RFC4138 allows Nagle override when new data must be sent
This is a corner case where less than MSS sized new data thingie
is awaiting in
David Miller <[EMAIL PROTECTED]> wrote:
> Issue a RTM_GETLINK rtnetlink request, and parse the response.
Okay, I've managed to find code that does this. However, RTM_GETLINK does not
appear to return any IPv4 addressing information. It does, however, contain
the MTU details which is one of the
A packet which is being discarded because of no routes in the
forwarding path should not be counted as OutNoRoutes but as
InNoRoutes.
Additionally, on this occasion, a packet whose destinaion is
not valid should be counted as InAddrErrors separately.
Based on patch from Mitsuru Chinen <[EMAIL PROT
On Thu, Apr 12, 2007 at 02:36:34PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
> I am not sure if the problem is fixed or just harder to hit,
> but for now it looks good.
Wasn't default congestion control algo changed between that kernel
releases?
With such small rtt like in your setup there coul
44 matches
Mail list logo
