Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
> 
> 
> > On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
> > 
> >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> >> 
> >> 
> >>>> On 22. Aug 2018, at 17:46, Konstantin Belousov  
> >>>> wrote:
> >>>> 
> >>>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> >>>> 
> >>>> 
> >>>>>> On 20. Aug 2018, at 17:09, Konstantin Belousov  
> >>>>>> wrote:
> >>>>>> 
> >>>>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >>>>>> 
> >>>>>> See here for a screenshot (also including the output of "show pte
> >>>>>> 0xf8000100"):
> >>>>>> 
> >>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> >>>>> It is too early for ddb routines to register.
> >>>>> Ok can you try the following debugging patch, to verify my guess ?
> >>>>> 
> >>>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>>>> index 18777d23f09..cd05fdb763f 100644
> >>>>> --- a/sys/amd64/amd64/pmap.c
> >>>>> +++ b/sys/amd64/amd64/pmap.c
> >>>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >>>>>  pd_p = (pd_entry_t *)DMPDkernphys;
> >>>>>  for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >>>>>  pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> >>>>> -X86_PG_M | X86_PG_A | pg_nx |
> >>>>> -bootaddr_rwx(i << PDRSHIFT);
> >>>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >>>>>  for (i = 0; i < nkdmpde; i++)
> >>>>>  pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >>>>>  X86_PG_V;
> >>>> 
> >>>> With this change it boots okay (mptramp_pagetables is 0x100, as 
> >>>> expected).
> >>> 
> >>> Can you apply the following on top of the previous debugging patch and 
> >>> show
> >>> me the line printed ?
> >>> 
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 3d70532b7fd..613fa9f2165 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >>>   pmap->pm_pcids[i].pm_gen = 1;
> >>>   }
> >>>   pmap_activate_boot(pmap);
> >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> >>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> >>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, 
> >>> (uintptr_t)etext, (uintptr_t)KERNBASE);
> >>> }
> >>> 
> >>> void
> >> 
> >> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
> >> 0x823cf840 brwsection #81a0 etext 0x812041e4 
> >> KERNBASE 0x8000
> >> 
> > 
> > Try this, please.  Revert all debugging pmap.c patches that I provided
> > before.
> > 
> > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> > index 4ca2e07e578..2ee8f862854 100644
> > --- a/sys/amd64/amd64/mp_machdep.c
> > +++ b/sys/amd64/amd64/mp_machdep.c
> > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> > 
> > #define GiB(v)(v ## ULL << 30)
> > 
> > +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> > +
> > externstruct pcpu __pcpu[];
> > 
> > /* Temporary variables for init_secondary()  */
> > @@ -101,45 +103,78 @@ char *dbg_stack;
> > 
> > static intstart_ap(int apic_id);
> > 
> > +static bool
> > +is_kernel_paddr(vm_paddr_t pa)
> > +{
> > +
> > +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> > +   pa < round_page(_end - KERNBASE));
> > +}
> > +
> > +static bool
> > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> > +{
> > +
> > +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> > +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> > +}
> >

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
> 
> 
> > On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
> > Please apply the following debugging patch on top of the previous 'fix'.
> > You need debug.late_console=0.
> 
> Unfortunately debug.late_console=0 doesn???t work on this machine (no more 
> output on the console), I tried that earlier in this thread - hence the 
> slightly complicated debugging code I had to add to see the contents of 
> physmap.
> 
> I could run this code after boot (feeding it an identical physmap) to get 
> debug output, would this make sense?
> 
Yes, with exactly the same physmap[].

Really, I do not need exactly the output from my patch, but just make it
clear why is_kernel_paddr() did not triggered selection from different
location.


___
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: r336876 breaks sysutils/acpi_call

[Konstantin Belousov]

On Sat, Aug 25, 2018 at 11:51:21PM -0400, Theron wrote:
> 
> A recent change in CURRENT has sysutils/acpi_call reliably cause a 
> kernel panic when run on a Dell XPS laptop system.  I bisected this to 
> r336876: Use SMAP on amd64.  I would have thought that this is a simple 
> compatibility problem requiring only a port update, except that the same 
> kernel and acpi_call on different hardware are not affected.  On the 
> problematic system, the kernel module loads without incident; it is when 
> executing ACPI commands, even normally harmless operations such as 
> requesting read-only constants, that the system freeze occurs.  ACPI 
> functionality seems otherwise unaffected.
Does system freeze or panic ?  I would expect the later.

The fact that it occurs on some system and not another is encouraging and
if my expectations are right, it fails on the system where SMAP is supported
by hardware.  If true, this means that this kernel module is already broken
and accesses userspace directly without using copyin(9).  Detecting such
situations and stopping the system is the whole point of SMAP.

> 
> Kernel debugging console and crash dumps are also broken on this system 
> (I suspect due to Intel graphics) however it is an unrelated problem, 
> and is only an excuse for my inability to provide any further crash 
> information.
> 
> Having already bisected to the breaking commit, is there anything else I 
> should do to improve the chances this problem gets fixed, or are there 
> any hardware compatibility notes I may have missed?
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> Now, with the patch applied correctly, the machine actually boots.
> 
> Before calling init_ops.mp_bootaddress in
> getmemsize (machdep.c), physmap looks like this:
> 
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x4 0x40
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf7a000 0x7bf7a
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> 
> With your patch, it looks like this now
> (after calling getmemsize)
> 
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x4 0x40
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf77000 0x7bf77
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> PAGETABLES is 0x7bf77000
> 
> So I guess this means that the gap is now at the last three pages of [0x1000, 
> 0x7bf7a[.
> 
> If this is what was intended, I guess it's good, as the machine boots okay 
> now.

It triggered the new code to chomp at the end of the suitable range,
instead of the start. Anyway, to do that, it must evaluated the start
of the range as intersecting with the kernel text, which I interpret as
success.

I put a review with the change at D16907.

> 
> Sorry again for the extra roundtrip, the patched file was simply in the wrong 
> path.

No problem.
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1, 
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer= 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> 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= 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via 
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
>guesses about the problem source a bit easier?

It is not in 'enabling'.  Looking at the faulting VA, I believe that
it occurs inside the BIOS code.

Disable efirt by removing the kernel option, then try to load the module
at runtime.  Does it still fault ?  Also, get the efi mem map for the
machine and look at which region the faulting address and the faulting
instruction belong.
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:
> I guess this patch might do it:
> https://people.freebsd.org/~kevans/efi-bootmap.diff
> 
> Linux commit messages depict a tale in which they used to also only
> map RUNTIME entries, but they were effectively forced to back down on
> that because of buggy firmware that does exactly what you've described
> and they later reintroduced the restrictive mapping for i386-only
> where they'd not found such bugs.

Orthogonal to the loader patch, please try the following.  Even better,
try this with the stock loader.

You need to remove efirt from the kernel config for now, instead load
efirt.ko, perhaps after the system booted into single user.  I am interested
if the panic goes away.  You should see some interesting message from
kernel about EFI realtime clock.

If you have any binary modules like nvidia or vbox, do not load them
with the patched kernel.

diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S
new file mode 100644
index 000..82e5646e645
--- /dev/null
+++ b/sys/amd64/amd64/efirt_support.S
@@ -0,0 +1,105 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2018 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov 
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#include 
+
+#include "assym.inc"
+
+   .text
+ENTRY(efirt_arch_call)
+   pushq   %rbp
+   movq%rsp, %rbp
+
+   movq%rbx, EC_STATE+TF_RBX(%rdi)
+   movq%rsp, EC_STATE+TF_RSP(%rdi)
+   movq%rbp, EC_STATE+TF_RBP(%rdi)
+   movq%r12, EC_STATE+TF_R12(%rdi)
+   movq%r13, EC_STATE+TF_R13(%rdi)
+   movq%r14, EC_STATE+TF_R14(%rdi)
+   movq%r15, EC_STATE+TF_R15(%rdi)
+   movqPCPU(CURTHREAD), %rax
+   movq%rdi, TD_MD+MD_EFIRT_TMP(%rax)
+
+   movqPCPU(CURPCB), %rsi
+   movq$efirt_fault, PCB_ONFAULT(%rsi)
+
+   movlEC_ARGCNT(%rdi), %ecx
+   movl%ecx, %ebx
+   shll$3, %ecx
+   subq%rcx, %rsp
+
+   cmpl$0, %ebx
+   jz  1f
+   movqEC_ARG1(%rdi), %rcx
+   decl%ebx
+   jz  1f
+   movqEC_ARG2(%rdi), %rdx
+   decl%ebx
+   jz  1f
+   movqEC_ARG3(%rdi), %r8
+   decl%ebx
+   jz  1f
+   movqEC_ARG4(%rdi), %r9
+   /* XXX on-stack regs */
+1: movqEC_FPTR(%rdi), %rax
+   callq   *%rax
+
+   movqPCPU(CURTHREAD), %rbx
+   movqTD_MD+MD_EFIRT_TMP(%rbx), %rdi
+   movq%rax, EC_STATE(%rdi)
+   movqPCPU(CURPCB), %rsi
+   xorl%eax, %eax
+   movq%rax, PCB_ONFAULT(%rsi)
+
+efirt_arch_call_tail:
+   movqEC_STATE+TF_R15(%rdi), %r15
+   movqEC_STATE+TF_R14(%rdi), %r14
+   movqEC_STATE+TF_R13(%rdi), %r13
+   movqEC_STATE+TF_R12(%rdi), %r12
+   movqEC_STATE+TF_RBP(%rdi), %rbp
+   movqEC_STATE+TF_RSP(%rdi), %rsp
+   movqEC_STATE+TF_RBX(%rdi), %rbx
+
+   popq%rbp
+   ret
+END(efirt_arch_call)
+
+ENTRY(efirt_fault)
+   xorl%eax, %eax
+   movqPCPU(CURPCB), %rsi
+   movq%rax, PCB_ONFAULT(%rsi)
+   movl$EFAULT, %eax
+   movqPCPU(CURTHREAD), %rbx
+   movqTD_MD+MD_EFIRT_TMP(%rbx), %rdi
+   jmp efirt_arch_call_tail
+END(efirt_fault)
diff --git a/sys/amd64/amd64/genassym.c b/sys/amd64/amd64/genassym.c
index d61b5c7bb6d..c38a596089a 100644
--- a/sys/amd64/amd64/genassym.c
+++ b/sys/amd64/amd64/genassym.c
@@ -77,12 +77,15 @@ ASSYM(P_MD, offsetof(stru

Re: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 07:17:07PM +0300, Yuri Pankov wrote:
> Konstantin Belousov wrote:
> > On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:
> >> I guess this patch might do it:
> >> https://people.freebsd.org/~kevans/efi-bootmap.diff
> >>
> >> Linux commit messages depict a tale in which they used to also only
> >> map RUNTIME entries, but they were effectively forced to back down on
> >> that because of buggy firmware that does exactly what you've described
> >> and they later reintroduced the restrictive mapping for i386-only
> >> where they'd not found such bugs.
> > 
> > Orthogonal to the loader patch, please try the following.  Even better,
> > try this with the stock loader.
> > 
> > You need to remove efirt from the kernel config for now, instead load
> > efirt.ko, perhaps after the system booted into single user.  I am interested
> > if the panic goes away.  You should see some interesting message from
> > kernel about EFI realtime clock.
> > 
> > If you have any binary modules like nvidia or vbox, do not load them
> > with the patched kernel.
> 
> Done, getting exactly the same fault without any new messages printed 
> (made sure I'm using the updated efirt using `nm | grep efirt_fault`).

Can you show me exact fault messages ?
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
> Sorry, I accidentally took the discussion off-list, where Konstantin 
> provided some more patches.  I'm attaching the one that finally worked 
> for me.  It also adds some diagnostic prints which require bootverbose 
> to be enabled.

This patch requires some more work to make it committable.
Do not try to build it with efirt device in the kernel config,
only efirt.ko works, but it can be preloaded from loader.
___
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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

[Konstantin Belousov]

On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote:
> On 8/29/18 7:40 PM, John Baldwin wrote:
> > On 8/29/18 4:20 PM, Ian FREISLICH wrote:
> >> Hi
> >>
> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
> >> at line 84.  My system is UP  so I'm not compiling an SMP kernel.
> >>
> >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared
> >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
> >>     interrupt_sorted = mallocarray(num_io_irqs,
> >> sizeof(*interrupt_sorted),
> >>     ^~~~
> >>     interrupt_sources
> >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources'
> >> declared here
> >> static struct intsrc **interrupt_sources;
> >>    ^
> >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared
> >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
> >>     interrupt_sorted = mallocarray(num_io_irqs,
> >> sizeof(*interrupt_sorted),
> > 
> > Probably just needs #ifdef SMP around the mallocarray().  I'll test 
> > locallyon a UP kernel config.
> > 
> 
> I see another problem after using Ian's workaround of moving the #ifdef
> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III)
> machine with only 512MB of RAM:
> 
> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed
> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed
> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed
> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed

What is the kernel revision for "now".  What was the previous revision
where the kstack allocation failures did not happen.

Also, what is the workload ?
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Thu, Aug 30, 2018 at 10:12:33PM +0300, Konstantin Belousov wrote:
> On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
> > Sorry, I accidentally took the discussion off-list, where Konstantin 
> > provided some more patches.  I'm attaching the one that finally worked 
> > for me.  It also adds some diagnostic prints which require bootverbose 
> > to be enabled.
> 
> This patch requires some more work to make it committable.
> Do not try to build it with efirt device in the kernel config,
> only efirt.ko works, but it can be preloaded from loader.

A version of the patch which finishes items which I wanted
to handle, is available both for review and for testing at
https://reviews.freebsd.org/D16972 .
___
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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

[Konstantin Belousov]

On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote:
> On 8/31/18 1:28 AM, Konstantin Belousov wrote:
> > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote:
> 
>  [ .. snip .. ]
> 
> >> I see another problem after using Ian's workaround of moving the #ifdef
> >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III)
> >> machine with only 512MB of RAM:
> >>
> >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed
> >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed
> >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed
> >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
> >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
> >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed
> > 
> > What is the kernel revision for "now".  What was the previous revision
> > where the kstack allocation failures did not happen.
> > 
> > Also, what is the workload ?
> 
> Sorry for the delay. Any version at or after SVN r338360 would either a)
> not boot at all or b) crash shortly after boot with a swarm of messages
> as above. It was stable before that.
> 
> Unfortunately, this machine is remote and, being as old as it is, has no
> remote console facility. 'nextboot' has been my savior ;-)
> 
> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces,
> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an
> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a
> router/firewall with few actual applications running.
> 
> As another data point, I manually reversed both SVN r338360 and r338415
> (a related change) and it is now stable running at SVN r338520,

It is very unprobable.  I do not see how could r338360 affect KVA allocation.
Double-check that you booted right kernels.
___
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: Current-Alpha6 panic with new support.S AMD64

[Konstantin Belousov]

On Sun, Sep 16, 2018 at 01:43:51PM -0700, Manfred Antar wrote:
> With r338700 support.S i get panic after rebooting:
> 
> avail memory = 16529514496 (15763 MB)
> MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
> SMP: Added CPU 2 (AP)
> MADT: Found CPU APIC ID 1 ACPI ID 3: enabled
> SMP: Added CPU 1 (AP)
> MADT: Found CPU APIC ID 3 ACPI ID 4: enabled
> SMP: Added CPU 3 (AP)
> Event timer "LAPIC" quality 100
> kernel trap 9 with interrupts disabled
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer   = 0x20:0x80747d86
> stack pointer = 0x28:0x82451820
> frame pointer = 0x28:0x82451820
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = resume, IOPL = 0
> current process   = 0 ()
> [ thread pid 0 tid 0 ]
> Stopped at  strcmp+0x6: movb(%rsi),%dl
> db> bt
> Tracing pid 0 tid 0 td 0x81015180
> strcmp() at strcmp+0x6/frame 0x82451820
> sysctl_register_oid() at sysctl_register_oid+0x4c/frame 0x82451b40
> sysctl_add_oid() at sysctl_add_oid+0x20d/frame 0x82451b90
> et_register() at et_register+0x14d/frame 0x82451bf0
> native_lapic_init() at native_lapic_init+0x4e3/frame 0x82451c10
> madt_setup_local() at madt_setup_local+0x26e/frame 0x82451c40
> apic_setup_local() at apic_setup_local+0x44/frame 0x82451c50
> mi_startup() at mi_startup+0x118/frame 0x82451c70
> btext() at btext+0x2c
> db> 
> 
> With support.S r338683 no problem

What is your cpu ?  Show first 50 lines from the verbose dmesg.
Also please try this patch.

diff --git a/sys/amd64/amd64/support.S b/sys/amd64/amd64/support.S
index f86d3d11506..5a4e62faba1 100644
--- a/sys/amd64/amd64/support.S
+++ b/sys/amd64/amd64/support.S
@@ -122,7 +122,6 @@ ENTRY(memmove_std)
movq%rdx,%rcx
andq$7,%rcx /* any bytes left? */
jne 2f
-   movq%r9,%rax
POP_FRAME_POINTER
ret
 2:
___
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 EFI projects

[Konstantin Belousov]

On Mon, Sep 17, 2018 at 12:17:25PM -0600, Warner Losh wrote:
> On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran  wrote:
> I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old
> > Apple systems that use 32-bit EFI: it sounds like it should be possible,
> > and is something I'd like to try and get working.
> >
> 
> That should be possible, but there's a number of issue dealing with the
> 32-bit EFI not having a direct map that we can use to generate the mapping
> tables we need for the loader early in our boot. It's why we can't call the
> EFI runtime on armv7, for example.

Having EFI RT working when 64bit kernel is booted from 32bit EFI
environment is very non-trivial. DMAP is not an issue at all, loaders do
not use or need it (in fact loaders run with the 1:1 mapping or disabled
paging).  RT requires calling into 32 bit mode from 64 bit.  This is hard
to do since kernel interrupt and fault handlers assume that kernel mode
means flat 64bit.  Interrupts would switch to 64 bit, but existing kernel
code cannot handle such switch.  Just do not provide RT for 32bit EFI.

That said, making only the loader->kernel transition from EFI 32bit to
64bit kernel should be not too hard, and even significantly simpler than
to make 32bit EFI load 32bit kernel. amd64 kernels already aware that
there might be no BIOS and they do not try to make vm86 calls into real
code, and only read memory map from the loader metadata etc.

Besides old Macs, this should also benefit newer Intel embedded-like
boards.
___
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: vmstat -m and netstat -m dumping core when run on vmcores

[Konstantin Belousov]

On Mon, Oct 01, 2018 at 09:15:46AM +0300, Yuri Pankov wrote:
> Hi,
> 
> I've noticed the following rebooting after a panic:
> 
> pid 41246 (vmstat), uid 0: exited on signal 11 (core dumped)
> pid 47091 (netstat), uid 0: exited on signal 11
> 
> And indeed, trying to manually run those on the resulting vmcore makes 
> them crash:
> 
> # vmstat -m -M /var/crash/vmcore.0
> Segmentation fault (core dumped)
> # netstat -m -M /var/crash/vmcore.0
> Segmentation fault
> 
> Backtrace is below:
> 
> * thread #1, name = 'vmstat', stop reason = signal SIGSEGV
>* frame #0: 0x00080026d19f 
> libmemstat.so.3`memstat_kvm_malloc(list=0x0008007c5000, 
> kvm_handle=0x00080070e000) at memstat_malloc.c:351
>  frame #1: 0x00204b15 vmstat`main [inlined] domemstat_malloc 
> at vmstat.c:1406
>  frame #2: 0x00204af4 vmstat`main(argc=, 
> argv=0x7fffeb28) at vmstat.c:386
>  frame #3: 0x00204095 vmstat`_start(ap=, 
> cleanup=) at crt1.c:74
> 
> Wonder if it's just me or something is broken here?

I think this is due to r338899.  libmemstat needs an adjustments to handle
that.
___
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: dmesg submission service -- please submit today

[Konstantin Belousov]

On Sat, Oct 06, 2018 at 11:40:36PM -0600, Warner Losh wrote:
> On Sat, Oct 6, 2018 at 12:48 PM Warner Losh  wrote:
> 
> > Greetings,
> >
> > As you can tell, the project is looking to clear some of the deadwood from
> > its driver lists. One problem is that we have to guess what's in used based
> > on our personal experience. This has proven to be less reliable than hoped
> > in the 10/100 discussions that are going on now.
> >
> > So, to that end, I'd like to request as many people as possible submit
> > their current dmesg to the service at http://dmesgd.nycbug.org/index.cgi
> > so that we have a better basis for future preliminary lists of drivers for
> > other parts of the tree. Please take the time to make these submissions
> > regardless of what your current hardware is. Please submit for any machine
> > you'd like to upgrade to FreeBSD 12 or 13. Identifying information is
> > generally masked out.
> >
> > This is just a request by me. I'll be using the data in about a month to
> > look at old parallel scsi driver use. Though not definitive, it will be
> > suggestive of what's in use. The data is currently a bit thin, so I thought
> > I'd see what a message like this could do to improve that situation. This
> > should be viewed as a personal suggestion right now...
> >
> > Warner
> >
> > P.S. I know there's other user generated data sites out there, but this
> > appears to be the only one that's actually still working.
> >
> 
> This one-liner works to submit, though you'll need to change username,
> email and maybe tweak the description if your system doesn't have decent
> smbios entries. It's also x86 centric, since other systems won't have this
> information as readily available.
> 
> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d
> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv
> smbios.system.product)" -d "do=addd" --data-urlencode
> 'dmesg@/var/run/dmesg.boot'
> http://dmesgd.nycbug.org/index.cgi

