[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] HVMAssist BIOS 32 GB Barrier


  • To: "Tomas Florian" <tomas@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.