mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>
Subject: Re: [E1000-devel] [in-tree drivers] freezing e1000e in 2.6.31 (SMP only? MSI?)
Date: Sun, 08 Nov 2009 15:55:58 +0000	[thread overview]
Message-ID: <87ljihnh81.fsf@spindle.srvr.nix> (raw)
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365F9923A504@rrsmsx501.amr.corp.intel.com> (Emil S. Tantilov's message of "Fri, 6 Nov 2009 16:58:09 -0700")

On 6 Nov 2009, Emil S. Tantilov verbalised:

> Nix wrote:
>> Ever since 2.6.31 was released, my gigabit e1000e link has been acting
>> up. Notably, under sufficient load (generally, on this machine, NFS
>> load), packets cease to be transferred, and the (MSI) interrupt count
>> ceases to rise. Pulling the interface down and bringing it back up
>> works, both via ip(8) and by simply yanking the cable and plugging it
>> in again.
>
> Can you please send the output of ethtool -S from the interface after you observe the failure?

Sure:

NIC statistics:
     rx_packets: 16502510
     tx_packets: 16371898
     rx_bytes: 14021876468
     tx_bytes: 13559743390
     rx_broadcast: 4011
     tx_broadcast: 69508
     rx_multicast: 146
     tx_multicast: 159
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 146
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 130
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 22
     tx_restart_queue: 61194
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 100122
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 1452391
     rx_flow_control_xoff: 1452502
     tx_flow_control_xon: 569948727
     tx_flow_control_xoff: 432717010
     rx_long_byte_count: 14021876468
     rx_csum_offload_good: 16478902
     rx_csum_offload_errors: 22235
     rx_header_split: 6854792
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0

I did a floodping out of the dead interface (100% packet loss) for a few
seconds and got some more:

NIC statistics:
     rx_packets: 16502523
     tx_packets: 16371898
     rx_bytes: 14021877794
     tx_bytes: 13559743390
     rx_broadcast: 4012
     tx_broadcast: 69508
     rx_multicast: 146
     tx_multicast: 159
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 146
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 132
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 22
     tx_restart_queue: 61194
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 100122
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 1452391
     rx_flow_control_xoff: 1452502
     tx_flow_control_xon: 623287688
     tx_flow_control_xoff: 432717010
     rx_long_byte_count: 14021877794
     rx_csum_offload_good: 16478902
     rx_csum_offload_errors: 22235
     rx_header_split: 6854792
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0


> Also try disabling Tx pause frames:
> ethtool -A fastnet tx off autoneg off

Trying that now. No freezes yet, but I haven't really given it long
enough.


Further mysteries: a couple of times bringing the interface down and up
again hasn't sufficed to fix it: I've had to do it multiple times. (It's
possible that this just the same bug being tripped again by the flood of
blocked traffic once the if comes up). Just once, the interface came back
on its own, without my needing to do a thing.

(Just in case, I changed the cable and the switch it's connected to. No
change. Of course given my luck that just means I have *two* bad cables
or switches ;P )

  reply	other threads:[~2009-11-08 15:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 20:21 Nix
2009-11-06 23:58 ` [E1000-devel] " Tantilov, Emil S
2009-11-08 15:55   ` Nix [this message]
2009-11-10  0:08     ` [E1000-devel] [in-tree drivers] freezing e1000e in 2.6.31 (SMP only? MSI? PAUSE!) Nix
2009-11-10  1:19       ` Allan, Bruce W

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=87ljihnh81.fsf@spindle.srvr.nix \
    --to=nix@esperi.org.uk \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=emil.s.tantilov@intel.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome