From owner-freebsd-emulation@FreeBSD.ORG Wed Apr 30 02:20:01 2014 Return-Path: Delivered-To: freebsd-emulation@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E5CD30B for ; Wed, 30 Apr 2014 02:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1902E16D1 for ; Wed, 30 Apr 2014 02:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3U2K0CI046156 for ; Wed, 30 Apr 2014 02:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3U2K0F8046155; Wed, 30 Apr 2014 02:20:00 GMT (envelope-from gnats) Date: Wed, 30 Apr 2014 02:20:00 GMT Message-Id: <201404300220.s3U2K0F8046155@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org Cc: From: Steven Spence Subject: Re: kern/186051: [vmware] [panic] FreeBSD 8.4+, 9.x+, 10.0 guest panic with VMWare Server on boot X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Steven Spence List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 02:20:01 -0000 The following reply was made to PR kern/186051; it has been noted by GNATS. From: Steven Spence To: John Baldwin Cc: bug-followup@freebsd.org Subject: Re: kern/186051: [vmware] [panic] FreeBSD 8.4+, 9.x+, 10.0 guest panic with VMWare Server on boot Date: Tue, 29 Apr 2014 20:13:20 -0600 On 04/29/2014 01:43 PM, John Baldwin wrote: > On Monday, April 28, 2014 11:04:40 pm Steven Spence wrote: >> On 04/28/2014 08:32 AM, John Baldwin wrote: >>> On Monday, April 21, 2014 01:45:10 PM Steven Spence wrote: >>> >>>> Output of "sysctl machdep.idle" >>>> machdep.idle: amdc1e >>>> This is from a 8.3-RELEASE-p15 box. >>> Hummm. We really shouldn't be doing anything differently. However, we do a >>> >>> bit more (including a wrmsr) during idle halt on your machine. Can you >>> build >>> >>> a stable/8 kernel with debug symbols in an 8.3 guest and capture the panic >>> >>> messages from booting that kernel? >>> >>> >> Here is a capture of the panic from a stable/8 kernel. Is the only >> debugging option you are looking for in the kernel config >> "makeoptions DEBUG=-g"? I still have the 8.3 kernel on there I can >> boot if I need to get in and recompile the stable/8 kernel differently. >> I am not sure how much use the information below will be to you. >> >> kernel trap 1 with interrupts disabled >> Fatal trap 1: privileged instruction fault while in kernel mode >> cpuid = 0; apic id = 00 >> instruction pointer = 0x20:0xffffffff809c342e >> stack pointer = 0x28:0xffffff8000211b40 >> acd0: CDROM at ata1-master UDMA33 >> frame pointer = 0x28:0xffffff8000211b60 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 11 (idle: cpu0) >> trap number = 1 >> panic: privileged instruction fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff8067c0b6 at kdb_backtrace+0x66 >> #1 0xffffffff8064861e at panic+0x1ce >> #2 0xffffffff809d3750 at trap_fatal+0x290 >> #3 0xffffffff809d3ce5 at trap+0x105 >> #4 0xffffffff809ba944 at calltrap+0x8 >> #5 0xffffffff8066e08f at sched_idletd+0x11f >> #6 0xffffffff8061ceaf at fork_exit+0x11f >> #7 0xffffffff809bae8e at fork_trampoline+0xe >> Uptime: 1s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> I have also tried to dump the panic to a swap device but I don't think >> it is getting far enough in the kernel boot to initialize any hard drive >> storage devices. >> >> If there is anything else I can try to get more information out of this >> let me know. > If you have the result of this kernel build, can you find the kernel.debug > file it generated and run 'gdb kernel.debug' and then 'l *0xffffffff809c342e'? > That will (hopefully) identify the exact line it panic'd on. It might also > be useful to do 'x/i 0xffffffff809c342e' in gdb as well. > Below are the results of the two gdb commands: (gdb) l *0xffffffff809c342e 0xffffffff809c342e is in cpu_idle_mwait (cpufunc.h:470). 465 } 466 467 static __inline void 468 cpu_monitor(const void *addr, int extensions, int hints) 469 { 470 __asm __volatile("monitor;" 471 : :"a" (addr), "c" (extensions), "d"(hints)); 472 } 473 474 static __inline void (gdb) x/i 0xffffffff809c342e 0xffffffff809c342e : monitor %eax,%ecx,%edx Thanks, Steven