From: Zoltan Kiss <zoltan.kiss@schaman.hu>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Bruce Allan <bruce.w.allan@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
Don Skidmore <donald.c.skidmore@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
Alex Duyck <alexander.h.duyck@intel.com>,
John Ronciak <john.ronciak@intel.com>,
Tushar Dave <tushar.n.dave@intel.com>,
Akeem G Abodunrin <akeem.g.abodunrin@intel.com>,
"David S. Miller" <davem@davemloft.net>,
e1000-devel@lists.sourceforge.net,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org, Michael Chan <mchan@broadcom.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: igb and bnx2: "NETDEV WATCHDOG: transmit queue timed out" when skb has huge linear buffer
Date: Thu, 30 Jan 2014 19:08:11 +0000 [thread overview]
Message-ID: <52EAA31B.1090606@schaman.hu> (raw)
Hi,
I've experienced some queue timeout problems mentioned in the subject
with igb and bnx2 cards. I haven't seen them on other cards so far. I'm
using XenServer with 3.10 Dom0 kernel (however igb were already updated
to latest version), and there are Windows guests sending data through
these cards. I noticed these problems in XenRT test runs, and I know
that they usually mean some lost interrupt problem or other hardware
error, but in my case they started to appear more often, and they are
likely connected to my netback grant mapping patches. These patches
causing skb's with huge (~64kb) linear buffers to appear more often.
The reason for that is an old problem in the ring protocol: originally
the maximum amount of slots were linked to MAX_SKB_FRAGS, as every slot
ended up as a frag of the skb. When this value were changed, netback had
to cope with the situation by coalescing the packets into fewer frags.
My patch series take a different approach: the leftover slots (pages)
were assigned to a new skb's frags, and that skb were stashed to the
frag_list of the first one. Then, before sending it off to the stack it
calls skb = skb_copy_expand(skb, 0, 0, GFP_ATOMIC, __GFP_NOWARN), which
basically creates a new skb and copied all the data into it. As far as I
understood, it put everything into the linear buffer, which can amount
to 64KB at most. The original skb are freed then, and this new one were
sent to the stack.
I suspect that this is the problem as it only happens when guests send
too much slots. Does anyone familiar with these drivers have seen such
issue before? (when these kind of skb's get stucked in the queue)
Regards,
Zoltan Kiss
next reply other threads:[~2014-01-30 19:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-30 19:08 Zoltan Kiss [this message]
2014-01-30 20:34 ` igb and bnx2: "NETDEV WATCHDOG: transmit queue timed out" when skb has huge linear buffer Michael Chan
2014-01-30 20:34 ` Michael Chan
2014-01-31 13:29 ` Zoltan Kiss
2014-01-31 13:29 ` Zoltan Kiss
2014-02-04 19:47 ` Michael Chan
2014-02-04 19:47 ` Michael Chan
2014-02-05 20:23 ` Zoltan Kiss
2014-02-05 20:23 ` Zoltan Kiss
2014-02-05 20:23 ` Zoltan Kiss
2014-02-05 20:27 ` Zoltan Kiss
2014-02-05 20:27 ` Zoltan Kiss
2014-02-05 20:27 ` Zoltan Kiss
2014-02-05 20:43 ` Andrew Cooper
2014-02-05 20:43 ` Andrew Cooper
2014-02-05 20:43 ` Andrew Cooper
2014-02-06 9:58 ` Zoltan Kiss
2014-02-06 9:58 ` Zoltan Kiss
2014-02-06 9:58 ` Zoltan Kiss
2014-01-30 20:34 ` Michael Chan
2014-01-31 18:56 ` Wei Liu
2014-01-31 18:56 ` Wei Liu
2014-02-04 21:32 ` Zoltan Kiss
2014-02-04 21:32 ` Zoltan Kiss
2014-02-04 21:32 ` Zoltan Kiss
2014-02-12 17:13 ` Zoltan Kiss
2014-02-12 17:13 ` Zoltan Kiss
2014-02-12 17:13 ` Zoltan Kiss
-- strict thread matches above, loose matches on Subject: below --
2014-01-30 19:08 Zoltan Kiss
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=52EAA31B.1090606@schaman.hu \
--to=zoltan.kiss@schaman.hu \
--cc=akeem.g.abodunrin@intel.com \
--cc=alexander.h.duyck@intel.com \
--cc=bruce.w.allan@intel.com \
--cc=carolyn.wyborny@intel.com \
--cc=davem@davemloft.net \
--cc=donald.c.skidmore@intel.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=gregory.v.rose@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=tushar.n.dave@intel.com \
--cc=xen-devel@lists.xenproject.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.