From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 23 16:09:33 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 4512FA08; Tue, 23 Apr 2013 16:09:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 27C7B1E2F; Tue, 23 Apr 2013 16:09:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA19010; Tue, 23 Apr 2013 19:09:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5176B238.7030306@FreeBSD.org> Date: Tue, 23 Apr 2013 19:09:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dimitry Andric , John Baldwin Subject: Re: Rebooting from loader causes a "fault" in VMware Workstation References: <20130419162834.GA90217@icarus.home.lan> <20130420014821.GA98555@icarus.home.lan> <5172812A.10309@gmail.com> <201304221129.43119.jhb@freebsd.org> <006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E@FreeBSD.org> In-Reply-To: <006B20F1-F67B-4E9D-B0DF-D4ED843F7E8E@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 16:09:33 -0000 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 IDT= 00005e00 00000197 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000001 CCD=00000000 CCO=LOGICL EFER=0000000000000000 -- Andriy Gapon