FreeBSD/Xen ugliness

FreeBSD/Xen ugliness

[Derrik Pates]

All:

I have still not, as yet, been able to get FreeBSD/Xen to actually work. 
It still hangs partway through the kernel boot process. I thought I'd 
try to do a build, but unfortunately the instructions which are provided 
in http://www.bsdclusters.com/xenofreebsd/xenbsdsetup.txt don't work at 
all. I've run across the following so far:

   - Couldn't get BitKeeper to work at all on FreeBSD (complains about 
not being licensed?) - was able to work around this by using BitKeeper 
on my PowerBook running Debian.
   - The directory that's supposed to be symlinked from the Xen source 
tree _does not exist_. I borrowed the matching files from the NetBSD/Xen 
source tree.
   - Had to hand-edit several of the copied headers, so they'd include 
files on the right paths.
   - There is no 'make kernel-depend'. Doing 'make depend' finally sort 
of worked, until it got to dependency generation for the AIC7xxx 
drivers, at which point it tried to pull in something nonexistant and 
bombed.

Has _anyone_ successfully used FreeBSD/Xen? I tried e-mailing Kip Macy 
directly, but have gotten no response as yet. If this doesn't work, 
that's fine; however, FreeBSD is not scoring big points with me today, 
as it seems to be giving me fits in assorted ways today. If anyone has 
anything to say at all, it'd be appreciated.

-- 
Derrik Pates
dpates@dsdk12.net


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

On Thu, 6 Jan 2005, Derrik Pates wrote:

> All:
>
> I have still not, as yet, been able to get FreeBSD/Xen to actually work.
> It still hangs partway through the kernel boot process. I thought I'd
> try to do a build, but unfortunately the instructions which are provided
> in http://www.bsdclusters.com/xenofreebsd/xenbsdsetup.txt don't work at
> all. I've run across the following so far:
>
>    - Couldn't get BitKeeper to work at all on FreeBSD (complains about
> not being licensed?) - was able to work around this by using BitKeeper
> on my PowerBook running Debian.

I should have used the openlogging version of bitkeeper on the
repository. I'll try re-importing the files into a new repository.


>    - The directory that's supposed to be symlinked from the Xen source
> tree _does not exist_. I borrowed the matching files from the NetBSD/Xen
> source tree.

You're probably using a newer version of xen then I was. I only promised
that it work on the version that I was using.


>    - Had to hand-edit several of the copied headers, so they'd include
> files on the right paths.

See above.

>    - There is no 'make kernel-depend'. Doing 'make depend' finally sort
> of worked, until it got to dependency generation for the AIC7xxx
> drivers, at which point it tried to pull in something nonexistant and
> bombed.

This doesn't sound correct - make kernel-depend has always worked for
me. However, I have only built on 5.1 and 5.2.1.


>
> Has _anyone_ successfully used FreeBSD/Xen? I tried e-mailing Kip Macy
> directly, but have gotten no response as yet. If this doesn't work,
> that's fine; however, FreeBSD is not scoring big points with me today,
> as it seems to be giving me fits in assorted ways today. If anyone has
> anything to say at all, it'd be appreciated.

I understand your frustration, having been in the same position dozens
of times before when using "free" open source software (it is only truly
free if your time is free). Nonetheless, there are numerous other
things going on in my life that frequently take priority.

I'm going to try and build FreeBSD against xen-2.0-testing.bk.




				-Kip


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Derrik Pates]

Kip Macy wrote:
> You're probably using a newer version of xen then I was. I only promised
> that it work on the version that I was using.

I'm using the 2.0.2 source, though the directory doesn't exist in 2.0.1 
either.

> This doesn't sound correct - make kernel-depend has always worked for
> me. However, I have only built on 5.1 and 5.2.1.

I tried 'make kernel-depend' under sys-5.2.1/ and 
sys-5.2.1/i386-xeno/compile/XENCONF; I got the "no target by that name" 
message in both cases. I tried to follow your directions, but it was 
difficult since things started diverging about halfway through.

> I understand your frustration, having been in the same position dozens
> of times before when using "free" open source software (it is only truly
> free if your time is free). Nonetheless, there are numerous other
> things going on in my life that frequently take priority.

Understood, but I can't seem to find anyone who can say for sure it even 
works; I thought I'd be able to build it, and no dice. I've been dealing 
with another (unrelated) FreeBSD annoyance, as well, and it's getting to 
me. I'm just generally irritated today, don't take it too personally. :)

