public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Bill Fink <billfink@mindspring•com>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel•com>
Cc: "L F" <lfabio.linux@gmail•com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@intel•com>,
	"James Chapman" <jchapman@katalix•com>, <netdev@vger•kernel.org>
Subject: Re: e1000 driver and samba
Date: Tue, 18 Sep 2007 02:03:58 -0400	[thread overview]
Message-ID: <20070918020358.d50653d5.billfink@mindspring.com> (raw)
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203592D77@orsmsx418.amr.corp.intel.com>

On Mon, 17 Sep 2007, Brandeburg, Jesse wrote:

> L F wrote:
> > On 9/17/07, Kok, Auke <auke-jan.h.kok@intel•com> wrote:
> >> The statistic we were looking at _will_ increase when running in
> >> half duplex, but if it increases when running in full duplex might
> >> indicate a hardware failure. Probably you have fixed the issue with
> >> the CAT6 cable. 
> > Uhm, 'fixed' may be premature: I restarted the machine and with 22
> > hours uptime I am getting:
> > tx_deferred_ok: 36254
> > 
> >> Can you run this new configuration with the old cable? that would
> >> eliminate the cable (or not)
> > I most certainly can. This seems to have gotten worse by a factor or
> > 100 or more.. so am I to suspect the new cable?
> > 
> >> A single port failure on a switch can also happen, and samba is
> >> definately 
> >> a good test for defective hardware. I cannot rule out anything from
> >> the information we have gotten yet.
> > True, but I tried changing the switch ports with little change.
> > Putting a client on the same switch port yielded no errors on the
> > client, although unfortunately I don't have ethtool statistics on XP.
> > The switch, btw, is a fairly generic GS108 from Netgear (there
> > actually are two).
> 
> it may be not well documented, but the hardware has several states that
> it can get into that can cause tx_deferred counter to increment.  None
> of them are fatal to traffic, it is mainly an informational statistic.
> 
> in this case it is in the "due to receiving flow control; tx is paused"
> state...
> 
> he has 488 rx flow control xoff/xon, which means the switch is being
> overloaded and sending flow control, or the switch is passing through
> flow control packets (which it should not since they are multicast) and
> (some) client is overloaded.
> 
> can you turn off flow control at the server?  ethtool -A ethX rx off tx
> off or load the driver with parameter FlowControl=0  With the 7.6.5
> driver at least you'll get confirmation of the flow control change on
> the "Link Up:" line.

It may also be a useful test to disable hardware TSO support
via "ethtool -K ethX tso off".

						-Bill

  reply	other threads:[~2007-09-18  6:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-14  2:04 e1000 driver and samba L F
2007-09-14 17:18 ` Kok, Auke
2007-09-14 18:40   ` L F
2007-09-14 20:59     ` Kok, Auke
2007-09-15  0:37       ` L F
2007-09-15  5:09         ` Bill Fink
2007-09-15 12:27           ` L F
2007-09-15 12:44             ` L F
2007-09-15 17:44       ` James Chapman
2007-09-15 19:07         ` Kok, Auke
2007-09-16  4:06           ` L F
2007-09-16  5:04             ` Kok, Auke
2007-09-17 16:42               ` L F
2007-09-17 17:02                 ` Kok, Auke
2007-09-17 18:58                   ` L F
2007-09-17 21:01                     ` Brandeburg, Jesse
2007-09-18  6:03                       ` Bill Fink [this message]
2007-09-18  7:45                         ` Urs Thuermann
2007-09-18  8:47                           ` Bill Fink
2007-09-18 13:39                           ` Florian Weimer
2007-09-18 16:32                             ` L F
2007-09-18 17:04                               ` Tantilov, Emil S
2007-09-19 14:53                                 ` L F
2007-09-20  2:51                                   ` Bill Fink
2007-09-21 14:08                                     ` L F
2007-09-20  4:53                                   ` Bill Fink
2007-09-18 16:44                             ` Bill Fink
2007-09-17 18:02               ` Rick Jones
2007-09-17 18:51                 ` Kok, Auke
2007-09-16 16:24           ` James Chapman
2007-09-16 20:03             ` Kok, Auke
2007-09-16  4:07         ` L F
2007-09-14 18:26 ` Francois Romieu
2007-09-14 18:41   ` L F
  -- strict thread matches above, loose matches on Subject: below --
2007-09-20 23:30 Bruce Cole
2007-09-21 14:13 ` L F
2007-09-21 18:21   ` Bruce Cole
2007-09-21 21:49 ` Francois Romieu
2007-09-21 22:01   ` Bruce Cole
2007-09-21 22:41     ` Francois Romieu

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=20070918020358.d50653d5.billfink@mindspring.com \
    --to=billfink@mindspring$(echo .)com \
    --cc=auke-jan.h.kok@intel$(echo .)com \
    --cc=jchapman@katalix$(echo .)com \
    --cc=jesse.brandeburg@intel$(echo .)com \
    --cc=lfabio.linux@gmail$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox