FreeBSD 6.2 sees lots of "Signal 11" with dual-processor VM

[Mike_O_Brien]

I'm running a pretty vanilla FreeBSD 6.2-RELEASE system under Beta 4. I'm just setting it up. Host machine is a 4-core Mac Pro, so I gave the VM two processors. FreeBSD SMP under 6.2-RELEASE isn't great but isn't awful either.

To both update the thing and shake things out I did a "freebsd-update" to get recent changes, then did "cd /usr/src/; make -j5 buildworld". It died, repeatedly, getting periodic "Signal 11" errors. Nothing in the VMWare log on the host machine.

I cut the number of virtual processors back to one, and a "make -j3 buildworld" seems to be running to completion now.

Looks like virtual processor scheduling has a problem or two. No idea how to give more data on what's going wrong, though.

[slewsys]

There may be a couple of workarounds for your problem. One is to install X11 and then manually install VMWare tools (attach the image file /Library/Application Support/VMware Fusion/isoimages/freebsd.iso to the FreeBSD host cdrom device). There are some issues with Xorg 7.x as discussed in other posts, but FreeBSD 6.2 uses an earlier version of X11, so VMWare Tools should install without a hitch. In an X11/VMWare Tools environment, I have not experienced freezes/SIGSEGV issues in FreeBSD 6.2.

An alternative workaround is to tell VMWare to assign only a single CPU to the FreeBSD guest OS. Then you should be able to recompile the system even in console mode (i.e., no X11) without experiencing a SIGSEGV. If you don't redirect standard I/O, you may need to click into the FreeBSD host window occasionally and press a key. The I/O sticks for some reason.

Assigning multiple CPUs to a guest is problematic and has been discussed in this forum (in the context of XP). In short, it appears to have something to do with poor scheduling in the Mac kernel. Rumor is that Leopard has better scheduling, but whether VMWare will benefit from this remains to be seen.

[sparcdr]

While I agree with your reply to his question, I do not completely agree with the scheduling comment. It's more of an issue of compatibility testing on Apple's behalf with systems that have double the cores of previous generation systems. I do agree that mach by design can be cpu intensive, and maybe Leopard will make it better, but it's still an issue of optimization, not really design, I don't think there's much to improve.

[Mike_O_Brien]

FWIW I was running in console mode when doing "make -j5 buildworld". So there is indeed something wrong with assigning two processors to a guest FreeBSD system. "buildworld" just builds the core user-space environment; X is part of the FreeBSD "ports" system, not part of the base install, so X wasn't involved here.

The single-core FreeBSD VM did manage to complete "make -j3 buildworld" without further intervention on my part, though for some reason the Ethernet driver decided to ignore a few packets for lack of space to put them. Which is odd, since I wasn't exercising the net.

[sparcdr]

For what it's worth, Parallels had an issue with Solaris and the networking card, something to do with missing legacy ISA functionality. This in turn caused some verbose errors. Perhaps since VMware is also founded upon virtualized hardware, there's a bug in its emulated network card, maybe related to legacy support, since the pcn driver and e1000g driver were originally coded for legacy BIOS with ISA bridging.

[Mike_O_Brien]

Thought I'd follow up. I'm now running Version 1.0 (50460), and the behavior is the same. An SMP kernel of FreeBSD 6.2-RELEASE gets lots of signals sent to running processes during parallel operations. A uniprocessor kernel runs fine.

I've cut back the number of processors to one, but this doesn't make me feel good about VMWare's internal stability.

Still seeing ethernet packet overruns from the ethernet driver, too.