> I'm going to try and build FreeBSD against xen-2.0-testing.bk.

If that works, will this prohibit it from playing nice with Xen 2.0.2?

-- 
Derrik Pates
dpates@dsdk12.net


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

> I tried 'make kernel-depend' under sys-5.2.1/ and
> sys-5.2.1/i386-xeno/compile/XENCONF; I got the "no target by that name"
> message in both cases. I tried to follow your directions, but it was
> difficult since things started diverging about halfway through.

I don't understand that. All I can do is try and start more or less from
scratch in my environment.

> Understood, but I can't seem to find anyone who can say for sure it even
> works; I thought I'd be able to build it, and no dice. I've been dealing

I can say for sure that it works in my environment. It is inevitable
that I have some undocumented assumptions. If you have the spare cycles
to work with me, I'll do what I can, time permitting, to make it work in
yours.

> with another (unrelated) FreeBSD annoyance, as well, and it's getting to
> me. I'm just generally irritated today, don't take it too personally. :)

I understand. I've dropped it several times in the past when things
simply required too much handholding to get working. From my experience,
*all* operating systems are perpetually in beta.

I've gotten a commitment from O'Brien to help me with getting the port
into FreeBSD's CVS. However, with the zillions of ports that he
maintains, I don't know how much time he is going to have - so it might
take a while.


> > I'm going to try and build FreeBSD against xen-2.0-testing.bk.
>
> If that works, will this prohibit it from playing nice with Xen 2.0.2?

Well, I'd like to see it work with all three trees (xen-2.0.bk,
xen-2.0-testing.bk, and xeno-unstable.bk). 2.0-testing just seems like a
good place to start.

				-Kip


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Ian Pratt]

> > > I'm going to try and build FreeBSD against xen-2.0-testing.bk.
> >
> > If that works, will this prohibit it from playing nice with Xen 2.0.2?
> 
> Well, I'd like to see it work with all three trees (xen-2.0.bk,
> xen-2.0-testing.bk, and xeno-unstable.bk). 2.0-testing just seems like a
> good place to start.

The hypervisor API should be identical between 2.0-testing.bk and
2.0.bk

The API has changed in the unstable series to allow SMP guests.

Ian


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Derrik Pates]

Kip:

Well, I have good news; thanks to Darren Tucker pointing out that the 
boot.netif.* parameters _have_ to be added, I was able to successfully 
boot your FreeBSD/Xen kernel. It seems to work okay so far. It fairly 
regularly (every few minutes or so) spits out a line like:

Expensive timeout(9) function: 0xc00b0bd0(0) 0.010000854 s

at me, but it seems to otherwise behave as FreeBSD should. The only 
thing I've noticed so far is that, looking at the output of 'xm list', 
its domain's virtual-time clock seems to grow at a constant rate. I'm 
guessing this means it doesn't call up to the hypervisor and say "Please 
schedule someone else, I'm idle right now" when it has nothing to do. It 
doesn't seem to affect the performance of other domains though, but I 
thought it worth pointing out. Unfortunately, I don't know enough about 
FreeBSD's scheduler to make the necessary changes to make this work as 
it should. I'll have to see about getting a proper full CVS pull of the 
sys/ tree for 5.2.1 on my FreeBSD install in VMware, and see if I can 
make a FreeBSD kernel build work; however, I'd like to see the 5.3 
kernel when you get around to it.

-- 
Derrik Pates
dpates@dsdk12.net


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

I've seen the same timing issues. We do call yield where appropriate:

static void
cpu_idle_default(void)
{
#if 0
        /*
         * we must absolutely guarentee that hlt is the
         * absolute next instruction after sti or we
         * introduce a timing window.
         */
        __asm __volatile("sti; hlt");
#endif
        enable_intr();
        HYPERVISOR_yield();
}


So I'm not sure what the problem is. After the 5.3 work and coredump is
done I might look into it. There may have been some fixes to the clock
code in the meantime.


				-Kip


On Sat, 8 Jan 2005, Derrik Pates wrote:

