Re: GENERIC crash 11.3-PRERELEASE (i386)

2019-07-10 Thread Schuendehuette, Matthias (LDA IT PLM)

Hello Konstantin,

the 'svn' output:

*
root@blnn719x - /usr/src
2052 # svn st
?   sys/i386/conf/BLNN719X

root@blnn719x - /usr/src
2053 # 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: 349719
Node Kind: directory
Schedule: normal
Last Changed Author: delphij
Last Changed Rev: 349718
Last Changed Date: 2019-07-04 09:32:25 +0200 (Thu, 04 Jul 2019)
*

The last lines of the verbose boot messages can be found here:

https://www.dropbox.com/preview/FreeBSD-stable/Boot_verbose.jpg


Thank you very much so far

Matthias


Am 05.07.2019 um 21:11 schrieb Konstantin Belousov:

On Fri, Jul 05, 2019 at 11:12:29AM +, Schuendehuette, Matthias wrote:

Hello Konstantin,

***
Obviously Outlook has destroyed my last reply - here again:
***

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

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'. Also remains true that a kernel of
'r349719' crashes as described earlier.

Ok, show me
1. svn st and svn info output of the checkout you use
2. While kernel messages with verbose boot enabled, for your machine, and
the kernel which fails to boot.


With best regards and have a nice weekend

Matthias Schuendehuette




-Ursprüngliche Nachricht-
Von: Konstantin Belousov  
Gesendet: Mittwoch, 3. Juli 2019 15:55

An: Schuendehuette, Matthias (LDA IT PLM)
Cc: 'freebsd-stable@freebsd.org'; Osipov, Michael (LDA IT 
PLM)
Betreff: Re: GENERIC crash 11.3-PRERELEASE (i386)

On Wed, Jul 03, 2019 at 08:42:21AM +, 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@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@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. I

Re: GENERIC crash 11.3-PRERELEASE (i386)

2019-07-10 Thread Schuendehuette, Matthias (LDA IT PLM)

