5.0-RELEASE & VMWare 3.2

[dro...@rpi.edu]

At 11:56 AM -0800 1/23/03, Brooks Davis wrote:
>On Thu, Jan 23, 2003 at 10:50:01PM +0300, Lev Serebryakov wrote:
> > Now I'm trying to look at 5.0-RELEASE (I've downloaded ISO
> > of first i386 CD).
> >
> > It doesn't work under VMWare 3.2! Ok, it works, really. But
> > speed is VERY low. I even could not do installation!
>
> From sys/i386/conf/NOTES:
>
> # CPU_DISABLE_CMPXCHG disables the CMPXCHG instruction
> # on > i386 IA32 machines. VmWare seems to emulate this
> # instruction poorly, causing the guest OS to run very
> # slowly. Enabling this with a SMP kernel will cause the
> # kernel to be unusable.
>
>You need a kernel with this option or compiled with "cpu I386_CPU".

Someone recently added an 'SMP' file to sys/i386/conf, which just
includes GENERIC, changes the 'ident' and then turns on the SMP
and APIC_IO options. Perhaps we should add a VMWARE one, with an
eye towards building a "vmware-appropriate" kernel that would be
available on the install CD's?

It is easy to imagine someone wanting to just test freebsd, and
having vmware the way to test it, and not wanting to build a kernel
just to see freebsd running. (I just gave away about 15 release-4
CD's to a unix user's group just for this kind of "try it out!"
purpose. Note that these are people who do not already have any
freebsd system running. That works fine with release four, but
will not work so well once we want to be handing out release-5 CD's)

--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

[na...@root.org]

On Thu, 23 Jan 2003, Garance A Drosihn wrote:
> Someone recently added an 'SMP' file to sys/i386/conf, which just
> includes GENERIC, changes the 'ident' and then turns on the SMP
> and APIC_IO options. Perhaps we should add a VMWARE one, with an
> eye towards building a "vmware-appropriate" kernel that would be
> available on the install CD's?

Or to fix this longer term, provide a way at run-time for a kernel to
provide different code for the same purpose. Linux did this for the
syscall (int 0x80 vs. syscall) instructions. I could see it being done
for locking low-level operations as well.

-Nate