Date: Wed, 24 Apr 2013 01:03:31 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: Jeremy Chadwick <jdc@koitsu.org>, freebsd-hackers@FreeBSD.org, Joshua Isom <jrisom@gmail.com> Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation Message-ID: <4735123C-E912-4D32-80D4-D057E2821626@FreeBSD.org> In-Reply-To: <650A4439-B258-4FDA-BD5C-C9DEF5DC81ED@FreeBSD.org> References: <20130419162834.GA90217@icarus.home.lan> <006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E@FreeBSD.org> <5176B238.7030306@FreeBSD.org> <201304231231.38765.jhb@freebsd.org> <51770149.6020802@FreeBSD.org> <650A4439-B258-4FDA-BD5C-C9DEF5DC81ED@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 24, 2013, at 00:03, Dimitry Andric <dim@FreeBSD.org> wrote: > On Apr 23, 2013, at 23:46, Andriy Gapon <avg@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 >>>>=20 >>>> Triple fault >>>> CPU Reset (CPU 0) >>>> ESI=3D0004503c EDI=3D3fe50968 EBP=3D00094a80 ESP=3D00001800 >>>> EIP=3D000090ef EFL=3D00000046 [---Z-P-] CPL=3D0 II=3D0 A20=3D1 = SMM=3D0 HLT=3D0 >>>> ES =3D0033 0000a000 ffffffff 00cff300 DPL=3D3 DS [-WA] >>>> CS =3D0008 00000000 ffffffff 00cf9a00 DPL=3D0 CS32 [-R-] >>>> SS =3D0010 00000000 ffffffff 00cf9300 DPL=3D0 DS [-WA] >>>> DS =3D0033 0000a000 ffffffff 00cff300 DPL=3D3 DS [-WA] >>>> FS =3D0033 0000a000 ffffffff 00cff300 DPL=3D3 DS [-WA] >>>> GS =3D0033 0000a000 ffffffff 00cff300 DPL=3D3 DS [-WA] >>>> LDT=3D0000 00000000 0000ffff 00008200 DPL=3D0 LDT >>>> TR =3D0038 00005f98 00002067 00008900 DPL=3D0 TSS32-avl >>>> GDT=3D ff85c789 00000000 >>>=20 >>> This seems wrong (address is way too high). I wonder if the gdtdesc = was=20 >>> trashed by something? Can you dump memory before the lgdtl = instruction at the=20 >>> 0x95d0 address? >>=20 >> 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 >>=20 >> Nevertheless doing stepi leads to exactly the same triple fault. >=20 >=20 > 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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. */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4735123C-E912-4D32-80D4-D057E2821626>