All of lore.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.com \
    --cc=auke-jan.h.kok@intel.com \
    --cc=jchapman@katalix.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=lfabio.linux@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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.