From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEnI4-0002tP-Rs for qemu-devel@nongnu.org; Thu, 11 Jun 2009 12:38:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEnI0-0002j4-Dt for qemu-devel@nongnu.org; Thu, 11 Jun 2009 12:38:12 -0400 Received: from [199.232.76.173] (port=33768 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEnI0-0002ir-BB for qemu-devel@nongnu.org; Thu, 11 Jun 2009 12:38:08 -0400 Received: from mail2.shareable.org ([80.68.89.115]:52231) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MEnHz-0003M9-Ps for qemu-devel@nongnu.org; Thu, 11 Jun 2009 12:38:08 -0400 Date: Thu, 11 Jun 2009 17:38:03 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Register uhci_reset() callback. Message-ID: <20090611163803.GB12367@shareable.org> References: <20090611084808.GA19508@redhat.com> <200906111441.34151.paul@codesourcery.com> <20090611134656.GC19508@redhat.com> <200906111453.13421.paul@codesourcery.com> <20090611140054.GD19508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090611140054.GD19508@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Paul Brook , qemu-devel@nongnu.org Gleb Natapov wrote: > RHEL4.8 hangs after reboot because usb interrupt is not goes away. This > patch fixes it. Reseting all devices on a system reset is a right thing to do > even if there is no reproducible bug exist. I've got real hardware with this problem! It doesn't reset the USB hardware (with some kinds of reset), and after reset the kernel runs about 100x too slow because it's getting a high rate of USB interrupts, until it loads the USB driver. In the real hardware the solution is to explicitly shut down the USB chip prior to manual reset, and fortunately the watchdog/power-on resets do reset the USB chip anyway. So I definitely support the idea that all components should be reset on a system reset event :-) Now, a CPU-only reset, such as triple fault on x86, that's a bit different. -- Jamie