Basically, the loader finds a simple safe way to reboot that's worked
since the 286, and VMWare doesn't like it. It's called a triple fault.
FreeBSD and Linux even use it to reboot as a fail safe. Read
sys/i386/i386/vm_machdep.c and cpu_reset_real to see how FreeBSD handles
it. VMWare at least says that "it would have caused the physical
machine to restart." Blame VMWare.
On 4/19/2013 11:28 AM, Jeremy Chadwick wrote:
(Please keep me CC'd as I'm not subscribed to -hackers)
When running FreeBSD under VMware Workstation (I'm using 9.0.1, but this
issue has existed for many years now, I remember it occurring on
Workstation 6.x), the following is reproducible:
1. Power on + boot FreeBSD VM
2. At loader menu, press "3" to reboot
3. Loader prints "Rebooting..."
4. VMware proceeds to show the following message in a dialog box:
"A fault has occurred causing a virtual CPU to enter the shutdown state.
If this fault had occurred outside of a virtual machine, it would have
caused the physical machine to restart. The shutdown state can be
reached incorrectly configuring the virtual machine, a bug in the guest
operating system, or a problem in VMware Workstation."
It can also happen when dropping to the loader prompt and doing
"reboot".
It *does not* happen when booting fully into FreeBSD and issuing
"shutdown -r now". Likewise, hw.acpi.disable_on_reboot and
hw.acpi.handle_reboot have no bearing (e.g. changing either of those to
1 (default = 0) then doing "shutdown -r now" to try and induce the
problem).
So it seems the issue is specific to the bootstrap/loader env.
FreeBSD 9.1-STABLE is being used, but I've seen this happen with FreeBSD
8.x as well as 7.x. It does not happen with other OSes like Linux and
Solaris. I have not tried other VM systems (VirtualBox, etc.) but I
imagine they might just silently deal with the situation rather than
provide a useful message (although I know VirtualBox has an amazingly
detailed debugger).
I've looked at sys/boot/i386/loader/main.c (func command_reboot()) and
the actual magic seems to happen inside of __exit.
__exit comes from sys/boot/i386/btx/lib/btxsys.s, which zeros eax then
issues INT 0x30 (syscall interrupt). That lead me to this:
http://www.freebsd.org/doc/en/books/arch-handbook/book.html
Eek. x86 architecture is a lot different than I remember it being in
my 386 days, so this is all a bit over my head.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