Sorry, wrong link... :-(

See the verbose boot messages here...

https://www.dropbox.com/sh/buzxekimo2h2r67/AADpUvLndhm2SHa5t9s9Ckksa?dl=0

...in file "Boot_verbose.jpg"

Regards - Matthias


Am 10.07.2019 um 14:47 schrieb [ext] Schuendehuette, Matthias (LDA IT PLM):

Hello Konstantin,

the 'svn' output:

*
root@blnn719x - /usr/src
2052 # svn st
?   sys/i386/conf/BLNN719X

root@blnn719x - /usr/src
2053 # 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: 349719
Node Kind: directory
Schedule: normal
Last Changed Author: delphij
Last Changed Rev: 349718
Last Changed Date: 2019-07-04 09:32:25 +0200 (Thu, 04 Jul 2019)
*

The last lines of the verbose boot messages can be found here:

https://www.dropbox.com/preview/FreeBSD-stable/Boot_verbose.jpg


Thank you very much so far

Matthias


Am 05.07.2019 um 21:11 schrieb Konstantin Belousov:
On Fri, Jul 05, 2019 at 11:12:29AM +, Schuendehuette, Matthias 
wrote:

Hello Konstantin,

***
Obviously Outlook has destroyed my last reply - here again:
***

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

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'. Also remains true that a kernel of
'r349719' crashes as described earlier.

Ok, show me
1. svn st and svn info output of the checkout you use
2. While kernel messages with verbose boot enabled, for your machine, 
and

    the kernel which fails to boot.


With best regards and have a nice weekend

Matthias Schuendehuette




-Ursprüngliche Nachricht-
Von: Konstantin Belousov Gesendet: Mittwoch, 3. 
Juli 2019 15:55
An: Schuendehuette, Matthias (LDA IT 
PLM)
Cc: 'freebsd-stable@freebsd.org'; 
Osipov, Michael (LDA IT PLM)

Betreff: Re: GENERIC crash 11.3-PRERELEASE (i386)

On Wed, Jul 03, 2019 at 08:42:21AM +, 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@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@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

Re: RELENG_10 to RELENG11 buildworld no possible ?

2019-07-10 Thread Dimitry Andric
On 9 Jul 2019, at 19:02, Warner Losh  wrote:
> On Tue, Jul 9, 2019 at 12:12 AM Dimitry Andric  wrote:
>> On 9 Jul 2019, at 08:08, Warner Losh  wrote:
...
>>> Could you look into what the new requirement is? If there's no simple
>> workaround, I'd like to at least document what the minimum is better than I
>> have.
>> 
>> Okay,
>> http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#minimum-required-compiler-version
>> says:
>> 
>> Clang   3.5
>> Apple Clang 6.0
>> GCC 5.1
>> Visual Studio   2017
>> 
> 
> OK, so the clang in releng10 is 3.4.1. I'll update the note then.

I committed a workaround in r349876, which makes it possible to directly
build clang 8.0.0 with clang 3.4.1, and will MFC that after the usual
timeout.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Random panics in 11.0 and 12.0 on J1900

2019-07-10 Thread James Snow
I have a set of J1900 hosts running 11.0-RELEASE-p1 that experience
seemingly random panics. The panics are all basically the same:

Fatal trap 12: page fault while in kernel mode
fault code = supervisor read data, page not present

Adding workloads to the hosts seems to increase panic frequency, but the
panics have also occurred on completely idle hosts. Similarly, uptime
when panicking has been as low as minutes, and as high as ~620 days.

For reasons, it has not been possible to extract a coredump from these
hosts, nor practical to run memtest on them or upgrade them to a newer
release. About 1% of our hosts are affected each day, so we've just been
living with the problem.

However, while testing 12.0 on the same hardware, I encountered the same
panic and was able to capture the core dump. (See below.)

All of my Google-fu on this panic has turned up threads suggesting the
problem is hardware, but there are two problems with that idea...

One, memtest has turned up no errors on 12.0 host I witnessed the panic
on.

Two, a small number of systems on the same hardware are running
10.3-RELEASE, and have experienced no panics in their history. Panics
have only happened on 11s, and now 12.

kgdb output from the panic follows. (This particular host was in the
middle of rebooting when it panicked.)

Hoping someone here has some insight. My uninformed wild-ass guess is
something relating to spectre/meltdown fixes.

Thanks,


-Snow



root@j1900_12:~ # kgdb /boot/kernel/kernel /var/crash/vmcore.0
GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
<118>.
<118>Terminated
<118>Jul 10 07:03:50 j1900_12 syslogd: last message repeated 9 times
<118>Jul 10 07:04:08 j1900_12 syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 done
Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... done
All buffers synced.
Uptime: 23h22m43s
umass0: detached
ukbd0: detached
uhid0: detached
uhub3: detached
uhub2: detached


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x3201c450
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b7ad1d
stack pointer   = 0x28:0xfe003f231820
frame pointer   = 0x28:0xfe003f231890
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1 (init)
trap number = 12
panic: page fault
cpuid = 0
time = 1562742255
KDB: stack backtrace:
#0 0x80be7977 at kdb_backtrace+0x67
#1 0x80b9b563 at vpanic+0x1a3
#2 0x80b9b3b3 at panic+0x43
#3 0x8107496f at trap_fatal+0x35f
#4 0x810749c9 at trap_pfault+0x49
#5 0x81073fee at trap+0x29e
#6 0x8104f1d5 at calltrap+0x8
#7 0x808a6029 at re_shutdown+0x99
#8 0x80bd878a at bus_generic_shutdown+0x5a
#9 0x80bd878a at bus_generic_shutdown+0x5a
#10 0x80bd878a at bus_generic_shutdown+0x5a
#11 0x80bd878a at bus_generic_shutdown+0x5a
#12 0x80bd878a at bus_generic_shutdown+0x5a
#13 0x80452a8d at acpi_shutdown+0xd
#14 0x80bd878a at bus_generic_shutdown+0x5a
#15 0x80bd878a at bus_generic_shutdown+0x5a
#16 0x80bdbb6e at root_bus_module_handler+0x11e
#17 0x80b7a86f at module_shutdown+0x6f
Uptime: 23h22m44s
Dumping 494 out of 7976 MB:..4%..13%..23%..33%..43%..52%..62%..72%..81%..91%

__curthread () at ./machine/pcpu.h:230
230 ./machine/pcpu.h: No such file or directory.
(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=) at /usr/src/

Re: GENERIC crash 11.3-PRERELEASE (i386)

2019-07-10 Thread Konstantin Belousov
On Wed, Jul 10, 2019 at 03:02:40PM +0200, Schuendehuette, Matthias (LDA IT PLM) 
wrote:
> Sorry, wrong link... :-(
> 
> See the verbose boot messages here...
> 
> https://www.dropbox.com/sh/buzxekimo2h2r67/AADpUvLndhm2SHa5t9s9Ckksa?dl=0
> 
> ...in file "Boot_verbose.jpg"

Can you try the following patch ?

Index: sys/x86/x86/cpu_machdep.c
===
--- sys/x86/x86/cpu_machdep.c   (revision 349890)
+++ sys/x86/x86/cpu_machdep.c   (working copy)
@@ -953,7 +953,6 @@
  * architectural state except possibly %rflags. Also, it is always
  * called with interrupts disabled.
  */
-void (*mds_handler)(void);
 void mds_handler_void(void);
 void mds_handler_verw(void);
 void mds_handler_ivb(void);
@@ -962,6 +961,7 @@
 void mds_handler_skl_avx(void);
 void mds_handler_skl_avx512(void);
 void mds_handler_silvermont(void);
+void (*mds_handler)(void) = mds_handler_void;
 
 static int
 sysctl_hw_mds_disable_state_handler(SYSCTL_HANDLER_ARGS)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


[Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

2019-07-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323

Eugene Grosbein  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2391
   ||19

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


wrong permissions on files edited by etcupdate after upgrade to 11.3-RELEASE

2019-07-10 Thread Miroslav Lachman
I upgraded our first machine from 11.2-p10 to 11.3-RELEASE from the 
sources with GENERIC kernel.
I did not run "make delete-old" but some installed apps, like tmux, 
cannot run anymore:


# tmux
Shared object "libevent-2.1.so.6" not found, required by "tmux"

Then I found some services are not running. For example jails and PF. I 
tried to run PF manually:


# service pf reload
pf does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable

# ls -l /etc/rc.d/pf
-rw-r--r--  1 root  wheel   1.2K Jul 10 16:56 /etc/rc.d/pf

OK, now I know what this problem is:

# ls -l /etc/rc.d/ | grep 'rw-r--r'
-rw-r--r--  1 root  wheel   3032 Jul 10 20:30 ipfw
-rw-r--r--  1 root  wheel788 Jul 10 20:32 ipmon
-rw-r--r--  1 root  wheel  14256 Jul 10 16:58 jail
-rw-r--r--  1 root  wheel   2956 Jul 10 16:56 ldconfig
-rw-r--r--  1 root  wheel   4500 Jul 10 20:34 ntpd
-rw-r--r--  1 root  wheel   1263 Jul 10 16:56 pf

All these files where edited by etcupdate because there were some 
conflicts. I was using mergemaster in the past and never had a problem 
like this so my question is: why files with conflicts edited by 
etcupdate have wrong permissions?


Kind regards
Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"