From owner-freebsd-current@freebsd.org Mon Oct 22 02:55:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BDAFFD9A49 for ; Mon, 22 Oct 2018 02:55:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9838883D21 for ; Mon, 22 Oct 2018 02:55:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VhEc3yYVM1k27JbELO4NkN7laW5z9kZeYwLQiUT6T.uyBpPw_0X33QJ0Y9exs52 yHjduUpNNJZ1Al4NKZh3p5drtqSW8Sxg92C6dVmaepk7IbYGz7e9xtO91p.S8OFSHkurb2xYQZ0. VbAeCfozjVG3uzidMiCmJ72bo7OhGdOiT.ESPt77Gp1GixbYXXZ7nnf0MloJxOsFLXoY_INH8Vke 4JBOCBWqAU.MSKevbmGbQnO3CSK0F_891BlvTT1Uu0PtWLZm70N6KEJUd_ByvH9iCw253VZ.73ch TuTNDsx1QVbmF67SOFuIIi5xrvB0YeF99w_wyxw3X5UXetArI0SoUqeNGXTRubzoUSUiPWP5FdB5 F7gJuLQWZh2xXRz8Il5O0ZxNeD.LjN4hW06X5MCyZG9lpKFwAW1v4uMRliaXfsYhz.55zIfqRhjC DFDThFihasvl5PtEP.eAXMDHEOT9_wLMlgjE_67pQ9Rk7t4i4dSBTsRfbcj891Fui5s_qptE28P. YgYc.LlB.zYxzoFpw6Lxzqj3Z4WRGN9MmMSAzawXkKNEc6Z7T0lfNgVw8Mq31n.Hhuen3VH_wAnB pWEQn_Q_tZJrGCQRwgDiJb9Y13EHDo77qClRxZmDeNSG9uae6U2oRdP2U9xM4YlIqaNiJZPEAkM3 BhvbVRqlDfB8V56Q0RWktd8gIgbEi70W13mon_A8WVlBC13G_nEI_Ib0hkoZ4OzqYWxnEdCbHsT1 voDYbKSUdp6TPNVv8b08i.t7fRwY.mEzU5STqw.psxCu1.DeA5ad5ifsDezXvk8uWc.DHIGFIGNF iXVCX7Zbx2xCSud2VGbYWhZCfkqsYU6_5hk3rCmfYS2L_7kGdPa32ywCWNnVLy4gQnr699hIKOw2 XzT.Iq.hpcC7fQoZcBC4JVEVtLAGRXw6qfyaQR5Y8TevBM_q4k3qW9OWD_GxO968F5KTJRoPGK2w PgwReTKid3O72BiDX.8EcUisQM.4e.GUWxiE6taro893QLR4eOWNEn4fyvppTjPptZSO0EXH7c_n EfCBx9Wkrarnxltpg9_XqJ59m.XN_3DYTXApZYPFIFFzBqKTnrRNhE9HkwGPDTMIq7aOd1mKfgq1 ._Z58 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 Oct 2018 02:55:49 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 804ecb38ee3d4126093554721b6b1f8d; Mon, 22 Oct 2018 02:55:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated Date: Sun, 21 Oct 2018 19:55:45 -0700 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> To: Konstantin Belousov , FreeBSD Current , freebsd-stable@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 02:55:57 -0000 [I built based on WITHOUT_ZFS=3D for other reasons. But, after installing the build, Hyper-V based boots are working.] On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: > On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: >=20 >> I attempted to jump from head -r334014 to -r339076 >> on a threadripper 1950X board and the boot fails. >> This is both native booting and under Hyper-V, >> same machine and root file system in both cases. >=20 > I did my investigation under Hyper-V after seeing > a boot failure native. >=20 > Looks like the native failure is even earlier, > before db> is even possible, possibly during > early loader activity. >=20 > So this report is really for running under > Hyper-V: -r338804 boots and -r338810 does > not. By contrast -r334804 does not boot native. > (But I've little information for that context.) >=20 > Sorry for the confusion. I rushed the report > in hopes of getting to sleep. It was not to be. >=20 >> It fails just after the FreeBSD/SMP lines, >> reporting "kernel trap 9 with interrupts disabled". >>=20 >> It fails in pmap_force_invaldiate_cache_range at >> a clflusl (%rax) instruction that produces a >> "Fatal trap 9: general protection fault while >> in kernel mode". cpudid=3D0 apic id=3D 00 >>=20 >> I used kernel.txz files from: >>=20 >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >>=20 >> to narrow the range of kernel builds for working -> failing >> and got: >>=20 >> -r338804 boots fine >> (no amd64 kernel builds between to try) >> -r338810+ fails (any that I tried, anyway) >>=20 >> In that range is -r338807 : >>=20 >> QUOTE >> Author: kib >> Date: Wed Sep 19 19:35:02 2018 >> New Revision: 338807 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/338807 >>=20 >>=20 >> Log: >> Convert x86 cache invalidation functions to ifuncs. >>=20 >> This simplifies the runtime logic and reduces the number of >> runtime-constant branches. >>=20 >> Reviewed by: alc, markj >> Sponsored by: The FreeBSD Foundation >> Approved by: re (gjb) >> Differential revision:=09 >> https://reviews.freebsd.org/D16736 >>=20 >> Modified: >> head/sys/amd64/amd64/pmap.c >> head/sys/amd64/include/pmap.h >> head/sys/dev/drm2/drm_os_freebsd.c >> head/sys/dev/drm2/i915/intel_ringbuffer.c >> head/sys/i386/i386/pmap.c >> head/sys/i386/i386/vm_machdep.c >> head/sys/i386/include/pmap.h >> head/sys/x86/iommu/intel_utils.c >> END QUOTE >>=20 >> There do seem to be changes associated with >> clflush(...) use. Looking at: >>=20 >> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >>=20 >> it appears that pmap_force_invalidate_cache_range has not >> changed since -r338807. >>=20 >> It seems that -r338806 and -r3388810 would be unlikely >> contributors. >=20 I went after my native-boot loader problem first because I could switch kernels via the loader for booting FreeBSD under Hyper-V. Switching loaders is more of a problem. In order to avoid the loader-time crash I switched to building installing based on WITHOUT_ZFS=3D . I've had no active use of ZFS in years. (The old official-build loaders that worked were non-ZFS ones.) This took care of the native-boot loader-crash --and, to my surprise, also the Hyper-V-boot kernel-time crash. My private builds now boot the 1950X in both contexts just fine. During my early investigation I did pick up specific changes from after -r339076 that seemed to be tied to Ryzen and such. (They made no difference to the boot problems at the time but I saw no reason to remove them.) # uname -apKU FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun = Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG amd64 amd64 1200084 1200084 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)