From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 23 22:03:14 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF933D98; Tue, 23 Apr 2013 22:03:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 96F3011B3; Tue, 23 Apr 2013 22:03:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::106e:515:ef78:2c64] (unknown [IPv6:2001:7b8:3a7:0:106e:515:ef78:2c64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EB4415C45; Wed, 24 Apr 2013 00:03:10 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation From: Dimitry Andric In-Reply-To: <51770149.6020802@FreeBSD.org> Date: Wed, 24 Apr 2013 00:03:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Andriy Gapon X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , freebsd-hackers@FreeBSD.org, Joshua Isom X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:03:14 -0000 On Apr 23, 2013, at 23:46, Andriy Gapon 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. 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)?