All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Pelletier <plr.vincent@gmail.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@vger.kernel.org
Subject: Re: r8169: IO_PAGE_FAULT & netdev watchdog
Date: Sat, 2 Jun 2012 15:42:28 +0200	[thread overview]
Message-ID: <201206021542.28869.plr.vincent@gmail.com> (raw)
In-Reply-To: <20120602105645.GA28769@electric-eye.fr.zoreil.com>

Le samedi 02 juin 2012 12:56:45, vous avez écrit :
> And partly because the patch I sent included its content in the commit
> message as well. :o/

I noticed the repetition after trying to apply on 3.4, and dropped one. And 
only then realised it was really already applied.

> If the inlined patch makes a difference, you should see it with 3.4.

It made a difference, when testing with netcat: without any change over 
vanilla 3.3.7, network trafic drops to 0 in a matter of seconds (up to around 
10s). With it, it stayed stable for 10 minutes, until I killed nc.
I reproduced this with 3.4 as well (no patch = bug, patch = no problem).
In both version without patch, I got the watchdog warning 10 minutes after 
traffic drop - though without the IO_PAGE_FAULT message.

I spent quite some time testing with nc in UDP mode first, and couldn't 
reproduce the issue (then I switched to TCP as said above). Does that make any 
sense ?
I also noticed the significant lag at bootup when eth0 is brought up is much 
reduced on patched kernel. Does that makes sense ?

FWIW, the commands I used were based on:
  nc -l -p 5555 < /dev/zero > /dev/null

With/without -u flag, and of course client-side equivalent command so the 
connection was used full-duplex at maximum speed: 450Mb/s in TCP, 800+Mb/s in 
UDP, each way. UDP was limited by CPU on one side (~450Mb/s upload from 
that box, 800Mb/s download, 100% cpu on it).
Values are as reported by nload & htop.
All tests were done in runlevel 2, with rsyslog manually started with its init 
script.

> My life is a bit easier when you work somewhere in the main branch
> (or in davem's -next but it is not relevant for regression fixes).

I'm not sure: does 3.4 tarball from kernel.org qualify as "main branch" ? 
Otherwise, which git repos & branch should I use ?

Regards,
-- 
Vincent Pelletier

      reply	other threads:[~2012-06-02 13:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 21:31 r8169: IO_PAGE_FAULT & netdev watchdog Vincent Pelletier
2012-06-01 12:59 ` Francois Romieu
2012-06-01 19:20   ` Vincent Pelletier
2012-06-01 20:13     ` Francois Romieu
2012-06-02  9:08   ` Vincent Pelletier
2012-06-02 10:56     ` Francois Romieu
2012-06-02 13:42       ` Vincent Pelletier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201206021542.28869.plr.vincent@gmail.com \
    --to=plr.vincent@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.