On Apr 23, 2013, at 23:46, Andriy Gapon <a...@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)? _______________________________________________ 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"
