Quantcast

Rebooting from loader causes a "fault" in VMware Workstation

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rebooting from loader causes a "fault" in VMware Workstation

Jeremy Chadwick-4
(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 "3" to reboot
3. Loader prints "Rebooting..."
4. VMware proceeds to show the following message in a dialog box:

"A fault has occurred causing a virtual CPU to enter the shutdown state.
If this fault had occurred outside of a virtual machine, it would have
caused the physical machine to restart. The shutdown state can be
reached incorrectly configuring the virtual machine, a bug in the guest
operating system, or a problem in VMware Workstation."

It can also happen when dropping to the loader prompt and doing
"reboot".

It *does not* happen when booting fully into FreeBSD and issuing
"shutdown -r now".  Likewise, hw.acpi.disable_on_reboot and
hw.acpi.handle_reboot have no bearing (e.g. changing either of those to
1 (default = 0) then doing "shutdown -r now" to try and induce the
problem).

So it seems the issue is specific to the bootstrap/loader env.

FreeBSD 9.1-STABLE is being used, but I've seen this happen with FreeBSD
8.x as well as 7.x.  It does not happen with other OSes like Linux and
Solaris.  I have not tried other VM systems (VirtualBox, etc.) but I
imagine they might just silently deal with the situation rather than
provide a useful message (although I know VirtualBox has an amazingly
detailed debugger).

I've looked at sys/boot/i386/loader/main.c (func command_reboot()) and
the actual magic seems to happen inside of __exit.

__exit comes from sys/boot/i386/btx/lib/btxsys.s, which zeros eax then
issues INT 0x30 (syscall interrupt).  That lead me to this:

http://www.freebsd.org/doc/en/books/arch-handbook/book.html

Eek.  x86 architecture is a lot different than I remember it being in
my 386 days, so this is all a bit over my head.

--
| Jeremy Chadwick                                   [hidden email] |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Joshua Isom-2
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 least says that "it would have caused the physical
machine to restart."  Blame VMWare.

On 4/19/2013 11:28 AM, Jeremy Chadwick wrote:

> (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 "3" to reboot
> 3. Loader prints "Rebooting..."
> 4. VMware proceeds to show the following message in a dialog box:
>
> "A fault has occurred causing a virtual CPU to enter the shutdown state.
> If this fault had occurred outside of a virtual machine, it would have
> caused the physical machine to restart. The shutdown state can be
> reached incorrectly configuring the virtual machine, a bug in the guest
> operating system, or a problem in VMware Workstation."
>
> It can also happen when dropping to the loader prompt and doing
> "reboot".
>
> It *does not* happen when booting fully into FreeBSD and issuing
> "shutdown -r now".  Likewise, hw.acpi.disable_on_reboot and
> hw.acpi.handle_reboot have no bearing (e.g. changing either of those to
> 1 (default = 0) then doing "shutdown -r now" to try and induce the
> problem).
>
> So it seems the issue is specific to the bootstrap/loader env.
>
> FreeBSD 9.1-STABLE is being used, but I've seen this happen with FreeBSD
> 8.x as well as 7.x.  It does not happen with other OSes like Linux and
> Solaris.  I have not tried other VM systems (VirtualBox, etc.) but I
> imagine they might just silently deal with the situation rather than
> provide a useful message (although I know VirtualBox has an amazingly
> detailed debugger).
>
> I've looked at sys/boot/i386/loader/main.c (func command_reboot()) and
> the actual magic seems to happen inside of __exit.
>
> __exit comes from sys/boot/i386/btx/lib/btxsys.s, which zeros eax then
> issues INT 0x30 (syscall interrupt).  That lead me to this:
>
> http://www.freebsd.org/doc/en/books/arch-handbook/book.html
>
> Eek.  x86 architecture is a lot different than I remember it being in
> my 386 days, so this is all a bit over my head.
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Jeremy Chadwick-4
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.c and cpu_reset_real to see how
> FreeBSD handles it.  VMWare at least says that "it would have caused
> the physical machine to restart."  Blame VMWare.
>
> On 4/19/2013 11:28 AM, Jeremy Chadwick wrote:
> >(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 "3" to reboot
> >3. Loader prints "Rebooting..."
> >4. VMware proceeds to show the following message in a dialog box:
> >
> >"A fault has occurred causing a virtual CPU to enter the shutdown state.
> >If this fault had occurred outside of a virtual machine, it would have
> >caused the physical machine to restart. The shutdown state can be
> >reached incorrectly configuring the virtual machine, a bug in the guest
> >operating system, or a problem in VMware Workstation."
> >
> >It can also happen when dropping to the loader prompt and doing
> >"reboot".
> >
> >It *does not* happen when booting fully into FreeBSD and issuing
> >"shutdown -r now".  Likewise, hw.acpi.disable_on_reboot and
> >hw.acpi.handle_reboot have no bearing (e.g. changing either of those to
> >1 (default = 0) then doing "shutdown -r now" to try and induce the
> >problem).
> >
> >So it seems the issue is specific to the bootstrap/loader env.
> >
> >FreeBSD 9.1-STABLE is being used, but I've seen this happen with FreeBSD
> >8.x as well as 7.x.  It does not happen with other OSes like Linux and
> >Solaris.  I have not tried other VM systems (VirtualBox, etc.) but I
> >imagine they might just silently deal with the situation rather than
> >provide a useful message (although I know VirtualBox has an amazingly
> >detailed debugger).
> >
> >I've looked at sys/boot/i386/loader/main.c (func command_reboot()) and
> >the actual magic seems to happen inside of __exit.
> >
> >__exit comes from sys/boot/i386/btx/lib/btxsys.s, which zeros eax then
> >issues INT 0x30 (syscall interrupt).  That lead me to this:
> >
> >http://www.freebsd.org/doc/en/books/arch-handbook/book.html
> >
> >Eek.  x86 architecture is a lot different than I remember it being in
> >my 386 days, so this is all a bit over my head.

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?

--
| Jeremy Chadwick                                   [hidden email] |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Joshua Isom-2
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.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

John Baldwin
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Dimitry Andric-4
On Apr 22, 2013, at 17:29, John Baldwin <[hidden email]> 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. :-)

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Benjamin VILLAIN-2
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 <[hidden email]> wrote:

> On Apr 22, 2013, at 17:29, John Baldwin <[hidden email]> 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. :-)
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Andriy Gapon
In reply to this post by Dimitry Andric-4
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 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. :-)

