Re: does i386 still work?

["Mathew\, Cherry G.*" <c%bow.st@localhost>]

>>>>> Greg Troxel <gdt%lexort.com@localhost> writes:

    > "Mathew, Cherry G.*" <c%bow.st@localhost> writes:
    >>>>>>> Greg Troxel <gdt%lexort.com@localhost> writes:
    >> 
    >> 
    >> [...]
    >> 
    >> 
    >> > Thanks.  After disabling autoballoon (for dom0), checking
    >> things > over, rebooting the dom0, and trying again, it worked
    >> normally.
    >> 
    >> Would you know if this is to do with the domU (balloon(4)) or
    >> something else ? ie; does the boot dmesg give any indication
    >> about when the hang occurs ?

    > The hang is just before the root filesystem should be accessed.

    > The autoballoon that I changed was only supposed to change dom0
    > behavior.  As documented, if dom0 memory is not explicitly
    > configured (so it should get all), then if you start a domU, the
    > needed memory is obtained from dom0 via the balloon driver which
    > presumably allocates RAM and promises not to use it, passing the
    > dom0 addrs back so that the hypervisor can treat those pages as
    > freed.  But that's me guessing.

    > I have 8 GB, and had been booting with:

    >   menu=Xen:load /netbsd-XEN3_DOM0.gz root=wd0a
    > rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz
    > dom0_mem=4096M

    > so autoballoon should not be happening, but it was and my dom0
    > went down to 2GB.  This and zfs do not play well, but that's a
    > rant for another day.

    > So I set:

    >   autoballoon="off"

    > which indeed caused dom0 RAM not to get taken.

    > I was observing the domU starting fine, memory/CPU ok, probing
    > devices included xennet and xbd and failing later.  So I'm pretty
    > sure the autoballoon change is unrelated.

Okay thanks - was just wondering what could be bothering the balloon
codepath.

-- 
~cherry