From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 22 16:07:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82BF8FB for ; Mon, 22 Apr 2013 16:07:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 574D21349 for ; Mon, 22 Apr 2013 16:07:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5D9C4B94C; Mon, 22 Apr 2013 12:07:02 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation Date: Mon, 22 Apr 2013 11:29:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130419162834.GA90217@icarus.home.lan> <20130420014821.GA98555@icarus.home.lan> <5172812A.10309@gmail.com> In-Reply-To: <5172812A.10309@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304221129.43119.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Apr 2013 12:07:02 -0400 (EDT) Cc: Jeremy Chadwick , Joshua Isom X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:07:05 -0000 On Saturday, April 20, 2013 7:51:06 am Joshua Isom wrote: > On 4/19/2013 8:48 PM, Jeremy Chadwick wrote: > > 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? > > A triple fault is standard practice as a fail safe guarantee of reboot. > It's used either as a reboot, switch to real mode(IBM OS/2), or > catastrophic unrecoverable failure. > > By the looks of grub(Linux and Solaris), it either jumps to it's own > instruction, hoping the bios catches it("tell the BIOS a boot failure, > which may result in no effect"), or jumps to a location that I can't yet > determine what code exists there. I can't seem to find OpenBSD's reboot > method from OpenBSD's cvsweb, only an exit but not where that exit leads > to. The native operating system is irrelevant, only the boot loader so > all the Linux distributions and Solaris forks all count as "grub." Many > other bootloaders don't even have the reboot option, just "fail." > Here's barebox, a Das U-Boot fork: > > /** How to reset the machine? */ > while(1) > > In any case, it's a bag of tricks, finding something that works and is > "nice." We're talking 30 years of legacy. A triple fault, assuming the > mbr and loader ignores or zeroes previous memory, is guaranteed and > doesn't hang. Actually, the traditional reboot method in real-mode (e.g. in DOS) is to jump to 0xffff:0. The BIOS is supposed to have a restart routine at that location. I've also seen jumps to 0xf000:fff0. For example, BTX (the mini-kernel that "hosts" the loader and boot2) uses the latter: /* * Reboot or await reset. */ sti # Enable interrupts testb $0x1,btx_hdr+0x7 # Reboot? exit.3: jz exit.3 # No movw $0x1234, BDA_BOOT # Do a warm boot ljmp $0xf000,$0xfff0 # reboot the machine And in fact, when the loader calls __exit() that is precisely where it ends up. The int 0x30 ends up here in btx.S: /* * System calls. */ .set SYS_EXIT,0x0 # Exit .set SYS_EXEC,0x1 # Exec ... /* * System Call. */ intx30: cmpl $SYS_EXEC,%eax # Exec system call? jne intx30.1 # No ... intx30.1: orb $0x1,%ss:btx_hdr+0x7 # Flag reboot jmp exit # Exit And the 'exit' label eventually ends up at the 'exit.3' code I quoted above. If the BIOS VMWare exports a reboot routine VMWare doesn't like then VMWare needs to fix its BIOS. :) The operations we try on x86 to shutdown from protected mode is quite a bit longer (not including the ACPI bits). You can look at cpu_reset_real() in sys/i386/i386/vm_machdep.c. -- John Baldwin