FWIW, on my NUC smbios part looks like this:
nuc% kenv | grep smbios.system\|smbios.planar ~
smbios.planar.location="To be filled by O.E.M."
smbios.planar.maker="Intel Corporation"
smbios.planar.product="NUC5CPYB"
smbios.planar.serial="GEPY645001G0"
smbios.planar.tag=" "
smbios.planar.version="H61145-407"
smbios.system.family=" "
smbios.system.maker=" "
smbios.system.product=" "
smbios.system.serial=" "
smbios.system.sku=" "
smbios.system.uuid="96091100-727a-11e3-b004-f44d30670aa1"
smbios.system.version=" "
___
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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

[Konstantin Belousov]

On Thu, Oct 11, 2018 at 07:07:45PM +, Glen Barber wrote:
> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote:
> > Maybe related to recent Glen's Heads-UP?
> > 
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html
> > 
> 
> No, this is different, and more recent than the heads-up.  I now see
> failures on powerpc, powerpc64, powerpcspe, sparc64, and arm.
> 
> I'm trying to track down what commit introduced this, but it was not the
> final merge from the projects/openssl111 branch.

The libcrypto library dependency on libpthread was introduced with the
OpenSSL 1.1.1 import.
___
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: OpenSSL 1.1.1 libssl.so version number

[Konstantin Belousov]

On Sun, Oct 14, 2018 at 05:45:30PM +0200, Dirk Meyer wrote:
> Don Lewis schrieb:,
> 
> > It looks to me like the base libssl.so version needs to get moved to a
> > value that doesn't collide with ports, perhaps 12.  These are the
> > library version numbers currently used by the various ssl ports:
> > 
> > boringssl   1
> > openssl 9
> > openssl-devel   10
> > openssl111  11
> > libressl43
> > libressl-devel  44
> 
> The linker will always pick the highest so version of a lib (e.g. libssl.so).
> I the past the base version must be smaller then the port version,

This is simply not true, both static and dynamic ELF linkers do not care
about version numbers at all.

Static linker ld(1) only looks for libXXX.so file and records DT_SONAME from
the shared library into the linked binary.  Dynamic linker ld-elf.so.1
looks for exact match of the library filename and DT_SONAME.

So for instance we have
libc.so -> libc.so.7
symlink and libc.so.7 has DT_SONAME libc.so.7.  Then -lc causes recording
the dependency libc.so.7 and dynamic linker loads it when activating the
image. 
___
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: boot hang at r339386

[Konstantin Belousov]

On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote:
> 
> On r339386 I am seeing a 100% hang at boot up time.  Boot ends at
> 
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>     The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-ALPHA10 r339415 GENERIC amd64
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
> LLVM 6.0.1)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: AMD Ryzen 5 1600X Six-Core Processor    (3593.34-MHz
> K8-class CPU)
>   Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
>  
> Features=0x178bfbff
>  
> Features2=0x7ed8320b
>   AMD Features=0x2e500800
>   AMD
> Features2=0x35c233ff
>   Structured Extended
> Features=0x209c01a9
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID EBX=0x1007
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
> real memory  = 34359738368 (32768 MB)
> avail memory = 33255837696 (31715 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
> FreeBSD/SMP: 1 package(s) x 2 cache groups x 3 core(s) x 2 hardware threads
> random: unblocking device.
> Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid
> Length but zero Address: 0x/0x1 (20181003/tbfadt-796)
> ioapic0  irqs 0-23 on motherboard
> ioapic1  irqs 24-55 on motherboard
> Launching APs: 10 1 2 3 9 11 8 5 7 6 4
> Timecounter "TSC-low" frequency 1796668938 Hz quality 1000
> random: entropy device external interface
> module_register_init: MOD_LOAD (vesa, 0x810e6a80, 0) error 19
> kbd1 at kbdmux0
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> netmap: loaded module
> [ath_hal] loaded
> nexus0
> vtvga0:  on motherboard
> aesni0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> 
> Adding boot verbose, shows the lines below before the hang.
> 
> 
> ACPI: 7 ACPI AML tables successfully acquired and loaded
> PCIe: Memory Mapped configuration base @ 0xf800
> 
> The box is hard locked up and I cannot break to debugger either.
> 
> Going back to r339385 works. But going to the next commit hangs the box
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html

Try the patch at https://reviews.freebsd.org/D17612
___
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: Current status of Ryzen (non-)support

[Konstantin Belousov]

On Sun, Oct 21, 2018 at 06:09:50PM +0200, Hannes Hauswedell wrote:
> Hi everyone,
> 
> I wanted to ask what the current status of Ryzen support is and/or
> whether any new changes are planned.
> 
> My situation:
> * second generation Ryzen: 2600X
> * running -CURRENT
> * I have done the things described here:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
This was based on the public errata document for the first gen ryzen.
I am not aware of the erratas ('revision guides' in AMD terminology)
for the second gen ryzens.

For now you can only get fixes for microcode from your BIOS updates.

> * no full system freezes, but under load, e.g. building with 12 threads,
> programs start to segfault.
> * memtest86 ran through without issues
> * on a Linux dual boot I haven't had any issues
Or look at the Linux sources and see if any workarounds are applied
and chicken bits are set for your CPU.

> 
> Is this a known problem? Anythings I can do about it? I thought the
> Ryzen problem were only supposed to happen with first generation CPUs...
> 
> Thanks and regards,
> Hannes
> 



___
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: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

[Konstantin Belousov]

On Tue, Oct 23, 2018 at 08:54:24AM -0600, Warner Losh wrote:
> On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome  wrote:
> 
> >
> > > On 23 Oct 2018, at 13:53, Lev Serebryakov  wrote:
> > >
> > > On 22.10.2018 12:27, Toomas Soome wrote:
> > >
> > >> It would help to get output from loader lsdev -v command.
> > > current loader crashes on "lsdev" for me:
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not
> > > threadripper-related, my hardware is Intel Atom).
> > >
> > > --
> > > // Lev Serebryakov
> > >
> >
> > That error means something is corrupting the memory, it is hard to guess
> > what exactly and debugging it is nasty - it means we would need to track
> > down what was allocated before this memory block (guard1 is marker inserted
> > in front of the allocated memory block).
> >
> > Fortunately the code to print the partition table is in
> > stand/common/disk.c and the partition code is just next to it and so it
> > should be relatively easy to find the guilty one… I will try to see if I
> > can replicate the issue.
> >
> 
> We've had reports of other systems mysteriously hanging on boot with the
> new boot loader, but not older ones. It isn't limited to new AMD boxes, but
> it's been seen on other Intel boxes of various flavors. When we crash, it
> seems like we don't have a good recovery like we do with BTX. Maybe they
> are related?

There is the 'grab_faults' command which might be used to get
information about the fault (as in, CPU fault due to the programming
mistake). You need to issue it before doing something that can cause the
fault. It is not enabled by default due to the methods it uses to catch
the exceptions.

I recently noted that at least UEFI 2.7 provides debugging interfaces
which can be used to achieve the same fault interception effect without
hacks.
___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote:
> On 01/11/2018 15:43, Charlie Li wrote:
> > On 01/11/2018 12:04, Brooks Davis wrote:
> >> Is this failure with devel/llvm70?  It's currently missing the patch
> >> required to make this work.  https://reviews.freebsd.org/D17709 contains
> >> this patch among others.  I'll see about getting it applied.
> >>
> > Yes, devel/llvm70. Will build with your port commit at my next opportunity.
> > 
> After building world and kernel r340097, kernel runs fine, but every
> userspace program in world crashes with Illegal instruction. They all
> crash in exactly the same way. Example backtrace from bmake, running
> from objdir (first discovered after updating a poudriere jail and
> attempting to even start it):
> 
> Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done.
> done.
> [New LWP 100097]
> Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make
> --help'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x002f5664 in _init ()
> (gdb) bt
> #0  0x002f5664 in _init ()
> #1  0x002290fe in _start (ap=, cleanup= out>) at /usr/src/lib/csu/amd64/crt1.c:66
> 
> Given the line number referenced in crt1.c, I'm guessing this condition
> may have existed since at least r339351.

Some minimal amount of facts instead of guesses would be much more useful.

What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
Regardless of what is the instruction, show either the output from
'x86info -f' on the machine, or cpu identification lines from the
_verbose_ boot dmesg.

make is statically linked, do dynamically linked program fault ?

___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote:
> On 03/11/2018 11:29, Konstantin Belousov wrote:
> > Some minimal amount of facts instead of guesses would be much more useful.
> > 
> Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> > What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
> > Regardless of what is the instruction, show either the output from
> > 'x86info -f' on the machine, or cpu identification lines from the
> > _verbose_ boot dmesg.
> > 
> It appears that 0x2f5664 does not exist:
Or rather, it is a middle of the valid instruction.
Next frame looks like it is process_irelocs(), if trusting the line
numbers.  So most likely it is something related to calling wrong
relocator function, if anything.

Perhaps you could try to trace the things manually, doing
single-stepping of the startup code in debugger. There should be very
modest amount of the irelocs, perhaps only one, and see where things go
off the way.

Might be try to vary the clang version, we know that this work with
6.0.1, and according to your report, breaks with 7.0.  Try clang trunk ?

> 
> Disassembly of section .init:
> 
> 002f565c <_init>:
>   2f565c:   48 83 ec 08 sub$0x8,%rsp
>   2f5660:   e8 fb 3c f3 ff  callq  229360 
>   2f5665:   e8 b6 ff ff ff  callq  2f5620
> <__do_global_ctors_aux>
>   2f566a:   48 83 c4 08 add$0x8,%rsp
>   2f566e:   c3  retq
> 
> CPU ident:
> 
> CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4
> 
> Features=0xbfebfbff
> 
> Features2=0x7ffafbbf
>   AMD Features=0x2c100800
>   AMD Features2=0x121
>   Structured Extended
> Features=0x21c27ab
>   Structured Extended Features3=0x9c00
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> > make is statically linked, do dynamically linked program fault ?
> > 
> After some more checks, only the statically linked programs crash.
> 
> -- 
> Charlie Li
> Can't think of a witty .sigline today…
> 
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
> 



___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sun, Nov 04, 2018 at 12:43:34AM -0700, Julian Elischer wrote:
> what's an ifunc?
> 
A special kind of relocation, controlled by the user code.
___
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: drm changes and updating to 12.0

[Konstantin Belousov]

On Mon, Nov 05, 2018 at 06:56:57PM +, Johannes Lundberg wrote:
> The short version is that drm2 in base (/sys/dev/drm2/) have support for hw
> up to 2013 (maybe 2014), that's why drm-legacy-kmod is said to support hw
> up to that year.
drm2 in base supports everything from gen3 to gen6 and did some entrance
into gen7 for Intel.

Practically it means that the list is
G33 chipset graphics (gen3)
G45 (gen4), both cover everything that has chipset graphics for Core2,
core i5 6xx AKA desktop Westmere (gen5)
Sandy/Ivy Bridge (gen6)
unstable Haswell (gen7) (I dropped it when upstream had still
  major stability issues)

Broadwell does not work at all, and I am not sure about Atoms even when
the same generation of graphics was used by the north bridge.
___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Mon, Nov 05, 2018 at 09:10:13PM -0500, Charlie Li wrote:
> On 03/11/2018 19:45, Konstantin Belousov wrote:
> > Or rather, it is a middle of the valid instruction.
> > Next frame looks like it is process_irelocs(), if trusting the line
> > numbers.  So most likely it is something related to calling wrong
> > relocator function, if anything.
> > 
> > Perhaps you could try to trace the things manually, doing
> > single-stepping of the startup code in debugger. There should be very
> > modest amount of the irelocs, perhaps only one, and see where things go
> > off the way.
> > 
> After a few more complete buildworlds, including one with all
> bootstrapping enabled, this doesn't look compiler-specific. Static
> binaries built with the in-tree base LLVM (6.0.1) also crash.
For you, but not for me.

> 
> I stepped through bmake with base lldb, comparing the working copy in my
> system from circa r339990 with r340173 built with bootstrapped
> toolchain. Only the differing parts are shown for conciseness.
> 
> Circa r339990:
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step over
> frame #0: 0x0024ab06 make`_init_tls at tls.c:471
>468  }
>469  tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
>470
> -> 471  _set_tp(tls);
>472  #endif
>473  }
> (lldb) n
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step over
> frame #0: 0x00255e60 make`_set_tp(tp=0x0008002f7830) at
> _set_tp.c:38
>35
>36   void
>37   _set_tp(void *tp)
> -> 38   {
>39
>40   amd64_set_fsbase(tp);
>41   }
> (lldb) s
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step in
> frame #0: 0x00255e64 make`_set_tp(tp=0x0008002f7830) at
> _set_tp.c:40
>37   _set_tp(void *tp)
>38   {
>39
> -> 40   amd64_set_fsbase(tp);
>41   }
> (lldb) s
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step in
> frame #0: 0x00256580
> make`amd64_set_fsbase(addr=0x0008002f7830) at amd64_set_fsbase.c:43
>40   #include 
>41   #include 
>42   #include 
> -> 43   #include "libc_private.h"
>44
>45   static int
>46   amd64_set_fsbase_cpu(void *addr)
> (lldb)
> 
> r340173:
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step over
> frame #0: 0x00247c96 make`_init_tls at tls.c:471
>468  }
>469  tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
>470
> -> 471  _set_tp(tls);
>472  #endif
>473  }
> (lldb) n
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step over
> frame #0: 0x00252eb0 make`_set_tp(tp=0x0008002ed830) at
> _set_tp.c:38
>35
>36   void
>37   _set_tp(void *tp)
> -> 38   {
>39
>40   amd64_set_fsbase(tp);
>41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
> frame #0: 0x00252eb4 make`_set_tp(tp=0x0008002ed830) at
> _set_tp.c:40
>37   _set_tp(void *tp)
>38   {
>39
> -> 40   amd64_set_fsbase(tp);
>41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
> frame #0: 0x00252eb5 make`_set_tp(tp=0x0008002ed830) at
> _set_tp.c:40
>37   _set_tp(void *tp)
>38   {
>39
> -> 40   amd64_set_fsbase(tp);
>41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
> frame #0: 0x002ebdb0 make
> ->  0x2ebdb0: movq   0x3ce9(%rip), %r11
> 0x2ebdb7: callq  0x2ebda0  ; _fini
> 0x2ebdbc: jmp0x2ebd92  ; _init + 6
> 0x2ebdc1: pushq  $0x0
> (lldb) n
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = instruction step over
> frame #0: 0x002ebdb7 make
> ->  0x2ebdb7: callq  0x2ebda0  ; _fini
I guess this is where things go off for you, but I may be wrong.
After ifuncification, 'amd64_set_fsbase()' line should be represented
by the asm as either
call
and the place in plt is just
jmp *(rip-based offset to GOT)(%rip)
In fact the call to amd64_set_fsbase() in the tail-call position, so
the first call is jmp.

For me, everything works.  If for you it does not you should look at the
instructions and see which values went off.  You completely omitted that
details from your trace, so I cannot even guess which part was corrupted.
Again, for me it works with the in-tree toolchain, so I am quite sure that
you have trouble with the toolchain.

___
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: Processes stuck in STOP state on 12.0-BETA3

[Konstantin Belousov]

On Thu, Nov 08, 2018 at 07:08:50PM -0700, Alan Somers wrote:
> On a fresh install of 12.0-BETA3, I'm seeing processes get stuck in the
> STOP state.  Neither SIGCONT nor SIGKILL has any effect.  And it's
> reproducible.  All I have to do is:
> 1) Login to my login manager, which starts xfce
> 2) Start firefox
> 3) kill X
> 4) Login again
> 5) ps -ax  | egrep '\'
> 
> And I see three firefox processes.  It's not just firefox either; I first
> saw 0ad spontaneously enter the STOP state, without first killing X.
> 
> Anybody have any ideas?  The bug seems reproducible, so I'll try anything.

Look at the state of all its threads using procstat -k.
___
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: 13.0 failing to boot multiuser on one PC due to system utilities crashing during rc scipt

[Konstantin Belousov]

On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote:
> On 10/11/18 13:08, Guido Falsi wrote:
> > Hi,
> > 
> > Today I was updating my home machines to recent head, r340303.
> > Previously I was running r339449.
> > 
> > I have a build machine where I build base packages (and also runs
> > poudriere). I updated that machine using packages I built successfully.
> > it is running fine and also successfully rebuilt a full ports package
> > set on the new head.
> > 
> > After that I upgraded, using the same package set, another machine, a PC
> > from around three years ago with an i5. After upgrade the kernel boots
> > fine but when running the rc script to go multiuser some system
> > utilities fail, especially zfs, making it impossible for the machine to
> > complete the boot process.
> > 
> > I have tested booting from the memstick snapshot images, I tested:
> > 
> > FreeBSD-13.0-CURRENT-amd64-20181107-r340239-memstick.img
> > FreeBSD-13.0-CURRENT-amd64-20181101-r339979-memstick.img
> > 
> > and both are also failing to go multiuser. The utility failing in this
> > case is fsck, which, like zfs before, dumps core.
> > 
> > I see a pattern where only disk related utilities crash.
> > 
> > The 12.0-BETA4 installation memstick works fine though.
> > 
> > So clearly something changed between r339449 and r340303 which causes
> > incompatibility with my hardware.
> > 
> > I'll to bisect things, but it will be a slow process.
> 
> I narrowed it down to r339895.
I somehow doubt that this is the case.

If you take post-r339895 kernel and start e.g. 11.2-RELEASE userspace
(untar the installation into jail to avoid reinstallation), does it
still demonstrate the behaviour ?

Also try to run pre-r339895 with the 12.0 userspace from e.g. 12.0-BETA4 
builds.

> 
> I'm not sure why it fails, it goes beyond my knowledge, the change looks
> unharmful, but clearly isn't.
Usually it means that the bisect went wrong and your environment failed
to cleanly isolate the change.

> 
> My impression is that the other conditions not moved inside the ifunc
> also play a role so such optimization is not possible on all systems.
> 
> > 
> > I have put dmesg and pciconf output here in case it could be useful:
> > 
> > https://people.freebsd.org/~madpilot/boot_fail/
This is haswell, right ?  It is exactly the same micro-arch as the machine
where I tested this series of changes.
___
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: 13.0 failing to boot multiuser on one PC due to system utilities crashing during rc scipt

[Konstantin Belousov]

On Sun, Nov 11, 2018 at 08:44:24PM +0100, Guido Falsi wrote:
> On 11/11/18 11:10, Guido Falsi wrote:
> > On 11/11/18 00:07, Konstantin Belousov wrote:
> >> On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote:
> >>> On 10/11/18 13:08, Guido Falsi wrote:
> >>>> I'll to bisect things, but it will be a slow process.
> >>>
> >>> I narrowed it down to r339895.
> >> I somehow doubt that this is the case.
> >>
> > 
> > I did not mean to accuse you. Instead thanks for this reply and the
> > suggestions. Really appreciated.
> > 
> > I simply found out that removing that commit from my sources gives me a
> > stable system and reported such finding.
> > 
> > I understand that the actual cause could be an interaction with other
> > code and am ready to review my findings.
> > 
> >> If you take post-r339895 kernel and start e.g. 11.2-RELEASE userspace
> >> (untar the installation into jail to avoid reinstallation), does it
> >> still demonstrate the behaviour ?
> >>
> >> Also try to run pre-r339895 with the 12.0 userspace from e.g. 12.0-BETA4 
> >> builds.
> > 
> > I'll perform such tests. Please allow me some time to report back what I
> > get.
> 
> I performed these tests. I downloaded the 12.0-BETA4 and 11.2
> installation images and replaced the kernels in there. This was faster
> than working with jails on a crippled system.
> 
> r339895 kernel on 11.2-RELEASE causes fsck (launched by rc) to dump core
> and this stops the boot procedure.
> 
> r339894 kernel on 12.0-BETA4 works fine.

Ok, let try to find some reason.

- When you build your kernels, you do not use any cpu-specific optimization
  flags, do you ?  More, you follow the standard build procedure and your
  make.conf and src.conf are empty, right ?
- Do you preload a microcode update from the loader ?
- Show the output of sysctl vm.pmap.
- Show verbose dmesg from the boot of the problematic kernel.
  You posted non-verbose dmesg for 12.0-BETA4.
- Enter ddb, when booted the problematic kernel.  Do
  db> x/x cpu_stdext_feature
  db> x/x cpu_stdext_feature+4
- From the same ddb session, disassemble e.g. cpu_set_user_tls().
  You could paste me whole disassembling, but really I want to know
  the single line with the call to set_pcb_flags, it should be
  either set_pcb_flags_raw or set_pcb_flags_fsgsbase.  To disassemble
  in ddb, do
  db> x/i cpu_set_user_tls
  and then press  more to get next and next instructions.
  (I want the disassembly from ddb and not from gdb/kgdb).
- Try the following patch.

diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 6e36ae97523..8dafd4b4756 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -2627,8 +2627,8 @@ set_pcb_flags_raw(struct pcb *pcb, const u_int flags)
  * the PCB_FULL_IRET flag is set.  We disable interrupts to sync with
  * context switches.
  */
-static void
-set_pcb_flags_fsgsbase(struct pcb *pcb, const u_int flags)
+void
+set_pcb_flags(struct pcb *pcb, const u_int flags)
 {
register_t r;
 
@@ -2649,13 +2649,6 @@ set_pcb_flags_fsgsbase(struct pcb *pcb, const u_int 
flags)
}
 }
 
