From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 23 17:34:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78BD52F3; Tue, 23 Apr 2013 17:34:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 524CF12D9; Tue, 23 Apr 2013 17:34:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54E80B926; Tue, 23 Apr 2013 13:34:30 -0400 (EDT) From: John Baldwin To: Andriy Gapon Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation Date: Tue, 23 Apr 2013 12:31:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130419162834.GA90217@icarus.home.lan> <006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E@FreeBSD.org> <5176B238.7030306@FreeBSD.org> In-Reply-To: <5176B238.7030306@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304231231.38765.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 23 Apr 2013 13:34:30 -0400 (EDT) Cc: Jeremy Chadwick , freebsd-hackers@freebsd.org, Joshua Isom , Dimitry Andric 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 17:34:32 -0000 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? -- John Baldwin