For the inquisitive minds here how last instructions (and CPU state) look
according to qemu log:

IN:
0x000000000000a030:  xor    %eax,%eax
0x000000000000a032:  int    $0x30

----------------
IN:
0x00000000000093e0:  cmp    $0x1,%eax
0x00000000000093e3:  jne    0x93ff

----------------
IN:
0x00000000000093ff:  orb    $0x1,%ss:0x9007
0x0000000000009407:  jmp    0x90d2

----------------
IN:
0x00000000000090d2:  cli
0x00000000000090d3:  mov    $0x1800,%esp
0x00000000000090d8:  mov    %cr0,%eax
0x00000000000090db:  and    $0x7fffffff,%eax
0x00000000000090e0:  mov    %eax,%cr0

----------------
IN:
0x00000000000090e3:  xor    %ecx,%ecx
0x00000000000090e5:  mov    %ecx,%cr3

----------------
IN:
0x00000000000090e8:  lgdtl  0x95d0
0x00000000000090ef:  ljmpw  $0x18,$0x90f5

Triple fault
CPU Reset (CPU 0)
ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
GDT=     ff85c789 00000000
IDT=     00005e00 00000197
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000001 CCD=00000000 CCO=LOGICL
EFER=0000000000000000

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

John Baldwin
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: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. :-)
>
> For the inquisitive minds here how last instructions (and CPU state) look
> according to qemu log:
>
> IN:
> 0x000000000000a030:  xor    %eax,%eax
> 0x000000000000a032:  int    $0x30
>
> ----------------
> IN:
> 0x00000000000093e0:  cmp    $0x1,%eax
> 0x00000000000093e3:  jne    0x93ff
>
> ----------------
> IN:
> 0x00000000000093ff:  orb    $0x1,%ss:0x9007
> 0x0000000000009407:  jmp    0x90d2
>
> ----------------
> IN:
> 0x00000000000090d2:  cli
> 0x00000000000090d3:  mov    $0x1800,%esp
> 0x00000000000090d8:  mov    %cr0,%eax
> 0x00000000000090db:  and    $0x7fffffff,%eax
> 0x00000000000090e0:  mov    %eax,%cr0
>
> ----------------
> IN:
> 0x00000000000090e3:  xor    %ecx,%ecx
> 0x00000000000090e5:  mov    %ecx,%cr3
>
> ----------------
> IN:
> 0x00000000000090e8:  lgdtl  0x95d0
> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>
> Triple fault
> CPU Reset (CPU 0)
> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
> GDT=     ff85c789 00000000

This seems wrong (address is way too high).  I wonder if the gdtdesc was
trashed by something?  Can you dump memory before the lgdtl instruction at the
0x95d0 address?

