AW: GENERIC crash 11.3-PRERELEASE (i386)

Thu Jul 4 09:56:09 UTC 2019

Hello Konstantin,

I did what you suggested: deleted the content of /usr/src and 'svn co'
the 11-STABLE sources again.

Currently 'make buildworld' still runs, but I investigated the three
source files mentioned below and confirmed the 'svn diff' results:

"hw_mds_recalculate();" has been removed from

	sys/amd64/amd64/initcpu.c	and
	sys/i386/i386/initcpu.c

and:

"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);"

has been inserted into 'sys/x86/x86/cpu_machdep.c'

That's still the case for 'r349719'.

Did you misunderstand the "+" and "-" signs below? 

"+" was the *working* copy, that is 'r348361'
"-" was the next revision 'r384362', which produced the kernel crash

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: Mittwoch, 3. Juli 2019 15:55
An: Schuendehuette, Matthias (LDA IT PLM) <matthias.schuendehuette at siemens.com>
Cc: 'freebsd-stable at freebsd.org' <freebsd-stable at freebsd.org>; Osipov, Michael (LDA IT PLM) <michael.osipov at siemens.com>
Betreff: Re: GENERIC crash 11.3-PRERELEASE (i386)

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.