qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Scott Tsai <scottt.tw@gmail.com>
To: qemu-devel@nongnu.org
Cc: markmc@redhat.com, Sven_Rudolph@drewag.de
Subject: [Qemu-devel] qemu: async sending in tap causes "NFS not responding" error
Date: Sun, 25 Oct 2009 02:12:31 +0800	[thread overview]
Message-ID: <ef2f888d0910241112h61102320pd3dba0bb6693a7c3@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Dear all,

I recently found that this chageset:
http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=e19eb22486f258a421108ac22b8380a4e2f16b97
"net: make use of async packet sending API in tap client"
causes NFS root Linux guest setups using TAP networking to fail with
error messages like:
nfs: server 172.20.0.1 not responding, still trying
nfs: server 172.20.0.1 OK
< .... repeat infinitely ...>
This happens on both the "master" and "stable-0.11" branches on qemu.

The attached '0001-net-revert-e19eb22486f258a421108ac22b8380a4e2f16b97.patch'
makes NFS root on qemu emulated "arm-integrator-cp" boards work for me
again.

I've uploaded wireshark captures of qemu-0.10(good, nfsroot works) and
qemu-0.11(bad) here:
http://scottt.tw/bug/qemu-async-tap-drops-packets/qemu-nfsroot-good.pcap
http://scottt.tw/bug/qemu-async-tap-drops-packets/qemu-nfsroot-bad.pcap

Inspecting frame 268 in "qemu-nfsroot-bad.pcap", I see:
"ICMP Fragment reassembly time exceeded", reply to request in frame
53, duplicate to the reply in frame 56
and suspect qemu is dropping ethernet frames from larger, fragmented
IP packets used for NFS READ replies.

After finding:
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01173.html
through Google and reading through the potentially bad commits that
Sven found through bisection,
I patched "tap_send()" to not run in a loop ("drain the tap send queue
in one go"?) and the error goes away.

To reproduce this, download "zImage", "scripts/" and "trigger-bug" from:
http://scottt.tw/bug/qemu-async-tap-drops-packets/
and run the "trigger-bug" script

I've only just started reading
linux/Documentation/networking/tuntap.txt after encountering this
problem and currently find the code
called from "tap_send()" ex: qemu_send_packet_async,
qemu_deliver_packet and the semantics of their return values pretty
confusing.
I'm sure my patch should be refined to both make both NFS root and the
originally intended optimization work.

[-- Attachment #2: 0001-net-revert-e19eb22486f258a421108ac22b8380a4e2f16b97.patch --]
[-- Type: text/x-patch, Size: 1099 bytes --]

From ffde3feb1922c1d5663ace9d5a32eacaa26491dd Mon Sep 17 00:00:00 2001
From: Scott Tsai <scottt.tw@gmail.com>
Date: Sun, 25 Oct 2009 01:52:36 +0800
Subject: [PATCH] net: revert e19eb22486f258a421108ac22b8380a4e2f16b97 to fix nfsroot

---
 net.c |   19 ++++++++-----------
 1 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/net.c b/net.c
index 4708080..39dcd04 100644
--- a/net.c
+++ b/net.c
@@ -1357,17 +1357,14 @@ static void tap_send(void *opaque)
     TAPState *s = opaque;
     int size;
 
-    do {
-        size = tap_read_packet(s->fd, s->buf, sizeof(s->buf));
-        if (size <= 0) {
-            break;
-        }
-
-        size = qemu_send_packet_async(s->vc, s->buf, size, tap_send_completed);
-        if (size == 0) {
-            tap_read_poll(s, 0);
-        }
-    } while (size > 0);
+    size = tap_read_packet(s->fd, s->buf, sizeof(s->buf));
+    if (size <= 0) {
+        return;
+    }
+    size = qemu_send_packet_async(s->vc, s->buf, size, tap_send_completed);
+    if (size == 0) {
+        tap_read_poll(s, 0);
+    }
 }
 
 #ifdef TUNSETSNDBUF
-- 
1.6.2.5


             reply	other threads:[~2009-10-24 18:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-24 18:12 Scott Tsai [this message]
2009-10-26 13:21 ` [Qemu-devel] Re: qemu: async sending in tap causes "NFS not responding" error Sven Rudolph

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=ef2f888d0910241112h61102320pd3dba0bb6693a7c3@mail.gmail.com \
    --to=scottt.tw@gmail.com \
    --cc=Sven_Rudolph@drewag.de \
    --cc=markmc@redhat.com \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).