A FYI on FreeBSD with Linode:

I seem to have FreeBSD-7.2-RELEASE running happily on Linode after some hackery, however there are some major issues that prevent this from being a genuinely happy solution:

1) 7.3-release had kernel panic on boot
2) 8.0-release had kernel panic on boot
3) 8.0-stable had kernel panic on boot
4) 9.0-current had kernel panic on boot
5) 7.2-release only works in non-SMP mode
6) I haven't cleaned up boot process, so booting the system requires me to manually specify kernel location and root filesystem

I assume with some work on my part, #6 could be overcome. #1-5, however, have me worried. Seems this issue has been reported, but I'm not certain anybody with the Xen knowledge has the time or care to fix it.

The panics generally all happened at HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, &ctxt) early in the kernel boot.

The lack of activity on existing PR's like this one has me concerned about the future of Xen DomU support on FreeBSD:

http://www.freebsd.org/cgi/query-pr.cgi?pr=135069

Edit by Jed: This deserves its own thread.

Someone told me about this post today, and after thinking about it I'm kind of confused.

Stabbing into the dark, but is this a scheduler issue? One notable difference about 7.2 versus earlier 7.x editions is the change to the new 'ULE' scheduler by default, which has been used since (and is used in 8.0).

Also, uh, this bug report is a year old, and about 7 months before 8 was released.

I guess what strikes me as odd about the whole thing is that there are 2-3 xen-based freebsd vps offerings, and they seem to be not-bankrupt.

Scheduler sounds like a possibility, however I noticed after hacking many printf statements into a 8-stable kernel that the panic is caused while trying to bring up the 2nd cpu (cpuid 1).

While I had no luck booting a kernel if I disabled SMP and APIC options, I did manage to get past the kernel panics by changing MAXCPU in sys/i386/include/params.h from 32 to 1, so that the kernel did not attempt to init any additional CPU's. Clearly this is not a "fix" as I would call a kernel using one CPU on a 4-cpu system buggy.

So seemingly by limiting MAXCPU to 1, 8-stable will run on Linode (and quite possibly 7.3-release, 8.0-release, and 9-current).



Frustratingly, NetBSD seems to not only work happily, but even builds on a finnix system, as demonstrated at http://www.linode.com/wiki/index.php/BSD_Howto so people who aren't too picky about which BSD flavor to run have what is likely a far more reliable option in NetBSD.

-stable? yeesh.

ISTR one of the big deals in 8 was also the removal of the GIANT lock, so maybe winding back the clock will get you better results.

Are for 7.x, you using the 7.x patchsets on xensource or just going bare or ?

Doh, I jumped the gun. It was 8.0-RELEASE I had built and booted. Seems 8-stable causes:

panic: HYPERVISOR_update_va_mapping(((unsigned long)(va)), (pa | 0x002 | 0x001 | pgeflag | pmap_cache_bits(mode, 0)), UVMF_INVLPG| UVMF_ALL) < 0: /usr/src/sys/i386/xen/pmap.c:1269

=(

And yes, 7.2 required patches just to build a XEN kernel, as the XEN kernconf wasn't shipped with that release. A friend helped get that built for me, I'll see if I can dig up the details. Sadly I really don't think of 7.2-release as a "solution" at all due to it being outdated at this point, even though it is still getting security patches.