From patchwork Tue Apr 2 08:53:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Crosthwaite X-Patchwork-Id: 233108 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DBCBF2C00A8 for ; Wed, 3 Apr 2013 05:00:17 +1100 (EST) Received: from localhost ([::1]:42044 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN5VI-0001yI-4J for incoming@patchwork.ozlabs.org; Tue, 02 Apr 2013 14:00:16 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMwyI-0000Cu-TZ for qemu-devel@nongnu.org; Tue, 02 Apr 2013 04:53:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMwyE-0008EW-QZ for qemu-devel@nongnu.org; Tue, 02 Apr 2013 04:53:38 -0400 Received: from mail-pd0-f172.google.com ([209.85.192.172]:62898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMwyE-0008E7-KS for qemu-devel@nongnu.org; Tue, 02 Apr 2013 04:53:34 -0400 Received: by mail-pd0-f172.google.com with SMTP id 5so125844pdd.17 for ; Tue, 02 Apr 2013 01:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer; bh=b5v55nUm5UlLZSJrGTf5PG+Q99suwcWvrUqbizs32dE=; b=KWJvRD7sak9QdNdmp1R8V+HZKAs759uc+TUdvZtimS7LCw+BbERDW/23lU/eZPzFup LNTxbVkQ9nHKXuFSh+8Hu0sPr1tXRlaF/WKT/SitE5geeiZl/m3ySmBUuKO/nSlEGGCB xod/c3M+4S1JJsvK0ADoG+suuQSJKSyiHW5ubpShZEOdi6ic23dgSCZaPKK+myOmru6/ 2ymGhdc4NAdBCPNhm1rbWqo3+/9neBYh+lGow+9qzYoulN4xhsHt+w7X3kv1IdvqN8DA x6K355zQ/zXzzvbLabm/ouS7Uf0PcUMqQxzt0xwBrzk5kSuZcaw9u96FkmRDkrfv5cKu v2tw== X-Received: by 10.68.129.9 with SMTP id ns9mr23410532pbb.16.1364892813367; Tue, 02 Apr 2013 01:53:33 -0700 (PDT) Received: from localhost ([149.199.62.254]) by mx.google.com with ESMTPS id jz5sm118445pbc.26.2013.04.02.01.53.31 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 01:53:32 -0700 (PDT) From: Peter Crosthwaite To: qemu-devel@nongnu.org Date: Tue, 2 Apr 2013 18:53:13 +1000 Message-Id: <1364892793-10237-1-git-send-email-peter.crosthwaite@xilinx.com> X-Mailer: git-send-email 1.7.0.4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.192.172 X-Mailman-Approved-At: Tue, 02 Apr 2013 13:59:49 -0400 Cc: aliguori@us.ibm.com, aurelien@aurel32.net, gson@gson.org Subject: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Public bug: 1154328 Broken Commit: a29753f8aa79a34a324afebe340182a51a5aef11 ATM, the timeout from g_pollfds_fill is inhibiting unlocking of the iothread. This is capable of causing a total deadlock when hw/serial is used as a device. The bug manifests when you go -nographic -serial mon:stdio and then paste 40 or more chars into the terminal. My knowledge of this g_foo is vague at best, but my best working theory is this: - First 8 chars are recieved by the serial device no complaints. - The next 32 chars, serial returns false for can_receive() so they are buffered by the MuxDriver object - mux_chr_read() - Buffer is full, so 41st char causes false return from Muxes own can_read() - This propagates all the way up to glib_pollfds_fill and manifests as a timeout - Timeout means no unlock of IOthread. Device land never sees any more cycles so the serial port never progresses - no flushing of buffer - Deadlock Tested on petalogix_ml605 microblazeel machine model, which was faulty due to 1154328. Fix by removing the conditions on unlocking the iothread. Don't know what else this will break but the timeout is certainly the wrong condition for the unlock. Probably the real solution is to have a more selective unlock policy. I'm happy for someone to take this patch off my hands, or educate me on the correct implementation. For the peeps doing automated testing on nographic platforms this will get your build working again. Signed-off-by: Peter Crosthwaite --- main-loop.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/main-loop.c b/main-loop.c index eb80ff3..a376898 100644 --- a/main-loop.c +++ b/main-loop.c @@ -194,15 +194,11 @@ static int os_host_main_loop_wait(uint32_t timeout) glib_pollfds_fill(&timeout); - if (timeout > 0) { - qemu_mutex_unlock_iothread(); - } + qemu_mutex_unlock_iothread(); ret = g_poll((GPollFD *)gpollfds->data, gpollfds->len, timeout); - if (timeout > 0) { - qemu_mutex_lock_iothread(); - } + qemu_mutex_lock_iothread(); glib_pollfds_poll(); return ret;