All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
To: netdev@vger.kernel.org
Subject: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
Date: Thu, 02 May 2019 14:58:35 +0200	[thread overview]
Message-ID: <2623037.2OFtx9BLgF@rocinante.m.i2n> (raw)
In-Reply-To: <1970944.Bv0UlMJzsJ@storm>

Hi All.

While updating to kernel 4.19, we realised that a problem reported in 2015 for 
kernel 3.7 is still around. Please see this link for more details: https://
marc.info/?l=linux-netdev&m=142124954120315

Basically, when using the e1000e driver, each few minutes the following 
messages appear in dmesg or system log.

[12465.174759] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
  TDH                  <c6>
  TDT                  <fb>
  next_to_use          <fb>
  next_to_clean        <c4>
buffer_info[next_to_clean]:
  time_stamp           <2e5e92>
  next_to_watch        <c6>
  jiffies              <2e67e8>
  next_to_watch.status <0>
MAC Status             <40080083>
PHY Status             <796d>
PHY 1000BASE-T Status  <7800>
PHY Extended Status    <3000>
PCI Status             <10>

Back in 2015, we applied a workaround that decreases the page size:

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 85ab7d7..9f0ef97 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2108,7 +2108,7 @@ static inline void __skb_queue_purge(struct 
sk_buff_head *list)
                kfree_skb(skb);
 }
 
-#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
+#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(4096)
 #define NETDEV_FRAG_PAGE_MAX_SIZE  (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
 #define NETDEV_PAGECNT_MAX_BIAS           NETDEV_FRAG_PAGE_MAX_SIZE
 

Testing kernel 4.19 with the same hardware showed the same problems, so we 
tried to adapt the old workaround to the current code:

diff -u -r -p linux-4.19.i686/net/core/sock.c linux-4.19.i686.e1000e/net/core/
sock.c
--- linux-4.19.i686/net/core/sock.c     2019-03-22 13:55:24.198266383 +0100
+++ linux-4.19.i686.e1000e/net/core/sock.c      2019-03-22 13:56:43.165765856 
+0100
@@ -2183,7 +2183,8 @@ static void sk_leave_memory_pressure(str
 }
 
 /* On 32bit arches, an skb frag is limited to 2^15 */
-#define SKB_FRAG_PAGE_ORDER    get_order(32768)
+/* Limit to 4096 instead of 32768 */
+#define SKB_FRAG_PAGE_ORDER    get_order(4096)
 
 /**
  * skb_page_frag_refill - check that a page_frag contains enough room


Unfortunately, this patch does not help with the "Unit Hang" messages anymore, 
the problem occurs with any page size.


Some insight in how to deal with this problem would be very much appreciated.

Thank you!






  reply	other threads:[~2019-05-02 13:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 15:32 [bisected regression] e1000e: "Detected Hardware Unit Hang" Thomas Jarosch
2015-01-14 17:20 ` Eric Dumazet
2015-01-15 10:11   ` Thomas Jarosch
2015-01-15 14:43     ` Eric Dumazet
2015-01-15 14:58       ` Thomas Jarosch
2015-01-15 15:25         ` Eric Dumazet
2015-01-15 15:48           ` Thomas Jarosch
2015-01-15 16:00             ` Eric Dumazet
2015-01-15 17:04               ` Thomas Jarosch
2015-01-15 17:20                 ` Eric Dumazet
2015-01-15 17:37                   ` Thomas Jarosch
2015-01-15 18:24                     ` Re: Re: Re: " Eric Dumazet
2015-01-19 16:49           ` Thomas Jarosch
2015-01-15 14:59       ` Jeff Kirsher
2015-02-11 11:23         ` Thomas Jarosch
2015-02-11 11:34           ` Jeff Kirsher
2015-02-12 23:28             ` Brown, Aaron F
2015-02-13 16:14               ` Thomas Jarosch
2015-02-21  1:59                 ` Brown, Aaron F
2015-03-23 13:58                   ` Thomas Jarosch
2015-03-23 22:37                     ` Brown, Aaron F
2015-05-27 16:00                       ` Thomas Jarosch
2015-05-30  1:18                         ` Brown, Aaron F
2015-07-29  8:51                           ` Thomas Jarosch
2019-05-02 12:58                             ` Juliana Rodrigueiro [this message]
2015-02-12  1:18           ` nick

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=2623037.2OFtx9BLgF@rocinante.m.i2n \
    --to=juliana.rodrigueiro@intra2net.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.