On Wed, Jul 03, 2019 at 08:42:21AM +0000, Schuendehuette, Matthias
wrote:> Hello Konstantin,
>
> I did some research regarding the kernel crash with the following
results>
>
> 1) Last working kernel is:
>
> "FreeBSD 11.3-BETA1 (BLNN719X) #8 r348361: Wed Jul 3 09:30:17 CEST
2019"
>
> 1a) DDB-Backtrace of the crashing kernel r348362 can be seen on
"Boot_BT.jpg"
> in the dropbox directory
>
"https://www.dropbox.com/sh/buzxekimo2h2r67/AADpUvLndhm2SHa5t9s9Ckksa?dl=0"
>
>
> 2) Source code revision is:
>
> root at blnn719x - /usr/src
> 2056 # svn info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/stable/11
> Relative URL: ^/stable/11
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 348361
> Node Kind: directory
> Schedule: normal
> Last Changed Author: jkim
> Last Changed Rev: 348343
> Last Changed Date: 2019-05-29 02:00:52 +0200 (Wed, 29 May 2019)
>
>
> 3) Diff to next revision:
>
> root at blnn719x - /usr/src
> 2057 # svn diff -r 348362
> Index: sys/amd64/amd64/initcpu.c
> ==================================================================> ---
sys/amd64/amd64/initcpu.c (revision 348362)
> +++ sys/amd64/amd64/initcpu.c (working copy)
> @@ -247,6 +247,7 @@
> }
> hw_ibrs_recalculate();
> hw_ssb_recalculate(false);
> + hw_mds_recalculate();
> switch (cpu_vendor_id) {
> case CPU_VENDOR_AMD:
> init_amd();
> Index: sys/i386/i386/initcpu.c
> ==================================================================> ---
sys/i386/i386/initcpu.c (revision 348362)
> +++ sys/i386/i386/initcpu.c (working copy)
> @@ -769,6 +769,7 @@
> elf32_nxstack = 1;
> }
> #endif
> + hw_mds_recalculate();
> if ((amd_feature & AMDID_RDTSCP) != 0 ||
> (cpu_stdext_feature2 & CPUID_STDEXT2_RDPID) != 0)
> wrmsr(MSR_TSC_AUX, PCPU_GET(cpuid));
> Index: sys/x86/x86/cpu_machdep.c
> ==================================================================> ---
sys/x86/x86/cpu_machdep.c (revision 348362)
> +++ sys/x86/x86/cpu_machdep.c (working copy)
> @@ -1118,14 +1118,6 @@
> }
> }
>
> -static void
> -hw_mds_recalculate_boot(void *arg __unused)
> -{
> -
> - hw_mds_recalculate();
> -}
> -SYSINIT(mds_recalc, SI_SUB_SMP, SI_ORDER_ANY, hw_mds_recalculate_boot,
NULL);
> -
> static int
> sysctl_mds_disable_handler(SYSCTL_HANDLER_ARGS)
> {
> Index: .
> ==================================================================> ---
. (revision 348362)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> ## -0,1 +0,0 ##
> Reverse-merged /head:r348075
>
>
>
> Somewhere here is the problem...
Definitely, there is some problem, but I doubt that it is due to the
revision in the svn. The diff above is the reverse of the stable/11
r348362 that was committed on 2019-05-29. Indeed, the missed (or
reverted) r348362 would cause exactly the symptoms you described with
failing AP startup.
I have no idea why do you have the change reverted with merge info, in
your sources. Clean up and retry with pristine tree.
>
>
>
>
> with best regards
> Matthias Sch?ndeh?tte
>
> Siemens AG
> Large Drives Applications
> Information Technology
> Information Technology Product Lifecycle Management
> LDA IT PLM
> Nonnendammallee 72
> 13629 Berlin, Deutschland
> Tel.: +49 30 386-29957
> Mobil: +49 170 8162912
> mailto:matthias.schuendehuette at siemens.com
>
> www.siemens.com/ingenuityforlife
>
> -----Urspr?ngliche Nachricht-----
> Von: Konstantin Belousov <kostikbel at gmail.com>
> Gesendet: Donnerstag, 27. Juni 2019 21:00
> An: Schuendehuette, Matthias (LDA IT PLM) <matthias.schuendehuette at
siemens.com>
> Cc: 'freebsd-stable at freebsd.org' <freebsd-stable at
freebsd.org>
> Betreff: Re: GENERIC crash 11.3-PRERELEASE (i386)
>
> On Thu, Jun 27, 2019 at 07:11:40AM +0000, Schuendehuette, Matthias wrote:
> > Hi,
> >
> > the missing attachments can be found here now:
> >
> >
https://www.dropbox.com/sh/buzxekimo2h2r67/AADpUvLndhm2SHa5t9s9Ckksa?dl=0
> >
> So your AP (Application Processor) seems to get fault, most likely in the
> trap handler. There were absolutely no changes in the stable/11 in the
> area of SMP startup for quite long time.
>
> To get anywhere, you should perhaps add ddb to your kernel configuration
> and get the backtrace. The backtrace would be long, I am only interested
> in the first several frames before faults go into recursion.
>
> But, since 1 month earlier kernel worked, and there were no changes, this
> might indicate either a failing hardware (your machine is quite old, it
> is Core2 Xeon, am I right ?) or problems with your build environment.