to me, thanks Ben !
Acked-by: Eric Dumazet eduma...@google.com
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1429122164.7346.139.ca...@edumazet-glaptop2
On Tue, 2015-04-14 at 08:32 +0100, Ben Hutchings wrote:
Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a (tcp: make connect()
mem charging friendly) was backported to various stable branches:
v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly
v3.12.40: d06381e8aac5 tcp: make
On Tue, 2013-05-21 at 14:55 +0200, Jiri Pirko wrote:
This is looking good to me. On my test machine it makes tbf work correctly
with gso packets.
I worked on similar patch (enqueue path) myself some time ago but I got
distracted by other tasks.
Yes, I understood this.
Do you plan to
On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote:
I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO
kicks in on the LAN interface.
On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote:
[...]
The Windows system is connected to the LAN interface (int0). Turning
On Mon, 2013-05-20 at 17:53 -0700, Eric Dumazet wrote:
On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote:
I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO
kicks in on the LAN interface.
On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
can even raise it to 0x3000 and don't see any tcp retransmits. Do you
have an advice on
On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
in the driver
Le jeudi 23 février 2012 à 15:36 +0100, Eric Dumazet a écrit :
[PATCH] ipsec: be careful of non existing mac headers
Nicollo Belli reported ipsec crashes in case we handle a frame without
mac header (atm in his case)
Oops sorry for your name being mangled in changelog, its Niccolò
header, better make sure it is present.
Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809
Reported-by: Niccolò Belli darkba...@linuxsystems.it
Tested-by: Niccolò Belli darkba...@linuxsystems.it
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
---
net/ipv4/xfrm4_mode_beet.c
Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit :
Three instances of the same piece of code, maybe a helper function is
appropriate at that point? :-) You might even get ambitious and add a
big comment to that helper function explaining the situation.
I did have this idea but
Le jeudi 23 février 2012 à 15:23 -0500, David Miller a écrit :
I think the work to backport is equal whether you use a helper function
or not. Heck, use an inline function so you don't have to worry about
module exports or any details like that.
Besides, I'm the one who likely has to
-by: Niccolò Belli darkba...@linuxsystems.it
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
---
V2: added skb_mac_header_rebuild() helper as David suggested.
include/linux/skbuff.h | 10 ++
net/ipv4/xfrm4_mode_beet.c |5 +
net/ipv4/xfrm4_mode_tunnel.c |6 ++
net
Le jeudi 23 février 2012 à 01:59 +0100, Niccolò Belli a écrit :
Hi,
The bug is still present in latest 3.2.7 vanilla kernel. I wasted the
whole day debugging that damn thing and I finally discovered the root cause.
The problem is with my Traverse Solos multi-port ADSL2+ PCI card[1]
(which
Le jeudi 23 février 2012 à 02:38 +0100, Eric Dumazet a écrit :
Which driver handles this Traverse Solos card ?
If br2684_push() is used, it seems it lacks proper call to
skb_reset_mac_header(skb) in paths where eth_type_trans() is not called.
Later in xfrm4_mode_tunnel_input() we crash because
Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit :
I'll check this out. After kernel.org was cracked I've missed
@kernel.org mail account.
At first glance, start_tx() is racy against TX completion.
It does :
if (np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 1
Le lundi 30 janvier 2012 à 11:14 +0100, Eric Dumazet a écrit :
Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit :
I'll check this out. After kernel.org was cracked I've missed
@kernel.org mail account.
At first glance, start_tx() is racy against TX completion.
It does
Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit :
Yes, I spotted that. But no descriptors are pushed to the hardware
here; that's done in the driver's TX tasklet. Although... maybe that
can run immediately when scheduled from here? I've never had to deal
with tasklets so I
Le lundi 30 janvier 2012 à 14:41 +, Ben Hutchings a écrit :
On Mon, 2012-01-30 at 15:28 +0100, Eric Dumazet wrote:
Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit :
Yes, I spotted that. But no descriptors are pushed to the hardware
here; that's done in the driver's
Le lundi 30 janvier 2012 à 15:57 +0100, Eric Dumazet a écrit :
Hmm, TX _completion_ is not run from tasklet but hardware IRQ, this is
why I added the spin_lock_irqsave().
Tasklet fires the TX, but hardware IRQ does the TX completion part.
This driver is ... interesting :)
Oh well, we
pass it on to the nvidia driver
packagers (who would presumably help you file a report with nvidia).
Actually this bug is really obvious (to me). It's this change:
commit 4924f44b97a034dbf44c14b709b0b0907ee23f04
Author: Eric Dumazet eric.duma...@gmail.com
Date: Mon Jul 4 17:57:10 2011
Le mardi 08 novembre 2011 à 01:39 +0100, Florian Fuessl a écrit :
Unfortunately the system still suffered from two network disconnects starting
with the following messages in the kernel log:
Nov 7 06:38:41 spozerl kernel: [ 9025.854230] Route hash chain too long!
Nov 7 06:38:41 spozerl
Le vendredi 21 octobre 2011 à 01:07 +0100, Ben Hutchings a écrit :
Eric, do you see any problems with this? Would we need any more
follow-up fixes?
Hi Ben
This patch is probably safe, it should avoid the emergency rebuild
trigger.even with few entries in cache, because of one long chain
Le dimanche 11 septembre 2011 à 14:52 +0100, Ben Hutchings a écrit :
On Sat, 2011-09-10 at 16:59 +0200, Eric Dumazet wrote:
Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
Is there any chance that this change could be backported to the 2.6.32.y
longterm branch
Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
Is there any chance that this change could be backported to the 2.6.32.y
longterm branch:
commit 87c48fa3b4630905f98268dde838ee43626a060c
Author: Eric Dumazet eric.duma...@gmail.com
Date: Thu Jul 21 21:25:58 2011 -0700
Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit :
On 11-07-15 00:14, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via
the bugzilla web interface).
Here: WARN_ON(next_time == 0);
From the other thread on
Le vendredi 29 juillet 2011 à 15:27 +0200, Eric Dumazet a écrit :
Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit :
On 11-07-15 00:14, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via
the bugzilla web interface
Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945
Reported-by: Lucas Bocchi lucas.boc...@gmail.com
Reported-and-bisected-by: Michal Pokrywka wolfm...@o2.pl
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
CC: Michal Soltys sol...@ziu.info
Acked-by: Patrick McHardy ka...@trash.net
Le lundi 25 octobre 2010 à 12:53 -0700, David Miller a écrit :
I'll commit the following to upstream, and submit a combined
patch to -stable.
net: Increase xmit RECURSION_LIMIT to 10.
Three is definitely too low, and we know from reports that GRE tunnels
stacked as
Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 14 Oct 2010 06:11:59 +0200
net-next-2.6 contains a fix for this, adding the perc_cpu
xmit_recursion limit. We might push it to net-2.6
We need to think a bit more about
Le lundi 18 octobre 2010 à 23:45 +0200, Francois Romieu a écrit :
Ben Hutchings b...@decadent.org.uk :
[...]
Arnout Boelens reported that his RTL8111/8168B fails to link-up after
suspend and resume, both under Debian's kernel based on 2.6.32 and under
2.6.36-rc6. Full details are at
xmit_recursion
limit. We might push it to net-2.6
Thanks
commit 745e20f1b626b1be4b100af5d4bf7b3439392f8f
Author: Eric Dumazet eric.duma...@gmail.com
Date: Wed Sep 29 13:23:09 2010 -0700
net: add a recursion limit in xmit path
As tunnel devices are going to be lockless, we need
Le mardi 13 avril 2010 à 11:03 +0100, stephen mulcahy a écrit :
Eric Dumazet wrote:
OK it seems forcedeth has problem with checksums ?
Try to change ethtool -k eth0 settings ?
ethtool -K eth0 tso off tx off
Yes, that makes an unresponsive system responsive again immediately, nice
Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit :
Ok, I've tried both of the following with my reproducer
1. ethtool -K eth0 tso off
RESULT: reproducer causes multiple hosts to be come unresponsive on
first run.
2. ethtool -K eth0 tx off
RESULT: reproducer runs three
Le mardi 13 avril 2010 à 15:49 +0100, stephen mulcahy a écrit :
Eric Dumazet wrote:
Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit :
Ok, I've tried both of the following with my reproducer
1. ethtool -K eth0 tso off
RESULT: reproducer causes multiple hosts to be come
Le mardi 13 avril 2010 à 16:08 +0100, stephen mulcahy a écrit :
Eric Dumazet wrote:
I am scratching my head, but I thought you told me that
ethtool -K eth0 tso off
ethtool -K eth0 tx on
was working ?
No, sorry for the confusion.
ethtool -K eth0 tx off
fixes the problem
Le mardi 13 avril 2010 à 16:25 +0100, stephen mulcahy a écrit :
Eric Dumazet wrote:
OK, thanks for clarification.
Last question, did you tried a vanilla kernel, aka 2.6.33.2 for
example ?
I built a Debian package from the vanilla 2.6.33.2 and installed that on
all nodes and tried my
Le mardi 13 avril 2010 à 14:43 -0700, David Miller a écrit :
Do you really come to the conclusion that TSO is broken with the above
test results?
I would conclude that there is a TX checksumming issue, since merely
turning TSO off does not fix the problem whereas turning TX
checksumming off
Le lundi 12 avril 2010 à 13:39 +0100, stephen mulcahy a écrit :
stephen mulcahy wrote:
It doesn't - further testing over the weekend saw 6 of 45 machines drop
off the network with this problem. Nothing in dmesg or system logs.
Happy to run more tests if someone can advise on what should
Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit :
Does that help?
Well, yes, because it seems a TCP problem.
r...@node20:~# tcpdump host node20 and node05
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet),
Le lundi 12 avril 2010 à 17:11 +0100, stephen mulcahy a écrit :
Eric Dumazet wrote:
Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit :
Do you have some netfilters rules ?
Hi Eric,
I don't have any netfilters rules:
r...@node34:~# for table in filter nat mangle raw
40 matches
Mail list logo
