Re: Inability to build FreeBSD-current amd64
from Niclas Zeising: So now I wonder why I failed four times straight building current. One definition of insanity is doing the same thing repeatedly and expecting a different result. Maybe the build host, 11.1-STABLE from July 30, 2017, was too old? I wouldn't have thought it was too old. I could also try an old current host from August 2, 2017, or try to build 12-STABLE from my 11.1-STABLE host. Would I do better to build amd64 or i386 from amd64 host? I presently have no FreeBSD i386 installation, only amd64. I can't quote anything from your message because of problems with mutt on xterm; this is NetBSD 8.99.39 amd64 with icewm. But here is the relevant error message, I believe: ===> usr.bin/clang/llvm-mca (all) Warning: Object directory not changed from original /usr/src/usr.bin/clang/llvm-mca c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/contrib/llvm/tools/llvm-mca -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -g line-tables-only -MD -MF.depend.Views_DispatchStatistics.o -MTViews/DispatchStatistics.o -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/tools/llvm-mca/Views/DispatchStatistics.cpp -o Views/DispatchStatistics.o error: unable to open output file 'Views/DispatchStatistics.o': 'No such file or directory' 1 error generated. *** Error code 1 I switched to the other computer with an installation of FreeBSD-current from August 2, 2017, and managed to succeed. I had the same mergemaster problem cited in another thread, copied etc/master.passwd and etc/group from the 12-STABLE src tree. That enabled me to successfully get through the update, but the result was a strong negative selling point for FreeBSD: no internet access. Ethernet (re) would not connect, Hiro H50191 USB wi-fi adapter gave "Device not configured" as rsu0, and Edimax USB wi-fi adapter dropped the connection as I was trying the dhclient or ifconfig step. Only other thing I could try is urndis with my mobile phone as access point. I really ought to try that on FreeBSD and/or NetBSD. I thought maybe the lack of etc/master.passwd and etc/group in src tree was a fault of subversion on NetBSD from pkgsrc as opposed to subversion on FreeBSD from ports, but browsing svnweb.freebsd.org/base/head revealed that master.passwd and group had indeed been moved, and mergemaster had not been appropriately updated. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > I just updated from r346856 to r347950 and ran into a new panic, caused
> > by having if_tap_load="YES" in /boot/loader.conf - because it's already
> > built-in to the kernel:
>
> I think this patch should fix the panic, but I only compile-tested it.
> I considered having the logic live in preload_delete_name() instead, but
> the boot-time ucode code must still defer the deletion somewhat.
Try this instead. I will revert r347931 after this landed, or could keep
it alone.
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 1cf09dc5cb7..03fe8a5d096 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
bzero((void *)thread0.td_kstack, kstack0_sz);
physfree += kstack0_sz;
+ /*
+* Initialize enough of thread0 for delayed invalidation to
+* work very early. Rely on thread0.td_base_pri
+* zero-initialization, it is reset to PVM at proc0_init().
+*/
+ pmap_thread_init_invl_gen(&thread0);
+
/*
* make gdt memory segments
*/
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7997a9f65dc..ecd701399fc 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -700,9 +700,12 @@ pmap_delayed_invl_start_u(void)
invl_gen = &td->td_md.md_invl_gen;
PMAP_ASSERT_NOT_IN_DI();
lock_delay_arg_init(&lda, &di_delay);
+ pri = td->td_base_pri;
+ if (pri <= PVM)
+ goto again;
thread_lock(td);
pri = td->td_base_pri;
- if (pri < PVM) {
+ if (pri <= PVM) {
invl_gen->saved_pri = 0;
} else {
invl_gen->saved_pri = pri;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
On Sat, 18 May 2019 at 00:10, wrote: > > Igor et al, > > Instead of debating definitions of hate speech, free speech, and trying to > discover intent, I suggest we focus on right relationships. > > https://www.youtube.com/watch?v=A14THPoc4-4 This is a typical example of reframing a problem in one side's favourable terms. Freedom of expression is a fundamental freedom as recognised by the United Nations, and is guaranteed by the highest courts of any civilised society. Attacking one's freedom of expression under whatever auspices makes one an EXCEPTIONALLY terrible person that should go and re-thing their life purpose! End of discussion. -- Igor M. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic after update from r347896 to r347950: panic: insanity vmem 0xffffffff81d7c840
This was fairly late in the transition from single- to multi-user mode:
the NICs had been probed; em0 was determined (correctly) to have no
link, but the wireless NIC (wlan0) hadn't associated to the AP yet.
I have placed copies of the dump and a couple of screenshots in
http://www.catwhisker.org/~david/FreeBSD/head/r347950/
Just before the panic message, there's:
.overwrapped tags
0x81d7cc70: 0 0, 5(cursor)
0xf800040086c8: fe0c1052c000 800, 3(free)
and then we get to:
panic: insanity vmem 0x81d7c840
Unread portion of the kernel message buffer:
__curthread () at /usr/src/sys/amd64/include/pcpu.h:246
246 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(OFFSETOF_CURTHREAD));
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:383
#2 0x8049884b in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:574
#3 0x80498619 in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:481
#4 0x80498394 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#5 0x8049b53f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:252
#6 0x80bc9acc in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:692
#7 0x80fde7d1 in trap (frame=0xfe0c185ab810)
at /usr/src/sys/amd64/amd64/trap.c:619
#8
#9 kdb_enter (why=0x81252ef5 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:479
#10 0x80b80c5a in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:885
#11 0x80b809d3 in panic (
fmt=0x81c75d38 "\226\216!\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:823
#12 0x80be7fd3 in vmem_check (
vm=0x81d7c840 )
at /usr/src/sys/kern/subr_vmem.c:1766
#13 vmem_periodic (unused=, pending=)
at /usr/src/sys/kern/subr_vmem.c:768
#14 0x80bdcd8c in taskqueue_run_locked (queue=0xf80009e33500)
at /usr/src/sys/kern/subr_taskqueue.c:467
#15 0x80bddd08 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:773
#16 0x80b40044 in fork_exit (
callout=0x80bddc80 ,
arg=0x81e95000 , frame=0xfe0c185abac0)
at /usr/src/sys/kern/kern_fork.c:1058
#17
(kgdb)
[that last copy/pasted from core.txt.1].
I noticed nothing peculiar while (briefly) running r347896 (built
yesterday evening & smoke-tested: booted to multi-user mode; wlan0
associated to the expected AP at the time; X11 (xdm) came up, and
I was able to login, ssh to home -- the usual stuff).
The above link should be functional (but slow -- residential ADSL);
it has:
albert(11.3-P)[8] ls -lT
total 42849
-rw-r--r-- 1 david wheel301534 May 18 05:18:26 2019 console_0.jpg
-rw-r--r-- 1 david wheel311923 May 18 05:18:26 2019 console_1.jpg
-rw-r--r-- 1 david staff156926 May 18 05:07:13 2019 core.txt.1
-rw-r--r-- 1 david staff 37080 May 18 05:07:13 2019 core.txt.1.gz
-rw-r--r-- 1 david staff 56590336 May 18 05:23:15 2019 vmcore.1.gz
albert(11.3-P)[9]
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
One wonders just who benefits from Trump's trade war with China.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: panic booting with if_tap_load="YES" in loader.conf
On 2019-05-18 02:55, Konstantin Belousov wrote: > Try this instead. I will revert r347931 after this landed, or could keep > it alone. That works - thanks! -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > I just updated from r346856 to r347950 and ran into a new panic, caused
> > > by having if_tap_load="YES" in /boot/loader.conf - because it's already
> > > built-in to the kernel:
> >
> > I think this patch should fix the panic, but I only compile-tested it.
> > I considered having the logic live in preload_delete_name() instead, but
> > the boot-time ucode code must still defer the deletion somewhat.
>
> Try this instead. I will revert r347931 after this landed, or could keep
> it alone.
I have no strong feeling either way.
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 1cf09dc5cb7..03fe8a5d096 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> bzero((void *)thread0.td_kstack, kstack0_sz);
> physfree += kstack0_sz;
>
> + /*
> + * Initialize enough of thread0 for delayed invalidation to
> + * work very early. Rely on thread0.td_base_pri
> + * zero-initialization, it is reset to PVM at proc0_init().
> + */
> + pmap_thread_init_invl_gen(&thread0);
> +
I think pmap_thread_init_invl_gen() also needs to initialize
invl_gen->saved_pri to 0.
> /*
>* make gdt memory segments
>*/
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 7997a9f65dc..ecd701399fc 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -700,9 +700,12 @@ pmap_delayed_invl_start_u(void)
> invl_gen = &td->td_md.md_invl_gen;
> PMAP_ASSERT_NOT_IN_DI();
> lock_delay_arg_init(&lda, &di_delay);
> + pri = td->td_base_pri;
> + if (pri <= PVM)
> + goto again;
> thread_lock(td);
> pri = td->td_base_pri;
> - if (pri < PVM) {
> + if (pri <= PVM) {
> invl_gen->saved_pri = 0;
> } else {
> invl_gen->saved_pri = pri;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after update from r347896 to r347950: panic: insanity vmem 0xffffffff81d7c840
On Sat, May 18, 2019 at 05:35:06AM -0700, David Wolfskill wrote: > This was fairly late in the transition from single- to multi-user mode: > the NICs had been probed; em0 was determined (correctly) to have no > link, but the wireless NIC (wlan0) hadn't associated to the AP yet. > > I have placed copies of the dump and a couple of screenshots in > http://www.catwhisker.org/~david/FreeBSD/head/r347950/ > > Just before the panic message, there's: > > .overwrapped tags > 0x81d7cc70: 0 0, 5(cursor) > 0xf800040086c8: fe0c1052c000 800, 3(free) > > and then we get to: > panic: insanity vmem 0x81d7c840 Thanks. This should be fixed by r347955. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote: > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote: > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote: > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote: > > > > I just updated from r346856 to r347950 and ran into a new panic, caused > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's already > > > > built-in to the kernel: > > > > > > I think this patch should fix the panic, but I only compile-tested it. > > > I considered having the logic live in preload_delete_name() instead, but > > > the boot-time ucode code must still defer the deletion somewhat. > > > > Try this instead. I will revert r347931 after this landed, or could keep > > it alone. > > I have no strong feeling either way. > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > index 1cf09dc5cb7..03fe8a5d096 100644 > > --- a/sys/amd64/amd64/machdep.c > > +++ b/sys/amd64/amd64/machdep.c > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) > > bzero((void *)thread0.td_kstack, kstack0_sz); > > physfree += kstack0_sz; > > > > + /* > > +* Initialize enough of thread0 for delayed invalidation to > > +* work very early. Rely on thread0.td_base_pri > > +* zero-initialization, it is reset to PVM at proc0_init(). > > +*/ > > + pmap_thread_init_invl_gen(&thread0); > > + > > I think pmap_thread_init_invl_gen() also needs to initialize > invl_gen->saved_pri to 0. It is zero-initialized, same as td_base_pri. The call to pmap_thread_init_invl_gen() is needed because _INVALID bit must be set, which is cleared by default. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > I just updated from r346856 to r347950 and ran into a new panic,
> > > > > caused
> > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's
> > > > > already
> > > > > built-in to the kernel:
> > > >
> > > > I think this patch should fix the panic, but I only compile-tested it.
> > > > I considered having the logic live in preload_delete_name() instead, but
> > > > the boot-time ucode code must still defer the deletion somewhat.
> > >
> > > Try this instead. I will revert r347931 after this landed, or could keep
> > > it alone.
> >
> > I have no strong feeling either way.
> >
> > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > --- a/sys/amd64/amd64/machdep.c
> > > +++ b/sys/amd64/amd64/machdep.c
> > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > physfree += kstack0_sz;
> > >
> > > + /*
> > > + * Initialize enough of thread0 for delayed invalidation to
> > > + * work very early. Rely on thread0.td_base_pri
> > > + * zero-initialization, it is reset to PVM at proc0_init().
> > > + */
> > > + pmap_thread_init_invl_gen(&thread0);
> > > +
> >
> > I think pmap_thread_init_invl_gen() also needs to initialize
> > invl_gen->saved_pri to 0.
> It is zero-initialized, same as td_base_pri. The call to
> pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> which is cleared by default.
I now think that you mean something else, that invl_gen.saved_pri must
be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
act on the priority from the previous DI block.
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 1cf09dc5cb7..03fe8a5d096 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
bzero((void *)thread0.td_kstack, kstack0_sz);
physfree += kstack0_sz;
+ /*
+* Initialize enough of thread0 for delayed invalidation to
+* work very early. Rely on thread0.td_base_pri
+* zero-initialization, it is reset to PVM at proc0_init().
+*/
+ pmap_thread_init_invl_gen(&thread0);
+
/*
* make gdt memory segments
*/
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7997a9f65dc..89ba9da19d8 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
invl_gen = &td->td_md.md_invl_gen;
PMAP_ASSERT_NOT_IN_DI();
lock_delay_arg_init(&lda, &di_delay);
- thread_lock(td);
+ invl_gen->saved_pri = 0;
pri = td->td_base_pri;
- if (pri < PVM) {
- invl_gen->saved_pri = 0;
- } else {
- invl_gen->saved_pri = pri;
- sched_prio(td, PVM);
+ if (pri > PVM) {
+ thread_lock(td);
+ pri = td->td_base_pri;
+ if (pri > PVM) {
+ invl_gen->saved_pri = pri;
+ sched_prio(td, PVM);
+ }
+ thread_unlock(td);
}
- thread_unlock(td);
-
again:
PV_STAT(i = 0);
for (p = &pmap_invl_gen_head;; p = prev.next) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > > I just updated from r346856 to r347950 and ran into a new panic,
> > > > > > caused
> > > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's
> > > > > > already
> > > > > > built-in to the kernel:
> > > > >
> > > > > I think this patch should fix the panic, but I only compile-tested it.
> > > > > I considered having the logic live in preload_delete_name() instead,
> > > > > but
> > > > > the boot-time ucode code must still defer the deletion somewhat.
> > > >
> > > > Try this instead. I will revert r347931 after this landed, or could
> > > > keep
> > > > it alone.
> > >
> > > I have no strong feeling either way.
> > >
> > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > > --- a/sys/amd64/amd64/machdep.c
> > > > +++ b/sys/amd64/amd64/machdep.c
> > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t
> > > > physfree)
> > > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > > physfree += kstack0_sz;
> > > >
> > > > + /*
> > > > +* Initialize enough of thread0 for delayed invalidation to
> > > > +* work very early. Rely on thread0.td_base_pri
> > > > +* zero-initialization, it is reset to PVM at proc0_init().
> > > > +*/
> > > > + pmap_thread_init_invl_gen(&thread0);
> > > > +
> > >
> > > I think pmap_thread_init_invl_gen() also needs to initialize
> > > invl_gen->saved_pri to 0.
> > It is zero-initialized, same as td_base_pri. The call to
> > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> > which is cleared by default.
> I now think that you mean something else, that invl_gen.saved_pri must
> be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
> act on the priority from the previous DI block.
That is not what I was thinking about, but I agree. thread0's saved_pri
should be zero-initialized, but I don't see how any other thread's
saved_pri is initialized - td_md is not in the zero or copy region of
the thread structure. Your patch should address this as well, but maybe
I am still missing something about how saved_pri gets initialized. The
patch looks right to me.
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 1cf09dc5cb7..03fe8a5d096 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> bzero((void *)thread0.td_kstack, kstack0_sz);
> physfree += kstack0_sz;
>
> + /*
> + * Initialize enough of thread0 for delayed invalidation to
> + * work very early. Rely on thread0.td_base_pri
> + * zero-initialization, it is reset to PVM at proc0_init().
> + */
> + pmap_thread_init_invl_gen(&thread0);
> +
> /*
>* make gdt memory segments
>*/
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 7997a9f65dc..89ba9da19d8 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
> invl_gen = &td->td_md.md_invl_gen;
> PMAP_ASSERT_NOT_IN_DI();
> lock_delay_arg_init(&lda, &di_delay);
> - thread_lock(td);
> + invl_gen->saved_pri = 0;
> pri = td->td_base_pri;
> - if (pri < PVM) {
> - invl_gen->saved_pri = 0;
> - } else {
> - invl_gen->saved_pri = pri;
> - sched_prio(td, PVM);
> + if (pri > PVM) {
> + thread_lock(td);
> + pri = td->td_base_pri;
> + if (pri > PVM) {
> + invl_gen->saved_pri = pri;
> + sched_prio(td, PVM);
> + }
> + thread_unlock(td);
> }
> - thread_unlock(td);
> -
> again:
> PV_STAT(i = 0);
> for (p = &pmap_invl_gen_head;; p = prev.next) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019, 9:48 AM Mark Johnston wrote:
> On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote:
> > On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > > > I just updated from r346856 to r347950 and ran into a new
> panic, caused
> > > > > > > by having if_tap_load="YES" in /boot/loader.conf - because
> it's already
> > > > > > > built-in to the kernel:
> > > > > >
> > > > > > I think this patch should fix the panic, but I only
> compile-tested it.
> > > > > > I considered having the logic live in preload_delete_name()
> instead, but
> > > > > > the boot-time ucode code must still defer the deletion somewhat.
> > > > >
> > > > > Try this instead. I will revert r347931 after this landed, or
> could keep
> > > > > it alone.
> > > >
> > > > I have no strong feeling either way.
> > > >
> > > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > > > --- a/sys/amd64/amd64/machdep.c
> > > > > +++ b/sys/amd64/amd64/machdep.c
> > > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t
> physfree)
> > > > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > > > physfree += kstack0_sz;
> > > > >
> > > > > + /*
> > > > > +* Initialize enough of thread0 for delayed invalidation to
> > > > > +* work very early. Rely on thread0.td_base_pri
> > > > > +* zero-initialization, it is reset to PVM at proc0_init().
> > > > > +*/
> > > > > + pmap_thread_init_invl_gen(&thread0);
> > > > > +
> > > >
> > > > I think pmap_thread_init_invl_gen() also needs to initialize
> > > > invl_gen->saved_pri to 0.
> > > It is zero-initialized, same as td_base_pri. The call to
> > > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> > > which is cleared by default.
> > I now think that you mean something else, that invl_gen.saved_pri must
> > be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
> > act on the priority from the previous DI block.
>
> That is not what I was thinking about, but I agree. thread0's saved_pri
> should be zero-initialized, but I don't see how any other thread's
> saved_pri is initialized - td_md is not in the zero or copy region of
> the thread structure. Your patch should address this as well, but maybe
> I am still missing something about how saved_pri gets initialized. The
> patch looks right to me.
>
Could this crash on other architectures? Do we need fixes there as well...
Warner
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > index 1cf09dc5cb7..03fe8a5d096 100644
> > --- a/sys/amd64/amd64/machdep.c
> > +++ b/sys/amd64/amd64/machdep.c
> > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> > bzero((void *)thread0.td_kstack, kstack0_sz);
> > physfree += kstack0_sz;
> >
> > + /*
> > + * Initialize enough of thread0 for delayed invalidation to
> > + * work very early. Rely on thread0.td_base_pri
> > + * zero-initialization, it is reset to PVM at proc0_init().
> > + */
> > + pmap_thread_init_invl_gen(&thread0);
> > +
> > /*
> >* make gdt memory segments
> >*/
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 7997a9f65dc..89ba9da19d8 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
> > invl_gen = &td->td_md.md_invl_gen;
> > PMAP_ASSERT_NOT_IN_DI();
> > lock_delay_arg_init(&lda, &di_delay);
> > - thread_lock(td);
> > + invl_gen->saved_pri = 0;
> > pri = td->td_base_pri;
> > - if (pri < PVM) {
> > - invl_gen->saved_pri = 0;
> > - } else {
> > - invl_gen->saved_pri = pri;
> > - sched_prio(td, PVM);
> > + if (pri > PVM) {
> > + thread_lock(td);
> > + pri = td->td_base_pri;
> > + if (pri > PVM) {
> > + invl_gen->saved_pri = pri;
> > + sched_prio(td, PVM);
> > + }
> > + thread_unlock(td);
> > }
> > - thread_unlock(td);
> > -
> > again:
> > PV_STAT(i = 0);
> > for (p = &pmap_invl_gen_head;; p = prev.next) {
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-curr
Re: FreeBSD Core Team Response to Controversial Social Media Posts
On Sat, May 18, 2019 at 4:12 AM Igor Mozolevsky wrote: > This is a typical example of reframing a problem in one side's > favourable terms. Freedom of expression is a fundamental freedom as > recognised by the United Nations, and is guaranteed by the highest > courts of any civilised society. Attacking one's freedom of expression > under whatever auspices makes one an EXCEPTIONALLY terrible person > that should go and re-thing their life purpose! End of discussion. > I'd go a bit further and say its also every individuals right to be exposed to such things, and make judgements for themselves. The voices who are the most different deserve the most protection. Without these, any "freedom of speech" is illusion. One wonders where these advocates of censorship will turn when the tool they helped create is eventually turned back on them. -- Adam ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 12:57:29PM -0600, Warner Losh wrote: > On Sat, May 18, 2019, 9:48 AM Mark Johnston wrote: > > > On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote: > > > On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote: > > > > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote: > > > > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote: > > > > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote: > > > > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote: > > > > > > > > I just updated from r346856 to r347950 and ran into a new > > panic, caused > > > > > > > > by having if_tap_load="YES" in /boot/loader.conf - because > > it's already > > > > > > > > built-in to the kernel: > > > > > > > > > > > > > > I think this patch should fix the panic, but I only > > compile-tested it. > > > > > > > I considered having the logic live in preload_delete_name() > > instead, but > > > > > > > the boot-time ucode code must still defer the deletion somewhat. > > > > > > > > > > > > Try this instead. I will revert r347931 after this landed, or > > could keep > > > > > > it alone. > > > > > > > > > > I have no strong feeling either way. > > > > > > > > > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > > > > > index 1cf09dc5cb7..03fe8a5d096 100644 > > > > > > --- a/sys/amd64/amd64/machdep.c > > > > > > +++ b/sys/amd64/amd64/machdep.c > > > > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t > > physfree) > > > > > > bzero((void *)thread0.td_kstack, kstack0_sz); > > > > > > physfree += kstack0_sz; > > > > > > > > > > > > + /* > > > > > > +* Initialize enough of thread0 for delayed invalidation to > > > > > > +* work very early. Rely on thread0.td_base_pri > > > > > > +* zero-initialization, it is reset to PVM at proc0_init(). > > > > > > +*/ > > > > > > + pmap_thread_init_invl_gen(&thread0); > > > > > > + > > > > > > > > > > I think pmap_thread_init_invl_gen() also needs to initialize > > > > > invl_gen->saved_pri to 0. > > > > It is zero-initialized, same as td_base_pri. The call to > > > > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set, > > > > which is cleared by default. > > > I now think that you mean something else, that invl_gen.saved_pri must > > > be set on each entry to invl_start_u(). Otherwise invl_finish_u() might > > > act on the priority from the previous DI block. > > > > That is not what I was thinking about, but I agree. thread0's saved_pri > > should be zero-initialized, but I don't see how any other thread's > > saved_pri is initialized - td_md is not in the zero or copy region of > > the thread structure. Your patch should address this as well, but maybe > > I am still missing something about how saved_pri gets initialized. The > > patch looks right to me. > > > > Could this crash on other architectures? Do we need fixes there as well... The lock-less DI only exists on amd64. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RFC w.r.t. toggling debugging on/off for mountd via a signal
Hi, I've been working with Peter Errikson on a patch for mountd that adds a new option for incremental updating of exports. This seems to be helping a lot w.r.t. performance on an NFS server with lots (1+) of exported file systems. I have debug syslog() calls in the code, which I/Peter think would be worth keeping in the production code in case someone runs into problems with this new option. As such, I'd like to have the code compiled in by default (not only if DEBUG is defined, as mountd.c has now). I also was thinking it would be nice if the daemon didn't need to be restarted to enable/disable the debugging output, since that breaks NFS mounting during the restart. So, I was thinking of having the debugging output toggled on/off via SIGUSR1. What do you think of this idea? Any other/better ways to do this? Also, would LOG_DAEMON and LOG_DEBUG sound like the correct facility and priority for theses syslog() calls? Thanks in advance for any comments, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC w.r.t. toggling debugging on/off for mountd via a signal
On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote: > > Hi, > > I've been working with Peter Errikson on a patch for mountd that adds a new > option > for incremental updating of exports. This seems to be helping a lot w.r.t. > performance > on an NFS server with lots (1+) of exported file systems. > > I have debug syslog() calls in the code, which I/Peter think would be worth > keeping > in the production code in case someone runs into problems with this new > option. > > As such, I'd like to have the code compiled in by default (not only if DEBUG > is defined, > as mountd.c has now). I also was thinking it would be nice if the daemon > didn't need > to be restarted to enable/disable the debugging output, since that breaks NFS > mounting during the restart. > > So, I was thinking of having the debugging output toggled on/off via SIGUSR1. > > What do you think of this idea? > Any other/better ways to do this? > Also, would LOG_DAEMON and LOG_DEBUG sound like the correct facility and > priority for theses syslog() calls? > > Thanks in advance for any comments, rick If the debug messages aren't so verbose that they'll slow down syslogd, then you can just leave them enabled all the time. syslogd will filter them. However, if they're super-verbose then SIGUSR1 sounds reasonable. I can't think of another daemon with runtime selectable logging verbosity like that. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/usr/lib/libomp.so that was added in 13-CURRENT causes port failures and might conflict with libomp.so provided by devel/openmp
There are several port failures triggered by LIB_DEPENDS=libomp.so:devel/openmp. It finds /usr/lib/libomp.so and doesn't use devel/openmp, but then the build fails because it also needs some other libraries. Why was /usr/lib/libomp.so added to the base? Its addition potentially creates an error-prone situation with library compatibility issues between base and port libraries. Yuri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC w.r.t. toggling debugging on/off for mountd via a signal
Alan Somers wrote: >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote: >> >> Hi, >> >> I've been working with Peter Errikson on a patch for mountd that adds a new >> option >> for incremental updating of exports. This seems to be helping a lot w.r.t. >> performance >> on an NFS server with lots (1+) of exported file systems. >> >> I have debug syslog() calls in the code, which I/Peter think would be worth >> keeping >> in the production code in case someone runs into problems with this new >> option. >> >> As such, I'd like to have the code compiled in by default (not only if DEBUG >> is defined, >> as mountd.c has now). I also was thinking it would be nice if the daemon >> didn't need >> to be restarted to enable/disable the debugging output, since that breaks NFS >> mounting during the restart. >> >> So, I was thinking of having the debugging output toggled on/off via SIGUSR1. >> >> What do you think of this idea? >> Any other/better ways to do this? >> Also, would LOG_DAEMON and LOG_DEBUG sound like the correct facility and >> priority for theses syslog() calls? >> >> Thanks in advance for any comments, rick > >If the debug messages aren't so verbose that they'll slow down >syslogd, then you can just leave them enabled all the time. syslogd >will filter them. However, if they're super-verbose then SIGUSR1 >sounds reasonable. I can't think of another daemon with runtime >selectable logging verbosity like that. Yes, these are pretty chatty. 5-10 lines for each entry in an exports file. Multiply that times the number of entries. (Peter's servers are between 2 to 72000+ file systems. Not sure if he has multiple entries/file system.) To give you a clue, without this patch, it can take 20sec->over 1min to reload them when mountd gets a SIGHUP. It's just that the export file handling code is pretty convoluted, so I think the patch is ok, but I won't be too surprised if someone finds a problem. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
