amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in
certain KVM environments
Konstantin Belousov
kostikbel at gmail.com
Sun Aug 5 14:00:06 UTC 2012
The following reply was made to PR amd64/170388; it has been noted by GNATS.
From: Konstantin Belousov <kostikbel at gmail.com>
To: Jimmy Olgeni <olgeni at freebsd.org>
Cc: FreeBSD-gnats-submit at freebsd.org, jkim at freebsd.org
Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments
Date: Sun, 5 Aug 2012 16:55:18 +0300
--USJBhEEH8TT+Is94
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 05, 2012 at 11:31:11AM +0200, Jimmy Olgeni wrote:
>=20
> >Number: 170388
> >Category: amd64
> >Synopsis: 8-STABLE amd64 past r233799 is unable to boot in certain=
KVM environments
> >Confidential: no
> >Severity: critical
> >Priority: high
> >Responsible: freebsd-amd64
> >State: open
> >Quarter: =20
> >Keywords: =20
> >Date-Required:
> >Class: sw-bug
> >Submitter-Id: current-users
> >Arrival-Date: Sun Aug 05 09:40:02 UTC 2012
> >Closed-Date:
> >Last-Modified:
> >Originator: Jimmy Olgeni
> >Release: FreeBSD 8.3-STABLE amd64
> >Organization:
> >Environment:
> >Description:
>=20
> FreeBSD 8-STABLE is unable to boot in some KVM environments after r233799.
>=20
> ------------------------------------------------------------------------
> r233799 | jkim | 2012-04-02 20:27:06 +0200 (Mon, 02 Apr 2012) | 4 lines
>=20
> MFC: r233702
>=20
> Work around Erratum 721 for AMD Family 10h and 12h processors.
>=20
> ------------------------------------------------------------------------
>=20
> The following panic message is shown immediately after the kernel starts:
>=20
> =3D=3D=3D
> kernel trap 9 with interrupts disabled
>=20
> Fatal trap 9: general protection fault while in kernel mode
> cpuid =3D 0; apic id =3D 00
> instruction pointer =3D 0x20:0xffffffff808fd8dc
> stack pointer =3D 0x28:0xffffffff80cd5440
> frame pointer =3D 0x28:0xffffffff80cd5470
> code segment =3D base 0x0, limit 0xfffff, type 0x1b
> =3D DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags =3D resume, IOPL =3D 0
> current process =3D 0 ()
> trap number =3D 9
> panic: general protection fault
> cpuid =3D 0
> KDB: stack backtrace:
> #0 0xffffffff8064e18e at ??+0
> #1 0xffffffff8061b247 at ??+0
> #2 0xffffffff80912ca0 at ??+0
> #3 0xffffffff80913235 at ??+0
> #4 0xffffffff808faad4 at ??+0
> #5 0xffffffff80904cc2 at ??+0
> #6 0xffffffff801a0244 at ??+0
> =3D=3D=3D
>=20
> When booting from the latest 8-STABLE branch the booting process
> just halts after the first panic line.
>=20
> The same problem can be observed in 9-STABLE, but I did not actually
> bisect all the way to the relevant commit yet. However, r233702
> seems a reasonable guess.
>=20
> Once the system is booted by reverting r233799, the following
> processor information can be read:
>=20
> CPU: Six-Core AMD Opteron(tm) Processor 2427 (2211.49-MHz K8-class CP=
U)
> Origin =3D "AuthenticAMD" Id =3D 0x100f80 Family =3D 10 Model =
=3D 8 Stepping =3D 0
> Features=3D0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MT=
RR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2>
> Features2=3D0x80802001<SSE3,CX16,POPCNT,HV>
> AMD Features=3D0xe6500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,LM,3DNow!+,=
3DNow!>
> AMD Features2=3D0x1f7<LAHF,CMP,SVM,CR8,ABM,SSE4A,MAS,Prefetch>
> TSC: P-state invariant
>=20
> Also, using x86info:
>=20
> x86info v1.30. Dave Jones 2001-2011
> Feedback to <davej at redhat.com>.
>=20
> Extended Family: 1 Extended Model: 0 Family: 15 Model: 8 Stepping: 0
> CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion (II)/O=
pteron (HY-D0)
> Processor name string (BIOS programmed): Six-Core AMD Opteron(tm) Pro=
cessor 2427
>=20
> Monitor/Mwait: min/max line size 0/0, ecx bit 0 support, enumeration =
extension
> SVM: revision 1, 16 ASIDs, np, NRIPSave
> Address Size: 48 bits virtual, 40 bits physical
> running at an estimated 2.35GHz
>=20
> Unfortunately I have no detailed information about the QEMU
> configuration, but I set up a dedicated VM that I could use to test
> patches.
Try this. Comment should give enough explanation what happens there, my
guess anyway.
diff --git a/sys/amd64/amd64/initcpu.c b/sys/amd64/amd64/initcpu.c
index 3890551..dbeaec6 100644
--- a/sys/amd64/amd64/initcpu.c
+++ b/sys/amd64/amd64/initcpu.c
@@ -91,11 +91,17 @@ init_amd(void)
*
* http://support.amd.com/us/Processor_TechDocs/41322_10h_Rev_Gd.pdf
* http://support.amd.com/us/Processor_TechDocs/44739_12h_Rev_Gd.pdf
+ *
+ * Hypervisors do not provide access to the errata MSR,
+ * causing #GP exception on attempt to apply the errata. The
+ * MSR write shall be done on host and persist globally
+ * anyway, so do not try to do it when under virtualization.
*/
switch (CPUID_TO_FAMILY(cpu_id)) {
case 0x10:
case 0x12:
- wrmsr(0xc0011029, rdmsr(0xc0011029) | 1);
+ if ((cpu_feature2 & CPUID2_HV) =3D=3D 0)
+ wrmsr(0xc0011029, rdmsr(0xc0011029) | 1);
break;
}
}
--USJBhEEH8TT+Is94
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAlAee0UACgkQC3+MBN1Mb4gWWACg6fxUCW+uah3gPZZxiqTEtH8j
G+oAoMXjm4aBYfLr8af7cCc3PwWL/kXX
=yeJJ
-----END PGP SIGNATURE-----
--USJBhEEH8TT+Is94--
More information about the freebsd-amd64
mailing list