> Kip:
>
> Well, I have good news; thanks to Darren Tucker pointing out that the
> boot.netif.* parameters _have_ to be added, I was able to successfully
> boot your FreeBSD/Xen kernel. It seems to work okay so far. It fairly
> regularly (every few minutes or so) spits out a line like:
>
> Expensive timeout(9) function: 0xc00b0bd0(0) 0.010000854 s
>
> at me, but it seems to otherwise behave as FreeBSD should. The only
> thing I've noticed so far is that, looking at the output of 'xm list',
> its domain's virtual-time clock seems to grow at a constant rate. I'm
> guessing this means it doesn't call up to the hypervisor and say "Please
> schedule someone else, I'm idle right now" when it has nothing to do. It
> doesn't seem to affect the performance of other domains though, but I
> thought it worth pointing out. Unfortunately, I don't know enough about
> FreeBSD's scheduler to make the necessary changes to make this work as
> it should. I'll have to see about getting a proper full CVS pull of the
> sys/ tree for 5.2.1 on my FreeBSD install in VMware, and see if I can
> make a FreeBSD kernel build work; however, I'd like to see the 5.3
> kernel when you get around to it.
>
> --
> Derrik Pates
> dpates@dsdk12.net
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Keir Fraser]

Kip,

You need to block rather than yield -- if noone else is runnable and
you call yield, Xen will simply continue to run your idle loop rather
than powering down the CPU. If you call block then Xen will *not* run
you until there is some event upcall to be delivered -- this is the
behaviour that you actually want.

You want your idle loop to look something like this:

 while ( !<should leave idle loop> ) {
   disable_intr();
   if ( <should leave idle loop> ) {
     enable_intr();
     break;
   }
   if ( HYPERVISOR_set_timer_op(<next timeout>) == 0 )
     HYPERVISOR_block();
   else
     enable_intr();
 }

The use of HYPERVISOR_set_time_op() is confusing on first
sight. Recall that you stop getting periodic timer upcalls when your
domain is not running. If you block then you will receive no periodic
upcalls until after the next time you receive some other asynchronous
upcall (which serves to unblock you). 

This is bad if the next piece of work your OS needs to execute is
being scheduled off of the timer upcall! What we do in Linux is peek
at the timer subsystem's alarm list, looking for the earliest
requested timeout. We then set a one-shot alarm in Xen that will
wake/unblock us at that point if we were not unblocked already.

 -- Keir

> I've seen the same timing issues. We do call yield where appropriate:
> 
> static void
> cpu_idle_default(void)
> {
> #if 0
>         /*
>          * we must absolutely guarentee that hlt is the
>          * absolute next instruction after sti or we
>          * introduce a timing window.
>          */
>         __asm __volatile("sti; hlt");
> #endif
>         enable_intr();
>         HYPERVISOR_yield();
> }
> 
> 
> So I'm not sure what the problem is. After the 5.3 work and coredump is
> done I might look into it. There may have been some fixes to the clock
> code in the meantime.
> 
> 
> 				-Kip
> 
> 
> On Sat, 8 Jan 2005, Derrik Pates wrote:
> 
> > Kip:
> >
> > Well, I have good news; thanks to Darren Tucker pointing out that the
> > boot.netif.* parameters _have_ to be added, I was able to successfully
> > boot your FreeBSD/Xen kernel. It seems to work okay so far. It fairly
> > regularly (every few minutes or so) spits out a line like:
> >
> > Expensive timeout(9) function: 0xc00b0bd0(0) 0.010000854 s
> >
> > at me, but it seems to otherwise behave as FreeBSD should. The only
> > thing I've noticed so far is that, looking at the output of 'xm list',
> > its domain's virtual-time clock seems to grow at a constant rate. I'm
> > guessing this means it doesn't call up to the hypervisor and say "Please
> > schedule someone else, I'm idle right now" when it has nothing to do. It
> > doesn't seem to affect the performance of other domains though, but I
> > thought it worth pointing out. Unfortunately, I don't know enough about
> > FreeBSD's scheduler to make the necessary changes to make this work as
> > it should. I'll have to see about getting a proper full CVS pull of the
> > sys/ tree for 5.2.1 on my FreeBSD install in VMware, and see if I can
> > make a FreeBSD kernel build work; however, I'd like to see the 5.3
> > kernel when you get around to it.
> >
> > --
> > Derrik Pates
> > dpates@dsdk12.net
> >
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

Thanks!

		-Kip


On Sun, 9 Jan 2005, Keir Fraser wrote:

