From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC1HR-0000Gx-FI for qemu-devel@nongnu.org; Mon, 06 Jul 2015 03:57:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZC1HM-0002CU-Gl for qemu-devel@nongnu.org; Mon, 06 Jul 2015 03:57:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC1HM-0002Ar-Ak for qemu-devel@nongnu.org; Mon, 06 Jul 2015 03:57:28 -0400 Date: Mon, 6 Jul 2015 15:57:24 +0800 From: Fam Zheng Message-ID: <20150706075724.GE9051@ad.nay.redhat.com> References: <20150706015557.GA8444@ad.nay.redhat.com> <20150706073618.GC9051@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] TAP network breaks after debugger break-in List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Filippov Cc: qemu-devel , Stefan Hajnoczi On Mon, 07/06 10:45, Max Filippov wrote: > On Mon, Jul 6, 2015 at 10:36 AM, Fam Zheng wrote: > > On Mon, 07/06 10:27, Max Filippov wrote: > >> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng wrote: > >> > On Sat, 07/04 10:47, Max Filippov wrote: > >> >> Hello, > >> >> > >> >> I'm using QEMU with TAP network and after the commit > >> >> 0a2df857a703 "Merge remote-tracking branch > >> >> 'remotes/stefanha/tags/net-pull-request' into staging" > >> >> I've noticed that activation of debugger connected to QEMU's > >> >> gdbstub during network I/O almost always breaks network > >> >> connection: network stops working completely after return > >> >> from the debugger. > >> >> > >> >> Stefan, Fam, any hint on where to start debugging it? > >> >> > >> > > >> > Which NIC are you using? > >> > >> opencores_eth. > >> > > > > Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work? > > Looks like it does, though the revert isn't clean. I can't really tell what happened to opencores_eth because it has proper open_eth_notify_can_receive() calls that should flush the queue as expected since a90a7425cf592a3afeff3eaf32f543b83050ee5c (some other NICs are broken because of missing such flushes). FWIW, what is changed by that patch is that if NIC's .can_receive() callback returns 0, it should later call qemu_flush_queued_packets() explicitly, when conditions becomes ready again (i.e. .can_receive() would return true on next invocation). Fam