Date: Fri, 19 Apr 2013 18:48:21 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Joshua Isom <jrisom@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation Message-ID: <20130420014821.GA98555@icarus.home.lan> In-Reply-To: <5171C9FE.8080409@gmail.com> References: <20130419162834.GA90217@icarus.home.lan> <5171C9FE.8080409@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 19, 2013 at 05:49:34PM -0500, Joshua Isom wrote: > 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. I'm happy to open up a ticket with VMware about the issue as I'm a customer, but I find it a little odd that other operating systems do not exhibit this problem, including another BSD. Ones which reboot just fine from their bootloaders: - Linux -- so many that I don't know where to begin: ArchLinux 2012.10.06, CentOS 6.3, Debian 6.0.7, Finnix 1.0.5, Knoppix 7.0.4, Slackware 14.0, and Ubuntu 11.10 - OpenBSD 5.2 - OpenIndiana -- build 151a7 (server version) So when you say "Blame VMware", I'd be happy to, except there must be something FreeBSD's bootstraps are doing differently than everyone else that causes this oddity. Would you not agree? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130420014821.GA98555>