On Wed, 19 Apr 2006, Jesse Brandeburg wrote:
Boris B. Zhmurov wrote:
Hello, Herbert Xu.
On 19.04.2006 03:27 you said the following:
On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
I think it is deserving of some run time assertions, else these bugs
will elude us continua
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 09:53:48 -0700
> Please put this in the next -stable load...
I already sent it to -stable.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
On Tue, 18 Apr 2006 22:32:04 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Hi Dave:
>
> You're absolutely right about there being a problem with the TSO packet
> trimming code. The cause of this lies in the tcp_fragment() function.
>
> When we allocate a fragment for a completely non-linear pac
Boris B. Zhmurov wrote:
Hello, Herbert Xu.
On 19.04.2006 03:27 you said the following:
On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
I think it is deserving of some run time assertions, else these bugs
will elude us continually. Luckily there are only a few places that
wo
On Wed, Apr 19, 2006 at 10:04:53AM +0400, Boris B. Zhmurov wrote:
>
> I confirm, finally I don't see messages in dmesg about assertions. Nice
> work :)
That's great. Thanks a lot for your and everyone else's help in
tracking down.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: H
Hello, Herbert Xu.
On 19.04.2006 03:27 you said the following:
On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
I think it is deserving of some run time assertions, else these bugs
will elude us continually. Luckily there are only a few places that
would need the run time ass
On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
>
> I think it is deserving of some run time assertions, else these bugs
> will elude us continually. Luckily there are only a few places that
> would need the run time assertion checks on skb->truesize, and I'll
> try to spend a fe
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 18 Apr 2006 22:32:04 +1000
> You're absolutely right about there being a problem with the TSO packet
> trimming code. The cause of this lies in the tcp_fragment() function.
>
> When we allocate a fragment for a completely non-linear packet the
> tr
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Tue, 18 Apr 2006 18:29:59 +0200
> But shouldn't we put this kind of hairy manipulation into some nice
> functions? Driver writers were already confused by all that size,
> len and truesize stuff, as this bug showed.
It's 2 lines and frankly it's a bit c
Hi Herbert,
Herbert Xu wrote:
> I've copied the code you used in tso_fragment which should work here.
I'm happy to see, that this got resolved and this is a nice minimalistic fix
for -stable.
But shouldn't we put this kind of hairy manipulation into some nice functions?
Driver writers were alr
Hi Dave:
You're absolutely right about there being a problem with the TSO packet
trimming code. The cause of this lies in the tcp_fragment() function.
When we allocate a fragment for a completely non-linear packet the
truesize is calculated for a payload length of zero. This means that
truesize
11 matches
Mail list logo
