A little more information in that subject, rebooting from the FreeBSD
bootloader doesn't work on VirtualBox either (version 4.2). It juste enter
an infinite loop without any error message (Grub does reboot).
Hope this could help understanding what's going on here :)
--
Ben
On Tue, Apr 23, 2013 at 4:36 PM, Dimitry Andric <d...@freebsd.org> wrote:
> On Apr 22, 2013, at 17:29, John Baldwin <j...@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. :-)
>
> _______________________________________________
> 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"
>
_______________________________________________
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"
