On Wed, Jan 31, 2007 at 01:50:48PM +1100, Daniel Carosone wrote:
> On Sun, Jan 28, 2007 at 06:50:43PM +0100, Manuel Bouyer wrote:
> > On Wed, Jan 24, 2007 at 09:28:14AM +1100, Daniel Carosone wrote:
> > > On Mon, Jan 22, 2007 at 11:17:55AM +0100, Manuel Bouyer wrote:
> > > > > Just one:
> > > > > 
> > > > >   _xen_alloc_contig low 0 high fffff000 address_bits 32
> > > > 
> > > > That's surprising, I would have expected high to be 0x3fffffff or 0x40000000
> > > 
> > > 
> > > However, if I use larger dom0_mem, I do get output with high at
> > > 0x40000000 as you predicted --- and immediately after that, a panic
> > > "HYPERVISOR_mmu_update failed".
> > > 
> > sorry for the delay replying to this
> > Did you have time to get a stack trace ? Also, is your kernel configured
> > with options DEBUG ?
> 
> I have a backtrace. Sorry, the most useful form I could capture it in
> was as pictures of the screen, dust and reflections and all.  No
> serial ports on this laptop for console, and a very glossy reflective
> screen..
> 
>   ftp.n.o:~dan/imgp3*.jpg
> 
> No DEBUG in this kernel at the moment, I can add it.

OK, I found some time to look at this again. After several unsucessfull
experiements I ended up looking at the xen sources, and found that the
minimum allowed "address_bits" is hardcoded to 31 (2GB). So with a stock
Xen kernel it's not possible to get bce working reliably under Xen :(
(This value seems to come from a restriction on aac devices, from what I
found in comments).

I you want to run Xen on this system I should be able to build a xen kernel
which allows "address_bits" to be 30 instead of 31. It's not possible
to fix it to allow any value for address_bits without rewriting the
Xen memory allocator :(

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--