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] HVMAssist BIOS 32 GB Barrier

To: "Tomas Florian" <tomas@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] HVMAssist BIOS 32 GB Barrier
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Tue, 4 Apr 2006 15:03:37 +0200
Delivery-date: Tue, 04 Apr 2006 07:21:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZXV02VfA/nyfv+RXG/i6xFTaJwpQAjy68g
Thread-topic: [Xen-devel] HVMAssist BIOS 32 GB Barrier
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Tomas Florian
> Sent: 03 April 2006 20:43
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] HVMAssist BIOS 32 GB Barrier
> 
> Hello,
> 
> I'm trying to run a HVM guest with a hard drive > 33.8 GB and 
> it says it works, but as soon as I start writing data to it I 
> get hundreds of:
> 
> EXT3-fs error (device ide0(3,65)): ext3_new_block: Allocating 
> block in system zone - block = 8257846
> 
> and after a few minutes the hard drive corrupts itself (even 
> superblock
> lost)
> Looking at the qemu-dm.log file I can see that no matter what 
> size of disk I use I get:
> 
> HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $
> ata0-0: PCHS=5952/16/63 translation=lba LCHS=744/128/63 ata0 
> master: QEMU HARDDISK ATA-2 Hard-Disk (2929 MBytes)
> *ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 
> ata0  slave: QEMU HARDDISK ATA-2 Hard-Disk (32120 MBytes)
> *

It looks like the BIOS doesn't suport LBA mode for more than 1024/255/63
- which is not unexpected. 

You may be able to work out why by looking at the source in
.../tools/firmware/rombios/rombios.c

Of course, you'll also have to figure out what the protocol is for
supporting > 32GB disks, which I don't know anything about, so I can't
help you there.

> 
> This looks to me like the BIOS has some kind of a barrier on it.  Is 
> there a way to overcome this barrier?   I'm using the xen0-3.0.1-4 
> package from FC5.  Would an upgrade to the newest changeset 
> help? And on 
> a more general note?   What will give me more stability 
> (among all the 
> unstable) ... a released rpm like the one from FC5 or the 
> newest latest 
> changeset from the unstable branch?   Even the 3.0.1-4 rpm is 
> from the 
> unstable branch in the end ...right?

Everything that gets released will have been in the unstable branch at
some previous point in time. The difference is that just prior to a
release, there is a freeze on patches that aren't ACTUALLY fixing broken
bits - such as feature changes, improvements to performance, or "I found
a different way to do this and I like it to be part of the code". So,
the 3.0.1-4 is a release based on the code in the 3.0.1 release [at
least I presume so from the name, but of course, I don't work for
RedHat]. RedHat presumably has done SOME SORT of testing on the RPM they
release - but of course, if you're not doing the same thing that RedHat
has tested, that's not really any better than something untested -
except it's unlikely to fail to start trivial things... Being able to
run a web-browser does not really prove that you can run Oracle or DB/2
on a machine, but not being able to run the web-browser pretty much
ensures that much other software will ALSO not work, if you see what I
mean.

As to the stability of the unstable tree it varies greatly - some days
it works a charm, and other days you can't even start a simple guest. Of
coruse, supposedly there is a "release-test" where each new patch that
gets introduced into the tree is tested through some automatic tests.
But it's still true to say that, particularly HVM, is broken every now
and again - you can check the test-results from David Barrera, Rick
Gonzales and Alex Shi to see what they say about a certain changeset -
if things aren't too bad, then that's probably a good changeset to go
for... But unstable IS that - it's new changes every day, sometimes as
many as 50 or 80 - which means that things break from time to time. 

Testing is the next level up in stability, where only fixes for reported
bugs are being added... That may be a better choice if you're not into
hacking the Xen Hypervisor... 

> 
> In the end I'll probably mount NFS and deal with the limit 
> that way ... 
> but it would be nice to do it properly

That may work quite well, I would think... 

--
Mats
> 
> Thank you,
> Tomas
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 


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

<Prev in Thread] Current Thread [Next in Thread>