-DEFINE_IFUNC(, void, set_pcb_flags, (struct pcb *, const u_int), static)
-{
-
-   return ((cpu_stdext_feature & CPUID_STDEXT_FSGSBASE) != 0 ?
-   set_pcb_flags_fsgsbase : set_pcb_flags_raw);
-}
-
 void
 clear_pcb_flags(struct pcb *pcb, const u_int flags)
 {
___
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: 13.0 failing to boot multiuser on one PC due to system utilities crashing during rc scipt

[Konstantin Belousov]

On Mon, Nov 12, 2018 at 11:52:25AM +0100, Guido Falsi wrote:
> cpu_stdext_feature: 281
...
> cpu_set_user_tls+0x2d:  callset_pcb_flags_raw
...
> 
> The patch does produce a working kernel. In fact I'm running that kernel
> now.

Do you have a bios option called like 'limit max cpuid value' set ?
If yes, try to disable it and see how it works out.
___
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: 13.0 failing to boot multiuser on one PC due to system utilities crashing during rc scipt

[Konstantin Belousov]

On Mon, Nov 12, 2018 at 06:08:11PM +0100, Guido Falsi wrote:
> On 12/11/18 15:33, Konstantin Belousov wrote:
> > On Mon, Nov 12, 2018 at 11:52:25AM +0100, Guido Falsi wrote:
> >> cpu_stdext_feature: 281
> > ...
> >> cpu_set_user_tls+0x2d:  callset_pcb_flags_raw
> > ...
> >>
> >> The patch does produce a working kernel. In fact I'm running that kernel
> >> now.
> > 
> > Do you have a bios option called like 'limit max cpuid value' set ?
> > If yes, try to disable it and see how it works out.
> > 
> 
> Yes it does and switching it from "enabled" to "disabled" actually made
> the problem disappear.
> 
> I don't know why I had that enabled. It looks like the default is disabled.
> 
> Maybe I enabled it sometime in the past while trying to diagnose
> something else and left it enabled since.
> 
> So, to fix it for me disabling that option is ok, and thanks for helping
> me finding out!
> 
> But maybe some safety is still required to avoid other stumbling in the
> same problem. Or at least a notice in the docs.
> 
> My BIOS presents the disabled option as a compatibility thing for
> Windows 95, which could encourage people tom enable it.
> 
Try this patch, with the option enabled.

diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 6e36ae97523..55db65ffc63 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1581,6 +1581,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
 
identify_cpu1();
identify_hypervisor();
+   identify_cpu_fixup_bsp();
identify_cpu2();
initializecpucache();
 
diff --git a/sys/x86/include/x86_var.h b/sys/x86/include/x86_var.h
index 286c01261f0..8f53b41fd19 100644
--- a/sys/x86/include/x86_var.h
+++ b/sys/x86/include/x86_var.h
@@ -129,6 +129,7 @@ voiddump_drop_page(vm_paddr_t);
 void   finishidentcpu(void);
 void   identify_cpu1(void);
 void   identify_cpu2(void);
+void   identify_cpu_fixup_bsp(void);
 void   identify_hypervisor(void);
 void   initializecpu(void);
 void   initializecpucache(void);
diff --git a/sys/x86/x86/identcpu.c b/sys/x86/x86/identcpu.c
index 8e406f053ba..56186b2f3ba 100644
--- a/sys/x86/x86/identcpu.c
+++ b/sys/x86/x86/identcpu.c
@@ -1467,6 +1467,19 @@ identify_cpu2(void)
}
 }
 
+void
+identify_cpu_fixup_bsp(void)
+{
+   u_int regs[4];
+
+   cpu_vendor_id = find_cpu_vendor_id();
+
+   if (fix_cpuid()) {
+   do_cpuid(0, regs);
+   cpu_high = regs[0];
+   }
+}
+
 /*
  * Final stage of CPU identification.
  */
@@ -1478,12 +1491,7 @@ finishidentcpu(void)
u_char ccr3;
 #endif
 
-   cpu_vendor_id = find_cpu_vendor_id();
-
-   if (fix_cpuid()) {
-   do_cpuid(0, regs);
-   cpu_high = regs[0];
-   }
+   identify_cpu_fixup_bsp();
 
if (cpu_high >= 5 && (cpu_feature2 & CPUID2_MON) != 0) {
do_cpuid(5, regs);
___
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: maxswzone NOT used correctly and defaults incorrect?

[Konstantin Belousov]

On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote:
> I have an BeagleBoard Black.  I'm running a recent snapshot:
> FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC  arm
> 
> aka:
> FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz
> 
> It has 512MB of memory on board.  I created a 4GB swap file.  According
> to loader(8), this should be the default capable:
>in bytes of KVA space.  If no value is provided, the system
>allocates enough memory to handle an amount of swap that
>corresponds to eight times the amount of physical memory
>present in the system.
> 
> avail memory = 505909248 (482 MB)
> 
> but I get this:
> warning: total configured swap (1048576 pages) exceeds maximum recommended 
> amount (248160 pages).
> warning: increase kern.maxswzone or reduce amount of swap.
> 
> So, this appears that it's only 2x amount of memory, NOT 8x like the
> documentation says.
> 
> When running make in sbin/ggate/ggated, make consumes a large amount
> of memory.  Before the OOM killer just kicked in, top showed:
> Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free
> Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out
> 
>   PIDUID  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
>  1029   10011  440   594M  3848K RUN  2:03  38.12% make
> 
> swapinfo -k showed:
> /dev/md99 4194304   254392  3939912 6%
> 
> sysctl:
> vm.swzone: 4466880
> vm.swap_maxpages: 496320
> kern.maxswzone: 0
> 
> dmesg when OOM strikes:
> swap blk zone exhausted, increase kern.maxswzone
> pid 1029 (make), uid 1001, was killed: out of swap space
> pid 984 (bash), uid 1001, was killed: out of swap space
> pid 956 (bash), uid 1001, was killed: out of swap space
> pid 952 (sshd), uid 0, was killed: out of swap space
> pid 1043 (bash), uid 1001, was killed: out of swap space
> pid 626 (dhclient), uid 65, was killed: out of swap space
> pid 955 (sshd), uid 1001, was killed: out of swap space
> pid 1025 (bash), uid 1001, was killed: out of swap space
> swblk zone ok
> lock order reversal:
>  1st 0xd374d028 filedesc structure (filedesc structure) @ 
> /usr/src/sys/kern/sys_generic.c:1451
>  2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513
> stack backtrace:
> swap blk zone exhausted, increase kern.maxswzone
> pid 981 (tmux), uid 1001, was killed: out of swap space
> pid 983 (tmux), uid 1001, was killed: out of swap space
> pid 1031 (bash), uid 1001, was killed: out of swap space
> pid 580 (dhclient), uid 0, was killed: out of swap space
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> pid 577 (dhclient), uid 0, was killed: out of swap space
> pid 627 (devd), uid 0, was killed: out of swap space
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> pid 942 (getty), uid 0, was killed: out of swap space
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> pid 1205 (init), uid 0, was killed: out of swap space
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> pid 1206 (init), uid 0, was killed: out of swap space
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> swblk zone ok
> swap blk zone exhausted, increase kern.maxswzone
> swblk zone ok
> 
> So, as you can see, despite having plenty of swap, and swap usage being
> well below any of the maximums, the OOM killer kicked in, and killed off
> a bunch of processes.
OOM is guided by the pagedaemon progress, not by the swap amount left.
If the system cannot meet the pagedaemon targetp by doing
$(sysctl vm.pageout_oom_seq) back-to-back page daemon passes,
it declares OOM condition. E.g. if you have very active process which
keeps a lot of active memory by referencing the pages, and simultenously
a slow or stuck swap device, then you get into this state.

Just by looking at the top stats, you have a single page in the inactive
queue, which means that pagedaemon desperately frees clean pages and
moves dirty pages into the laundry.  Also, you have relatively large
laundry queue, which supports the theory about slow swap.

You may try to increase vm.pageout_oom_seq to move OOM trigger furhter
after the system is overloaded with swapping.

> 
> It also looks like the algorithm for calculating kern.maxswzone is not
> correct.
> 
> I just tried to run the system w/:
> kern.maxswzone: 21474836
> 
> and it again died w/ plenty of swap free:
> /dev/md99 4194304   238148  3956156 6%
> 
> This time I had vmstat -z | grep sw running, and saw:
> swpctrie:48,  62084, 145, 270, 203,   0,   0
> swblk:   72,  62040,   56357,  18,   56587,   0,   0
> 
> after the system died, I logged back in as see:
> swpctrie:48,  62084,  28, 387, 240,   0,   0
> swblk:   72,  62040, 175,   61865,   62957,  16,   0
> 
> so, it c

Re: maxswzone NOT used correctly and defaults incorrect?

[Konstantin Belousov]

On Sat, Nov 24, 2018 at 12:09:34PM -0800, John-Mark Gurney wrote:
> Konstantin Belousov wrote this message on Sat, Nov 24, 2018 at 12:40 +0200:
> > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote:
> > > I have an BeagleBoard Black.  I'm running a recent snapshot:
> > > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC  arm
> > > 
> > > aka:
> > > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz
> > > 
> > > It has 512MB of memory on board.  I created a 4GB swap file.  According
> > > to loader(8), this should be the default capable:
> > >in bytes of KVA space.  If no value is provided, the 
> > > system
> > >allocates enough memory to handle an amount of swap 
> > > that
> > >corresponds to eight times the amount of physical 
> > > memory
> > >present in the system.
> > > 
> > > avail memory = 505909248 (482 MB)
> > > 
> > > but I get this:
> > > warning: total configured swap (1048576 pages) exceeds maximum 
> > > recommended amount (248160 pages).
> > > warning: increase kern.maxswzone or reduce amount of swap.
> > > 
> > > So, this appears that it's only 2x amount of memory, NOT 8x like the
> > > documentation says.
> > > 
> > > When running make in sbin/ggate/ggated, make consumes a large amount
> > > of memory.  Before the OOM killer just kicked in, top showed:
> > > Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K 
> > > Free
> > > Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out
> > > 
> > >   PIDUID  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
> > >  1029   10011  440   594M  3848K RUN  2:03  38.12% make
> > > 
> > > swapinfo -k showed:
> > > /dev/md99 4194304   254392  3939912 6%
> > > 
> > > sysctl:
> > > vm.swzone: 4466880
> > > vm.swap_maxpages: 496320
> > > kern.maxswzone: 0
> > > 
> > > dmesg when OOM strikes:
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 1029 (make), uid 1001, was killed: out of swap space
> > > pid 984 (bash), uid 1001, was killed: out of swap space
> > > pid 956 (bash), uid 1001, was killed: out of swap space
> > > pid 952 (sshd), uid 0, was killed: out of swap space
> > > pid 1043 (bash), uid 1001, was killed: out of swap space
> > > pid 626 (dhclient), uid 65, was killed: out of swap space
> > > pid 955 (sshd), uid 1001, was killed: out of swap space
> > > pid 1025 (bash), uid 1001, was killed: out of swap space
> > > swblk zone ok
> > > lock order reversal:
> > >  1st 0xd374d028 filedesc structure (filedesc structure) @ 
> > > /usr/src/sys/kern/sys_generic.c:1451
> > >  2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513
> > > stack backtrace:
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 981 (tmux), uid 1001, was killed: out of swap space
> > > pid 983 (tmux), uid 1001, was killed: out of swap space
> > > pid 1031 (bash), uid 1001, was killed: out of swap space
> > > pid 580 (dhclient), uid 0, was killed: out of swap space
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 577 (dhclient), uid 0, was killed: out of swap space
> > > pid 627 (devd), uid 0, was killed: out of swap space
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 942 (getty), uid 0, was killed: out of swap space
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 1205 (init), uid 0, was killed: out of swap space
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > pid 1206 (init), uid 0, was killed: out of swap space
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > swblk zone ok
> > > swap blk zone exhausted, increase kern.maxswzone
> > > swblk zone ok
> > > 
> > > So, as you can see, despite having plenty of swap, and swap usage being
> > > well below any of the maximums, the OOM killer kicked in, and killed off
> > > a bunch of processes.
> > OOM is guided by the pagedaemon progress, not by the swap amount left.
> > If the system cannot meet the pagedaemon targetp by doing
> > $(

Re: r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink

[Konstantin Belousov]

On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> Following test case triggers assertion after r340343:
> 
> 
> #include 
> 
> int
> main(int argc, char **argv)
> {
>     openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
> }
> 
> It results in:
> 
> panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
> /usr/src/sys/kern/vfs_lookup.c:182
> 

The following should fix it. Problem was that the topping directory was
only latched when the initial path was absolute. Since your example
switched from the relative argument to the absolute symlink, the BENEATH
tracker rightfully complained that there were no recorded top.

I also added some asserts I used during the debugging.

diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 78893c4f2bd..7a80775d91d 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -202,8 +202,10 @@ nameicap_cleanup(struct nameidata *ndp, bool clean_latch)
vdrop(nt->dp);
uma_zfree(nt_zone, nt);
}
-   if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0)
+   if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0) {
+   ndp->ni_lcf &= ~NI_LCF_LATCH;
vrele(ndp->ni_beneath_latch);
+   }
 }
 
 /*
@@ -264,6 +266,7 @@ namei_handle_root(struct nameidata *ndp, struct vnode **dpp)
return (ENOTCAPABLE);
}
if ((cnp->cn_flags & BENEATH) != 0) {
+   MPASS((ndp->ni_lcf & NI_LCF_LATCH) != 0);
ndp->ni_lcf |= NI_LCF_BENEATH_ABS;
ndp->ni_lcf &= ~NI_LCF_BENEATH_LATCHED;
nameicap_cleanup(ndp, false);
@@ -446,7 +449,7 @@ namei(struct nameidata *ndp)
if (error == 0 && dp->v_type != VDIR)
error = ENOTDIR;
}
-   if (error == 0 && (ndp->ni_lcf & NI_LCF_BENEATH_ABS) != 0) {
+   if (error == 0 && (cnp->cn_flags & BENEATH) != 0) {
if (ndp->ni_dirfd == AT_FDCWD) {
ndp->ni_beneath_latch = fdp->fd_cdir;
vrefact(ndp->ni_beneath_latch);
@@ -471,6 +474,8 @@ namei(struct nameidata *ndp)
vrele(dp);
goto out;
}
+   MPASS((ndp->ni_lcf & (NI_LCF_BENEATH_ABS | NI_LCF_LATCH)) !=
+   NI_LCF_BENEATH_ABS);
if (((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) != 0 &&
lookup_cap_dotdot != 0) ||
((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) == 0 &&
___
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: r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink

[Konstantin Belousov]

On Wed, Nov 28, 2018 at 10:50:59AM +0100, Peter Holm wrote:
> On Wed, Nov 28, 2018 at 01:46:17AM +0200, Konstantin Belousov wrote:
> > On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> > > Following test case triggers assertion after r340343:
> > > 
> > > 
> > > #include 
> > > 
> > > int
> > > main(int argc, char **argv)
> > > {
> > >     openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
> > > }
> > > 
> > > It results in:
> > > 
> > > panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
> > > /usr/src/sys/kern/vfs_lookup.c:182
> > > 
> > 
> > The following should fix it. Problem was that the topping directory was
> > only latched when the initial path was absolute. Since your example
> > switched from the relative argument to the absolute symlink, the BENEATH
> > tracker rightfully complained that there were no recorded top.
> > 
> > I also added some asserts I used during the debugging.
> > 
> > diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
> > index 78893c4f2bd..7a80775d91d 100644
> > --- a/sys/kern/vfs_lookup.c
> 
> With this patch I got a:
> 
> $ ./beneath.sh
> open("a/b") succeeded
> stat("a/b
> panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at 
> ../../../kern/vfs_lookup.c:269
> cpuid = 4
> time = 1543397647
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c71881a0
> vpanic() at vpanic+0x1a3/frame 0xfe00c7188200
> panic() at panic+0x43/frame 0xfe00c7188260
> namei_handle_root() at namei_handle_root+0xf7/frame 0xfe00c71882b0
> namei() at namei+0x617/frame 0xfe00c71884f0
> vn_open_cred() at vn_open_cred+0x526/frame 0xfe00c7188640
> vn_open() at vn_open+0x4c/frame 0xfe00c7188680
> kern_openat() at kern_openat+0x2e9/frame 0xfe00c71888e0
> sys_openat() at sys_openat+0x69/frame 0xfe00c7188910
> syscallenter() at syscallenter+0x4e3/frame 0xfe00c71889f0
> amd64_syscall() at amd64_syscall+0x4d/frame 0xfe00c7188ab0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00c7188ab0
> --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8003a215a, rsp = 
> 0x7fffe4f8, rbp = 0x7fffe5e0 ---
> 
> https://people.freebsd.org/~pho/stress/log/kostik1127.txt

Thank you for reporting this.  The issue is due to wrong assert, which is
valid for later call to namei_handle_root(), but not for the very first
call.  Below is the updated patch.

diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 78893c4f2bd..cb69a75ea65 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -202,8 +202,10 @@ nameicap_cleanup(struct nameidata *ndp, bool clean_latch)
vdrop(nt->dp);
uma_zfree(nt_zone, nt);
}
-   if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0)
+   if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0) {
+   ndp->ni_lcf &= ~NI_LCF_LATCH;
vrele(ndp->ni_beneath_latch);
+   }
 }
 
 /*
@@ -446,7 +448,7 @@ namei(struct nameidata *ndp)
if (error == 0 && dp->v_type != VDIR)
error = ENOTDIR;
}
-   if (error == 0 && (ndp->ni_lcf & NI_LCF_BENEATH_ABS) != 0) {
+   if (error == 0 && (cnp->cn_flags & BENEATH) != 0) {
if (ndp->ni_dirfd == AT_FDCWD) {
ndp->ni_beneath_latch = fdp->fd_cdir;
vrefact(ndp->ni_beneath_latch);
@@ -471,6 +473,8 @@ namei(struct nameidata *ndp)
vrele(dp);
goto out;
}
+   MPASS((ndp->ni_lcf & (NI_LCF_BENEATH_ABS | NI_LCF_LATCH)) !=
+   NI_LCF_BENEATH_ABS);
if (((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) != 0 &&
lookup_cap_dotdot != 0) ||
((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) == 0 &&
___
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: HEADSUP: Something has gone south with -current

[Konstantin Belousov]

On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote:
> On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote:
> > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote:
> > > 
> > > make core dumps.
> > > devd core dumps.
> > > init core dumps.
> > > cc   core dumps.  
> > > c++  core dumps.
> > > 
> > > Something seems to be broken.
> > > 
> > 
> > Further investigation,
> > as core dumps.
> > cpp core dumps.
> > /rescue/vi core dumps.
> > 
> > All of these programs are statically linked.  Note, ar and ranlib
> > have static linkage, and appear to still work but these were not
> > replaced by the failing 'make installworld'.
> > 
> > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar
> > is static and not stripped and works!  But, if I do
> > 
> > cp ar ar.new
> > strip ar
> > ./ar
> > 
> > This ar core dumps.  So, stripping static binaries seems to 
> > break the binary.
> > 
> 
> Yep, definitely, a problem with stripping static binaries.
> 
> I copied both init and devd from /usr/obj to /sbin without
> stripping the binaries.  System rebooted as expected.

Most likely this is an issue fixed by r339350.
___
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: HEADSUP: Something has gone south with -current

[Konstantin Belousov]

On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote:
> On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote:
> > On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote:
> > > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote:
> > > > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote:
> > > > > 
> > > > > make core dumps.
> > > > > devd core dumps.
> > > > > init core dumps.
> > > > > cc   core dumps.  
> > > > > c++  core dumps.
> > > > > 
> > > > > Something seems to be broken.
> > > > > 
> > > > 
> > > > Further investigation,
> > > > as core dumps.
> > > > cpp core dumps.
> > > > /rescue/vi core dumps.
> > > > 
> > > > All of these programs are statically linked.  Note, ar and ranlib
> > > > have static linkage, and appear to still work but these were not
> > > > replaced by the failing 'make installworld'.
> > > > 
> > > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar
> > > > is static and not stripped and works!  But, if I do
> > > > 
> > > > cp ar ar.new
> > > > strip ar
> > > > ./ar
> > > > 
> > > > This ar core dumps.  So, stripping static binaries seems to 
> > > > break the binary.
> > > > 
> > > 
> > > Yep, definitely, a problem with stripping static binaries.
> > > 
> > > I copied both init and devd from /usr/obj to /sbin without
> > > stripping the binaries.  System rebooted as expected.
> > 
> > Most likely this is an issue fixed by r339350.
> 
> My tree is at r341703.  The last paragraph of the commit 
> message for r339350 is
Which tree ?  The strip that is used by install should be past this
revision.

> 
>   Just remove filter_reloc.  This fixes certain cases including statically
>   linked binaries containing ifuncs.  Stripping binaries with relocations
>   referencing removed symbols was already broken, and after this change
>   may still be broken in a different way.
> 
> So, I guess I'm hitting the "broken in a different way".
> 
> The gdb82 backtrace ends up in jemalloc.  I do build world with
> MALLOC_PRODUCTION="YES".  Perhaps, ifuncs+jemalloc aren't at
> production level.  I have few more broken static binaries that
> I need to replace before I can rebuild without MALLOC_PRODUCTION.
> 
> -- 
> Steve
___
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: HEADSUP: Something has gone south with -current

[Konstantin Belousov]

On Fri, Dec 07, 2018 at 05:02:03PM -0800, Steve Kargl wrote:
> On Sat, Dec 08, 2018 at 02:43:17AM +0200, Konstantin Belousov wrote:
> > On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote:
> > > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote:
> > > > 
> > > > Most likely this is an issue fixed by r339350.
> > > 
> > > My tree is at r341703.  The last paragraph of the commit 
> > > message for r339350 is
> > Which tree ?  The strip that is used by install should be past this
> > revision.
> > 
> 
> % cd /usr/src
> % svn info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 341703
> Node Kind: directory
> Schedule: normal
> Last Changed Author: emaste
> Last Changed Rev: 341703
> Last Changed Date: 2018-12-07 08:52:52 -0800 (Fri, 07 Dec 2018)
> 
> This is the /usr/src that has led to the broken static binaries.
> 
> Looking at timestamps, I have
> 
> % ls -l  /usr/bin/strip
> -r-xr-xr-x  2 root  wheel  - 131144 Oct 10 17:10 /usr/bin/strip*
> 
> which is the strip from my Oct 10 build.  This strip did not get
> updated because 'make installworld' died.  Does install during
> an installworld use the old strip instead of freshly built strip?

It is installed (host) strip that is used, AFAIK.  You can build
static lib/libelftc and usr.bin/strip from the later date and install
it to get past the issue.
___
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: Linux is considering dropping x32.

[Konstantin Belousov]

On Tue, Dec 11, 2018 at 04:04:15PM -0500, Kris Moore wrote:
> On 12/11/18 4:01 PM, Alexandre C. Guimarães wrote:
> > Hi.
> >
> > This is just informative.
> >
> > Apparently Linux is considering deprecate x32 support:
> >
> > https://lkml.org/lkml/2018/12/10/1151
> >
> > Cheers!
> >
> 
> Hey that's great! Now that the precedent is set, we start the timer to
> deprecate on FreeBSD in roughly 10 years now :)

Fine, but we would need to implement it first.
___
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: HEAD buildworld fails in libc

[Konstantin Belousov]

On Fri, Dec 28, 2018 at 10:18:12AM +0100, Gary Jennejohn wrote:
> I don't know why this hasn't already been reported, but I've been
> seeing this error since the commit was made.
> 
> ===> lib/libc (obj,all,install)
> /usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to 
> parameter of type 'char *' discards qualifiers 
> [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
> __uprefix,
> ^
> /usr/src/lib/libc/string/strerror.c:61:23: note: passing argument to 
> parameter 'uprefix' here
> errstr(int num, char *uprefix, char *buf, size_t len)
>   ^
> 1 error generated.
> *** [strerror.o] Error code 1
> 
> I deleted /usr/obj, disabled META_MODE and ran the ``make buildworld''
> with -j1.
> 
> My /usr/src is at r342569.

Do you have WITHOUT_NLS set ?  If yes, then the following should fix it.
Confirm and I will commit.

diff --git a/lib/libc/string/strerror.c b/lib/libc/string/strerror.c
index be3732d5b9e..7cd984ea48f 100644
--- a/lib/libc/string/strerror.c
+++ b/lib/libc/string/strerror.c
@@ -58,7 +58,7 @@ __FBSDID("$FreeBSD$");
  * statically linked binaries.
  */
 static void