--
John Baldwin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Andriy Gapon
In reply to this post by Andriy Gapon
on 23/04/2013 19:09 Andriy Gapon said the following:

> ----------------
> IN:
> 0x00000000000090d2:  cli
> 0x00000000000090d3:  mov    $0x1800,%esp
> 0x00000000000090d8:  mov    %cr0,%eax
> 0x00000000000090db:  and    $0x7fffffff,%eax
> 0x00000000000090e0:  mov    %eax,%cr0
>
> ----------------
> IN:
> 0x00000000000090e3:  xor    %ecx,%ecx
> 0x00000000000090e5:  mov    %ecx,%cr3
>
> ----------------
> IN:
> 0x00000000000090e8:  lgdtl  0x95d0
> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5

Perhaps the problem is that lgdt is called after disabling paging?

> Triple fault
> CPU Reset (CPU 0)
> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
> GDT=     ff85c789 00000000
> IDT=     00005e00 00000197
> CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> CCS=00000001 CCD=00000000 CCO=LOGICL
> EFER=0000000000000000
>


--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

John Baldwin
On Tuesday, April 23, 2013 1:32:34 pm Andriy Gapon wrote:

> on 23/04/2013 19:09 Andriy Gapon said the following:
> > ----------------
> > IN:
> > 0x00000000000090d2:  cli
> > 0x00000000000090d3:  mov    $0x1800,%esp
> > 0x00000000000090d8:  mov    %cr0,%eax
> > 0x00000000000090db:  and    $0x7fffffff,%eax
> > 0x00000000000090e0:  mov    %eax,%cr0
> >
> > ----------------
> > IN:
> > 0x00000000000090e3:  xor    %ecx,%ecx
> > 0x00000000000090e5:  mov    %ecx,%cr3
> >
> > ----------------
> > IN:
> > 0x00000000000090e8:  lgdtl  0x95d0
> > 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>
> Perhaps the problem is that lgdt is called after disabling paging?

That should be fine.  Generally speaking paging shouldn't be enabled
anyway (it only is if the i386 kernel panics before it has setup its
own IDT).  With paging disabled that should load the gdt from that
physical address which looks correct (the GDT descriptor is stored
just after the static gdt in btx.S itself).

> > Triple fault
> > CPU Reset (CPU 0)
> > ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
> > EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> > ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> > CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
> > SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
> > DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> > FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> > GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> > LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
> > TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
> > GDT=     ff85c789 00000000
> > IDT=     00005e00 00000197
> > CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
> > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
> > DR6=00000000ffff0ff0 DR7=0000000000000400
> > CCS=00000001 CCD=00000000 CCO=LOGICL
> > EFER=0000000000000000
> >
>
>
> --
> Andriy Gapon
>

--
John Baldwin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Andriy Gapon
In reply to this post by John Baldwin
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 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. :-)
>>
>> For the inquisitive minds here how last instructions (and CPU state) look
>> according to qemu log:
>>
>> IN:
>> 0x000000000000a030:  xor    %eax,%eax
>> 0x000000000000a032:  int    $0x30
>>
>> ----------------
>> IN:
>> 0x00000000000093e0:  cmp    $0x1,%eax
>> 0x00000000000093e3:  jne    0x93ff
>>
>> ----------------
>> IN:
>> 0x00000000000093ff:  orb    $0x1,%ss:0x9007
>> 0x0000000000009407:  jmp    0x90d2
>>
>> ----------------
>> IN:
>> 0x00000000000090d2:  cli
>> 0x00000000000090d3:  mov    $0x1800,%esp
>> 0x00000000000090d8:  mov    %cr0,%eax
>> 0x00000000000090db:  and    $0x7fffffff,%eax
>> 0x00000000000090e0:  mov    %eax,%cr0
>>
>> ----------------
>> IN:
>> 0x00000000000090e3:  xor    %ecx,%ecx
>> 0x00000000000090e5:  mov    %ecx,%cr3
>>
>> ----------------
>> IN:
>> 0x00000000000090e8:  lgdtl  0x95d0
>> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>>
>> Triple fault
>> CPU Reset (CPU 0)
>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
>> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
>> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
>> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
>> GDT=     ff85c789 00000000
>
> This seems wrong (address is way too high).  I wonder if the gdtdesc was
> trashed by something?  Can you dump memory before the lgdtl instruction at the
> 0x95d0 address?

Looks correct:
Breakpoint 1, 0x000090e8 in ?? ()
(gdb) x/i $eip
0x90e8: lgdtl  0x95d0
(gdb) x/3xh 0x95d0
0x95d0: 0x003f  0x9590  0x0000
(gdb) x/16xh 0x9590
0x9590: 0x0000  0x0000  0x0000  0x0000  0xffff  0x0000  0x9a00  0x00cf
0x95a0: 0xffff  0x0000  0x9300  0x00cf  0xffff  0x0000  0x9a00  0x0000

