Rebooting from loader causes a "fault" in VMware Workstation

Dimitry Andric dim at FreeBSD.org
Tue Apr 23 22:03:14 UTC 2013


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)?



More information about the freebsd-hackers mailing list