-errstr(int num, char *uprefix, char *buf, size_t len)
+errstr(int num, const char *uprefix, char *buf, size_t len)
 {
char *t;
unsigned int uerr;
___
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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Konstantin Belousov]

On Sat, Jan 19, 2019 at 11:54:25PM +0300, Lev Serebryakov wrote:
> Hello Rebecca,
> 
> Saturday, January 19, 2019, 6:06:52 PM, you wrote:
> 
> >  Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could
> > not find or understand anything in this home-rown UI with crazy-fast mouse. 
> > On ASUS systems you normally press F8 during POST to bring up the boot 
> > menu, and F11 on Supermicro systems.
>  Yes, I know. But what should I do next? There is no  "Set UEFI Boot Var"
> item in it. You could select different physical drives (but not partitions
> of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI
> Shell" which is not documented anywhere, and it doesn't work always.
> 
>  When I google "ASUS EFI Shell", for example, all results says about
> preparing USB stick with EFI shell and such, not about commands and
> variables of EFI shell.
> 
>  I don't say, that it is impossible, I only could not find good (or any)
> documentation.

The specification for EFI Shell is available together with other
UEFI specifications, at http://www.uefi.org/specifications.
___
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"

PAE on i386

[Konstantin Belousov]

Hello,
at https://reviews.freebsd.org/D18894 I put a review which main goal is
to allow i386 kernels to use NX bits on capable hardware.  In essence,
single kernel now can operate using either PAE or non-PAE pagetables,
the selection is done at the cold (very early boot, before paging is
turned on) time.

This together with earlier 4/4 work gives much more life into i386 kernels
for whoever still needs them.  Please review/test, see the differential
review text for more explanation.
___
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: problem building dev/e1000

[Konstantin Belousov]

On Thu, Feb 14, 2019 at 04:24:28PM -0500, Robert Huff wrote:
> 
>   On a system running:
> 
> FreeBSD 13.0-CURRENT r343080  amd64
> 
>   with source tree updated at midnight last night, attempts to
> build a kernel with "device em" die with:
Did you added 'device iflib' to your kernel config ?

> 
> 
> ctfconvert -L VERSION -g efirtc.o
> cc -target x86_64-unknown-freebsd13.0 
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing  
> -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include 
> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
> opt_global.h   -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD  
> -MF.depend.if_em.o -MTif_em.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
> -fdiagnostics-show-option -Wno-unknown-pragmas 
> -Wno-error-tautological-compare -Wno-error-empty-body 
> -Wno-error-parentheses-equality -Wno-error-unused-function 
> -Wno-error-pointer-sign -Wno-error-shift-negative-value 
> -Wno-address-of-packed-member  -mno-
 ae
>  s -mno-avx  -std=iso9899:1999 -Werror  /usr/src/sys/dev/e1000/if_em.c 
> -I/usr/src/sys/dev/e1000
> In file included from /usr/src/sys/dev/e1000/if_em.c:30:
> /usr/src/sys/dev/e1000/if_em.h:91:10: fatal error: 'ifdi_if.h' file not found
> #include "ifdi_if.h"
>  ^~~
> 1 error generated.
> *** Error code 1
> 
> 
>   'ifdi_if.h' is not in the local e1000 direstory, nor is it in the
> equavalent place in the svn repository on FreeBSD.org.
>   Is this something I'm doing wrong?  Or is there a problem in
> "if_em.h"?
> 
> 
>   Respectfully,
> 
> 
>   Robert Huff
> ___
> 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote:
> On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote:
> > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote:
> > > r343567 merges the PAE vs non-PAE pmap headers for i386
> > > freebsd.  After bisection and dealing with the drm-legacy-kmod
> > > fallout, I bisected /usr/src to r343567.  Building world and
> > > a GENERIC kernel and the minimum set of ports to start Xorg
> > > on my Dell Latitude D530 laptop, results in a black screen
> > > of death and a locked up laptop (no keyboard, mouse, or video).
> > > 
> > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads
> > > and functions) and r353467 (Xorg black screen of death) shows
> > > that /boot/modules/i915kms.ko loads correctly as the log
> > > files are identical.
> > > 
> > > Comparing dmesg for r343566 to r343567 shows the following
> > >  
> > > --- dmesg.343566  2019-02-20 08:13:07.727202000 -0800
> > > +++ dmesg.343567  2019-02-21 19:02:24.469562000 -0800
> > > @@ -3,11 +3,11 @@
> > >  Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > >   The Regents of the University of California. All rights reserved.
> > >  FreeBSD is a registered trademark of The FreeBSD Foundation.
> > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386
> > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386
> > >  FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on 
> > > LLVM 7.0.1)
> > >  WARNING: WITNESS option enabled, expect reduced performance.
> > >  VT(vga): resolution 640x480
> > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 
> > > 686-class CPU)
> > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 
> > > 686-class CPU)
> > >Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
> > >
> > > Features=0xbfebfbff
> > >
> > > Features2=0xe3bd
> > > @@ -16,7 +16,7 @@
> > >VT-x: (disabled in BIOS) HLT,PAUSE
> > >TSC: P-state invariant, performance statistics
> > >  real memory  = 4294967296 (4096 MB)
> > > -avail memory = 3639914496 (3471 MB)
> > > +avail memory = 4154175488 (3961 MB)
> > > 
> > > Somehow the r343567 kernel found an addition 490 MB of memory,
> > > which leads me to believe the after loading i915kms.ko there
> > > is some serious memory stomping issues.
> > > 
> > > I willing to do whatever is necessary to fix this issue (shorter
> > > of mailing the laptop to someone).  Is it possible to revert
> > > r343567 and move forward? 
> > > 
> > 
> > More info from sysctl.  With the "good" r343566, I see
> > 
> > vm.kmem_map_free: 1187033088
> > vm.kmem_map_size: 27234304
> > vm.kmem_size_scale: 3
> > vm.kmem_size_max: 1715470336
> > vm.kmem_size_min: 12582912
> > vm.kmem_zmax: 65536
> > vm.kmem_size: 1214267392
> > hw.physmem: 3714269184
> > hw.usermem: 3650867200
> > hw.realmem: 4294963200
> > 
> > With the problematic r343567, I see
> > 
> > vm.kmem_map_free: 1683152896
> > vm.kmem_map_size: 28123136
> > vm.kmem_size_scale: 1
> > vm.kmem_size_max: 1711276032
> > vm.kmem_size_min: 12582912
> > vm.kmem_zmax: 65536
> > vm.kmem_size: 1711276032
> > hw.physmem: 4252360704
> > hw.usermem: 4146999296
> > hw.realmem: 4294963200
> > 
> > Ideas?
> > 
> 
> Here's the 'diff -uw' between a verbose dmesg boot of r343566
> and dmesg boot of r343567.  The memory size looks rather puzzling.
> Can the people responsible for the i386 pmap.h merging take a
> look?
What is puzzling ?

When kernel boots in PAE mode, it can (and will) get a use for physical
memory mapped above 4G.  I highlighted the SMAP entry which represents
such memory, below.

kmem_scale was changed in the PAE commit, see the commit message for
explanation.

> 
> --- dmesg.343566.verbose  2019-02-22 19:08:33.458559000 -0800
> +++ dmesg.343567.verbose  2019-02-22 08:55:21.62331 -0800
> @@ -8,25 +8,25 @@
>  Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
>  FreeBSD is a registered trademark of The FreeBSD Foundation.
> -FreeBSD 13.0-CURRENT r343566 GENERIC i386
> +FreeBSD 13.0-CURRENT r343567 GENERIC i386
>  FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 
> 7.0.1)
>  WARNING: WITNESS option enabled, expect reduced performance.
>  VT(vga): resolution 640x480
> -Preloaded elf kernel "/boot/kernel/kernel" at 0x2501000.
> -Preloaded boot_entropy_cache "/boot/entropy" at 0x2509b20.
> -Preloaded elf module "/boot/kernel/cpuctl.ko" at 0x2509b6c.
> -Preloaded elf module "/boot/kernel/if_ath.ko" at 0x2509f68.
> -Preloaded elf module "/boot/kernel/ath_dfs.ko" at 0x250a314.
> -Preloaded elf module "/boot/kernel/ath_rate.ko" at 0x250a6c0.
> -Preloaded elf module "/boot/kernel/ath_hal_ar9300.ko" at 0x250aa70.
> -Preloaded elf module "/boot/kernel/ath_hal_ar5416.ko" at 0x250ae9c.
> -Preloaded elf module "/boot/kernel/ath_hal_ar5212.ko" at 0x250b2c8.
> -Preloaded elf module "/boot/kernel/ath_hal_a

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Konstantin Belousov]

On Sat, Feb 23, 2019 at 10:04:07AM -0800, Rodney W. Grimes wrote:
> > On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote:
> > > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote:
> > > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote:
> > > > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote:
> > > > > > r343567 merges the PAE vs non-PAE pmap headers for i386
> > > > > > freebsd.  After bisection and dealing with the drm-legacy-kmod
> > > > > > fallout, I bisected /usr/src to r343567.  Building world and
> > > > > > a GENERIC kernel and the minimum set of ports to start Xorg
> > > > > > on my Dell Latitude D530 laptop, results in a black screen
> > > > > > of death and a locked up laptop (no keyboard, mouse, or video).
> > > > > > 
> > > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads
> > > > > > and functions) and r353467 (Xorg black screen of death) shows
> > > > > > that /boot/modules/i915kms.ko loads correctly as the log
> > > > > > files are identical.
> > > > > > 
> > > > > > Comparing dmesg for r343566 to r343567 shows the following
> > > > > >  
> > > > > > --- dmesg.3435662019-02-20 08:13:07.727202000 -0800
> > > > > > +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800
> > > > > > @@ -3,11 +3,11 @@
> > > > > >  Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 
> > > > > > 1993, 1994
> > > > > > The Regents of the University of California. All rights 
> > > > > > reserved.
> > > > > >  FreeBSD is a registered trademark of The FreeBSD Foundation.
> > > > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386
> > > > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386
> > > > > >  FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based 
> > > > > > on LLVM 7.0.1)
> > > > > >  WARNING: WITNESS option enabled, expect reduced performance.
> > > > > >  VT(vga): resolution 640x480
> > > > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 
> > > > > > 686-class CPU)
> > > > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 
> > > > > > 686-class CPU)
> > > > > >Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  
> > > > > > Stepping=13
> > > > > >
> > > > > > Features=0xbfebfbff
> > > > > >
> > > > > > Features2=0xe3bd
> > > > > > @@ -16,7 +16,7 @@
> > > > > >VT-x: (disabled in BIOS) HLT,PAUSE
> > > > > >TSC: P-state invariant, performance statistics
> > > > > >  real memory  = 4294967296 (4096 MB)
> > > > > > -avail memory = 3639914496 (3471 MB)
> > > > > > +avail memory = 4154175488 (3961 MB)
> > > > > > 
> > > > > > Somehow the r343567 kernel found an addition 490 MB of memory,
> > > > > > which leads me to believe the after loading i915kms.ko there
> > > > > > is some serious memory stomping issues.
> > > > > > 
> > > > > > I willing to do whatever is necessary to fix this issue (shorter
> > > > > > of mailing the laptop to someone).  Is it possible to revert
> > > > > > r343567 and move forward? 
> > > > > > 
> > > > > 
> > > > > More info from sysctl.  With the "good" r343566, I see
> > > > > 
> > > > > vm.kmem_map_free: 1187033088
> > > > > vm.kmem_map_size: 27234304
> > > > > vm.kmem_size_scale: 3
> > > > > vm.kmem_size_max: 1715470336
> > > > > vm.kmem_size_min: 12582912
> > > > > vm.kmem_zmax: 65536
> > > > > vm.kmem_size: 1214267392
> > > > > hw.physmem: 3714269184
> > > > > hw.usermem: 3650867200
> > > > > hw.realmem: 4294963200
> > > > > 
> > > > > With the problematic r343567, I see
> > > > > 
> > > > > vm.kmem_map_free: 1683152896
> > > > > vm.kmem_map_size: 28123136
> > > > > vm.kmem_size_scale: 1
> > > > > vm.kmem_size_max: 1711276032

Re: kqueue send over unix socket?

[Konstantin Belousov]

On Tue, Mar 12, 2019 at 04:10:19PM -0500, Larry Rosenman wrote:
> I'm working with Aki Tuomi of Dovecot and he asks:
> 
> I tried to ask if you could ask from some Kernel hacker why I cannot 
> send kqueue() fd over unix socket, I get "Operation not supported".
Right, because sending kqfd to other process does not make sense.
For the same reason kqueue filedescriptors are closed on fork.

Issue is that kqueue operates on file descriptors, it stores events
and names them by fd you use for registration.  So all registered
events names become meaningless when process operates on different
file descriptor table, which happens after fork() or if kqfd is
passed over unix socket to other process.

Technically this occurs because kqueue file ops structure does not
specify DFLAG_PASSABLE.

> 
> Can anyone help me?
> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> ___
> 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Optimization bug with floating-point?

[Konstantin Belousov]

On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> On 2019-Mar-13 23:30:07 -0700, Steve Kargl 
>  wrote:
> >AFAICT, all libm float routines need to be modified to conditional
> >include ieeefp.h and call fpsetprec(FP_PD).  This will work around
> >issues is FP and libm.  FreeBSD needs to issue an erratum about 
> >the numerical issues with clang.
> 
> I vaguely recall looking into the x87 initialisation a long time ago
> and STR that the startup code (either crtX or in the kernel) does
> a fninit() to set the precision.  I don't recall exactly where.
At boot, a clean initial FPU state is stored in fpu_initialstate.
Then on first FPU access from userspace  (first for the given process
context), this saved state is copied into hardware registers.  The
quirk is that for i386 binaries on amd64, we adjust fpu control word
to what is expected by i386 binaries.

> 
> IMO, calling fpsetprec() in every libm float function is overkill. It
> should be enough to fpsetprec() before main() and add a note in the
> man pages that libm is built to use the default FPU configuration and
> changing the configuration (precision or rounding) may result in larger
> errors.
Changing default precision in crt1 would break the ABI.
___
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: Optimization bug with floating-point?

[Konstantin Belousov]

On Thu, Mar 14, 2019 at 12:59:14PM -0700, John Baldwin wrote:
> On 3/14/19 12:20 PM, Konstantin Belousov wrote:
> > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl 
> >>  wrote:
> >>> AFAICT, all libm float routines need to be modified to conditional
> >>> include ieeefp.h and call fpsetprec(FP_PD).  This will work around
> >>> issues is FP and libm.  FreeBSD needs to issue an erratum about 
> >>> the numerical issues with clang.
> >>
> >> I vaguely recall looking into the x87 initialisation a long time ago
> >> and STR that the startup code (either crtX or in the kernel) does
> >> a fninit() to set the precision.  I don't recall exactly where.
> > At boot, a clean initial FPU state is stored in fpu_initialstate.
> > Then on first FPU access from userspace  (first for the given process
> > context), this saved state is copied into hardware registers.  The
> > quirk is that for i386 binaries on amd64, we adjust fpu control word
> > to what is expected by i386 binaries.
> > 
> >>
> >> IMO, calling fpsetprec() in every libm float function is overkill. It
> >> should be enough to fpsetprec() before main() and add a note in the
> >> man pages that libm is built to use the default FPU configuration and
> >> changing the configuration (precision or rounding) may result in larger
> >> errors.
> > Changing default precision in crt1 would break the ABI.
> 
> So what I don't understand then is what is gcc doing different than clang
> in this case.  I assume neither GCC _nor_ clang are adjusting the FPU in
> compiler-generated code, and in fact as Steve's earlier tests shows, the
> precision is set to PD by default when a clang-built binary is run.

Precision control only affect elementary floating-point instructions.
Could this be the cause ?

SDM vol 1 8.1.5.2 Precision Control Field
The precision-control bits only affect the results of the following
floating-point instructions: FADD, FADDP, FIADD, FSUB, FSUBP, FISUB,
FSUBR, FSUBRP, FISUBR, FMUL, FMULP, FIMUL, FDIV, FDIVP, FIDIV, FDIVR,
FDIVRP, FIDIVR, and FSQRT.
___
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: leaked swap?

[Konstantin Belousov]

On Mon, Mar 18, 2019 at 05:20:35PM +0200, Andriy Gapon wrote:
> 
> First, a note that this was observed on a system that runs a fairly old 
> current
> (~ 1 year old) with a fairly long uptime (> 6 months).
> I noticed that the system was nearly out of memory, 98% of swap was in use,
> there was less than 1 GB of free memory, several GBs of each of active, 
> inactive
> and laundry memory, and many GBs of wired (mostly ZFS).
> I decided to pro-actively reboot the system, but to speed that up I put the
> system to the single-user mode (via shutdown) and then back to multi-user. So,
> there was no real hardware reboot and the kernel kept running.  However, all
> userland processes were terminated.
> 
> To my surprise, even while in the single-user mode the swap utilization didn't
> go below 70%.  Also, laundry memory remained in multi-GB area, but let's 
> ignore
> this for now.
> 
> I think that the swap could be used only for anonymous memory, so I expected 
> it
> go to zero after the shutdown to the single user mode.
> Does anyone have any ideas?
> Maybe that's something that has already been fixed?
> If not, any ideas on what to look for?
tmpfs, swap-backed (or even memory backed) md, persistent posix shared
memory, SysV shared memory.
___
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 12 kernel broken

[Konstantin Belousov]

On Fri, Mar 22, 2019 at 07:08:18PM +0300, Rozhuk Ivan wrote:
> 
> 
> ld: error: undefined symbol: xz_dec_init
> >>> referenced by g_uzip_lzma.c:106 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:106)
> >>>   g_uzip_lzma.o:(g_uzip_lzma_ctor)
> 
> ld: error: undefined symbol: xz_dec_run
> >>> referenced by g_uzip_lzma.c:81 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:81)
> >>>   g_uzip_lzma.o:(g_uzip_lzma_decompress)
> 
> ld: error: undefined symbol: xz_dec_end
> >>> referenced by g_uzip_lzma.c:60 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:60)
> >>>   g_uzip_lzma.o:(g_uzip_lzma_free)
> --- kernel.full ---
> *** [kernel.full] Error code 1
> 
Read the updated man page for geom_uzip.  Add
device xz
to your kernel config.
___
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 12 kernel broken

[Konstantin Belousov]

On Sat, Mar 23, 2019 at 01:23:58AM +0300, Rozhuk Ivan wrote:
> On Fri, 22 Mar 2019 12:12:44 -0700
> Maxim Sobolev  wrote:
> 
> > src/UPDATING entry perhaps in order?
> > 
> > > Read the updated man page for geom_uzip.  Add
> > > device xz
> > > to your kernel config.
> 
> 
> https://www.freebsd.org/cgi/man.cgi?query=geom_uzip&apropos=0&sektion=0&manpath=FreeBSD+13-current&arch=default&format=html
> https://www.freebsd.org/cgi/man.cgi?query=geom_uzip&apropos=0&sektion=0&manpath=FreeBSD+12.0-stable&arch=default&format=html
> 
> I see nothing about xz.
Because you are looking at outdated man pages.

Did you tried to look at the page from the same checkout as you build
the kernel from ?

> src/UPDATING - nothing.
___
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: Kernel regression in head, now unusable for package building

[Konstantin Belousov]

On Mon, Apr 08, 2019 at 12:10:23AM +0200, Antoine Brodin wrote:
> Hi,
> 
> There seems to be a kernel regression in head,  that happened
> somewhere between r343921 and r345991.
Can you bisect ?

I looked over the stated range and I do not see a revision that would be
an obvious candidate for the regression. I could think about r345955,
r345980, and r345982/r345983 as something that might be most interesting
to try.

