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 <dim at freebsd.org> wrote:
>> 
>> On Apr 24, 2013, at 00:03, Dimitry Andric <dim at FreeBSD.org> wrote:
>> 
>>> On Apr 23, 2013, at 23:46, Andriy Gapon <avg at FreeBSD.org> 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.
>>  */
>> 
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

_____________
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.