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 _______________________________________________ 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"