> When launching "poudriere bulk -a",  the ssh session is terminated
> when poudriere attempts to clone/start builders (tmpfs mounts, file
> copying...),  the jails don't start and the consequence is that we
> can't build any package.
Are there any more details about the issue ?  It is not clear, does the
machine survives the event, i.e. did kernel paniced, what are the console
messages, any more details that you can provide.

Long time ago there was a similarly sound bug where mountd(8) signalled wrong
process, which caused ssh sessions termination.

> 
> Cheers,
> 
> Antoine (with hat: portmgr)
___
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: CFT: FreeBSD Package Base

[Konstantin Belousov]

Cc: list trimmed to relevant.  Very long essey below, be warned.

On Sun, Apr 28, 2019 at 03:52:21PM -0400, k...@ixsystems.com wrote:
> FreeBSD Community,
> 
>  
> 
> I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current
> using "TrueOS-inspired" packaged base. These are stock FreeBSD images which
> will allow users to perform all updating via the 'pkg' command directly.
> Rather than trying to answer all questions in this announcement, we've
> created a FAQ page with more details. Please refer to this page, and let us
> know if you have additional questions that we can include on that page going
> forward.
> 
>  
> 
> Additionally, I will be hosting a Package Base working group at BSDCan 2019,
> and welcome user and developer attendance to discuss this and other ongoing
> package work:
> 
>  
> 
> https://wiki.freebsd.org/DevSummit/201905/PackageBase
> 
>  
> 
>  
> 
> FAQ
> 
> -
> 
> https://trueos.github.io/pkgbase-docs/
> 

I do not know what are design decisions for trueos pkgbase are, but I
do know something about in-tree split and why some packaging decisions
where made. I cannot attend your WG, but I believe the reasoning used
for the in-tree is important enough to represent it intact from the
source.  I have to start with some explanatory long text to put it into
the proper perspective.

There are two knots of interdependinces which are critical for correctness
of any upgrade where the target system cannot be simply discarded on failure:
1. C runtime
2. Minimal boot path to prompt.
Let me elaborate both, starting from point 1, which is typically very obscure
despite having the fundamental nature for anything related to upgrades.

The basic execution environment for any program executed by the FreeBSD
kernel is formed by combination of kernel' syscall interface and some
system userspace code which makes the expected environment over the
bare-bone image state after execve. The environment is typically named
C runtime environment since C language ABI is directly tied into it,
and normal C programs only get whatever is provided by the C runtime
unless additional libraries are linked in. Trully, it is not just C
runtime, any other execution environment on top of the OS is based on
this one, but since almost every 'advanced' language runtime is backed
by C language and its runtime, the name stuck.

FreeBSD C runtime, arguably, is provided by the following four objects:
/libexec/ld-elf.so.1
/lib/libc.so.7
/lib/libthr.so.3
/lib/libm.so.5
There, we do *guarantee* that the external ABI of the whole pack of
these four objects is backward compatible, i.e. if the binary was
compiled against set if base libraries at earlier date (may be also
on earlier branch), then the binary behaviour would be same when
executed on newer C runtime pack. This is not trivial to achieve,
besides technical measures that helps there, like backward-compatible
syscall interface, symbol versioning, providing fall-back code for
older interface, a lot of overhead in the development is enforced, like
carefull reviews of the changes, the policy and related discipline of
versioning, following published ABI standards, and so on.

But, internal ABI of the C runtime pack, i.e. interfaces which make rtld
work with libc and libthr, or way by which libthr, when loaded, makes
libc thread-aware, are not stable, and more, they are often changed
in backward-incompatible way. Requiring backward-compatibility there
would stop our ability to evolve the system. Answering some questions in
advance, yes, rtld delves into libc, libthr patches libc on load, libc
has hooks to control some libthr behaviour.

The only provision that we make is that ld-elf.so.1 is required to work
with older libc/libthr combination, but even then libc and libthr must
be built from the same sources with the same options set.

Now, returning to pkgbase, if you look at what libs are packed into clibs,
you see:
ld-elf.so.1
libc.so.7 (and modules like iconv tables or nss, if any)
libthr.so.3
libdl.so.1
libgcc{, _eh, _s}.so.1
libm.so.5
libedit.so.7
libncurses{, w}.so.8
libc++.so.1
It adds very popular libs like libncurses/libedit, and C++ runtime. The
basic reasoning is that this package is small and chances of something
going wrong while installing it are small as result. Put it other way,
the small clibs package organization makes it highly probable that
system is left in the consistent state (either all new libs, or all old
libs) after the upgrade, whetever the outcome is.

If the C runtime pack is not split from the whole 700MB+ update blob, libthr
update has almost certain chance to occur long after or before libc update,
so failures do tend to leave inconsistent rtld/libc/libthr set.  At best,
it gives you strange glitches, at worst you get unusable system that cannot
be repaired without exter

Re: leaked swap?

[Konstantin Belousov]

On Wed, May 15, 2019 at 10:02:51AM +1200, Thomas Munro wrote:
> 1.  As mentioned, you can't list 'em (unlike Linux, where you can just
> ls /dev/shm).  There's a TODO note, but it's not clear whether it's
> best to extend ipcs or create a new userspace tool, and it wasn't
> immediately clear to me how to feed the arbitrary sized results back
> to userspace.  I had a scheme worked out where you'd keep calling a
> sysctl repeatedly to collect the data until it was done, and it'd
> sometimes tell you you need a bigger buffer (because you probably have
> to drain at least a whole hash table bucket at a time), but an
> experienced FreeBSD hacker told me that was BS, and maybe what's
> needed is a device you read.  As well as the list-all-the-segments
> tool, you'd also want to be able to unlink to tidy up.

https://reviews.freebsd.org/D20258
___
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

[Konstantin Belousov]

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: panic booting with if_tap_load="YES" in loader.conf

[Konstantin Belousov]

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

[Konstantin Belousov]

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

[Konstantin Belousov]

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"

Re: RFC w.r.t. toggling debugging on/off for mountd via a signal

[Konstantin Belousov]

On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote:
> 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.

Instead of toggling the debugging by SIGUSR1, you can make the daemon
to try to open some file by receiving the normal reload signal, e.g.
/var/run/mountd.debug. If the file is present, the debugging is enabled.
The advantage is that the user knows what is the debugging state, instead
of requiring to count the number of sent SIGUSR1's.

More, in traditions of malloc(3), /var/run/mountd.debug could be a symlink,
which is read and interpreted as some options controlling the debug.
___
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: Weirdness when writing to pseudofs file

[Konstantin Belousov]

On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
> Hi
> 
> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
> to a file,
> 
> this works: # echo  1 >> /path/to/file
> 
> but this does not: # echo 1 > /path/to/file
> 
> "Operation not supported." is returned before the pseudofs code is even
> entered.
> 
> Is this expected behavior? (if so, why?)

Does the file exist ?

Pseudofs does not implement VOP_CREATE(), which is reasonable.
___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[Konstantin Belousov]

On Mon, May 27, 2019 at 03:55:21PM +0200, voida...@420blaze.it wrote:
> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping 
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
What problem are you trying to solve ?

> 
> The patch attached for the bug is for disabling these options by 
> default, following a few reasons which I'm going to list here:
>  - Keeping support for deprecated libraries isn't exactly the best we 
> could do to avoid security issues (if there are any) as I'm sure nobody 
> wants to spend that much time maintaining such stuff (it's enough to 
> think about misc/compat4x in the ports tree: that version of FreeBSD was 
> released on March 2000 and keeping 19 years old libraries around isn't 
> ideal)
>  - Devs should get track of time and realize that developing software 
> using unsupported libraries is NOT something that you should do
This is nonsense.  These options are not for developing new software.

>  - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older: 
> if the software won't compile without the legacy components (and has a 
> replacement of some kind), considering removal wouldn't be a bad idea
And that options are usually not about ports.

>  - This is on by default: most users don't care or don't use binaries 
> that old
This is I am really interesting about.  How do you know ?  The method
you came to this conclusion should allow us to solve many other old
issues, I hope.

> 
> I don't see any practical reason to keep these options on by default, 
> but I do appreciate any sort of input regarding this issue.

___
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: Crash on very recent CURRENT if using poudriere

[Konstantin Belousov]

On Fri, May 31, 2019 at 12:49:11PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> [panic] non-zero write count during poudriere run
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
> 
> Ideas on how to proceed ?

Try this.

diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c
index f92383179a9..b663d8d718d 100644
--- a/sys/fs/nullfs/null_vnops.c
+++ b/sys/fs/nullfs/null_vnops.c
@@ -810,6 +810,8 @@ null_reclaim(struct vop_reclaim_args *ap)
 */
if (vp->v_writecount > 0)
VOP_ADD_WRITECOUNT(lowervp, -vp->v_writecount);
+   else if (vp->v_writecount < 0)
+   vp->v_writecount = 0;
 
VI_UNLOCK(vp);
 
diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c
index f9db5f99e50..9fe58cd4c13 100644
--- a/sys/fs/tmpfs/tmpfs_subr.c
+++ b/sys/fs/tmpfs/tmpfs_subr.c
@@ -488,6 +488,8 @@ tmpfs_destroy_vobject(struct vnode *vp, vm_object_t obj)
VI_LOCK(vp);
vm_object_clear_flag(obj, OBJ_TMPFS);
obj->un_pager.swp.swp_tmpfs = NULL;
+   if (vp->v_writecount < 0)
+   vp->v_writecount = 0;
VI_UNLOCK(vp);
VM_OBJECT_WUNLOCK(obj);
 }
___
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: Crash on very recent CURRENT if using poudriere

[Konstantin Belousov]

On Sun, Jun 02, 2019 at 06:48:51PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > [panic] non-zero write count during poudriere run
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
> > > 
> > > Ideas on how to proceed ?
> > 
> > Try this.
> 
> Unfortunatly, I can no longer reproduce the crashes after the
> update of the kernel to r348454.

Regardless of that, did you run with the patch applied ?
___
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: Crash on very recent CURRENT if using poudriere

[Konstantin Belousov]

On Sun, Jun 02, 2019 at 07:45:34PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > > [panic] non-zero write count during poudriere run
> > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
> > > > > 
> > > > > Ideas on how to proceed ?
> > > > 
> > > > Try this.
> > > 
> > > Unfortunatly, I can no longer reproduce the crashes after the
> > > update of the kernel to r348454.
> > 
> > Regardless of that, did you run with the patch applied ?
> 
> No -- should I ? How would you or I know that it changed anything ?
> 
> Should I try with the previous kernel @ r348371M and that patch ?
Run today kernel with the patch.  I am only interested in report is it
panic or not (and all usual details it it does panics).
___
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: adding a syscall to libc?

[Konstantin Belousov]

On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote:
> Hi,
> 
> I've started working of a copy_file_range() syscall for FreeBSD. I think I 
> have the
> kernel patched and ready for some testing.
> However, I'm confused about what I need to do in src/lib/libc/sys?
> - Some syscalls have little .c files, but other ones do not.
>   When is one of these little .c files needed and, when not needed, what else
>   needs to be done? (I notice that syscall.mk in src/sys/sys automagically, 
> but
>   I can't see what else, if anything, needs to be done?)
Most important is to add the new syscall public symbol to sys/Symbol.map
into the correct version, FBSD_1.6 for CURRENT-13.  Do no bother with
__sys_XXX and __XXX aliases.

'Tiny .c files' are typically used for one of two purposes:
- Convert raw kernel interface into something expected by userspace,
  often this coversion uses more generic and non-standard interface to
  implement more usual function.  Examples are open(2) or waitid(2)
  which are really tiny wrappers around openat(2) and wait6(2) in
  today libc.
- Allow libthr to hook into libc to provide additional services.  Libthr
  often has to modify semantic of raw syscall, and libc contains the
  tables redirecting to implementation, the tables are patched on libthr
  load.  Since tables must fill entries with some address in case libthr
  is not loaded, tiny functions which wrap syscalls are created for
  use in that tables.

I think you do not need anything that complications for start, in which
case adding new syscall consists of the following steps:
- Add the syscall to sys/kern/syscalls.master, and if reasonable,
  to sys/compat/freebsd32/syscalls.master.
- Consider if the syscall makes sense in capsicumized environment,
  and if yes, list the syscall in sys/kern/capabilities.conf.  Typically,
  if syscall provides access to the global files namespace, it must be not
  allowed.  On the other hand, if syscall only operates on already opened
  file descriptors, then it is suitable (but of course there are lot of
  nuances).
- Add syscall prototype to the user-visible portion of header,
  hiding it under the proper visibility check.
- Add syscall symbol to lib/libc/sys/Symbol.ver.
- Implement the syscall.  There are some additional details that might
  require attention:
- If compat32 syscall going to be implemented, or you know
  that Linuxolator needs to implement same syscall and would
  like to take advantage of the code, provide
int kern_YOURSYSCALL();
  wrapper and declare it in sys/syscallsubr.h.  Real implementations
  of host-native and compat32 sys_YOURSYSCALL() should be just
  decoding of uap members and call into kern_YOURSYSCALL.
- Consider the need to add auditing for new syscall.
- Add man page for the syscall, at lib/libc/sys/YOURSYSCALL.2, and connect
  it to the build in lib/libc/sys/Makefile.inc.
- When creating review for the change, do not include diff for generated
  files after make sysent.  Similarly, when doing the commit, first commit
  everything non-generated, then do make -C sys/kern sysent (and
  make sysent -C sys/compat/freebsd32 sysent if appropriate) and commit
  the generated files in follow-up.

> 
> Thanks in advance for your help, rick
> ps: I am using the Linux man pages for the syscall ABI. At some point, I'll 
> put this
>   in phabricator and post here for comments/review.
> ___
> 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: adding a syscall to libc?

[Konstantin Belousov]

On Sun, Jun 09, 2019 at 06:12:59AM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote:
> >> Hi,
> >>
> First off, thanks Kostik for the fine explanation. I agree with Oliver that 
> it should
> be captured somewhere like the wiki. I'm no wiki guy, so hopefully someone 
> else
> will do this?
There is apparently https://wiki.freebsd.org/AddingSyscalls which is already
quite comprehensive.  I am adding missed information right now.

> 
> >> I've started working of a copy_file_range() syscall for FreeBSD. I think I 
> >> have the
> >> kernel patched and ready for some testing.
> >> However, I'm confused about what I need to do in src/lib/libc/sys?
> >> - Some syscalls have little .c files, but other ones do not.
> >>   When is one of these little .c files needed and, when not needed, what 
> >> else
> >>   needs to be done? (I notice that syscall.mk in src/sys/sys 
> >> automagically, but
> >>   I can't see what else, if anything, needs to be done?)
> >Most important is to add the new syscall public symbol to sys/Symbol.map
> >into the correct version, FBSD_1.6 for CURRENT-13.  Do no bother with
> >__sys_XXX and __XXX aliases.
> I could only find a Symbol.map in src/lib/libc/sys. I added it there and it 
> seems to
> work. (I am using a stable/12 source tree for testing the build/userland. 
> I'll check
> head in case it has moved.)
Yes, Symbol.map, it was thinko.

> 
> >'Tiny .c files' are typically used for one of two purposes:
> >- Convert raw kernel interface into something expected by userspace,
> >  often this coversion uses more generic and non-standard interface to
> >  implement more usual function.  Examples are open(2) or waitid(2)
> >  which are really tiny wrappers around openat(2) and wait6(2) in
> >  today libc.
> >- Allow libthr to hook into libc to provide additional services.  Libthr
> >  often has to modify semantic of raw syscall, and libc contains the
> >  tables redirecting to implementation, the tables are patched on libthr
> >  load.  Since tables must fill entries with some address in case libthr
> >  is not loaded, tiny functions which wrap syscalls are created for
> >  use in that tables.
> >
> >I think you do not need anything that complications for start, in which
> >case adding new syscall consists of the following steps:
> Yes, I don't think I need the above.
> 
> >- Add the syscall to sys/kern/syscalls.master, and if reasonable,
> >  to sys/compat/freebsd32/syscalls.master.
> I don't think a 32bit binary on a 64bit system needs this for now.
> (At least that's my understanding of what this is used for?)
Right.

> 
> >- Consider if the syscall makes sense in capsicumized environment,
> >  and if yes, list the syscall in sys/kern/capabilities.conf.  Typically,
> >  if syscall provides access to the global files namespace, it must be not
> >  allowed.  On the other hand, if syscall only operates on already opened
> >  file descriptors, then it is suitable (but of course there are lot of
> >  nuances).
> It uses open fds, but I think I'll leave it out of capabilities.conf for now. 
> If
> there is a need, someone more familiar with capsicum can check it.
> 
> >- Add syscall prototype to the user-visible portion of header,
> >  hiding it under the proper visibility check.
> Hmm, not quite sure what you mean here. It ends up in sys/sysproto.h
> automagically. Does it need to go somewhere else too?
sys/sysproto.h is not used by userspace.  If your syscall is going to be
useful for normal userspace (it should be, othewise why adding it at all ?)
you have to declare it in some header typically used by apps.  Take for
example include/unistd.h, where you should only add the syscall to
appropriate namespace, allowing strict standard-compliance compiler
option to hide symbols not specified by choosen standard.  I suspect that
you need
#if __BSD_VISIBLE
int your_syscall(args);
#endif
if the header is defined e.g. by POSIX.
> 
> >- Add syscall symbol to lib/libc/sys/Symbol.ver.
> All I found was lib/libc/sys/Symbol.map and I've added it there.
> 
> >- Implement the syscall.  There are some additional details that might
> >  require attention:
> >- If compat32 syscall going to be implemented, or you know
> >  that Linuxolator needs to implement same syscall and would
> >  like to take advantage of the code, provide
> >int kern_YOURSYSCALL();
> >  wrapper and declare it in sys/syscallsubr.h.  Real implementation

Re: should a copy_file_range(2) syscall be interrupted via a signal

[Konstantin Belousov]

On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote:
> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote:
> > I have been working on a Linux compatible copy_file_range(2) syscall
> > (the current code can be found at https://reviews.freebsd.org/D20584).
> 
> > One outstanding issue is how it should deal with signals. Right now, I
> > have vn_start_write() without PCATCH, so that it won't be interrupted
> > by a signal, but I notice that vn_write() {ie. write syscall } does
> > have PCATCH on vn_start_write() and so does vn_rdwr() when it is
> > called without IO_NODELOCKED.
> 
> A regular write() is only interruptible when writing to a terminal,
> pseudo-terminal master, pipe, socket, or, under certain conditions, a
> file on an NFS intr mount. Therefore, applications may not have the code
> to resume interrupted writes to regular files gracefully.
> 
> > I am thinking that copy_file_range(2) should do this also.
> > However, if it returns an error, it is impossible for the caller to
> > know how much of the data range got copied.
> 
> A regular write() returns partial success if interrupted by a signal
> when it has already written something. Therefore, the application can
> resume the operation by adjusting pointers and counts.
> 
> Something similar applies to "deterministic" errors like [EFBIG] where
> the first call will write as far as possible (if this is not nothing)
> successfully and the next attempt will return the error.
> 
> > What do you think the copy_file_range(2) code should do?
> 
> I'm not sure it should actually be done, but the need for adjusting
> pointers and counts could be avoided with a little extra kernel and libc
> code. The system call would receive an additional argument pointing to
> an off_t that indicates how many bytes previous calls have already
> written. A libc wrapper would initialize this to 0. With this, the
> system call can be restarted automatically after a signal.
> 
> In any case, [EINTR] and the internal ERESTART must not be returned
> unless it is safe to repeat the call with the same (direct) arguments.

BTW, if the syscall is made interruptible, it should be made cancellable ?

I think that PCATCH commonly used for vn_start_write(9) is not the best
decision.  It is safe in the sense explained by Jilles, since its interruption
only happens at the very beginning of the syscall, but it contradict to the
tradition of write(2) to the local fs being not interruptible.

I suggest to not make the syscall interruptible by default, and perhaps
only allow it with a flag.  Then you would need to explain that the
syscall is only interruptible between VOPs, it is up to fs to decide if
the VOP_READ/VOP_WRITE is interruptible (e.g. devfs and nfs).
___
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: should a copy_file_range(2) syscall be interrupted via a signal

[Konstantin Belousov]

On Fri, Jul 05, 2019 at 08:59:23PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote:
> >> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote:
> >> > I have been working on a Linux compatible copy_file_range(2) syscall
> >> > (the current code can be found at https://reviews.freebsd.org/D20584).
> >>
> >> > One outstanding issue is how it should deal with signals. Right now, I
> >> > have vn_start_write() without PCATCH, so that it won't be interrupted
> >> > by a signal, but I notice that vn_write() {ie. write syscall } does
> >> > have PCATCH on vn_start_write() and so does vn_rdwr() when it is
> >> > called without IO_NODELOCKED.
> >>
> >> A regular write() is only interruptible when writing to a terminal,
> >> pseudo-terminal master, pipe, socket, or, under certain conditions, a
> >> file on an NFS intr mount. Therefore, applications may not have the code
> >> to resume interrupted writes to regular files gracefully.
> Yes, agreed. Since this syscall only works on VREG vnodes, the only weird 
> cases
> are NFS (and maybe fuse). I'll let asomers@ address the fuse situation.
> 
> >>
> >> > I am thinking that copy_file_range(2) should do this also.
> >> > However, if it returns an error, it is impossible for the caller to
> >> > know how much of the data range got copied.
> >>
> >> A regular write() returns partial success if interrupted by a signal
> >> when it has already written something. Therefore, the application can
> >> resume the operation by adjusting pointers and counts.
> >>
> >> Something similar applies to "deterministic" errors like [EFBIG] where
> >> the first call will write as far as possible (if this is not nothing)
> >> successfully and the next attempt will return the error.
> >>
> >> > What do you think the copy_file_range(2) code should do?
> >>
> >> I'm not sure it should actually be done, but the need for adjusting
> >> pointers and counts could be avoided with a little extra kernel and libc
> >> code. The system call would receive an additional argument pointing to
> >> an off_t that indicates how many bytes previous calls have already
> >> written. A libc wrapper would initialize this to 0. With this, the
> >> system call can be restarted automatically after a signal.
> >>
> >> In any case, [EINTR] and the internal ERESTART must not be returned
> >> unless it is safe to repeat the call with the same (direct) arguments.
> Well, since the copy_file_range(2) syscall is allowed to return fewer bytes 
> copied
> than requested and this doesn't mean EOF, it seems that doing that would
> achieve the result of allowing an application to call it again.
> (Basically, it must be used in a loop until the bytes of the range have been 
> copied,
>  since returning fewer bytes copied than requested is a normal outcome.)
> 
> >BTW, if the syscall is made interruptible, it should be made cancellable ?
> Not sure what you mean by "cancellable"? If you mean "terminated by a signal
> where there has been no change to the output file, then that could only 
> easily be
> done by returning EINTR before any data has been copied.
> If you mean something else, then I'd need to know what that is?
See pthread_setcancelstate(3) for start, but the POSIX 1003.1-2017
2.9.5 Thread Cancellation is the definitive spec, including the quite
readable overview.

> 
> >I think that PCATCH commonly used for vn_start_write(9) is not the best
> >decision.  It is safe in the sense explained by Jilles, since its 
> >interruption
> >only happens at the very beginning of the syscall, but it contradict to the
> >tradition of write(2) to the local fs being not interruptible.
> >
> >I suggest to not make the syscall interruptible by default, and perhaps
> >only allow it with a flag.  Then you would need to explain that the
> >syscall is only interruptible between VOPs, it is up to fs to decide if
> >the VOP_READ/VOP_WRITE is interruptible (e.g. devfs and nfs).
> This is how it is coded now. The one thing I have noticed is that a
> copy_file_range() can take a long time (about 2min for 2Gbytes on the old 
> hardware
> I test on). This seems like a long delay for C when you do that to an 
> application
> copying a large file. ("cp" and "dd" also take 2min for 2Gbytes, so it isn't 
> a bug
> in copy_file_range(2). It just introduces a long delay in response to 
> C.)
That long delay is inconvenience but not something that we should spent
too much time trying to fix. We cause the same delay if program does a
write(2) of several GB, or when very large process like firefox dumps
core.
___
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: vm_page_free_prep: freeing mapped page

[Konstantin Belousov]

On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> I have cores.  Ideas?
> svn rev: r349976
> 
> [I] ➜ more core.txt.12
> borg.lerctr.org dumped core - see /var/crash/vmcore.12
> 
> Sat Jul 13 16:47:03 CDT 2019
> 
> FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976 
> LER-MINIMAL  amd64
> 
> panic: vm_page_free_prep: freeing mapped page 0xf82031044790
> 
> 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-freebsd13.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:
> panic: vm_page_free_prep: freeing mapped page 0xf82031044790
> cpuid = 21
> time = 1563053382
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> 0xfe018f9fd890
> vpanic() at vpanic+0x19d/frame 0xfe018f9fd8e0
> panic() at panic+0x43/frame 0xfe018f9fd940
> vm_page_free_prep() at vm_page_free_prep+0x18a/frame 0xfe018f9fd960
> vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfe018f9fd990
> vm_object_terminate() at vm_object_terminate+0x1db/frame 
> 0xfe018f9fd9e0
> vm_object_deallocate() at vm_object_deallocate+0x412/frame 
> 0xfe018f9fda40
> vm_map_process_deferred() at vm_map_process_deferred+0x7f/frame 
> 0xfe018f9fda60
> kern_munmap() at kern_munmap+0x181/frame 0xfe018f9fdad0
> amd64_syscall() at amd64_syscall+0x25c/frame 0xfe018f9fdbf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 
> 0xfe018f9fdbf0
> --- syscall (73, FreeBSD ELF64, sys_munmap), rip = 0x80119978a, rsp = 
> 0x7fffce18, rbp = 0x7fffce20 ---
> Uptime: 2h27m22s
> Dumping 15640 out of 131026 
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> 
> __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=1) at /usr/src/sys/kern/kern_shutdown.c:392
> #2  0x804b6620 in kern_reboot (howto=260)
>  at /usr/src/sys/kern/kern_shutdown.c:479
> #3  0x804b6a99 in vpanic (fmt=, ap= out>)
>  at /usr/src/sys/kern/kern_shutdown.c:905
> #4  0x804b67d3 in panic (fmt=)
>  at /usr/src/sys/kern/kern_shutdown.c:832
> #5  0x8076c21a in vm_page_free_prep (m=0xf82031044790)
>  at /usr/src/sys/vm/vm_page.c:3273
> #6  0x80768152 in vm_page_free_toq (m=0xf82031044790)
>  at /usr/src/sys/vm/vm_page.c:3483
> #7  0x8076321b in vm_object_terminate_pages (object= out>)
>  at /usr/src/sys/vm/vm_object.c:726
> #8  vm_object_terminate (object=0xf81b924c9600)
>  at /usr/src/sys/vm/vm_object.c:798
> #9  0x80762582 in vm_object_deallocate 
> (object=0xf81b924c9600)
>  at /usr/src/sys/vm/vm_object.c:663
> #10 0x80756aef in vm_map_entry_deallocate (entry= out>,
>  system_map=0) at /usr/src/sys/vm/vm_map.c:3457
> #11 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:586
> #12 0x807606b1 in kern_munmap (td=0xf80c207e,
>  addr0=, size=149200896) at 
> /usr/src/sys/vm/vm_mmap.c:603
> #13 0x807adaac in syscallenter (td=0xf80c207e)
>  at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
> #14 amd64_syscall (td=0xf80c207e, traced=0)
>  at /usr/src/sys/amd64/amd64/trap.c:1181
> #15 
> #16 0x00080119978a in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffce18
> (kgdb)

What was the process which caused the panic ?  Was it threaded ?

___
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: vm_page_free_prep: freeing mapped page

[Konstantin Belousov]

On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote:
> On Sun, Jul 14, 2019 at 01:14:57AM +0300, Konstantin Belousov wrote:
> > On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> > > I have cores.  Ideas?
> > > svn rev: r349976
> > > 
> > > [I] ➜ more core.txt.12
> > > borg.lerctr.org dumped core - see /var/crash/vmcore.12
> > > 
> > > Sat Jul 13 16:47:03 CDT 2019
> > > 
> > > FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976 
> > > LER-MINIMAL  amd64
> > > 
> > > panic: vm_page_free_prep: freeing mapped page 0xf82031044790
> >
> > What was the process which caused the panic ?  Was it threaded ?
> 
> I looked at some of the kernel dumps.  In all cases the crashing process
> is postgres.  We have:
> 
> (kgdb) p/x *m->md.pv_list.tqh_first
> $20 = {
>   pv_va = 0x801c0, 
>   pv_next = {
> tqe_next = 0xf80b3aacb568, 
> tqe_prev = 0xf81faf7ecbe8
>   }
> }
> (kgdb) p/x *m->md.pv_list.tqh_first->pv_next.tqe_next
> $21 = {
>   pv_va = 0x801c0, 
>   pv_next = {
> tqe_next = 0x0, 
> tqe_prev = 0xf80b3ab905d0
>   }
> }
> 
> We can find the corresponding pmaps for these mappings by going
> through the corresponding pv_chunks.  Then I looked up the other
> processes with mappings of the page.  They are also postgres processes.
> We have:
> 
> $33 = {
>   prev = 0xf818baa2be00,  
>   next = 0xf80e7e9875b0, 
>   left = 0xf814df7a6310, 
>   right = 0xf80e7e9875b0, 
>   start = 0x801c0,  
>   end = 0x80aa4a000,  
>   next_read = 0x801c0, 
>   max_free = 0x3000, 
>   object = {  
> vm_object = 0xf80bbeb94400, 
> sub_map = 0xf80bbeb94400
>   },  
>   offset = 0x60,  
>   eflags = 0x0, 
The eflags value is slightly strange.

>   protection = 0x3,  
>   max_protection = 0x7,
>   inheritance = 0x0,   
>   read_ahead = 0xf,   
>  
>   wired_count = 0x0, 
>   cred = 0x0,   
>   wiring_thread = 0x0
> }  
> 
> and
> 
> (kgdb) p $33->object.vm_object->ref_count
> $34 = 0
> (kgdb) p $33->object.vm_object->shadow_count 
> $35 = 5
What is the object type ?  Can you please print the object(s) ?

> 
> So it seems that there is some problem with vm_object reference
> counting; I'd expect a vm_map_entry reference to be counted in the
> ref_count field, and we have at least two such references.
> 
> Larry, could you open a bugzilla PR for this panic?
___
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: mmap port from 9 not working

[Konstantin Belousov]

On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a 
> pointer from the kernel via an ioctl and I map it into a shared buffer.
> char *kptr;   // mem ptr from kernel
> fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t)
>  ptr);
> 
> This worked perfectly in 9; memp I had a shared block of memory between the 
> kernel and user space.
> In 11.3 this returns an errno 22, which is pretty murky. I did notice that 
> off_t doesnt yield an actual offset; I've tried putting in the correct value 
> manuallybut it just fails and fails.I've tried read only also. 
> Please Help!

