Date: Wed, 30 Apr 2014 16:50:01 GMT From: Steven Spence <freebsd@stratum16.com> To: freebsd-emulation@FreeBSD.org Subject: Re: kern/186051: [vmware] [panic] FreeBSD 8.4+, 9.x+, 10.0 guest panic with VMWare Server on boot Message-ID: <201404301650.s3UGo1CU071894@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/186051; it has been noted by GNATS.
From: Steven Spence <freebsd@stratum16.com>
To: John Baldwin <jhb@freebsd.org>
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: Wed, 30 Apr 2014 10:47:31 -0600
On 04/30/2014 10:09 AM, John Baldwin wrote:
> On Tuesday, April 29, 2014 10:13:20 pm Steven Spence wrote:
>> 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 <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.
>>>
>> 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 <cpu_idle_mwait+62>: monitor %eax,%ecx,%edx
> That's interesting. It's dying on monitor, not hlt.
>
> Can you capture the CPU lines from dmesg from a working kernel? I want to see
> if VMWare is advertising the ability to use monitor via cpuid.
>
> Also, try setting 'machdep.idle_mwait=0' at the loader prompt before booting to
> see if that fixes the panic.
>
Here is the requested information:
CPU: Quad-Core AMD Opteron(tm) Processor 2384 (2726.06-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4
Stepping = 2
Features=0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2>
Features2=0x802009<SSE3,MON,CX16,POPCNT>
AMD
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
AMD
Features2=0x37e9<LAHF,ExtAPIC,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
TSC: P-state invariant
Setting 'machdep.idle_mwait=0' did fix the panic. It successfully
booted into 8.4-STABLE with this option set. I am not sure what (if
any) ramifications this option causes but if there are little to none I
am fine with sticking this in my /boot/loader.conf and running with it.
If you feel there is a deeper/generic problem that still needs to be
worked out I can try to provide whatever information you need.
Thanks,
Steven
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404301650.s3UGo1CU071894>