On Mon, 07/06 10:45, Max Filippov wrote: > On Mon, Jul 6, 2015 at 10:36 AM, Fam Zheng <f...@redhat.com> wrote: > > On Mon, 07/06 10:27, Max Filippov wrote: > >> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng <f...@redhat.com> 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