Start with providing (and looking yourself) at the output of kdump/ktrace
around the failing mmap.  The checks for correctness of the mmap(2) arguments
were greatly improved during years after FreeBSD 9.
___
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: mmap port from 9 not working

[Konstantin Belousov]

On Mon, Jul 22, 2019 at 02:03:26PM +0200, Ronald Klop wrote:
>  
> Van: Laurie Jennings 
> Datum: zondag, 21 juli 2019 16:58
> Aan: Konstantin Belousov 
> CC: FreeBSD Current 
> Onderwerp: Re: mmap port from 9 not working
> > 
> >  On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov 
> >  wrote:
> > 
> > On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> > > I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a 
> > > pointer from the kernel via an ioctl and I map it into a shared buffer.
> > > char *kptr;   // mem ptr from kernel
> > > fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t)
> > >  ptr);
> > > 
> > > This worked perfectly in 9; memp I had a shared block of memory between 
> > > the kernel and user space.
> > > In 11.3 this returns an errno 22, which is pretty murky. I did notice 
> > > that off_t doesnt yield an actual offset; I've tried putting in the 
> > > correct value manuallybut it just fails and fails.I've tried read only 
> > > also. 
> > > Please Help!
> > 
> > | Start with providing (and looking yourself) at the output of kdump/ktrace
> > | around the failing mmap.  The checks for correctness of the mmap(2) 
> > arguments
> > | were greatly improved during years after FreeBSD 9.
> > Since posting this I found a thread that said something about mmap no 
> > longer supporting /dev/kmem. If that's that case I need to find another 
> > method. No sense spending a day debugging something thatisn't supposed to 
> > work. 
> > SHOULD this still work? This always worked fine with non-wired memory but 
> > maybe things have changed since 9. 
> >  
> It looks like this is not possible anymore. Here is the code change with some 
> explanation.
> https://svnweb.freebsd.org/base?view=revision&revision=307332
> https://reviews.freebsd.org/D8248
> 
> Just a question of my site out of interest to people who know more about this 
> than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in 
> user space?
> https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29

KPTI has nothing to do with that.
___
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: [package - head-i386-default][sysutils/lsof] Failed for lsof-4.93.2_2,8 in build

[Konstantin Belousov]

On Thu, Jul 25, 2019 at 02:10:46PM -0500, Larry Rosenman wrote:
> On 07/25/2019 1:40 pm, Justin Hibbits wrote:
> > On Thu, 25 Jul 2019 12:35:32 -0600
> > Alan Somers  wrote:
> > 
> >> On Thu, Jul 25, 2019 at 12:13 PM Larry Rosenman 
> >> wrote:
> >> >
> >> > On 07/25/2019 1:10 pm, Alan Somers wrote:
> >> > > On Thu, Jul 25, 2019 at 12:05 PM Larry Rosenman 
> >> > > wrote:
> >> > >>
> >> > >> Um  Who broke this?
> > ...
> >> > > "svn blame" suggests r350199 by kib.  However, refcount.h should
> >> > > only be included if lsof defines _KERNEL, which normal programs
> >> > > shouldn't. So I think this should be considered a bug in lsof.
> >> > > -Alan
> >> >
> >> >
> >> > we *HAVE* to define _KERNEL, to get at the kernel structures.
> >> 
> >> Then I think you have to live with this amount of instability.
> >> refcount(9) says that you should include .  Did you do
> >> that?  If so, then this is a man page bug and refcount(9) should also
> >> specify stdbool.h.
> >> -Alan
> > 
> >  includes  already, which typedefs bool.  So
> >  should suffice to include in lsof.
> > 
> > - Justin
> > ___
> > 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"
> 
> Thanks all!  I've got a PR into the lsof repo, and I'll fix it there.
> 
> If we can't get a release out in the next day or 2, I'll patch it in the 
> port.
> 
> https://github.com/lsof-org/lsof/pull/70

Absolutely minimal change to accomodate updated refcount.h would be
inclusion of stdbool.h.
___
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: r350484 and ASLR enabled - init died (signal 6, exit 0)

[Konstantin Belousov]

On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> 
> > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > Hi,
> > > 
> > > Has anyone else noticed the kernel being unable to spawn init lately?
> > > 
> > > All I get is:
> > > 
> > > init died (signal 6, exit 0)
> > > panic: Going nowhere without my init!
> > > 
> > > /sbin/init hasn't had any changes in 4 months, and is present in /sbin 
> > > in the new BE.
> > > 
> > > I've tried and failed in VBox at home this weekend, and in Citrix 
> > > Hypervisor 8 at $WORK today. I think we can rule out the hypervisors.
> > > 
> > > Last known working revision is r350400.
> > > 
> > > There are numerous kernel changes between r350400 and r350583. I'll 
> > > try each revision in succession and see if I can identify any 
> > > culprits.
> > > ...
> > 
> > I have not seen the behavior in question; my last update was from
> > r350566 to r350584 (and was quite uneventful).
> > 
> > In each case, a "real machine" was used (laptop & a build machine).
> 
> After more trial and error, r350484 is the culprit for Citrix 
> Hypervisor 8.
> 
> I have these lines in /boot/loader.conf:
> 
> kern.elf32.aslr.enable="1"
> kern.elf32.aslr.pie_enable="1"
> 
> kern.elf64.aslr.enable="1"
> kern.elf64.aslr.pie_enable="1"
> 
> r350483 works like a charm, and so does r350484 iff I disable ASLR.
> 
> Reenabling ASLR and setting kern.elf{64,32}.aslr.stack_gap to zero has 
> no effect.
> 
> I've cc'd kib@ on this one.
> 
> I'm going home and see if VBox 6.0.10 exhibits the same behaviour.

Try r350608. There was a mis-merge in the committed patch (more serious
part), and some limits were not applied, which I did not see in my
testing due to the mismatch between stock FreeBSD and my testing
environment.
___
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"

NIS maps value length increase to 16m

[Konstantin Belousov]

Apparently, NIS is still in use even in large enterprise environments,
not everything was consumed by LDAP.  And there, Linux added a quirk
very long time ago, in 2013 at least, see
https://marc.info/?l=fedora-extras-commits&m=13667504323&w=2

What they did is the increase of the longest allowed key value (and
key name) in a map, from Sun-defined 1024 to 16M.  This change is
backward-compatible, in the sense that either old NIS master or old
NIS client are protocol-compatible with the updated masters and
clients, assuming that the maps only export values limited to 1024
bytes in length.  On the other hand, a new client can use much larger
values.  This works because values are specified in yp XDR as opaque
variadic-length arrays.

An example where this is useful is the environment with very large
automount maps exported by NIS.  For obvious reasons, FreeBSD cannot
function in such settings.

I wrote the patch to bump the limit in FreeBSD NIS implementation,
both in client and in servers, see
https://reviews.freebsd.org/D20900
If you are interested in the NIS code, please review.  I want to commit
the change into HEAD in approximately two weeks from now.

___
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: r350484 and ASLR enabled - init died (signal 6, exit 0)

[Konstantin Belousov]

On Thu, Aug 08, 2019 at 09:35:23AM +0300, Vladimir Zakharov wrote:
> On Mon, Aug 05, 2019, Konstantin Belousov wrote:
> > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> > > 
> > > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > > > Hi,
> > > > > 
> > > > > Has anyone else noticed the kernel being unable to spawn init lately?
> > > > > 
> > > > > All I get is:
> > > > > 
> > > > > init died (signal 6, exit 0)
> > > > > panic: Going nowhere without my init!
> > > > > 
> > Try r350608. There was a mis-merge in the committed patch (more serious
> > part), and some limits were not applied, which I did not see in my
> > testing due to the mismatch between stock FreeBSD and my testing
> > environment.
> 
> The issue persists still at r350713 on HP Probook after clean rebuild.
> 
> root@# uname -a
> FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r350713 GENERIC-NODEBUG  
> amd64
> 
> root@# grep aslr /boot/loader.conf
> #kern.elf32.aslr.enable=1
> #kern.elf64.aslr.enable=1

I was able to reproduce it, try r350758.
___
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: rc script: manual stop vs system shutdown

[Konstantin Belousov]

On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote:
> On 01/08/2019 22:51, Ian Lepore wrote:
> > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote:
> >> On 01/08/2019 19:12, Warner Losh wrote:
> >>>
> >>>
> >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes
> >>> mailto:freebsd-...@gndrsh.dnsmgr.net>>
> >>> wrote:
> >>>
> >>> >
> >>> > Is it possible in an rc script to distinguish between a manual stop
> >>> > (e.g., service foo stop) and a stop during a system shutdown (via
> >>> > rc.shutdown) ?
> >>> > Are there any marker variables for that?
> >>> > Or something in the global system state?
> >>>
> >>> Not that I can think of, but I like this idea,
> >>> I am sure that use cases exist.
> >>>
> >>>
> >>> What is the use case that needs to disambiguate the two cases...
> >>
> >> I have one use case in mind and it's a truly special case.
> >> I want rc.d/watchdogd to gracefully stop watchdogd and to disable the
> >> watchdog timer when the stop action is requested manually.  And I want
> >> it to stop watchdogd and set the watchdog timer to a special shutdown
> >> timeout during the shutdown.  If the special timeout is configured, of
> >> course.
> >>
> > 
> > The shutdown timeout is already supported:  you just set '-x '
> > in watchdogd_flags in rc.conf; no changes to the rc.d script needed.
> > 
> > I think probably you don't even need the first part of what you want. 
> > The -x arg covers you in the reboot case; most people probably won't
> > use it.  But if you are using it, and you want to truly kill the dog,
> > you would just do "watchdog -t 0" after "service watchdogd stop".  If
> > you really felt the need to cover that with a single service command,
> > then how about using "service watchdogd cancel" where the cancel verb
> > does the -t 0 after killing the daemon?
> 
> I guess that there is more than one way to achieve what I want or
> something similar to that.
> Rather than "expend words" on a theoretical discussion, I decided to do
> this: https://reviews.freebsd.org/D21221
> However, I am still open to the discussion and suggestions.
> One thing that I would prefer, though, is to make the watchdogd service
> as smart as possible -- but not smarter :-) -- that is, I would prefer
> to do without adding any new command verbs to it.

Did you considered exporting kern_shutdown.c:rebooting as a sysctl ?
___
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: userret: assert td_lk_slocks == 0

[Konstantin Belousov]

On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote:
> 
> I am trying to debug a leak of a shared vnode lock and I noticed that
> there is no check for td_lk_slocks in userret.  There are checks for
> td_rw_rlocks and td_sx_slocks.  I wonder if there is any valid scenario
> where a thread is allowed to retain a shared lock manager lock across
> system calls.

There is a situation where thread returns while keeping the lockmgr lock
busied.  This is used by buffer cache to keep everybody hands away of
async buffers until io is finished.  But the ownership of the lock is
erased, and the thread's slocks count is decremented.

I think it should be correct to add the assert you proposed.
___
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"

Stop installing /usr/bin/clang

[Konstantin Belousov]

Please look at https://reviews.freebsd.org/D21060
I propose to stop installing /usr/bin/clang, clang++, clang-cpp.

It probably does not matter when all your software comes from ports or
packages, but is actually very annoying when developing on FreeBSD.
In particular, you never know which `clang' is called in the user
environment, because it depends on the $PATH elements ordering.

To clear some confusion: this has nothing to do with not installing
compiler from base, /usr/bin/c{c,++,pp} are still there after the change
is applied.  It only to make clang on par with gcc, and to remove one
thing that was quite time-consuming in multi-target environment for me
during porting something large in FreeBSD userspace.
___
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: Stop installing /usr/bin/clang

[Konstantin Belousov]

On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> I see the same thing with base /usr/bin/ld and /usr/local/bin/ld from 
> binutils.
Yes but a direct ld use is very rare. When it is needed, usually the
level of hackery applied is already high enough for the user to already
know what she does.  I did not see it causing issues practically, while
multiple clangs in the path cause real problems.

> 
> --- Original message ---
> From: "Konstantin Belousov" 
> Date: 15 August 2019, 19:48:37
> 
> Please look at https://reviews.freebsd.org/D21060
> I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> 
> It probably does not matter when all your software comes from ports or
> packages, but is actually very annoying when developing on FreeBSD.
> In particular, you never know which `clang' is called in the user
> environment, because it depends on the $PATH elements ordering.
> 
> To clear some confusion: this has nothing to do with not installing
> compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> is applied.  It only to make clang on par with gcc, and to remove one
> thing that was quite time-consuming in multi-target environment for me
> during porting something large in FreeBSD userspace.
> ___
> 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Stop installing /usr/bin/clang

[Konstantin Belousov]

