on 24/04/2013 02:03 Dimitry Andric said the following:
> Indeed, the DS segment was incorrect, the GDT should be loaded from the
> CS segment instead.
Very good catch! Indeed the segments at this point were set up for "user" data
while the "supervisor" data is needed.
Thank you!
--
Andriy Gapo
+1 you rock.
I was silently watching this thread from the start, thinking…
Oh gawd, please don't let this be associated with the massive Forth changes
I've rolled in (this much I had doubted heavily, but kept a watchful eye just
in-case).
--
Devin
On Apr 23, 2013, at 4:11 PM, Adrian Chadd wr
Hah, nice catch! You guys rock.
Scratch one less weird shit thing with FreeBSD on VMWARE.
Adrian
On 23 April 2013 16:03, Dimitry Andric wrote:
>
> On Apr 24, 2013, at 00:03, Dimitry Andric wrote:
>
>> On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
>>> on 23/04/2013 19:31 John Baldwin said t
On Apr 24, 2013, at 00:03, Dimitry Andric wrote:
> On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
>> on 23/04/2013 19:31 John Baldwin said the following:
>>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
> ...
0x90e8: lgdtl 0x95d0
0x90ef: ljmpw
On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
> on 23/04/2013 19:31 John Baldwin said the following:
>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
...
>>> 0x90e8: lgdtl 0x95d0
>>> 0x90ef: ljmpw $0x18,$0x90f5
>>>
>>> Triple fault
>>> CPU Reset (CPU 0)
>
on 23/04/2013 19:31 John Baldwin said the following:
> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>> on 23/04/2013 17:36 Dimitry Andric said the following:
>>> I have tried to ascertain it actually arrives at this code when
>>> rebooting from the loader, but it does not seem to ever
On Tuesday, April 23, 2013 1:32:34 pm Andriy Gapon wrote:
> on 23/04/2013 19:09 Andriy Gapon said the following:
> >
> > IN:
> > 0x90d2: cli
> > 0x90d3: mov$0x1800,%esp
> > 0x90d8: mov%cr0,%eax
> > 0x90db: and$0x7f
On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
> on 23/04/2013 17:36 Dimitry Andric said the following:
> > 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:fff
on 23/04/2013 19:09 Andriy Gapon said the following:
>
> IN:
> 0x90d2: cli
> 0x90d3: mov$0x1800,%esp
> 0x90d8: mov%cr0,%eax
> 0x90db: and$0x7fff,%eax
> 0x90e0: mov%eax,%cr0
>
>
>
on 23/04/2013 17:36 Dimitry Andric said the following:
> 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 th
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
On Apr 22, 2013, at 17:29, John Baldwin 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
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 BS
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
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.
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 le
(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
17 matches
Mail list logo
