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.
_______________________________________________
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"