>
> Kip,
>
> You need to block rather than yield -- if noone else is runnable and
> you call yield, Xen will simply continue to run your idle loop rather
> than powering down the CPU. If you call block then Xen will *not* run
> you until there is some event upcall to be delivered -- this is the
> behaviour that you actually want.
>
> You want your idle loop to look something like this:
>
>  while ( !<should leave idle loop> ) {
>    disable_intr();
>    if ( <should leave idle loop> ) {
>      enable_intr();
>      break;
>    }
>    if ( HYPERVISOR_set_timer_op(<next timeout>) == 0 )
>      HYPERVISOR_block();
>    else
>      enable_intr();
>  }
>
> The use of HYPERVISOR_set_time_op() is confusing on first
> sight. Recall that you stop getting periodic timer upcalls when your
> domain is not running. If you block then you will receive no periodic
> upcalls until after the next time you receive some other asynchronous
> upcall (which serves to unblock you).
>
> This is bad if the next piece of work your OS needs to execute is
> being scheduled off of the timer upcall! What we do in Linux is peek
> at the timer subsystem's alarm list, looking for the earliest
> requested timeout. We then set a one-shot alarm in Xen that will
> wake/unblock us at that point if we were not unblocked already.
>
>  -- Keir
>
> > I've seen the same timing issues. We do call yield where appropriate:
> >
> > static void
> > cpu_idle_default(void)
> > {
> > #if 0
> >         /*
> >          * we must absolutely guarentee that hlt is the
> >          * absolute next instruction after sti or we
> >          * introduce a timing window.
> >          */
> >         __asm __volatile("sti; hlt");
> > #endif
> >         enable_intr();
> >         HYPERVISOR_yield();
> > }
> >
> >
> > So I'm not sure what the problem is. After the 5.3 work and coredump is
> > done I might look into it. There may have been some fixes to the clock
> > code in the meantime.
> >
> >
> > 				-Kip
> >
> >
> > On Sat, 8 Jan 2005, Derrik Pates wrote:
> >
> > > Kip:
> > >
> > > Well, I have good news; thanks to Darren Tucker pointing out that the
> > > boot.netif.* parameters _have_ to be added, I was able to successfully
> > > boot your FreeBSD/Xen kernel. It seems to work okay so far. It fairly
> > > regularly (every few minutes or so) spits out a line like:
> > >
> > > Expensive timeout(9) function: 0xc00b0bd0(0) 0.010000854 s
> > >
> > > at me, but it seems to otherwise behave as FreeBSD should. The only
> > > thing I've noticed so far is that, looking at the output of 'xm list',
> > > its domain's virtual-time clock seems to grow at a constant rate. I'm
> > > guessing this means it doesn't call up to the hypervisor and say "Please
> > > schedule someone else, I'm idle right now" when it has nothing to do. It
> > > doesn't seem to affect the performance of other domains though, but I
> > > thought it worth pointing out. Unfortunately, I don't know enough about
> > > FreeBSD's scheduler to make the necessary changes to make this work as
> > > it should. I'll have to see about getting a proper full CVS pull of the
> > > sys/ tree for 5.2.1 on my FreeBSD install in VMware, and see if I can
> > > make a FreeBSD kernel build work; however, I'd like to see the 5.3
> > > kernel when you get around to it.
> > >
> > > --
> > > Derrik Pates
> > > dpates@dsdk12.net
> > >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

>
> >    - The directory that's supposed to be symlinked from the Xen source
> > tree _does not exist_. I borrowed the matching files from the NetBSD/Xen
> > source tree.
It appears they renamed hypervisor-ifs to public:

kmacy@simf1 ls hypervisor-ifs/
COPYING                 arch-x86_64.h           grant_table.h           physdev.h
SCCS/                   dom0_ops.h              hypervisor-if.h         sched_ctl.h
arch-x86_32.h           event_channel.h         io/                     trace.h
kmacy@simf1 ls
/t/niners/users/xen/xen-2.0-testing.bk/xen/include/public/
COPYING                 arch-x86_64.h           grant_table.h           sched_ctl.h
SCCS/                   dom0_ops.h              io/                     trace.h
arch-x86_32.h           event_channel.h         physdev.h               xen.h


			-Kip


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Dave Feustel]

On Thursday 06 January 2005 02:14 pm, Derrik Pates wrote:
> If anyone has anything to say at all, it'd be appreciated.

Netbsd now runs faster than Freebsd according to a news article
appearing today in the bsd pubs.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Derrik Pates]

Dave Feustel wrote:
> Netbsd now runs faster than Freebsd according to a news article
> appearing today in the bsd pubs.

... Well, I guess that is _something_, though not what I was hoping for. 
All things being equal though, I'd as soon stick to Linux, because 
FreeBSD's irritating the crap out of me today.

