From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPE6S-0005ja-S4 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:45:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPE6N-0005h5-Uz for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:45:04 -0500 Received: from [199.232.76.173] (port=44956 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPE6N-0005h0-PD for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:44:59 -0500 Received: from mail.gmx.net ([213.165.64.20]:46304) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LPE6N-0005xm-61 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:44:59 -0500 Message-ID: <4975AB29.40909@gmx.net> Date: Tue, 20 Jan 2009 11:44:57 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error. References: <20090118110509.GG11299@redhat.com> <18804.27240.886522.337700@mariner.uk.xensource.com> <4974A704.3070605@codemonkey.ws> <18804.46780.936806.748045@mariner.uk.xensource.com> <49759870.3050305@redhat.com> <20090120093540.GA27675@redhat.com> In-Reply-To: <20090120093540.GA27675@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 20.01.2009 10:35, Gleb Natapov wrote: > On Tue, Jan 20, 2009 at 10:25:04AM +0100, Gerd Hoffmann wrote: > >> Ian Jackson wrote: >> >>> Anthony Liguori writes ("Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error."): >>> >>>> Ian Jackson wrote: >>>> >>>>> Once again, this feature should be optional. >>>>> >>>> Why? >>>> >>> Well, three reasons, one general and theoretical, and two practical >>> and rather Xen-specific. >>> >>> The theoretical reason is that a guest is in a better postion to deal >>> with the situation because it knows its access patterns. Often the >>> response to a failing write in a mission-critical system will be some >>> kind a fallback behaviour, which is likely to work. Stopping the VM >>> unconditionally is not something that the guest can cope with. >>> >> The fundamental issue is that you can't signal ENOSPC to the guest via >> IDE protocol because that is an error condition which simply can't >> happen on real hardware. You can only signal EIO, which is something >> very different, and the OS likely goes into "Oops, disk broken" mode. >> Which probably isn't what you want here ... >> >> > Windows using IDE retries DMA 3 times and then moves to PIO mode. And it > stays in PIO mode even after reboot. The only way to return to DMA mode > again is to reinstall the driver. > You can fix this in the registry without any reinstallation by setting the bitmask of allowed IDE modes back to 0xffffffff. It's a single value that needs to be changed. http://winhlp.com/node/10 has more info and a script to reset the bitmask. There's also an alternative for automatically resetting the mode after a successful access: http://support.microsoft.com/kb/817472 Regards, Carl-Daniel -- http://www.hailfinger.org/