On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote:
> On 15/08/2019 17:48, Konstantin Belousov wrote:
>  > Please look at https://reviews.freebsd.org/D21060
>  > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
>  >
>  > It probably does not matter when all your software comes from ports or
>  > packages, but is actually very annoying when developing on FreeBSD.
>  > In particular, you never know which `clang' is called in the user
>  > environment, because it depends on the $PATH elements ordering.
> 
> What is the confusion here?
Between /usr/bin/clang and /usr/local/bin/clang.

> The binary that is invoked as clang is from the base system.
Not necessary.

> The binary that is invoked as clang{version number} is from ports.
This is irrelevant.

> If the user has built clang from source and has set up 
> their path to put that first, then they will get a different clang, but 
> there's no way we can stop that kind of behaviour.
This is irrelevant as well.

You did not read neither review summary nor followups.  clang also
comes from devel/llvm.  Users that want clang do install it, esp. when
version in base is different.

> 
> For reference, on my machine, I have:
> 
> clang <- this one is from the base system
> clang60 <- this one if from ports
> clang70 <- this one if from ports
> clang80 <- this one if from ports
> clang-devel <- this one if from ports
> 
> Nothing in my PATH order affects this.
> 
> The only source of confusion that I regularly encounter comes from the 
> fact that FreeBSD packages install clang80, when every other system 
> installs clang-8, so I end up having to have a special case in CMake 
> logic for finding specific versions of tools like clang-format on FreeBSD.
> 
> That said, I don't know what the impact would be on configure scripts if 
> we didn't have a clang binary.  CMake seems to run ${CC} -v and parse 
> the output, so it's quite happy finding that cc is clang (and the 
> specific version).  How do most autoconf things handle this?  Apple 
> shipped a gcc symlink to clang for years because, in the absence of a 
> gcc binary, a load of programs detected /usr/bin/cc and decided not to 
> enable any GNU extensions.  We've managed to avoid having to do that, 
> but how many things look for clang, gcc, and cc in the path and enable 
> features based on which one they find?

I plan to ask for exp run with the patch after some more time to gather
feedback.
___
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: Stop installing /usr/bin/clang

[Konstantin Belousov]

On Fri, Aug 16, 2019 at 02:14:38AM -0700, Rodney W. Grimes wrote:
> > On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from 
> > > binutils.
> > Yes but a direct ld use is very rare. When it is needed, usually the
> > level of hackery applied is already high enough for the user to already
> > know what she does.  I did not see it causing issues practically, while
> > multiple clangs in the path cause real problems.
> 
> Though I have accepted the change, I have now heard this "multiple foo
> in path" argument twice, could you please elaborate on it?
I already did that more than once.  Please read the review.

> 
> If /usr/bin /bin are first I should get base stuff, 
> if /usr/local/bin are first I should get local stuff,
> what exactly is this "real problems" your refering too?
You cannot mandate the path elements order for user, there are multiple
conflicting requirements which create loop in the elements ordering.
Removing clang from /usr/bin removes one of the requirement.

People have to put ~/bin in front of their $PATH and create symlink,
which raises questions why should they do that, and makes awful experience
for starting developing on FreeBSD.

> 
> Is it that something is flipping paths around?  If so that
> should be fixed!  People have been using path to pick which
> overload order they prefer for decades, and if we have some
> how broken this.. well that should get fixed asap, not
> removing stuff out of base because something is broken by
> incorrect path manipulations.
> 
> Regards,
> Rod
> > > --- Original message ---
> > > From: "Konstantin?Belousov"?
> > > Date: 15?August?2019,?19:48:37
> > > 
> > > Please look at https://reviews.freebsd.org/D21060
> > > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> > > 
> > > It probably does not matter when all your software comes from ports or
> > > packages, but is actually very annoying when developing on FreeBSD.
> > > In particular, you never know which `clang' is called in the user
> > > environment, because it depends on the $PATH elements ordering.
> > > 
> > > To clear some confusion: this has nothing to do with not installing
> > > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > > is applied.  It only to make clang on par with gcc, and to remove one
> > > thing that was quite time-consuming in multi-target environment for me
> > > during porting something large in FreeBSD userspace.
> > > ___
> > > 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-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> > 
> 
> -- 
> Rod Grimes rgri...@freebsd.org
___
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: SVN r351457 breaks drm-current

[Konstantin Belousov]

On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
> that's the right fix.
More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
same as all in-tree consumers of the header do, apparently.

But another question is why the driver needs md_var.h, there are no
externally usable definitions there.

> 
> Warner
> 
> On Sat, Aug 24, 2019 at 10:35 AM Michael Butler 
> wrote:
> 
> > As follows ..
> >
> > Building
> >
> > /usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_compat.o
> > --- linux_compat.o ---
> > In file included from
> >
> > /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_compat.c:5:
> > ./machine/md_var.h:61:34: error: declaration of 'struct pcpu' will not
> > be visible outside of this function [-Werror,-Wvisibility]
> > voidamd64_bsp_pcpu_init1(struct pcpu *pc);
> > ^
> > ./machine/md_var.h:63:32: error: declaration of 'struct pcpu' will not
> > be visible outside of this function [-Werror,-Wvisibility]
> > voidamd64_bsp_ist_init(struct pcpu *pc);
> >   ^
> >
> > imb
> > ___
> > 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

[Konstantin Belousov]

On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
> I updated my kernel to r351461 today and now get a panic on boot.
> 
> 
> CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz
> K8-class CPU)
>   Origin="AuthenticAMD"  Id=0x800f82  Family=0x17  Model=0x8  Stepping=2
>  
> Features=0x178bfbff
>  
> Features2=0x7ed8320b
>   AMD Features=0x2e500800
>   AMD
> Features2=0x35c233ff
>   Structured Extended
> Features=0x209c01a9
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID
> EBX=0x1007
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
> real memory  = 137438953472 (131072 MB)
> avail memory = 133711564800 (127517 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> 
> Fatal trap 12: page fault while in kernel mode
> 
> cpuid = 0; apic id = 00
> 
> fault virtual address   = 0x30
> 
> fault code  = supervisor read data, page not present
> 
> instruction pointer = 0x20: 0x811bc664
So what is the source line for this address ?

> 
> stack pointer = 0x28:0x8441faa0
> 
> frame pointer = 0x28:0x8441fae0
> 
> code segment = base 0x0, limit 0xf, type 0x1b
> 
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> 
> processor eflags = resume, IOPL = 0
> 
> current process = 0 ()
> 
> tral number = 12
> 
> panic: page fault
> 
> cpuid = 0
> 
> time = 1
> 
> KDB: stack backtrace:
> 
> db_trace_self_wrapper()
> 
> ...
> 
> --- trap 0xc, rip = 0x811bc664, rsp = 0x8441faa0, rbp =
> 0x8441fae0 ---
> 
> native_start_all_aps()
> 
> cpu_mp_start()
> 
> mp_start()
> 
> mi_startup()
> 
> 
> -- 
> 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"
___
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 on boot with r351461 (AMD ThreadRipper 2990WX)

[Konstantin Belousov]

On Sat, Aug 24, 2019 at 04:54:26PM -0600, Rebecca Cran wrote:
> On 2019-08-24 14:33, Konstantin Belousov wrote:
> > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
> >> instruction pointer = 0x20: 0x811bc664
> > So what is the source line for this address ?
> 
> 
> I built a new kernel and got a new panic instruction pointer address of
> 0x8117f67c, but running it through addr2line only gave a
> function name, not a line number:
> 
> addr2line -af -e /usr/lib/debug/boot/kernel/kernel.debug 0x8117f67c
Use gdb instead.

> 
> mp_realloc_pcpu
> /usr/src/sys/amd64/amd64/mp_machdep.c:0

What was the previous bootable version of the kernel ?

Do you happen to have NUMA node without any local memory ? (Look at the
SRAT table).  If yes, try this patch.

diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index b38c688f8b4..84ce0b779ab 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -402,6 +402,8 @@ mp_realloc_pcpu(int cpuid, int domain)
return;
m = vm_page_alloc_domain(NULL, 0, domain,
VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ);
+   if (m == NULL)
+   return;
na = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m));
pagecopy((void *)oa, (void *)na);
pmap_qenter((vm_offset_t)&__pcpu[cpuid], &m, 1);
___
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 on boot with r351461 (AMD ThreadRipper 2990WX)

[Konstantin Belousov]

On Sat, Aug 24, 2019 at 05:29:23PM -0600, Rebecca Cran wrote:
> On 2019-08-24 17:08, Konstantin Belousov wrote:
> >
> > Use gdb instead.
> 
> Ah, thanks.
> 
> (gdb) info line *0x8117f67c
> Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address
> 0x8117f674  and ends at
> 0x8117f69a 
> 
> 
> > What was the previous bootable version of the kernel ? 
> 
> I attempted to upgrade from r350575.
> 
> > Do you happen to have NUMA node without any local memory ? (Look at the
> > SRAT table).  If yes, try this patch.
> 
> After applying the patch, I get a crash with the following backtrace:
What are the panic messages ?

> 
> 
> vm_domainset_iter_first()
What is the source line ?

> 
> vm_domainset_iter_policy_init()
> 
> kmem_malloc_domainset()
> 
> native_start_all_aps()
What is the source line ?

> 
> cpu_mp_start()
> 
> mp_start()
> 
> mi_startup()
> 
> 
> (gdb) info line *0x80f1027c
> Line 102 of "/usr/src/sys/vm/vm_domainset.c" starts at address
> 0x80f10267 
>    and ends at 0x80f1027f .
> 
> The SRAT contains:
> 
> 
>     Type=Memory
>     Flags={ENABLED}
>     Base Address=0x
>     Length=0x000a
>     Proximity Domain=0
> 
>     Type=Memory
>     Flags={ENABLED}
>     Base Address=0x0010
>     Length=0x7ff0
>     Proximity Domain=0
> 
>     Type=Memory
>     Flags={ENABLED}
>     Base Address=0x0001
>     Length=0x000f8000
>     Proximity Domain=0
> 
>     Type=Memory
>     Flags={ENABLED}
>     Base Address=0x00108000
>     Length=0x0010
>     Proximity Domain=2
> 
> 
> -- 
> 
> 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 on boot with r351461 (AMD ThreadRipper 2990WX)

[Konstantin Belousov]

On Sun, Aug 25, 2019 at 07:17:20AM -0600, Rebecca Cran wrote:
> On 2019-08-25 00:24, Konstantin Belousov wrote:
> > What are the panic messages ?
> 
> Fatal trap 18: integer divide fault while in kernel mode
> 
> instruction pointer = 0x20:0x80f1027c
> 
> stack pointer = 0x28:0x845809f0
> 
> frame pointer = 0x28:0x84580a00
> 
> code segment = base 0x0, limit 0xff, type 0x1b
> 
>     = DPL 0, pres 1, long 1, def32 0, gran 1
> 
> processor eflags = resume, IOPL = 0
> 
> current process = 0 ()
> 
> trap number = 18
> 
> panic: integer divide fault
> 
> cpuid = 0
> 
> time = 1
> 
> 
> > What is the source line ?
> 
> (gdb) info line *0x80f1027c
> Line 102 of "/usr/src/sys/vm/vm_domainset.c" starts at address
> 0x80f10267 
>    and ends at 0x80f1027f .

There was one more source line I asked about.

So what happens, IMO, is that for memory-less domains ds_cnt is zero
because ds_mask is zero, which causes the exception on divide.  You
can try the following combined patch, but I really dislike the fact
that I cannot safely use DOMAINSET_FIXED (if my diagnosis is correct).

I would prefer for kmem_malloc_domainset(DOMAINSET_FIXED(unpopulated domain))
to fail with NULL result, and then I would manually fall-back to
DOMAINSET_PREF().

OTOH, I think the chunk for mp_realloc_cpu() is the final fix.

diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index b38c688f8b4..2c3dc8744f6 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -402,6 +402,8 @@ mp_realloc_pcpu(int cpuid, int domain)
return;
m = vm_page_alloc_domain(NULL, 0, domain,
VM_ALLOC_NORMAL | VM_ALLOC_NOOBJ);
+   if (m == NULL)
+   return;
na = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m));
pagecopy((void *)oa, (void *)na);
pmap_qenter((vm_offset_t)&__pcpu[cpuid], &m, 1);
@@ -481,10 +483,10 @@ native_start_all_aps(void)
M_ZERO);
mce_stack = (char *)kmem_malloc(PAGE_SIZE, M_WAITOK | M_ZERO);
nmi_stack = (char *)kmem_malloc_domainset(
-   DOMAINSET_FIXED(domain), PAGE_SIZE, M_WAITOK | M_ZERO);
+   DOMAINSET_PREF(domain), PAGE_SIZE, M_WAITOK | M_ZERO);
dbg_stack = (char *)kmem_malloc_domainset(
-   DOMAINSET_FIXED(domain), PAGE_SIZE, M_WAITOK | M_ZERO);
-   dpcpu = (void *)kmem_malloc_domainset(DOMAINSET_FIXED(domain),
+   DOMAINSET_PREF(domain), PAGE_SIZE, M_WAITOK | M_ZERO);
+   dpcpu = (void *)kmem_malloc_domainset(DOMAINSET_PREF(domain),
DPCPU_SIZE, M_WAITOK | M_ZERO);
 
bootSTK = (char *)bootstacks[cpu] +
___
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: Kernel-Crash when working with ubt0

[Konstantin Belousov]

On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote:
> 
> 
> > On Aug 26, 2019, at 9:14 AM, Warner Losh  wrote:
> > 
> > Is it from read_connection_list? If so I have a 'patch' that I'm using but
> > haven't committed because it's just too gross: drop the lock before the
> > copyout and pick it up again after...
> > 
> 
> Hmm... interesting 
> 
> I only took a brief look at it. I suppose I can ensure user space address is 
> wired and then copyout() can be called with mutex held

No, you cannot do this, at least without making the kernel to panic.
User might unmap the wired mapping at any time still.

> 
> It’s odd that I’ve never seen this before. I’m traveling at the moment will 
> take a closer look this later this week
> 
> Thanks
> Max
> ___
> 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-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Kernel-Crash when working with ubt0

[Konstantin Belousov]

On Tue, Aug 27, 2019 at 06:03:46AM -0700, Maksim Yevmenkin wrote:
> > > Hmm... interesting
> > >
> > > I only took a brief look at it. I suppose I can ensure user space address 
> > > is wired and then copyout() can be called with mutex held
> >
> > >No, you cannot do this, at least without making the kernel to panic.
> > User might unmap the wired mapping at any time still.
> 
> Kostik,
> 
> i was thinking along the lines of vslock/vsunlock and copyout_nofault.
> basically similar to the sysctl code. do you think this would not
> work?

This would probably work, but at least causes fragmentation of userspace
vm_map entries.  If it is supposed to be used on high-frequency data path,
then it would cause significant blow up of the VM structures used to keep
user data map.
___
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: Host machines reboots when running bhyve VM

[Konstantin Belousov]

On Wed, Aug 28, 2019 at 01:29:24PM -0600, Rebecca Cran wrote:
> I recently upgraded to r351575 and now when I run a Bhyve VM, the host
> machine instantly reboots. The command-line I'm running is:
> 
> 
> bhyve -c 2 -m 8G -w -H -s 0,hostbridge -s
> 4,virtio-blk,/home/bcran/cube/opensuse-jenkins-node.img -s
> 15,virtio-net,tap0 -s 28,virtio-rnd -s
> 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768 -s 31,lpc -l com1,stdio -l
> bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd vm0
> 
> And the system (I've tried both GENERIC-NODEBUG and GENERIC) is:
> 
> 
> FreeBSD 13.0-CURRENT r351575 GENERIC-NODEBUG amd64

Try https://reviews.freebsd.org/D21418
___
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: ntpd segfaults on start

[Konstantin Belousov]

On Thu, Sep 05, 2019 at 06:07:22AM -0700, Cy Schubert wrote:
> In message <20190905063354.qxecqjkafikdtdyq@vzakharov>, Vladimir Zakharov 
> write
> s:
> > 
> > --ply3axd74k44nuk3
> > Content-Type: text/plain; charset=utf-8
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Sep 05, 2019, Vladimir Zakharov wrote:
> > > Hello!
> > >=20
> > > Accidentally it turned out that the ntpd does not start on boot.
> > > Logs show that it core dumps:
> > > 2019-09-05T08:38:43.588563+03:00 vzakharov ntpd 34934 - - ntpd 4.2.8p12-a=
> >  (1): Starting
> > > 2019-09-05T08:38:43.588717+03:00 vzakharov kernel - - - Security policy l=
> > oaded: MAC/ntpd (mac_ntpd)
> > > 2019-09-05T08:38:43.718356+03:00 vzakharov kernel - - - pid 35074 (ntpd),=
> >  jid 0, uid 123: exited on signal 11
> > >=20
> > > Not sure how long does it happen. ktrace and gdb points to `setrlimit`
> > > call. Clean rebuild has no effect. Does anyone have any idea what the
> > > problem could be?
> >
> > Accidental insight after sending initial mail: I've disabled
> > ASLR related sysctls, and now ntpd starts and runs again.
> > # grep aslr /boot/loader.conf
> > kern.elf32.aslr.enable=3D0
> > kern.elf64.aslr.enable=3D0
> > # service ntpd status
> > ntpd is running as pid 30528.
> 
> I'll take a look at this. When you get a chance can you open a PR for this 
> and assign the ticket to me, please.

See the thread 'ntpd doesn't like ASLR on stable/12 post-r350672' on stable.
Read it to the end.
___
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: ntpd segfaults on start

[Konstantin Belousov]

On Sat, Sep 07, 2019 at 12:53:19AM -0700, Harlan Stenn wrote:
> Cy,
> 
> On 9/6/2019 4:56 PM, Cy Schubert wrote:
> > ...
> > 
> > For those who enable ASLR, a better workaround is, to add this to your 
> > ntp.conf:
> > 
> > rlimit memlock 64
> > 
> > Until a more precise default is determined.
> 
> Should I change the default value for FreeBSD-12 to be 64 for now?
> 
> I can get this change in place for the upcoming ntp-4.2.8p14 release,
> and we can change it later if needed.

ASLR is disabled by default, so if anybody tweak a system config, she
should know better to tweak ntpd as well.  I am fine with changing the
defaults for ntpd, but I think that more useful would be to update
the documentation (but where to put it ?).
___
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: VOP_UNSET_TEXT returned 22: on r351627

[Konstantin Belousov]

On Sat, Sep 07, 2019 at 08:49:10AM -0500, Larry Rosenman wrote:
> I got the following panic this AM during a poudriere run.
> 
> r351627 is the revision I'm at.
> 
> Core *IS* available.
> 
> Ideas?
It highly suspect that is should be fixed by
https://reviews.freebsd.org/D21560.
Slightly amused that your report comes a day after the Andrew' one.

> 
> 
> 
> Unread portion of the kernel message buffer:
> VNASSERT failed
> 0xf809e6335960: tag tmpfs, type VREG
>  usecount 1, writecount 0, refcount 2
>  flags (VI_ACTIVE)
>  v_object 0xf81f37227000 ref 2 pages 1063 cleanbuf 0 dirtybuf 0
>  lock type tmpfs: SHARED (count 1)
> tag VT_TMPFS, tmpfs_node 0xf803214f83a0, flags 0x0, links 1
>   mode 0755, owner 65534, group 0, size 4352808, status 0x0
> 
> panic: VOP_UNSET_TEXT returned 22
> cpuid = 22
> time = 1567862254
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> 0xfe01bfd618b0
> vpanic() at vpanic+0x19d/frame 0xfe01bfd61900
> panic() at panic+0x43/frame 0xfe01bfd61960
> vm_map_entry_set_vnode_text() at vm_map_entry_set_vnode_text+0x275/frame 
> 0xfe01bfd619b0
> vm_map_process_deferred() at vm_map_process_deferred+0x70/frame 
> 0xfe01bfd619d0
> vm_map_remove() at vm_map_remove+0xc6/frame 0xfe01bfd61a00
> vmspace_exit() at vmspace_exit+0xd8/frame 0xfe01bfd61a40
> exit1() at exit1+0x57d/frame 0xfe01bfd61ab0
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe01bfd61ac0
> amd64_syscall() at amd64_syscall+0x29f/frame 0xfe01bfd61bf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 
> 0xfe01bfd61bf0
> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8008326aa, rsp = 
> 0x7fffe1b8, rbp = 0x7fffe1d0 ---
> Uptime: 7d15h33m31s
> Dumping 23246 out of 131027 
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> 
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
> pcpu,
> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
> #2  0x804bcf60 in kern_reboot (howto=260)
>  at /usr/src/sys/kern/kern_shutdown.c:479
> #3  0x804bd3d9 in vpanic (fmt=, ap= out>)
>  at /usr/src/sys/kern/kern_shutdown.c:905
> #4  0x804bd113 in panic (fmt=)
>  at /usr/src/sys/kern/kern_shutdown.c:832
> #5  0x807644e5 in vm_map_entry_set_vnode_text (entry= out>,
>  add=) at /usr/src/sys/vm/vm_map.c:557
> #6  0x807645a0 in vm_map_process_deferred ()
>  at /usr/src/sys/vm/vm_map.c:593
> #7  0x8076a1b6 in _vm_map_unlock (map=,
>  file=, line=3653) at /usr/src/sys/vm/vm_map.c:607
> #8  vm_map_remove (map=, start=4096, end=140737488355328)
>  at /usr/src/sys/vm/vm_map.c:3653
> #9  0x80764118 in vmspace_dofree (vm=)
>  at /usr/src/sys/vm/vm_map.c:335
> #10 vmspace_exit (td=0xf8016632c000) at /usr/src/sys/vm/vm_map.c:416
> #11 0x8047d27d in exit1 (td=0xf8016632c000, rval= out>,
>  signo=0) at /usr/src/sys/kern/kern_exit.c:416
> #12 0x8047ccfd in sys_sys_exit (td=, uap= out>)
>  at /usr/src/sys/kern/kern_exit.c:195
> #13 0x807f13df in syscallenter (td=0xf8016632c000)
>  at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
> #14 amd64_syscall (td=0xf8016632c000, traced=0)
>  at /usr/src/sys/amd64/amd64/trap.c:1180
> #15 
> #16 0x0008008326aa in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffe1b8
> (kgdb)
> 
> -- 
> Larry Rosenman http://people.freebsd.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 