-- 
Derrik Pates
dpates@dsdk12.net


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Dave Feustel]

On Thursday 06 January 2005 03:18 pm, Derrik Pates wrote:
> FreeBSD's irritating the crap out of me today.

Try Switching to OpenBSD.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Dick Davies]

* Dave Feustel <dfeustel@mindspring.com> [0146 23:46]:
> On Thursday 06 January 2005 03:18 pm, Derrik Pates wrote:
> > FreeBSD's irritating the crap out of me today.
> 
> Try Switching to OpenBSD.

That doesn't run under Xen does it?

-- 
'The pie is ready. You guys like swarms of things, right?'
		-- Bender
Rasputin :: Jack of All Trades - Master of Nuns


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Darren Tucker]

Derrik Pates wrote:
> I have still not, as yet, been able to get FreeBSD/Xen to actually
> work. It still hangs partway through the kernel boot process.
[...]
> Has _anyone_ successfully used FreeBSD/Xen?

I have the prebuilt kernel and root image from 
http://www.bsdclusters.com/xenofreebsd/ running on a Fedora Core 3 host. 
  My xen config for the guest is below.  It seems to work ok but seems 
to use more cpu time that the other guests (as shown by "xm list").

I found that without the boot.netif.* extras it would hang during boot 
right after the "GEOM: create disk xbd0" message (or "lo0: bpf" if 
booted in verbose mode).

kernel = "/xen/freebsd/kernel-5.2.1"
memory = 48
cpu = -1
name = "freebsd"
nics=1
vif = [ 'mac=aa:00:00:00:00:28,bridge=xen-br0' ]
disk = [ 'file:/xen/freebsd/mdroot,loop0,w' ]
extra = "boot.netif.ip=192.168.32.17"
extra += ",boot.netif.netmask=255.255.255.0"
extra += ",boot.netif.gateway=192.168.32.254"
extra += ",vfs.root.mountfrom=ufs:/dev/xbd0a"
extra += ",boot_verbose=yes"
#extra += ",boot_single=yes"

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Derrik Pates]

Darren Tucker wrote:
> I found that without the boot.netif.* extras it would hang during boot 
> right after the "GEOM: create disk xbd0" message (or "lo0: bpf" if 
> booted in verbose mode).

That's interesting. I just added that stuff, and you're correct - it 
boots all the way now. Well, now we know what will make it work right, 
but I'd be interested to know why it needs that stuff. In the meantime, 
this will be an educational experience. Thanks for pointing that out.

-- 
Derrik Pates
dpates@dsdk12.net



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: FreeBSD/Xen ugliness

[Kip Macy]

Due to some changes in my environment (all of the 5.2.1 machines are
being converted to 5.3 and 5.2.1 doesn't compile with 3.4.1), I'm
integrating the 5.3 changes to i386 into the xen port. It looks like
pmap.c is the only file I depend on that was heavily changed, so I may
be running 5.3 under Xen by the end of this weekend. If you could just
hold off until then...

Thanks.

					-Kip



On Thu, 6 Jan 2005, Derrik Pates wrote:

> All:
>
> I have still not, as yet, been able to get FreeBSD/Xen to actually work.
> It still hangs partway through the kernel boot process. I thought I'd
> try to do a build, but unfortunately the instructions which are provided
> in http://www.bsdclusters.com/xenofreebsd/xenbsdsetup.txt don't work at
> all. I've run across the following so far:
>
>    - Couldn't get BitKeeper to work at all on FreeBSD (complains about
> not being licensed?) - was able to work around this by using BitKeeper
> on my PowerBook running Debian.
>    - The directory that's supposed to be symlinked from the Xen source
> tree _does not exist_. I borrowed the matching files from the NetBSD/Xen
> source tree.
>    - Had to hand-edit several of the copied headers, so they'd include
> files on the right paths.
>    - There is no 'make kernel-depend'. Doing 'make depend' finally sort
> of worked, until it got to dependency generation for the AIC7xxx
> drivers, at which point it tried to pull in something nonexistant and
> bombed.
>
> Has _anyone_ successfully used FreeBSD/Xen? I tried e-mailing Kip Macy
> directly, but have gotten no response as yet. If this doesn't work,
> that's fine; however, FreeBSD is not scoring big points with me today,
> as it seems to be giving me fits in assorted ways today. If anyone has
> anything to say at all, it'd be appreciated.
>
> --
> Derrik Pates
> dpates@dsdk12.net
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt