mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stelian Pop <stelian@popies.net>
To: Matt Mackall <mpm@selenic.com>
Cc: kgdb-bugreport@lists.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 2.6] netpoll: prevent transmission stall
Date: Thu, 8 Apr 2004 12:39:25 +0200	[thread overview]
Message-ID: <20040408103924.GU2718@deep-space-9.dsnet> (raw)

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.

Stelian.

--- net/core/netpoll.c.ORIG	2004-04-06 10:50:05.000000000 +0200
+++ net/core/netpoll.c	2004-04-08 10:41:56.484026496 +0200
@@ -163,21 +163,15 @@
 	spin_lock(&np->dev->xmit_lock);
 	np->dev->xmit_lock_owner = smp_processor_id();
 
-	if (netif_queue_stopped(np->dev)) {
-		np->dev->xmit_lock_owner = -1;
-		spin_unlock(&np->dev->xmit_lock);
-
-		netpoll_poll(np);
-		goto repeat;
-	}
-
 	status = np->dev->hard_start_xmit(skb, np->dev);
 	np->dev->xmit_lock_owner = -1;
 	spin_unlock(&np->dev->xmit_lock);
 
 	/* transmit busy */
-	if(status)
+	if(status) {
+		netpoll_poll(np);
 		goto repeat;
+	}
 }
 
 void netpoll_send_udp(struct netpoll *np, const char *msg, int len)


-- 
Stelian Pop <stelian@popies.net>

             reply	other threads:[~2004-04-08 10:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-08 10:39 Stelian Pop [this message]
2004-04-08 14:06 ` Matt Mackall

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=20040408103924.GU2718@deep-space-9.dsnet \
    --to=stelian@popies.net \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /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