From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4wTu-0005bQ-1q for qemu-devel@nongnu.org; Thu, 01 Aug 2013 13:16:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V4wTm-0005ho-Od for qemu-devel@nongnu.org; Thu, 01 Aug 2013 13:16:05 -0400 Received: from thoth.sbs.de ([192.35.17.2]:20853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4wTm-0005hV-F4 for qemu-devel@nongnu.org; Thu, 01 Aug 2013 13:15:58 -0400 Message-ID: <51FA97CA.7050905@siemens.com> Date: Thu, 01 Aug 2013 19:15:54 +0200 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] net/tap.c: Possibly a way to stall tap input List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel , Stefan Hajnoczi Hi all, I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU version. Under certain load, our tap backend stops reading from the char device, and that even if we reset the guest. The frontend device (pcnet32) is able to receive (can_receive would return > 0), but the tap's fd is no longer registered with the iohandler list. I was digging into the involved code and found something fishy: net/tap.c: static void tap_send(void *opaque) { ... size = qemu_send_packet_async(&s->nc, buf, size, tap_send_completed); if (size == 0) { tap_read_poll(s, false); } So, if tap_send is registered for the mainloop polling (ie. can_receive returned true before starting to poll) but qemu_send_packet_async returns 0 now as qemu_can_send_packet/can_receive happens to report false in the meantime, we will disable read polling. If also write polling is off, the fd will be completely removed from the iohandler list. But even if write polling remains on, I wonder what should bring read polling back? We only have an unhandy reproduction scenario, so I wasn't able to confirm this theory on the target yet (and will not be before Monday, unfortunately). But any comments on this would be very welcome. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux