From owner-svn-src-all@freebsd.org Fri May 13 15:11:18 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C039BB391EE; Fri, 13 May 2016 15:11:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (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 92173126B; Fri, 13 May 2016 15:11:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u4DFBH6e090191; Fri, 13 May 2016 15:11:17 GMT (envelope-from bz@FreeBSD.org) Received: (from bz@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u4DFBH5k090190; Fri, 13 May 2016 15:11:17 GMT (envelope-from bz@FreeBSD.org) Message-Id: <201605131511.u4DFBH5k090190@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bz set sender to bz@FreeBSD.org using -f From: "Bjoern A. Zeeb" Date: Fri, 13 May 2016 15:11:17 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r299678 - head/sys/x86/x86 X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:11:18 -0000 Author: bz Date: Fri May 13 15:11:17 2016 New Revision: 299678 URL: https://svnweb.freebsd.org/changeset/base/299678 Log: We already turn the AMD erratum383 workaround on for certain VM_GUEST_VM if specific CPU features are not present. Some simulation environments, e.g. gem5, have been found to require more TLB management from the kernel in certain setups. It is currently unclear why. Turning on the workaround_erratum383 seems to help and make problems (panics) go away. Given this is a fairly uncommon environment so far, allowing the workaround to be manually enabled from loader in order to make debugging and comparing traces easier, but also to allow gem5 run FreeBSD in X86 timing mode, seems to be the least intrusive option for now until the issue if fully understood. Sponsored by: DARPA/AFRL Reviewed by: kib, alc (earlier) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6206 Modified: head/sys/x86/x86/mca.c Modified: head/sys/x86/x86/mca.c ============================================================================== --- head/sys/x86/x86/mca.c Fri May 13 15:09:38 2016 (r299677) +++ head/sys/x86/x86/mca.c Fri May 13 15:11:17 2016 (r299678) @@ -104,7 +104,8 @@ SYSCTL_INT(_hw_mca, OID_AUTO, intel6h_HS "Administrative toggle for logging of spurious corrected errors"); int workaround_erratum383; -SYSCTL_INT(_hw_mca, OID_AUTO, erratum383, CTLFLAG_RD, &workaround_erratum383, 0, +SYSCTL_INT(_hw_mca, OID_AUTO, erratum383, CTLFLAG_RD|CTLFLAG_RDTUN, + &workaround_erratum383, 0, "Is the workaround for Erratum 383 on AMD Family 10h processors enabled?"); static STAILQ_HEAD(, mca_internal) mca_freelist;