Nevertheless doing stepi leads to exactly the same triple fault.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Dimitry Andric-4
On Apr 23, 2013, at 23:46, Andriy Gapon <[hidden email]> wrote:
> on 23/04/2013 19:31 John Baldwin said the following:
>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
...

>>> 0x00000000000090e8:  lgdtl  0x95d0
>>> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>>>
>>> Triple fault
>>> CPU Reset (CPU 0)
>>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
>>> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
>>> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
>>> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>>> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
>>> GDT=     ff85c789 00000000
>>
>> This seems wrong (address is way too high).  I wonder if the gdtdesc was
>> trashed by something?  Can you dump memory before the lgdtl instruction at the
>> 0x95d0 address?
>
> Looks correct:
> Breakpoint 1, 0x000090e8 in ?? ()
> (gdb) x/i $eip
> 0x90e8: lgdtl  0x95d0
> (gdb) x/3xh 0x95d0
> 0x95d0: 0x003f  0x9590  0x0000
> (gdb) x/16xh 0x9590
> 0x9590: 0x0000  0x0000  0x0000  0x0000  0xffff  0x0000  0x9a00  0x00cf
> 0x95a0: 0xffff  0x0000  0x9300  0x00cf  0xffff  0x0000  0x9a00  0x0000
>
> Nevertheless doing stepi leads to exactly the same triple fault.


Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
not 0 (or equal to CS, I'm not sure which is correct here)?

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Dimitry Andric-4

On Apr 24, 2013, at 00:03, Dimitry Andric <[hidden email]> wrote:

> On Apr 23, 2013, at 23:46, Andriy Gapon <[hidden email]> wrote:
>> on 23/04/2013 19:31 John Baldwin said the following:
>>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
> ...
>>>> 0x00000000000090e8:  lgdtl  0x95d0
>>>> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>>>>
>>>> Triple fault
>>>> CPU Reset (CPU 0)
>>>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
>>>> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>>> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
>>>> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
>>>> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>>>> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
>>>> GDT=     ff85c789 00000000
>>>
>>> This seems wrong (address is way too high).  I wonder if the gdtdesc was
>>> trashed by something?  Can you dump memory before the lgdtl instruction at the
>>> 0x95d0 address?
>>
>> Looks correct:
>> Breakpoint 1, 0x000090e8 in ?? ()
>> (gdb) x/i $eip
>> 0x90e8: lgdtl  0x95d0
>> (gdb) x/3xh 0x95d0
>> 0x95d0: 0x003f  0x9590  0x0000
>> (gdb) x/16xh 0x9590
>> 0x9590: 0x0000  0x0000  0x0000  0x0000  0xffff  0x0000  0x9a00  0x00cf
>> 0x95a0: 0xffff  0x0000  0x9300  0x00cf  0xffff  0x0000  0x9a00  0x0000
>>
>> Nevertheless doing stepi leads to exactly the same triple fault.
>
>
> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
> not 0 (or equal to CS, I'm not sure which is correct here)?

Indeed, the DS segment was incorrect, the GDT should be loaded from the
CS segment instead.  This diff fixes the issue for me (and now "reboot"
command from loader nicely reboots in VMware):

Index: sys/boot/i386/btx/btx/btx.S
===================================================================
--- sys/boot/i386/btx/btx/btx.S (revision 248910)
+++ sys/boot/i386/btx/btx/btx.S (working copy)
@@ -248,7 +248,7 @@ exit: cli # Disable interrupts
 /*
  * Restore the GDT in case we caught a kernel trap.
  */
- lgdt gdtdesc # Set GDT
+ lgdt %cs:gdtdesc # Set GDT
 /*
  * To 16 bits.
  */

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Adrian Chadd-2
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 <[hidden email]> wrote:

>
> On Apr 24, 2013, at 00:03, Dimitry Andric <[hidden email]> wrote:
>
>> On Apr 23, 2013, at 23:46, Andriy Gapon <[hidden email]> wrote:
>>> on 23/04/2013 19:31 John Baldwin said the following:
>>>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>> ...
>>>>> 0x00000000000090e8:  lgdtl  0x95d0
>>>>> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>>>>>
>>>>> Triple fault
>>>>> CPU Reset (CPU 0)
>>>>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
>>>>> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>>>> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
>>>>> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
>>>>> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>>>>> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
>>>>> GDT=     ff85c789 00000000
>>>>
>>>> This seems wrong (address is way too high).  I wonder if the gdtdesc was
>>>> trashed by something?  Can you dump memory before the lgdtl instruction at the
>>>> 0x95d0 address?
>>>
>>> Looks correct:
>>> Breakpoint 1, 0x000090e8 in ?? ()
>>> (gdb) x/i $eip
>>> 0x90e8: lgdtl  0x95d0
>>> (gdb) x/3xh 0x95d0
>>> 0x95d0: 0x003f  0x9590  0x0000
>>> (gdb) x/16xh 0x9590
>>> 0x9590: 0x0000  0x0000  0x0000  0x0000  0xffff  0x0000  0x9a00  0x00cf
>>> 0x95a0: 0xffff  0x0000  0x9300  0x00cf  0xffff  0x0000  0x9a00  0x0000
>>>
>>> Nevertheless doing stepi leads to exactly the same triple fault.
>>
>>
>> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
>> not 0 (or equal to CS, I'm not sure which is correct here)?
>
> Indeed, the DS segment was incorrect, the GDT should be loaded from the
> CS segment instead.  This diff fixes the issue for me (and now "reboot"
> command from loader nicely reboots in VMware):
>
> Index: sys/boot/i386/btx/btx/btx.S
> ===================================================================
> --- sys/boot/i386/btx/btx/btx.S (revision 248910)
> +++ sys/boot/i386/btx/btx/btx.S (working copy)
> @@ -248,7 +248,7 @@ exit:               cli                             # Disable interrupts
>  /*
>   * Restore the GDT in case we caught a kernel trap.
>   */
> -               lgdt gdtdesc                    # Set GDT
> +               lgdt %cs:gdtdesc                # Set GDT
>  /*
>   * To 16 bits.
>   */
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Teske, Devin
+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 wrote:

> 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 <[hidden email]> wrote:
>>
>> On Apr 24, 2013, at 00:03, Dimitry Andric <[hidden email]> wrote:
>>
>>> On Apr 23, 2013, at 23:46, Andriy Gapon <[hidden email]> wrote:
>>>> on 23/04/2013 19:31 John Baldwin said the following:
>>>>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>>> ...
>>>>>> 0x00000000000090e8:  lgdtl  0x95d0
>>>>>> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
>>>>>>
>>>>>> Triple fault
>>>>>> CPU Reset (CPU 0)
>>>>>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
>>>>>> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>>>>> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>>> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
>>>>>> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
>>>>>> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>>> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>>> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
>>>>>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>>>>>> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
>>>>>> GDT=     ff85c789 00000000
>>>>>
>>>>> This seems wrong (address is way too high).  I wonder if the gdtdesc was
>>>>> trashed by something?  Can you dump memory before the lgdtl instruction at the
>>>>> 0x95d0 address?
>>>>
>>>> Looks correct:
>>>> Breakpoint 1, 0x000090e8 in ?? ()
>>>> (gdb) x/i $eip
>>>> 0x90e8: lgdtl  0x95d0
>>>> (gdb) x/3xh 0x95d0
>>>> 0x95d0: 0x003f  0x9590  0x0000
>>>> (gdb) x/16xh 0x9590
>>>> 0x9590: 0x0000  0x0000  0x0000  0x0000  0xffff  0x0000  0x9a00  0x00cf
>>>> 0x95a0: 0xffff  0x0000  0x9300  0x00cf  0xffff  0x0000  0x9a00  0x0000
>>>>
>>>> Nevertheless doing stepi leads to exactly the same triple fault.
>>>
>>>
>>> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
>>> not 0 (or equal to CS, I'm not sure which is correct here)?
>>
>> Indeed, the DS segment was incorrect, the GDT should be loaded from the
>> CS segment instead.  This diff fixes the issue for me (and now "reboot"
>> command from loader nicely reboots in VMware):
>>
>> Index: sys/boot/i386/btx/btx/btx.S
>> ===================================================================
>> --- sys/boot/i386/btx/btx/btx.S (revision 248910)
>> +++ sys/boot/i386/btx/btx/btx.S (working copy)
>> @@ -248,7 +248,7 @@ exit:               cli                             # Disable interrupts
>> /*
>>  * Restore the GDT in case we caught a kernel trap.
>>  */
>> -               lgdt gdtdesc                    # Set GDT
>> +               lgdt %cs:gdtdesc                # Set GDT
>> /*
>>  * To 16 bits.
>>  */
>>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "[hidden email]"
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rebooting from loader causes a "fault" in VMware Workstation

Andriy Gapon
In reply to this post by Dimitry Andric-4
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 Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Loading...