From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGu1T-0004dJ-RA for qemu-devel@nongnu.org; Wed, 06 Jan 2016 14:45:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGu1Q-00081W-Lc for qemu-devel@nongnu.org; Wed, 06 Jan 2016 14:45:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGu1Q-00080t-G9 for qemu-devel@nongnu.org; Wed, 06 Jan 2016 14:45:28 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 99BC8C0798E2 for ; Wed, 6 Jan 2016 19:45:27 +0000 (UTC) From: Laurent Vivier Date: Wed, 6 Jan 2016 20:45:23 +0100 Message-Id: <1452109525-32150-1-git-send-email-lvivier@redhat.com> Subject: [Qemu-devel] [PATCH v2 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, thuth@redhat.com, kraxel@redhat.com 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. v2: Address comments from Thomas update code comments split ohci_sof() to add ohci_eof_timer() Laurent Vivier (2): ohci: delay first SOF interrupt ohci: clear pending SOF on suspend hw/usb/hcd-ohci.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) -- 1.8.3.1