Date: Tue, 23 Apr 2013 16:36:24 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Jeremy Chadwick <jdc@koitsu.org>, freebsd-hackers@freebsd.org, Joshua Isom <jrisom@gmail.com> Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation Message-ID: <006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E@FreeBSD.org> In-Reply-To: <201304221129.43119.jhb@freebsd.org> References: <20130419162834.GA90217@icarus.home.lan> <20130420014821.GA98555@icarus.home.lan> <5172812A.10309@gmail.com> <201304221129.43119.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 22, 2013, at 17:29, John Baldwin <jhb@freebsd.org> wrote:
> 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
I have tried to ascertain it actually arrives at this code when
rebooting from the loader, but it does not seem to ever make it there,
at least not to the jump to f000:fff0. Maybe VMware intercepts the
switching back to real mode in the previous part, and dies on that, I am
not sure. It is of course rather tricky to print off any debug messages
at that point. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E>