___
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: ntpd segfaults on start

[Konstantin Belousov]

On Sat, Sep 07, 2019 at 06:09:16AM -0700, Cy Schubert wrote:
> In message <20190907075619.gg2...@kib.kiev.ua>, Konstantin Belousov writes:
> > On Sat, Sep 07, 2019 at 12:53:19AM -0700, Harlan Stenn wrote:
> > > Cy,
> > > 
> > > On 9/6/2019 4:56 PM, Cy Schubert wrote:
> > > > ...
> > > > 
> > > > For those who enable ASLR, a better workaround is, to add this to your 
> > > > ntp.conf:
> > > > 
> > > > rlimit memlock 64
> > > > 
> > > > Until a more precise default is determined.
> > > 
> > > Should I change the default value for FreeBSD-12 to be 64 for now?
> > > 
> > > I can get this change in place for the upcoming ntp-4.2.8p14 release,
> > > and we can change it later if needed.
> >
> > ASLR is disabled by default, so if anybody tweak a system config, she
> > should know better to tweak ntpd as well.  I am fine with changing the
> > defaults for ntpd, but I think that more useful would be to update
> > the documentation (but where to put it ?).
> 
> I agree. We should update the documentation for now. 64 MB was my first 
> successful test but I suspect we can get it lower, like 47 MB. For now we 
> can update the documentation to say that if a person enables ASLR they must 
> add this to ntp.conf. I'll find the best number instead of the current 
> sledgehammer.
> 
> Where to put it? I've added it to the ASLR wiki (https://wiki.freebsd.org/AS
> LR) for now. An ASLR page should go into the handbook documenting how to 
> use up ASLR and gotchas like this and mitigations.
May be in security(7).

There are actually two workarounds, with enabled ASLR.  One is the rlimit,
another one is to disable stack base randomization by gap.

> 
> 64 MB is safe for now. I will do more testing. I think it can go below 47. 
> My sandbox has been running ntpd all night with 47 so far. I will try lower.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
> 
>   The need of the many outweighs the greed of the few.
> 
___
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: ntpd segfaults on start

[Konstantin Belousov]

On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> I've been able to set the memlock rlimit as low as 20 MB. The issue is 
> letting it default to 0 which allows ntp to mlockall() anything it wants. 
> ntpd on my sandbox is currently using 18 MB.

Default stack size on amd64 is 512M, and default stack gap percentage is
3%. This means that the gap can be as large as ~17MB. If 3MB is enough
for the stack of the main thread of ntpd, then fine.
___
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: ntpd segfaults on start

[Konstantin Belousov]

On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote:
> On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin
> > > > Belousov writes:
> > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > > > > I've been able to set the memlock rlimit as low as 20 MB. The
> > > > > > issue is 
> > > > > > letting it default to 0 which allows ntp to mlockall()
> > > > > > anything it wants. 
> > > > > > ntpd on my sandbox is currently using 18 MB.
> > > > > 
> > > > > Default stack size on amd64 is 512M, and default stack gap
> > > > > percentage is
> > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is
> > > > > enough
> > > > > for the stack of the main thread of ntpd, then fine.
> > > > 
> > > > The default stack is 200K, which is also tuneable in ntp.conf.
> > > > 
> > > > [...]
> > > 
> > > I haven't seen anyone ask what I consider to be the crucial
> > > question
> > > yet:  why are we locking ntpd into memory by default at all?
> > > 
> > > I have seen two rationales for ntpd using mlockall() and
> > > setrlimit(): 
> > > 
> > >- There are claims that it improves timing performance.
> > > 
> > >- Because ntpd is a daemon that can run for months at a time,
> > >setting limits on memory and stack growth can help detect and
> > >mitigate against memory leak problems in the daemon.
> > 
> > Doesn't locking this memory down also protect ntpd from OOM kills?
> > If so that is a MUST preserve functionality, as IMHO killing ntpd
> > on a box that has it configured is a total no win situation.
> > 
> 
> Does it have that effect?  I don't know.  But I would argue that that's
> a separate issue, and we should make that happen by adding
> ntpd_oomprotect=YES to /etc/defaults/rc.conf
Wiring process memory has no effect on OOM selection. More, because
all potentially allocated pages are allocated for real after mlockall(),
the size of the vmspace, as accounted by OOM, is the largest possible
size from the whole lifetime.

On the other hand, the code execution times are not predictable if the
process's pages can be paged out. Under severe load next instruction
might take several seconds or even minutes to start. It is quite unlike
the scheduler delays. That introduces a jitter in the local time
measurements and their usage as done in userspace. Wouldn't this affect
the accuracy ?

> 
> Right now only syslogd has oomprotect set to YES by default.  Maybe
> that's a good choice -- once we start declaring one daemon to be more
> important than others, you'll discover there's a whole back lot full of
> bikesheds that need painting.
> 
> So maybe we should just document ntpd_oomprotect=YES in some more-
> prominent way.  If we were to add a comment block to ntp.conf
> describing rlimit, that might be a good place to mention setting
> ntpd_oomprotect in rc.conf.
> 
> -- Ian
> 
___
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: TSC-low clock slow on WhiskeyLake i7-8565U (HP Spectre x360 13-ap0043dx)

[Konstantin Belousov]

On Mon, Sep 09, 2019 at 04:07:39PM -0400, Neel Chauhan wrote:
> Hi,
> 
> I recently got a HP Spectre x360 13-ap0043dx as a gift and by default 
> the clock runs slower on FreeBSD than Windows or Linux. Yes, I know the 
> ThinkPad is the best laptop for FreeBSD, but getting an X1 Carbon would 
> increase the price of the gift even more which couldn't be done.
> 
> The kern.timecounter.hardware by default is set to TSC-low and the clock 
> is slow on the Spectre x360. Setting it to ACPI-slow resolves this 
> issue.
> 
> The CPU is a Intel WhiskeyLake Core i7-8565U.
> 
> Is the slow TSC-low an issue with WhiskeyLake in general or specifically 
> HP? Is it something else?
> 
> I am considering writing a patch but before I write one, do other people 
> with WhiskeyLake laptops (or newer) have slow clocks (where one second 
> on the system is actually more in real life), or not.

Start with providing full listing dmesg for verbose boot.

Out of blue, try to set
machdep.disable_tsc_calibration=1
in loader.conf and see if this improves things.
___
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: ntpd segfaults on start

[Konstantin Belousov]

On Mon, Sep 09, 2019 at 03:42:43PM -0600, Warner Losh wrote:
> On Mon, Sep 9, 2019 at 3:12 PM Ian Lepore  wrote:
> 
> > On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote:
> > > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote:
> > > > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > > > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin
> > > > > > > Belousov writes:
> > > > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert
> > > > > > > > wrote:
> > > > > > > > > [...]
> > > > >
> > > > > Doesn't locking this memory down also protect ntpd from OOM kills?
> > > > > If so that is a MUST preserve functionality, as IMHO killing ntpd
> > > > > on a box that has it configured is a total no win situation.
> > > > >
> > > >
> > > > Does it have that effect?  I don't know.  But I would argue that that's
> > > > a separate issue, and we should make that happen by adding
> > > > ntpd_oomprotect=YES to /etc/defaults/rc.conf
> > >
> > > Wiring process memory has no effect on OOM selection. More, because
> > > all potentially allocated pages are allocated for real after mlockall(),
> > > the size of the vmspace, as accounted by OOM, is the largest possible
> > > size from the whole lifetime.
> > >
> > > On the other hand, the code execution times are not predictable if the
> > > process's pages can be paged out. Under severe load next instruction
> > > might take several seconds or even minutes to start. It is quite unlike
> > > the scheduler delays. That introduces a jitter in the local time
> > > measurements and their usage as done in userspace. Wouldn't this affect
> > > the accuracy ?
> > >
> >
> > IMO, there is a large gap between "in theory, paging could cause
> > indeterminate delays in code execution" and "time will be inaccurate on
> > your system".  If there were a delay in a part of the code where it
> > matters that amounted to "seconds or even minutes", what you'd end up
> > with is a measurement that would be discarded by the median filter as
> > an outlier.  There would be some danger that if that kind of delay
> > happened for too many polling cycles in a row, you'd end up with no
> > usable measurements after a while and clock accuracy would suffer.
> > Sub-second delays would be more worriesome because they might not be
> > rejected as outliers.
> >
> > There are only a couple code paths in freebsd ntpd processing where a
> > paging (or scheduling) delay could cause measurement inaccuracy:
> >
> >  - When stepping the clock, the code that runs between calling
> > clock_gettime() and calling clock_settime() to apply the step
> > adjustment to the clock.
> >
> >  - When beginning an exchange with or replying to a peer, the code that
> > runs between obtaining system time for the outgoing Transmit Timestamp
> > and actually transmitting that packet.
> >
> > Stepping the clock typically only happens once at startup.  The ntpd
> > code itself recognizes that this is a time-critical path (it has
> > comments to that effect) but unfortunately the code that runs is
> > scattered among several different .c files so it's hard to say what the
> > likelyhood is that code in the critical section will all be in the same
> > page (or be already-resident because other startup-time code faulted in
> > those pages).  IMO, the right fix for this would be a kernel interface
> > that let you apply a step-delta to the clock with a single syscall
> > (perhaps as an extension to the existing ntp_adjtime() using a new mode
> > flag).
> >
> > On freebsd, the Receive timestamps are captured in the kernel and
> > delivered along with the packet to userland, and are retrieved by the
> > ntpd code from the SCM_BINTIME control message in the packet, so there
> > is no latency problem in the receive path.  There isn't a corresponding
> > kernel mechanism for setting the outgoing timestamps, so whether it's
> > originating a request to a peer or replying to a request from a peer,
> > the transmit timestamp could be wrong due to:
> >
> >  - paging delays
> >  - scheduler delays
> >  - network stack, outgoing queues, and driver delays
> >
> >

Re: spurious out of swap kills

[Konstantin Belousov]

On Thu, Sep 12, 2019 at 05:42:00PM -0700, Don Lewis wrote:
> On 12 Sep, Mark Johnston wrote:
> > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote:
> >> My poudriere machine is running 13.0-CURRENT and gets updated to the
> >> latest version of -CURRENT periodically.  At least in the last week or
> >> so, I've been seeing occasional port build failures when building my
> >> default set of ports, and I finally had some time to do some
> >> investigation.
> >> 
> >> It's a 16-thread Ryzen machine, with 64 GB of RAM and 40 GB of swap.
> >> Poudriere is configured with
> >>   USE_TMPFS="wrkdir data localbase"
> >> and I have
> >>   .if ${.CURDIR:M*/www/chromium}
> >>   MAKE_JOBS_NUMBER=16
> >>   .else
> >>   MAKE_JOBS_NUMBER=7
> >>   .endif
> >> in /usr/local/etc/poudriere.d/make.conf, since this gives me the best
> >> overall build time for my set of ports.  This hits memory pretty hard,
> >> especially when chromium, firefox, libreoffice, and both versions of
> >> openoffice are all building at the same time.  During this time, the
> >> amount of space consumed by tmpfs for /wrkdir gets large when building
> >> these large ports.  There is not enough RAM to hold it all, so some of
> >> the older data spills over to swap.  Swap usage peaks at about 10 GB,
> >> leaving about 30 GB of free swap.  Nevertheless, I see these errors,
> >> with rustc being the usual victim:
> >> 
> >> Sep 11 23:21:43 zipper kernel: pid 16581 (rustc), jid 43, uid 65534, was 
> >> killed: out of swap space
> >> Sep 12 02:48:23 zipper kernel: pid 1209 (rustc), jid 62, uid 65534, was 
> >> killed: out of swap space
> >> 
> >> Top shows the size of rustc being about 2 GB, so I doubt that it
> >> suddenly needs an additional 30 GB of swap.
> >> 
> >> I'm wondering if there might be a transient kmem shortage that is
> >> causing a malloc(..., M_NOWAIT) failure in the swap allocation path
> >> that is the cause of the problem.
> > 
> > Perhaps this is a consequence of r351114?  To confirm this, you might
> > try increasing the value of vm.pfault_oom_wait to a larger value, like
> > 20 or 30, and see if the OOM kills still occur.
> 
> I wonder if increasing vm.pfault_oom_attempts might also be a good idea.
If you are sure that you cannot exhaust your swap space, set
attempts to -1 to disable this mechanism.

Basically, page fault handler waits for vm.pfault_oom_wait *
vm.pfault_oom_attempts for a page allocation before killing the process.
Default is 30 secs, and if you cannot get a page for 30 secs, there is
something very wrong with the machine.
___
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: spurious out of swap kills

[Konstantin Belousov]

On Sat, Sep 14, 2019 at 06:17:25PM -0700, Don Lewis wrote:
> On 13 Sep, Konstantin Belousov wrote:
> > On Thu, Sep 12, 2019 at 05:42:00PM -0700, Don Lewis wrote:
> >> On 12 Sep, Mark Johnston wrote:
> >> > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote:
> >> >> My poudriere machine is running 13.0-CURRENT and gets updated to the
> >> >> latest version of -CURRENT periodically.  At least in the last week or
> >> >> so, I've been seeing occasional port build failures when building my
> >> >> default set of ports, and I finally had some time to do some
> >> >> investigation.
> >> >> 
> >> >> It's a 16-thread Ryzen machine, with 64 GB of RAM and 40 GB of swap.
> >> >> Poudriere is configured with
> >> >>   USE_TMPFS="wrkdir data localbase"
> >> >> and I have
> >> >>   .if ${.CURDIR:M*/www/chromium}
> >> >>   MAKE_JOBS_NUMBER=16
> >> >>   .else
> >> >>   MAKE_JOBS_NUMBER=7
> >> >>   .endif
> >> >> in /usr/local/etc/poudriere.d/make.conf, since this gives me the best
> >> >> overall build time for my set of ports.  This hits memory pretty hard,
> >> >> especially when chromium, firefox, libreoffice, and both versions of
> >> >> openoffice are all building at the same time.  During this time, the
> >> >> amount of space consumed by tmpfs for /wrkdir gets large when building
> >> >> these large ports.  There is not enough RAM to hold it all, so some of
> >> >> the older data spills over to swap.  Swap usage peaks at about 10 GB,
> >> >> leaving about 30 GB of free swap.  Nevertheless, I see these errors,
> >> >> with rustc being the usual victim:
> >> >> 
> >> >> Sep 11 23:21:43 zipper kernel: pid 16581 (rustc), jid 43, uid 65534, 
> >> >> was killed: out of swap space
> >> >> Sep 12 02:48:23 zipper kernel: pid 1209 (rustc), jid 62, uid 65534, was 
> >> >> killed: out of swap space
> >> >> 
> >> >> Top shows the size of rustc being about 2 GB, so I doubt that it
> >> >> suddenly needs an additional 30 GB of swap.
> >> >> 
> >> >> I'm wondering if there might be a transient kmem shortage that is
> >> >> causing a malloc(..., M_NOWAIT) failure in the swap allocation path
> >> >> that is the cause of the problem.
> >> > 
> >> > Perhaps this is a consequence of r351114?  To confirm this, you might
> >> > try increasing the value of vm.pfault_oom_wait to a larger value, like
> >> > 20 or 30, and see if the OOM kills still occur.
> >> 
> >> I wonder if increasing vm.pfault_oom_attempts might also be a good idea.
> > If you are sure that you cannot exhaust your swap space, set
> > attempts to -1 to disable this mechanism.
> 
> I had success just by increasing vm.pfault_oom_attempts from 3 to 10.
I do not mind changing this, but could you do an experiment, please ?
Set vm.pfault_oom_attempts to 1, and vm.pfault_oom_wait to 100. In other
words, the multiplication of attempts by wait should be the same, but
only one wait done. I am curious if it is enough for your config, i.e.
it is indeed the pageout speed issue, vs. vm_page_alloc() at fault time
does several speedups of pagedaemon during allocation attempts.

> 
> > Basically, page fault handler waits for vm.pfault_oom_wait *
> > vm.pfault_oom_attempts for a page allocation before killing the process.
> > Default is 30 secs, and if you cannot get a page for 30 secs, there is
> > something very wrong with the machine.
> 
> There is nothing really wrong with the machine.  The load is just high.
> Probably pretty bad for interactivity, but throughput is just fine, with
> CPU %idle pretty much pegged at zero the whole time.
> 
> I kept an eye on the machine for a while during a run with the new
> tuning.  Most of the time, free memory bounced between 2 and 4 GB, with
> little page out activity.  There were about 60 running processes, most
> of which were writing to 16 tmpfs filesystems.  Sometimes free memory
> dropped into the 1 to 2 GB range and pageouts spiked.  This condition
> could persist for 30 seconds or more, which is probably the reason for
> the OOM kills with the default tuning.  I sometimes saw free memory drop
> below 1 GB.  The lowest I aaw was 470 MB.  I'm guessing that this code
> fails page allocation when free memmory is below some threshold to avoid
> potential deadlocks.
This should be vm.v_free_reser

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

[Konstantin Belousov]

On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote:
> I'm consistently seeing panics in the NFS code on recent -current on aarm64.
> The panics are one of the following two:
> Sleeping on "vmopar" with the following non-sleepable locks held:
> exclusive sleep mutex NEWNFSnode lock (NEWNFSnode lock) r = 0 
> (0xfd0078b346f0) locked @ /usr/src/sys/fs/nfsclient/nfs_clport.c:432
> 
> Sleeping thread (tid 100077, pid 35) owns a non-sleepable lock
> 
> Both panics have nearly identical backtraces (see below).  I'm running
> diskless on a Rock64 with both filesystem and swap over NFS.  The panics
> can be fairly reliably triggered by any of:
> * "make -j4 buildworld"
> * linking the kernel (as part of buildkernel)
> * "make installworld"
> 
> Has anyone else seen this?
> 
> The first panic (sleeping on vmopar) has a backtrace:
> sched_switch() at mi_switch+0x19c
>  pc = 0x002ab368  lr = 0x0028a9f4
>  sp = 0x61192660  fp = 0x61192680
> 
> mi_switch() at sleepq_switch+0x100
>  pc = 0x0028a9f4  lr = 0x002d56dc
>  sp = 0x61192690  fp = 0x611926d0
> 
> sleepq_switch() at sleepq_wait+0x48
>  pc = 0x002d56dc  lr = 0x002d5594
>  sp = 0x611926e0  fp = 0x61192700
> 
> sleepq_wait() at _sleep+0x2c4  [***]
>  pc = 0x002d5594  lr = 0x00289eec
>  sp = 0x61192710  fp = 0x611927b0
> 
> _sleep() at vm_object_page_remove+0x178  [***]
>  pc = 0x00289eec  lr = 0x0052211c
>  sp = 0x611927c0  fp = 0x61192820
> 
> vm_object_page_remove() at vnode_pager_setsize+0xc0
>  pc = 0x0052211c  lr = 0x00539a70
>  sp = 0x61192830  fp = 0x61192870
> 
> vnode_pager_setsize() at nfscl_loadattrcache+0x2e8
>  pc = 0x00539a70  lr = 0x001ed4b4
>  sp = 0x61192880  fp = 0x611928e0
> 
> nfscl_loadattrcache() at ncl_writerpc+0x104
>  pc = 0x001ed4b4  lr = 0x001e2158
>  sp = 0x611928f0  fp = 0x61192a40
> 
> ncl_writerpc() at ncl_doio+0x36c
>  pc = 0x001e2158  lr = 0x001f0370
>  sp = 0x61192a50  fp = 0x61192ae0
> 
> ncl_doio() at nfssvc_iod+0x228
>  pc = 0x001f0370  lr = 0x001f1d88
>  sp = 0x61192af0  fp = 0x61192b50
> 
> nfssvc_iod() at fork_exit+0x7c
>  pc = 0x001f1d88  lr = 0x0023ff5c
>  sp = 0x61192b60  fp = 0x61192b90
> 
> fork_exit() at fork_trampoline+0x10
>  pc = 0x0023ff5c  lr = 0x00562c34
>  sp = 0x61192ba0  fp = 0x
> 
> 
> For the second panic, the [***] change to:
> sleepq_wait() at vm_page_sleep_if_busy+0x80
> vm_page_sleep_if_busy() at vm_object_page_remove+0xfc

Weird since this should have been fixed long time ago.  Anyway, please
try the following, it should fix the rest of cases.

diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
index 471e029a8b5..098de1ced80 100644
--- a/sys/fs/nfsclient/nfs_clport.c
+++ b/sys/fs/nfsclient/nfs_clport.c
@@ -511,10 +511,10 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
 * zero np->n_attrstamp to indicate that
 * the attributes are stale.
 */
-   vap->va_size = np->n_size;
+   nsize = vap->va_size = np->n_size;
+   setnsize = 1;
np->n_attrstamp = 0;
KDTRACE_NFS_ATTRCACHE_FLUSH_DONE(vp);
-   vnode_pager_setsize(vp, np->n_size);
} else if (np->n_flag & NMODIFIED) {
/*
 * We've modified the file: Use the larger
@@ -526,7 +526,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
}
-   vnode_pager_setsize(vp, np->n_size);
+   nsize = np->n_size;
+   setnsize = 1;
} else if (vap->va_size < np->n_size) {
/*
 * When shrinking the size, the call to
@@ -540,7 +541,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
} else {
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
-   vnode_pager_setsize(vp, np->n_size);