From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9CIm-0005of-Qd for qemu-devel@nongnu.org; Wed, 16 Dec 2015 08:39:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9CIh-0000vQ-OX for qemu-devel@nongnu.org; Wed, 16 Dec 2015 08:39:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9CIh-0000vM-JB for qemu-devel@nongnu.org; Wed, 16 Dec 2015 08:39:27 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 1ABFDC0B933D for ; Wed, 16 Dec 2015 13:39:27 +0000 (UTC) From: Laurent Vivier Date: Wed, 16 Dec 2015 14:39:23 +0100 Message-Id: <1450273165-2367-1-git-send-email-lvivier@redhat.com> Subject: [Qemu-devel] [PATCH 0/2] ohci: try to mimic real hardware command latency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: lvivier@redhat.com, Gerd Hoffmann OHCI linux driver has some critical sections not protected against device interrupts. Because of real hardware latency, it is generally not a problem as interrupts cannot be triggered fast enough to happen during these critical sections. But theoretically, it can happen. And with QEMU used on an overcommitted CPU, the vCPU becomes slow enough and it happens. This series fixes a kernel crash on boot (CPU stuck) when the OHCI driver tries to resume or suspend the device. Laurent Vivier (2): ohci: delay first SOF interrupt ohci: clear pending SOF on suspend hw/usb/hcd-ohci.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) -- 1.8.3.1