Date: Mon, 08 Aug 2016 00:13:05 +0000 From: bugzilla-noreply@freebsd.org To: vbox@FreeBSD.org Subject: maintainer-feedback requested: [Bug 211651] emulators/virtualbox-ose-kmod 5.0.26_1 with Linux guest crashes 12.0-CURRENT host when # of processors > 1 Message-ID: <bug-211651-26505-dkM0FiIFi6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211651-26505@https.bugs.freebsd.org/bugzilla/> References: <bug-211651-26505@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis <truckman@FreeBSD.org> has reassigned Bugzilla Automation <bugzilla@FreeBSD.org>'s request for maintainer-feedback to vbox@FreeBSD.or= g: Bug 211651: emulators/virtualbox-ose-kmod 5.0.26_1 with Linux guest crashes 12.0-CURRENT host when # of processors > 1 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211651 --- Description --- If I attempt to start a Linux guest on a FreeBSD 12.0-CURRENT host I get a kernel panic similar to: panic: Unregistered use of FPU in kernel cpuid =3D 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a31c= 030 vpanic() at vpanic+0x182/frame 0xfffffe085a31c0b0 kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a31c120 trap() at trap+0x7ae/frame 0xfffffe085a31c330 calltrap() at calltrap+0x8/frame 0xfffffe085a31c330 --- trap 0x16, rip =3D 0xffffffff827273a9, rsp =3D 0xfffffe085a31c408, rbp = =3D 0xfffff e085a31c430 --- null_bug_bypass() at 0xffffffff827273a9/frame 0xfffffe085a31c430 null_bug_bypass() at 0xffffffff826985c7/frame 0x3 KDB: enter: panic if the VM is configured with more than one processor. I've seen this with = both CentOS 7 and Ubuntu 12 guests. The panic appears to occur near the start of the guest kernel boot after grub has run. It appears to happen shortly aft= er the kernel message about TSC calibration is printed. The symbols printed by DDB leading up to the trap appear to be somewhat arbitrary. The location of the trap seems to be aboe the topmost BSS section symbol in one of the (las= t?) loaded .kmod. The code at the location that triggers the trap is: 0xffffffff8272739d: nop 0xffffffff8272739e: nop 0xffffffff8272739f: nop 0xffffffff827273a0: mov %rsi,%rdx 0xffffffff827273a3: shr $0x20,%rdx 0xffffffff827273a7: mov %esi,%eax =3D> 0xffffffff827273a9: xrstor (%rdi) 0xffffffff827273ac: retq=20=20=20 0xffffffff827273ad: int3=20=20=20 0xffffffff827273ae: int3=20=20=20 0xffffffff827273af: int3=20=20=20 0xffffffff827273b0: int3 It is called from here: 0xffffffff82667489: test %eax,%eax 0xffffffff8266748b: jne 0xffffffff826674a1 0xffffffff8266748d: movq $0x3,0x5238(%r15) 0xffffffff82667498: mov %rbx,%rsi 0xffffffff8266749b: and $0xfffffffffffffffc,%rsi 0xffffffff8266749f: je 0xffffffff826674ad 0xffffffff826674a1: mov 0x5240(%r15),%rdi 0xffffffff826674a8: callq 0xffffffff827273a0 =3D> 0xffffffff826674ad: or %rbx,0x5238(%r15) 0xffffffff826674b4: mov %r14d,%eax 0xffffffff826674b7: add $0x8,%rsp kgdb (from ports) doesn't believe that either of these to any function. The VMs where I first saw the problem were initially created with Virtualbo= x 4 and the paravirtualization setting is "Legacy", but I can reproduce this pa= nic after creating a new VM which uses the "Default" setting, increasing the nu= mber of processors to 4, and booting the CentOS 7 install .iso. The CPU info is: CPU: AMD FX-8320E Eight-Core Processor (3210.84-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x600f20 Family=3D0x15 Model=3D0x2 Stepp= ing=3D0 =20 Features=3D0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,= MCA,C MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> =20 Features2=3D0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPC= NT,AE SNI,XSAVE,OSXSAVE,AVX,F16C> AMD Features=3D0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> AMD Features2=3D0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,I BS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC> Structured Extended Features=3D0x8<BMI1> SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=3D65536 TSC: P-state invariant, performance statistics Whether or not this problem occurs with Intel CPUs is unknown. This problem did not occur before the upgrade from Virtualbox 4 to Virtualb= ox 5.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211651-26505-dkM0FiIFi6>