Re: Call for testing: Xen 4.0

-Dustin

On Fri, Jun 4, 2010 at 2:43 AM, Mick Russom <mickrussom%gmail.com@localhost> wrote:

Update on the instant-reboot issue with Xen4.

I was able to configure grub to boot Xen4 + netbsd-XEN3_DOM0 on a usb device. This hinted at two problems: Xen332 worked ok, but Xen4 has an issue with mboot.c32 (syslinux) and the bootloaders in mdec.

So if you are currently stuck not booting Xen4 you may get further with a grub-enabled USB device.

Next is the hang that occurs on the Intel Westmere/Greencity platform (12 cores, 24 threads). Regular netbsd 5.99.29 runs fine, but DOM0 on both Xen 3.3.2 and Xen 4 die during the cpu-attach routine.

I'll delve into the bootloader and the DOM0 hanging on cpu-attach on Westmere, any help with people using westmere + xen3 or xen4 + netbsd DOM0 would be handy.

On Thu, Jun 3, 2010 at 1:58 PM, Mick Russom <mickrussom%gmail.com@localhost> wrote:
Ok, on current/5.99.29 now, amd64.

- The gsed/sed thing is gone because strnlen is in head. Confirmed.

- The X11 mess goes away if you specify in mk.conf X11_TYPE=modular, Confirmed working.

- You can't compile Xen4 on a machine with xentools33 installed. Confirmed. Must remove the package if trying to compile xen4 tools. Confirmed, thanks.

- The only other warning comes from compiling qemu-xen-4.
In
xen-hooks.mak:56: === pciutils-dev package not found - missing /usr/include/pci
xen-hooks.mak === pciutils-dev package not found - missing /usr/include/pci

Even if you try and fix this numerous ways there is conflicts between pciutils and pci.h on netbsd. Not a major issue as this is for qemu only and shouldnt affect dom0/domU kernels.

Finally, the problem that still persists. I cannot boot xen4 + netbsd-XEN3_DOM0 , it loads both then suddenly after seemingly finished loading netbsd-XEN3_DOM0, reboots.

No (XEN) outputs, not nothing from the hypervisor. Its stuck at this multiboot loading section it seems.

Any help getting just Xen to load would be greatly appreciated.

On Wed, Jun 2, 2010 at 9:44 AM, Toby Karyadi <toby.karyadi%gmail.com@localhost> wrote:

On 5/27/2010, "Mick Russom" <mickrussom%gmail.com@localhost> wrote:

>6A) gsed is needed
>
>( I used a dirty hack of aliasing sed to gsed, solved the problem with
>
>-Ttext $(RELOC) -o
>
>RELOC is set in xen/arch/x86/boot/Makefile to $(BOOT_TRAMPOLINE), which is
>also set in that file:
>
>BOOT_TRAMPOLINE := $(shell sed -n
>'s,^\#define[[:space:]]\+BOOT_TRAMPOLINE[[:space:]]\+,,p'
>$(BASEDIR)/include/asm-x86/config.h)

This has been fixed in the latest version in the mercurial repositories.
No need for gsed.

>6B) second but, strnlen is needed by a considerable number of the utilities:

netbsd HEAD branch has strnlen, so at least it's not a problem with
netbsd HEAD.

>6C) Horrible X11 linking mess for building

I didn't encounter this, but I'm using HEAD, and I don't have an X
server, but I have specifIed X11_TYPE=modular in /etc/mk.conf

>6D) FATAL:
>
>-msse2: not found
>
>cc1: warnings being treated as errors
>
>xen/lowlevel/xc/xc.c: In function 'pyxc_vcpu_setaffinity':

Okay, this is due to the fact that you have xentools33 and make
dist-tools incorrectly uses the 3.3 version of the python Xen headers
instead. I just moved the xen related stuff from /usr/pkg/lnclude to
some other directory and it compiled fine.

>FATAL:
>
>Xen4.0.0 crashes when loading the netbsd XEN3_DOM0 kernel. It doesn't even
>give a (XEN) output or stop and panic. It simply reboots the machine while
>loading netbsd from mboot.c32.
>

I think I have a similar problem. When I use the /usr/mdec/boot 5.2,
which comes with netbsd 5.0 and do 'multiboot xen40.gz' from boot
command line, I would very briefly see the progress number of bytes
loaded and then the screen went blank for a short time. Afterwards the
computer just reboots.

If you try 'multiboot xen.gz' (from xenkernel33) you would get some
additional messages and the computer will halt and report that no dom0
kernel was specified. Is this a problem of grub vs multiboot?

Christoph, did you see this as well?

Thanks,
Toby