Mark Millard
2018-Oct-20 08:39 UTC
head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated
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. It fails just after the FreeBSD/SMP lines, reporting "kernel trap 9 with interrupts disabled". 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=0 apic id= 00 I used kernel.txz files from: https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ to narrow the range of kernel builds for working -> failing and got: -r338804 boots fine (no amd64 kernel builds between to try) -r338810+ fails (any that I tried, anyway) In that range is -r338807 : QUOTE Author: kib Date: Wed Sep 19 19:35:02 2018 New Revision: 338807 URL: https://svnweb.freebsd.org/changeset/base/338807 Log: Convert x86 cache invalidation functions to ifuncs. This simplifies the runtime logic and reduces the number of runtime-constant branches. Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation Approved by: re (gjb) Differential revision: https://reviews.freebsd.org/D16736 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 There do seem to be changes associated with clflush(...) use. Looking at: https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432 it appears that pmap_force_invalidate_cache_range has not changed since -r338807. It seems that -r338806 and -r3388810 would be unlikely contributors. ==Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Mark Millard
2018-Oct-20 09:09 UTC
head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated
On 2018-Oct-20, at 1:39 AM, Mark Millard <marklmi at yahoo.com> wrote:> 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.I did my investigation under Hyper-V after seeing a boot failure native. Looks like the native failure is even earlier, before db> is even possible, possibly during early loader activity. 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.) Sorry for the confusion. I rushed the report in hopes of getting to sleep. It was not to be.> It fails just after the FreeBSD/SMP lines, > reporting "kernel trap 9 with interrupts disabled". > > 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=0 apic id= 00 > > I used kernel.txz files from: > > https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ > > to narrow the range of kernel builds for working -> failing > and got: > > -r338804 boots fine > (no amd64 kernel builds between to try) > -r338810+ fails (any that I tried, anyway) > > In that range is -r338807 : > > QUOTE > Author: kib > Date: Wed Sep 19 19:35:02 2018 > New Revision: 338807 > URL: > https://svnweb.freebsd.org/changeset/base/338807 > > > Log: > Convert x86 cache invalidation functions to ifuncs. > > This simplifies the runtime logic and reduces the number of > runtime-constant branches. > > Reviewed by: alc, markj > Sponsored by: The FreeBSD Foundation > Approved by: re (gjb) > Differential revision: > https://reviews.freebsd.org/D16736 > > 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 > > There do seem to be changes associated with > clflush(...) use. Looking at: > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432 > > it appears that pmap_force_invalidate_cache_range has not > changed since -r338807. > > It seems that -r338806 and -r3388810 would be unlikely > contributors.==Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)