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] Cannot open root device for dom0

To: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Cannot open root device for dom0
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 19:53:28 +0000
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, stevegt@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Jan 2004 19:53:30 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Your message of "Sat, 17 Jan 2004 11:32:30 GMT." <E1Ahogq-0006D9-00@xxxxxxxxxxxxxxxxxxxx>
> Indeed; in more detail, the modprobe happened because major device 3 (ide0) 
> was not registered with the blkdev layer; and this happened because 
> something was screwed in the xenolinux 'probe' (where at start of day it
> asks Xen about what devices exist, etc). Given that this code has all just
> been rewritten (in Xen) to use red-black trees in place of a hash table so
> that order is deterministic, I reckon that's the culprit. 

So little faith ;-)

> Anyway, that's just for info -- I believe it's fixed now, right?

It is fixed now. The bug had actually been present for a long while --
GCC wasn't being told that memory is "clobbered" across a block_io_op
hypercall. The result is that Xenolinux didn't always pick up updates
to the block_io_op_t struct after the hypercall (It assumed the
initial value it wrote in there before the hypercall was still
valid). 

This bug bit certain versions of GCC in certain situations. Nice!

 -- Keir