The following reply was made to PR kern/186051; it has been noted by GNATS.
From: John Baldwin <j...@freebsd.org> To: Steven Spence <free...@stratum16.com> Cc: bug-follo...@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 15:43:16 -0400 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 <VMware Virtual IDE CDROM Drive/00000001> 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. -- John Baldwin _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
