From: Matt Mackall <mpm@selenic.com>
To: Stelian Pop <stelian@popies.net>,
kgdb-bugreport@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2.6] netpoll: prevent transmission stall
Date: Thu, 8 Apr 2004 09:06:33 -0500 [thread overview]
Message-ID: <20040408140633.GA6248@waste.org> (raw)
In-Reply-To: <20040408103924.GU2718@deep-space-9.dsnet>
On Thu, Apr 08, 2004 at 12:39:25PM +0200, Stelian Pop wrote:
> While working on kgdb over netpoll I found out another bug in
> netpoll.
>
> This one is in netpoll_send_skb(), and it is triggered by
> sending repeatedly more packets than the transmit buffers the
> ethernet card has, while being in the netpoll_trap. (this is
> rapidly triggered by kgdb when using a card with limited
> transmit buffers, like my pcmcia NE2000).
>
> One should poll() the ethernet card interrupt function in order
> to get the transmit acks from the card and free the transmit
> buffers in order to be able to transmit more packets.
>
> This is why in the original code, netpoll_send_skb() calls
> netpoll_poll() if dev->hard_start_xmit() fails. However, this
> does not work because netpoll_poll() is called only if
> netif_queue_stopped(). But the net queue functions are overridden
> if netpoll_trap() is on, causing netif_queue_stopped() to never
> return true.
>
> The attached patch 'fixes' this, by forcing a netpoll_poll()
> every time dev->hard_start_xmit() fails. Maybe there is a cleaner
> way to do this by making the queue functions work even under
> netpoll_trap, but it shouldn't really be necessary, I cannot
> see how forcing the netpoll_poll() call could break anything.
Ok, makes sense. I'll queue this up.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
prev parent reply other threads:[~2004-04-08 14:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-08 10:39 [PATCH 2.6] netpoll: prevent transmission stall Stelian Pop
2004-04-08 14:06 ` Matt Mackall [this message]
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=20040408140633.GA6248@waste.org \
--to=mpm@selenic.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stelian@popies.net \
/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.