On 08/27/2012 01:21 PM, Eric Dumazet wrote:
On Mon, 2012-08-27 at 12:55 -0500, Larry Finger wrote:
I have prepared a patch to fix all the unchecked allocations.
Over the weekend I made some progress. To test the latest vendor driver, I
installed a 32-bit system. Their driver is not compatible
On Mon, 2012-08-27 at 12:55 -0500, Larry Finger wrote:
> I have prepared a patch to fix all the unchecked allocations.
>
> Over the weekend I made some progress. To test the latest vendor driver, I
> installed a 32-bit system. Their driver is not compatible with a 64-bit
> system.
> I found
On 08/24/2012 12:47 PM, Eric Dumazet wrote:
dev_alloc_skb() can return NULL
-> crash
skb_clone() can also return NULL
-> crash
I have prepared a patch to fix all the unchecked allocations.
Over the weekend I made some progress. To test the latest vendor driver, I
installed a 32-bit
On 08/24/2012 12:47 PM, Eric Dumazet wrote:
dev_alloc_skb() can return NULL
- crash
skb_clone() can also return NULL
- crash
I have prepared a patch to fix all the unchecked allocations.
Over the weekend I made some progress. To test the latest vendor driver, I
installed a 32-bit system.
On Mon, 2012-08-27 at 12:55 -0500, Larry Finger wrote:
I have prepared a patch to fix all the unchecked allocations.
Over the weekend I made some progress. To test the latest vendor driver, I
installed a 32-bit system. Their driver is not compatible with a 64-bit
system.
I found that
On 08/27/2012 01:21 PM, Eric Dumazet wrote:
On Mon, 2012-08-27 at 12:55 -0500, Larry Finger wrote:
I have prepared a patch to fix all the unchecked allocations.
Over the weekend I made some progress. To test the latest vendor driver, I
installed a 32-bit system. Their driver is not compatible
On Fri, 2012-08-24 at 11:58 -0500, Larry Finger wrote:
> On 08/24/2012 11:23 AM, Eric Dumazet wrote:
> > On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
> >> On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
> >>> On 08/24/2012 10:19 AM, David Miller wrote:
>
> This looks
On 08/24/2012 11:23 AM, Eric Dumazet wrote:
On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen
On 08/24/2012 11:01 AM, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:49 -0500, Larry Finger wrote:
There is nothing in kernel log when it happens. The file STRACE is attached.
So there is indeed a corruption. What was the driver you used in this
case ?
The only driver that shows this
On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
> On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
> > On 08/24/2012 10:19 AM, David Miller wrote:
> > >
> > > This looks like full-on data corruption to me.
> >
> > I agree. The question is why does it happen with r8712u, and only
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
> On 08/24/2012 10:19 AM, David Miller wrote:
> >
> > This looks like full-on data corruption to me.
>
> I agree. The question is why does it happen with r8712u, and only after the
> commit in the subject. Drivers for other devices that I
On Fri, 2012-08-24 at 10:49 -0500, Larry Finger wrote:
> There is nothing in kernel log when it happens. The file STRACE is attached.
>
So there is indeed a corruption. What was the driver you used in this
case ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen with r8712u, and only after the
commit in the subject. Drivers for other devices that I have are OK. Thus far, I
have tested b43, rtl8187, ath9k_htc, and
From: Larry Finger
Date: Fri, 24 Aug 2012 09:09:57 -0500
> I usually get failures on the first or second try. A kernel built from
> "git checkout c862815" gets the following wget output:
>
>
> --2012-08-23 21:50:32--
>
Le vendredi 24 août 2012 à 09:09 -0500, Larry Finger a écrit :
> With kernel 3.6-rc2, the error changes to the following:
>
>
> --2012-08-24 08:26:42-- https://bugzilla.redhat.com/show_bug.cgi?id=847525
> Resolving
On 08/23/2012 04:26 PM, Eric Dumazet wrote:
skb->truesize is adjusted when a frag is added to one skb, or when
skb->head is re-allocated.
Are you sure you dont have another problem, because as I said commit
c8628155ece3 had a bug, so a bisect is not very useful.
How many reloads are needed
On 08/23/2012 04:26 PM, Eric Dumazet wrote:
skb-truesize is adjusted when a frag is added to one skb, or when
skb-head is re-allocated.
Are you sure you dont have another problem, because as I said commit
c8628155ece3 had a bug, so a bisect is not very useful.
How many reloads are needed to
Le vendredi 24 août 2012 à 09:09 -0500, Larry Finger a écrit :
With kernel 3.6-rc2, the error changes to the following:
--2012-08-24 08:26:42-- https://bugzilla.redhat.com/show_bug.cgi?id=847525
Resolving
From: Larry Finger larry.fin...@lwfinger.net
Date: Fri, 24 Aug 2012 09:09:57 -0500
I usually get failures on the first or second try. A kernel built from
git checkout c862815 gets the following wget output:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen with r8712u, and only after the
commit in the subject. Drivers for other devices that I have are OK. Thus far, I
have tested b43, rtl8187, ath9k_htc, and
On Fri, 2012-08-24 at 10:49 -0500, Larry Finger wrote:
There is nothing in kernel log when it happens. The file STRACE is attached.
So there is indeed a corruption. What was the driver you used in this
case ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen with r8712u, and only after the
commit in the subject. Drivers for other devices that I have are
On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen with r8712u, and only after the
On 08/24/2012 11:01 AM, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:49 -0500, Larry Finger wrote:
There is nothing in kernel log when it happens. The file STRACE is attached.
So there is indeed a corruption. What was the driver you used in this
case ?
The only driver that shows this
On 08/24/2012 11:23 AM, Eric Dumazet wrote:
On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data corruption to me.
I agree. The question is why does it happen
On Fri, 2012-08-24 at 11:58 -0500, Larry Finger wrote:
On 08/24/2012 11:23 AM, Eric Dumazet wrote:
On Fri, 2012-08-24 at 18:18 +0200, Eric Dumazet wrote:
On Fri, 2012-08-24 at 10:58 -0500, Larry Finger wrote:
On 08/24/2012 10:19 AM, David Miller wrote:
This looks like full-on data
On Thu, 2012-08-23 at 15:57 -0500, Larry Finger wrote:
> On 08/22/2012 11:03 PM, Eric Dumazet wrote:
> >
> > Changing the allocation size removes the problem ? thats really strange.
> >
> > If you try different sizes in the 9100-30720 range, can you pinpoint the
> > failure threshold ?
>
> The
On 08/22/2012 11:03 PM, Eric Dumazet wrote:
Changing the allocation size removes the problem ? thats really strange.
If you try different sizes in the 9100-30720 range, can you pinpoint the
failure threshold ?
The allocation size change did not fix the problem. It turned out that 10 tries
On 08/22/2012 11:03 PM, Eric Dumazet wrote:
Changing the allocation size removes the problem ? thats really strange.
If you try different sizes in the 9100-30720 range, can you pinpoint the
failure threshold ?
The allocation size change did not fix the problem. It turned out that 10 tries
On Thu, 2012-08-23 at 15:57 -0500, Larry Finger wrote:
On 08/22/2012 11:03 PM, Eric Dumazet wrote:
Changing the allocation size removes the problem ? thats really strange.
If you try different sizes in the 9100-30720 range, can you pinpoint the
failure threshold ?
The allocation size
On Wed, 2012-08-22 at 16:33 -0500, Larry Finger wrote:
> On 08/22/2012 12:15 AM, Eric Dumazet wrote:
> >
> > This particular commit is the start of a patches batch that ended in the
> > generic TCP coalescing mechanism.
> >
> > It is known to have problem on drivers doing skb_clone() in their rx
>
On 08/22/2012 12:15 AM, Eric Dumazet wrote:
This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.
It is known to have problem on drivers doing skb_clone() in their rx
path.
Current kernels should be ok, because coalescing doesnt happen if
On 08/22/2012 12:15 AM, Eric Dumazet wrote:
This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.
It is known to have problem on drivers doing skb_clone() in their rx
path.
Current kernels should be ok, because coalescing doesnt happen if
On 08/22/2012 12:15 AM, Eric Dumazet wrote:
This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.
It is known to have problem on drivers doing skb_clone() in their rx
path.
Current kernels should be ok, because coalescing doesnt happen if
On 08/22/2012 12:15 AM, Eric Dumazet wrote:
This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.
It is known to have problem on drivers doing skb_clone() in their rx
path.
Current kernels should be ok, because coalescing doesnt happen if
On Wed, 2012-08-22 at 16:33 -0500, Larry Finger wrote:
On 08/22/2012 12:15 AM, Eric Dumazet wrote:
This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.
It is known to have problem on drivers doing skb_clone() in their rx
path.
On Tue, 2012-08-21 at 23:07 -0500, Larry Finger wrote:
> Hi,
>
> The commit entitled "tcp: reduce out_of_order memory use" turns out to cause
> problems with a number of USB drivers.
>
> The first one called to my attention was for staging/r8712u. For this driver,
> there are problems with SSL
From: Larry Finger
Date: Tue, 21 Aug 2012 23:07:46 -0500
> I find it hard to understand why this patch should cause these
> effects; however, I have verified that a kernel generated from "git
> checkout e86b2919" works fine. This commit is immediately before the
> patch in question.
I can
From: Larry Finger larry.fin...@lwfinger.net
Date: Tue, 21 Aug 2012 23:07:46 -0500
I find it hard to understand why this patch should cause these
effects; however, I have verified that a kernel generated from git
checkout e86b2919 works fine. This commit is immediately before the
patch in
On Tue, 2012-08-21 at 23:07 -0500, Larry Finger wrote:
Hi,
The commit entitled tcp: reduce out_of_order memory use turns out to cause
problems with a number of USB drivers.
The first one called to my attention was for staging/r8712u. For this driver,
there are problems with SSL
40 matches
Mail list logo
