WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Windows Bug Check 0x101 issue

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Windows Bug Check 0x101 issue
From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Mar 2008 16:30:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Kouya Shimura <kouya@xxxxxxxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Thu, 27 Mar 2008 09:48:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18411.52353.526441.433440@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903
References: <7k4pawfnxs.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <C40D3B88.15566%keir.fraser@xxxxxxxxxxxxx> <7k1w5zf50j.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <18408.57824.846687.465435@xxxxxxxxxxxxxxxxxxxxxxxx> <20080325175718.GT4411@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7ky786dkup.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <18410.9596.488204.878357@xxxxxxxxxxxxxxxxxxxxxxxx> <7ktziseo9r.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20080327090831.2a9f9b05@core> <18411.52353.526441.433440@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> having decided to violate it, perhaps the right answer is to make the
> disk simply vanish: ignore all future command writes, zero all of the
> registers that the host is attempting to read, not issue an interrupt,
> and somehow discard the responses from any overlapped IO which is in
> flight.

I think it is safest - and if the underlying storage fails something bad
has happened and anything else we do would make it worse
> 
> Is that what you meant by `offline the virtual device' ?

Just leave the busy bit set forever, the host will get fed up of waiting,
reset, rinse repeat a few times and (except for older Linux) then offline
the device. Older Linux (ie drivers/ide) has problems coping with failed
drives so will carry on spewing but limp along ok.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel