Re: sbin/mount: failed to mount NFS root

2023-01-31 Thread qroxana
--- Original Message ---
On Monday, January 30th, 2023 at 3:08 PM, Rick Macklem  
wrote:

> I think this was fixed by a commit yesterday.
> 
> rick
>

Thanks Rick. Yes, it has been fixed.

commit ad055467bec35885dc3eff2f4dd765f5b2f53259
Author: Kirk McKusick 
AuthorDate: Sun Jan 29 15:12:48 2023 -0800
Commit: Kirk McKusick 
CommitDate: Sun Jan 29 15:14:43 2023 -0800

Fix for getmntpoint(3) when checking for NFS mount points.

Only attempt to add /dev/ to f_mntfromname names that result in a
valid character device.

MFC after:1 week
Reported by:  Bjoern A. Zeeb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37907




Re: buildworld failed after deleting /usr/obj

2023-01-31 Thread qroxana
- Original Message ---
On Sunday, January 29th, 2023 at 3:06 PM, qroxana  
wrote:


> It appears buildworld doesn't create the obj directory for 
> usr.bin/clang/llvm-objcopy in stage 2.2 after this commit.
> 
> commit adc3c128c6603054586a993d117e5dd808deac17
> Author: John Baldwin j...@freebsd.org
> 
> AuthorDate: Fri Nov 18 20:12:28 2022 -0800
> Commit: John Baldwin j...@freebsd.org
> 
> CommitDate: Fri Nov 18 20:12:28 2022 -0800
> 
> src.opts.mk: Require C++20 for C++ support.
> 
> libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
> does not support C++20.
> 
> Reviewed by: emaste
> Differential Revision: https://reviews.freebsd.org/D36893
> 
> diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
> index f69208f21556..5089a034350d 100644
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -348,6 +348,11 @@ __DEFAULT_YES_OPTIONS+=OPENMP
> __DEFAULT_NO_OPTIONS+=OPENMP
> .endif
> 
> +# libc++ requires C++20
> +.if !${COMPILER_FEATURES:Mc++20}
> +BROKEN_OPTIONS+=CXX
> +.endif
> +
> .include 
> 
> 
> #

Sorry for the noise, this has been fixed by this commit.

commit ac4c695ad61e81d00cff2a03202a4afe94a92513
Author: Ed Maste 
AuthorDate: Wed Nov 16 09:20:39 2022 -0500
Commit: Ed Maste 
CommitDate: Thu Jan 26 21:13:16 2023 -0500

Retire WITHOUT_CXX option

Several important base system components are written in C++, and the
WITHOUT_CXX option produced a system that was not fully functional.
Just accept this, and remove the option to build without C++ support.

This reverts commit adc3c128c6603054586a993d117e5dd808deac17.

Reviewed by:brooks, kevans, jhb (earlier)
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D33108




sbin/mount: failed to mount NFS root

2023-01-30 Thread qroxana
/etc/rc failed to run "mount -uw /" when booting from NFS root,
this happened after the commit 906c312bbf7493ccbcce883936d67e5c66a9c3c2,
the previous commit works fine.

+ mount -uw /
af 1 sotype 1 not supported
+ echo 'Mounting root filesystem rw failed, startup aborted'
Mounting root filesystem rw failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
2023-01-30T10:09:05.116920+00:00 - init 1 - - /bin/sh on /etc/rc terminated 
abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:

commit 906c312bbf7493ccbcce883936d67e5c66a9c3c2
Author: Kirk McKusick 
Date: Sun Jan 15 10:20:48 2023 -0800

Document the mntopts(3) functions.

The mntopts(3) functions support operations associated with a mount
point. The main purpose of this commit is to document the mntopts(3)
functions that now appear in 18 utilities in the base system. See
mntopts(3) for the documentation details.

The getmntopts() function appeared in 4.4BSD. The build_iovec(),
build_iovec_argf(), free_iovec(), checkpath(), and rmslashes()
functions were added with nmount(8) in FreeBSD 5.0. The getmntpoint()
and chkdoreload() functions are being added in this commit.

These functions should be in a library but for historic reasons are
in a file in the sources for the mount(8) program. Thus, to access
them the following lines need to be added to the Makefile of the
program wanting to use them:

SRCS+= getmntopts.c
MOUNT= ${SRCTOP}/sbin/mount
CFLAGS+= -I${MOUNT}
.PATH: ${MOUNT}

Once these changes have been MFC'ed to 13 they may be made into
a library.

Reviewed by: kib, gbe
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37907

Re: buildworld failed after deleting /usr/obj

2023-01-29 Thread qroxana


--- Original Message ---
On Monday, January 23rd, 2023 at 1:44 PM, qroxana  
wrote:


> --- Original Message ---
> On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric d...@freebsd.org 
> wrote:
> 
> 
> 
> > On 23 Jan 2023, at 04:05, qroxana qrox...@protonmail.com wrote:
> > 
> > > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
> > > 
> > > --- all_subdir_usr.bin ---
> > > --- objwarn ---
> > > Warning: Object directory not changed from original 
> > > /usr/src/usr.bin/clang/llvm-objcopy
> > 
> > This is usually an indication that your source directory contains object
> > files, e.g. is "dirty". Run "make clean" from the top level, or clean up
> > your source checkout with something like "git clean".
> > 
> > -Dimitry
> 
> 
> I had tried it with a clean source directory and empty /usr/obj
> 
> # find /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1
> /usr/src/usr.bin/clang/llvm-objcopy/Makefile
> 
> and "make buildworld" still ended with the same error.
> 
> In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=t option prevents 
> creating
> the obj directories for the stuff in usr.bin/clang/.
> 
> 1098 _obj:
> 1099 @echo
> 1100 @echo "--"
> 1101 @echo ">>> stage 2.2: rebuilding the object tree"
> 
> 1102 @echo "--"
> 1103 ${+}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj
> 
> > --- all_subdir_usr.bin ---
> > --- objwarn ---
> > Warning: Object directory not changed from original 
> > /usr/src/usr.bin/clang/llvm-objcopy
> 
> 
> This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created
> for usr.bin/clang/llvm-objcopy
> 

It appears buildworld doesn't create the obj directory for 
usr.bin/clang/llvm-objcopy in stage 2.2 after this commit.

commit adc3c128c6603054586a993d117e5dd808deac17
Author: John Baldwin 
AuthorDate: Fri Nov 18 20:12:28 2022 -0800
Commit: John Baldwin 
CommitDate: Fri Nov 18 20:12:28 2022 -0800

src.opts.mk: Require C++20 for C++ support.

libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
does not support C++20.

Reviewed by:emaste
Differential Revision:  https://reviews.freebsd.org/D36893

diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
index f69208f21556..5089a034350d 100644
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -348,6 +348,11 @@ __DEFAULT_YES_OPTIONS+=OPENMP
 __DEFAULT_NO_OPTIONS+=OPENMP
 .endif
 
+# libc++ requires C++20
+.if !${COMPILER_FEATURES:Mc++20}
+BROKEN_OPTIONS+=CXX
+.endif
+
 .include 
 
 #




Re: buildworld failed after deleting /usr/obj

2023-01-23 Thread qroxana
--- Original Message ---
On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric  
wrote:


> On 23 Jan 2023, at 04:05, qroxana qrox...@protonmail.com wrote:
> 
> > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
> > 
> > --- all_subdir_usr.bin ---
> > --- objwarn ---
> > Warning: Object directory not changed from original 
> > /usr/src/usr.bin/clang/llvm-objcopy
> 
> 
> This is usually an indication that your source directory contains object
> files, e.g. is "dirty". Run "make clean" from the top level, or clean up
> your source checkout with something like "git clean".
> 
> -Dimitry

I had tried it with a clean source directory and empty /usr/obj

# find /usr/src/usr.bin/clang/llvm-objcopy
/usr/src/usr.bin/clang/llvm-objcopy
/usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1
/usr/src/usr.bin/clang/llvm-objcopy/Makefile

and "make buildworld" still ended with the same error.

In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=t option prevents creating
the obj directories for the stuff in usr.bin/clang/.

  1098  _obj:
  1099  @echo
  1100  @echo 
"--"
  1101  @echo ">>> stage 2.2: rebuilding the object tree"
  1102  @echo 
"--"
  1103  ${_+_}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj


> --- all_subdir_usr.bin ---
> --- objwarn ---
> Warning: Object directory not changed from original 
> /usr/src/usr.bin/clang/llvm-objcopy

This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created 
for usr.bin/clang/llvm-objcopy





buildworld failed after deleting /usr/obj

2023-01-22 Thread qroxana
It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.

--- all_subdir_usr.bin ---
--- objwarn ---
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-objcopy
--- COFF/COFFObjcopy.o ---
c++ -target aarch64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common 
-I/usr/src/usr.bin/clang/llvm-objcopy 
-I/usr/src/contrib/llvm-project/llvm/tools/llvm-objcopy 
-I/usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"aarch64-unknown-freebsd14.0\" 
-DLLVM_HOST_TRIPLE=\"aarch64-unknown-freebsd14.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeAArch64AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeAArch64AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeAArch64Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeAArch64Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeAArch64TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeAArch64TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.COFF_COFFObjcopy.o 
-MTCOFF/COFFObjcopy.o -Wno-format-zero-length -fstack-protector-strong 
-Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments -fno-exceptions -fno-rtti -std=c++14 -stdlib=libc++ 
-Wno-c++11-extensions -c 
/usr/src/contrib/llvm-project/llvm/tools/llvm-objcopy/COFF/COFFObjcopy.cpp -o 
COFF/COFFObjcopy.o
--- all_subdir_tests ---
--- objwarn ---
Warning: Object directory not changed from original /usr/src/tests/sys/fs/fusefs
--- bmap ---
(cd /usr/src/tests/sys/fs/fusefs && DEPENDFILE=.depend.bmap NO_SUBDIR=1 make -f 
Makefile _RECURSING_PROGS=t PROG=bmap PROG_CXX=bmap)
--- all_subdir_usr.sbin ---
--- all_subdir_usr.sbin/bsnmpd/modules/snmp_mibII ---
===> usr.sbin/bsnmpd/modules/snmp_mibII (all)
--- all_subdir_usr.bin ---
error: unable to open output file 'COFF/COFFObjcopy.o': 'No such file or 
directory'
1 error generated.
--- all_subdir_tests ---

make[3]: stopped in /usr/src
--- all_subdir_usr.sbin ---

make[3]: stopped in /usr/src
--- all_subdir_usr.bin ---

make[3]: stopped in /usr/src
--- all_subdir_lib ---

make[3]: stopped in /usr/src
329.31 real 244.62 user 54.49 sys

make[2]: stopped in /usr/src

make[1]: stopped in /usr/srcr

Re: Kernel panic on armv7 when PF is enabled

2022-05-03 Thread qroxana


On Monday, May 2nd, 2022 at 9:02 AM, Kristof Provost  wrote:


> On 1 May 2022, at 5:13, qroxana wrote:
>
> > After git bisecting the panic started since this commit.
> >
> > commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113
> >
> > Author: Kristof Provost <
> > k...@freebsd.org
> >
> > Date: Mon Feb 14 20:09:54 2022 +0100
> >
> > vlan: allow net.link.vlan.mtag_pcp to be set per vnet
> >
> > The primary reason for this change is to facilitate testing.
> >
> > MFC after: 1 week
> >
> > sys/net/if_ethersubr.c | 9 +
> >
> > sys/net/if_vlan.c | 5 +++--
> >
> > 2 files changed, 8 insertions(+), 6 deletions(-)
> >
> > The armv7 board boots from a NFS root,
> >
> > it can boot without any problem if PF is disabled.
> >
> > Any helps?
> >
> > add host ::1: gateway lo0 fib 0: route already in table
> > add net fe80::: gateway ::1
> > add net ff02::: gateway ::1
> > add net :::0.0.0.0: gateway ::1
> > add net ::0.0.0.0: gateway ::1
> > Enabling pf.
> > Kernel page fault with the following non-sleepable locks held:
> > shared rm pf rulesets (pf rulesets) r = 0 (0xe3099430) locked @ 
> > /usr/src/sys/netpfil/pf/pf.c:6493
> > exclusive rw tcpinp (tcpinp) r = 0 (0xdb748d88) locked @ 
> > /usr/src/sys/netinet/tcp_usrreq.c:1008
> > stack backtrace:
> > #0 0xc0355cac at witness_debugger+0x7c
> > #1 0xc0356ef0 at witness_warn+0x3fc
> > #2 0xc05ec048 at abort_handler+0x1d8
> > #3 0xc05cb5ac at exception_exit+0
> > #4 0xe3083c10 at pf_syncookie_validate+0x60
> > #5 0xe30496a8 at pf_test+0x518
> > #6 0xe306d768 at pf_check_out+0x30
> > #7 0xc0415b44 at pfil_run_hooks+0xbc
> > #8 0xc0445cfc at ip_output+0xce8
> > #9 0xc045bc9c at tcp_default_output+0x20ac
> > #10 0xc0471eb4 at tcp_usr_send+0x1ac
> > #11 0xc0389464 at sosend_generic+0x490
> > #12 0xc0389790 at sosend+0x64
> > #13 0xc0502888 at clnt_vc_call+0x560
> > #14 0xc05009d8 at clnt_reconnect_call+0x170
> > #15 0xc01e7b14 at newnfs_request+0xb20
> > #16 0xc0230218 at nfscl_request+0x60
> > #17 0xc020d9bc at nfsrpc_getattr+0xb0
> > Fatal kernel mode data abort: 'Alignment Fault' on read
> > trapframe: 0xdf1f1c90
> > FSR=0001, FAR=d7840264, spsr=4013
> > r0 =6a228eda, r1 =dac0d785, r2 =d7840264, r3 =db5527c0
> > r4 =df1f1e00, r5 =dac0d75f, r6 =0018, r7 =d9422c00
> > r8 =c093e5e4, r9 =0001, r10=df1f1f5c, r11=df1f1d38
> > r12=e3098dd0, ssp=df1f1d20, slr=e3083bdc, pc =e3083c10
>
> The commit you point at is entirely unrelated to the code where the panic 
> occurred, so I’m pretty sure something went wrong in your bisect.
>
> The backtrace would suggest the issue occurs in the pf_syncookie_validate() 
> function, and likely in the line `if 
> (atomic_load_64(_pf_status.syncookies_inflight[cookie.flags.oddeven]) == 0)`
>
> The obvious way for that to panic would be to call it without the curvnet 
> context set, but pf_test() uses it earlier, so that’s going to be fine.
>
> Given that this is unique to armv7 I’d recommend talking to the armv7 
> maintainer about 64 bit atomic operations.
>
> You can probably avoid the atomic load with this patch (and not enabling 
> syncookie support):
>
> diff --git a/sys/netpfil/pf/pf_syncookies.c 
> b/sys/netpfil/pf/pf_syncookies.c
> index 5230502be30c..c86d469d3cef 100644
> --- a/sys/netpfil/pf/pf_syncookies.c
> +++ b/sys/netpfil/pf/pf_syncookies.c
> @@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd)
> ack = ntohl(pd->hdr.tcp.th_ack) - 1;
> cookie.cookie = (ack & 0xff) ^ (ack >> 24);
>
> +   if (V_pf_status.syncookies_mode == PF_SYNCOOKIES_NEVER)
> +   return (0);
> +
> /* we don't know oddeven before setting the cookie (union) */
>  if 
> (atomic_load_64(_pf_status.syncookies_inflight[cookie.flags.oddeven])
> == 0)
>
>
> That shouldn’t be required though.
>
> Br,
> Kristof

Thank you sir. You were right.
I tested patch with the latest kernel.
It can boot successfully with the patch,
and still got kernel panic without the patch.







Re: Kernel panic on armv7 when PF is enabled

2022-05-02 Thread qroxana
On Sun, 01 May 2022 03:13:43 +, qroxana  wrote:

> After git bisecting the panic started since this commit.
>
> commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113
> Author: Kristof Provost 
> Date:   Mon Feb 14 20:09:54 2022 +0100
>
> vlan: allow net.link.vlan.mtag_pcp to be set per vnet
>
> The primary reason for this change is to facilitate testing.
>
> MFC after:  1 week
>
> sys/net/if_ethersubr.c | 9 +
> sys/net/if_vlan.c  | 5 +++--
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> The armv7 board boots from a NFS root,
>
> it can boot without any problem if PF is disabled.

It appears this only occurs when the rootfs is NFS,
I also tried to boot it from a micro SD card, no kernel panic.

Another workaround to avoid the panic is to delay
starting /etc/rc.d/pf to SERVERS

--- pf.orig 2022-03-12 12:26:47.0 +
+++ pf  2022-05-02 02:59:28.131026862 +
@@ -4,7 +4,7 @@
 #

 # PROVIDE: pf
-# REQUIRE: FILESYSTEMS netif pflog pfsync routing
+# REQUIRE: SERVERS netif pflog pfsync routing
 # KEYWORD: nojailvnet

 . /etc/rc.subr

Thanks,

Kernel panic on armv7 when PF is enabled

2022-04-30 Thread qroxana
After git bisecting the panic started since this commit.

commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113

Author: Kristof Provost <
k...@freebsd.org
>

Date:   Mon Feb 14 20:09:54 2022 +0100

vlan: allow net.link.vlan.mtag_pcp to be set per vnet

The primary reason for this change is to facilitate testing.

MFC after:  1 week

sys/net/if_ethersubr.c | 9 +

sys/net/if_vlan.c  | 5 +++--

2 files changed, 8 insertions(+), 6 deletions(-)

The armv7 board boots from a NFS root,

it can boot without any problem if PF is disabled.

Any helps?

add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net :::0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Enabling pf.
Kernel page fault with the following non-sleepable locks held:
shared rm pf rulesets (pf rulesets) r = 0 (0xe3099430) locked @ 
/usr/src/sys/netpfil/pf/pf.c:6493
exclusive rw tcpinp (tcpinp) r = 0 (0xdb748d88) locked @ 
/usr/src/sys/netinet/tcp_usrreq.c:1008
stack backtrace:
#0 0xc0355cac at witness_debugger+0x7c
#1 0xc0356ef0 at witness_warn+0x3fc
#2 0xc05ec048 at abort_handler+0x1d8
#3 0xc05cb5ac at exception_exit+0
#4 0xe3083c10 at pf_syncookie_validate+0x60
#5 0xe30496a8 at pf_test+0x518
#6 0xe306d768 at pf_check_out+0x30
#7 0xc0415b44 at pfil_run_hooks+0xbc
#8 0xc0445cfc at ip_output+0xce8
#9 0xc045bc9c at tcp_default_output+0x20ac
#10 0xc0471eb4 at tcp_usr_send+0x1ac
#11 0xc0389464 at sosend_generic+0x490
#12 0xc0389790 at sosend+0x64
#13 0xc0502888 at clnt_vc_call+0x560
#14 0xc05009d8 at clnt_reconnect_call+0x170
#15 0xc01e7b14 at newnfs_request+0xb20
#16 0xc0230218 at nfscl_request+0x60
#17 0xc020d9bc at nfsrpc_getattr+0xb0
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xdf1f1c90
FSR=0001, FAR=d7840264, spsr=4013
r0 =6a228eda, r1 =dac0d785, r2 =d7840264, r3 =db5527c0
r4 =df1f1e00, r5 =dac0d75f, r6 =0018, r7 =d9422c00
r8 =c093e5e4, r9 =0001, r10=df1f1f5c, r11=df1f1d38
r12=e3098dd0, ssp=df1f1d20, slr=e3083bdc, pc =e3083c10

panic: Fatal abort
cpuid = 1
time = 1651366089
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc05c8c00  lr = 0xc007ac8c (db_trace_self_wrapper+0x30)
 sp = 0xdf1f1a68  fp = 0xdf1f1b80
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc007ac8c  lr = 0xc02e289c (vpanic+0x170)
 sp = 0xdf1f1b88  fp = 0xdf1f1ba8
 r4 = 0x0100  r5 = 0x
 r6 = 0xc0780529  r7 = 0xc090ea10
vpanic() at vpanic+0x170
 pc = 0xc02e289c  lr = 0xc02e264c (doadump)
 sp = 0xdf1f1bb0  fp = 0xdf1f1bb4
 r4 = 0xdf1f1c90  r5 = 0x0013
 r6 = 0xd7840264  r7 = 0x0001
 r8 = 0x0001  r9 = 0xdb5527c0
r10 = 0xd7840264
doadump() at doadump
 pc = 0xc02e264c  lr = 0xc05ec698 (abort_align)
 sp = 0xdf1f1bbc  fp = 0xdf1f1be8
 r4 = 0xd7840264  r5 = 0xdf1f1bb4
 r6 = 0xc02e264c r10 = 0xdf1f1bbc
abort_align() at abort_align
 pc = 0xc05ec698  lr = 0xc05ec198 (abort_handler+0x328)
 sp = 0xdf1f1bf0  fp = 0xdf1f1c88
 r4 = 0x0013  r5 = 0xd7840264
abort_handler() at abort_handler+0x328
 pc = 0xc05ec198  lr = 0xc05cb5ac (exception_exit)
 sp = 0xdf1f1c90  fp = 0xdf1f1d38
 r4 = 0xdf1f1e00  r5 = 0xdac0d75f
 r6 = 0x0018  r7 = 0xd9422c00
 r8 = 0xc093e5e4  r9 = 0x0001
r10 = 0xdf1f1f5c
exception_exit() at exception_exit
 pc = 0xc05cb5ac  lr = 0xe3083bdc (pf_syncookie_validate+0x2c)
 sp = 0xdf1f1d20  fp = 0xdf1f1d38
 r0 = 0x6a228eda  r1 = 0xdac0d785
 r2 = 0xd7840264  r3 = 0xdb5527c0
 r4 = 0xdf1f1e00  r5 = 0xdac0d75f
 r6 = 0x0018  r7 = 0xd9422c00
 r8 = 0xc093e5e4  r9 = 0x0001
r10 = 0xdf1f1f5c r12 = 0xe3098dd0
pf_syncookie_validate() at pf_syncookie_validate+0x60
 pc = 0xe3083c10  lr = 0xe30496a8 (pf_test+0x518)
 sp = 0xdf1f1d40  fp = 0xdf1f1ea8
 r4 = 0x0002  r5 = 0xdb4a6100
 r6 = 0x0018  r7 = 0xd9422c00
 r8 = 0x0002  r9 = 0x0001
pf_test() at pf_test+0x518
 pc = 0xe30496a8  lr = 0xe306d768 (pf_check_out+0x30)
 sp = 0xdf1f1eb0  fp = 0xdf1f1ec0
 r4 = 0xdf1f1f5c  r5 = 0xe306d738
 r6 = 0xdb6ba660  r7 = 0x
 r8 = 0xd9422c00  r9 = 0xdb748d80
r10 = 0xfff7
pf_check_out() at pf_check_out+0x30
 pc = 0xe306d768  lr = 0xc0415b44 (pfil_run_hooks+0xbc)
 sp = 0xdf1f1ec8  fp = 0xdf1f1ef0
 r4 = 0x0002  r5 = 0xe306d738
pfil_run_hooks() at pfil_run_hooks+0xbc
 pc = 0xc0415b44  lr = 0xc0445cfc (ip_output+0xce8)
 sp = 0xdf1f1ef8  fp = 0xdf1f1fa8
 r4 = 0x010a  r5 = 0x0a0a
 r6 = 0xdb4a6158  r7 = 0xc0946908
 r8 = 0xdb5bec00  r9 = 0xd9422c00
r10 = 0x05dc
ip_output() at ip_output+0xce8
 pc = 0xc0445cfc  lr = 0xc045bc9c (tcp_default_output+0x20ac)
 sp = 0xdf1f1fb0  

Kernel panic for if_epair

2022-02-16 Thread qroxana
It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @ 
/usr/src/sys/net/if_epair.c:165
stack backtrace:
#0 0xc03558f8 at witness_debugger+0x7c
#1 0xc0356b3c at witness_warn+0x3fc
#2 0xc05eb3c8 at abort_handler+0x1d8
#3 0xc05ca8e0 at exception_exit+0
#4 0xc0475928 at udp_input+0x1c0
#5 0xc0441884 at ip_input+0xa18
#6 0xc041426c at netisr_dispatch_src+0x100
#7 0xc040b9a0 at ether_demux+0x1c8
#8 0xc040d22c at ether_nh_input+0x514
#9 0xc041426c at netisr_dispatch_src+0x100
#10 0xc040be94 at ether_input+0x8c
#11 0xe2fd8130 at $a.8+0x128
#12 0xc02a1ee0 at ithread_loop+0x268
#13 0xc029e088 at fork_exit+0xa0
#14 0xc05ca870 at swi_exit+0
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xe2a0baf0
FSR=0001, FAR=e3f02a56, spsr=2013
r0 =, r1 =0001, r2 =0001, r3 =0a0a
r4 =, r5 =e3f02a6a, r6 =e3f02a56, r7 =0044
r8 =0044, r9 =c0af955c, r10=0014, r11=e2a0bc10
r12=, ssp=e2a0bb80, slr=c0441884, pc =c0475928

panic: Fatal abort
cpuid = 0
time = 1645004889
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc05c7f34  lr = 0xc007ac48 (db_trace_self_wrapper+0x30)
 sp = 0xe2a0b8c8  fp = 0xe2a0b9e0
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc007ac48  lr = 0xc02e259c (vpanic+0x170)
 sp = 0xe2a0b9e8  fp = 0xe2a0ba08
 r4 = 0x0100  r5 = 0x
 r6 = 0xc077f670  r7 = 0xc090d910
vpanic() at vpanic+0x170
 pc = 0xc02e259c  lr = 0xc02e234c (doadump)
 sp = 0xe2a0ba10  fp = 0xe2a0ba14
 r4 = 0xe2a0baf0  r5 = 0x0013
 r6 = 0xe3f02a56  r7 = 0x0001
 r8 = 0x0001  r9 = 0xe294e000
r10 = 0xe3f02a56
doadump() at doadump
 pc = 0xc02e234c  lr = 0xc05eba18 (abort_align)
 sp = 0xe2a0ba1c  fp = 0xe2a0ba48
 r4 = 0xe3f02a56  r5 = 0xe2a0ba14
 r6 = 0xc02e234c r10 = 0xe2a0ba1c
abort_align() at abort_align
 pc = 0xc05eba18  lr = 0xc05eb518 (abort_handler+0x328)
 sp = 0xe2a0ba50  fp = 0xe2a0bae8
 r4 = 0x0013  r5 = 0xe3f02a56
abort_handler() at abort_handler+0x328
 pc = 0xc05eb518  lr = 0xc05ca8e0 (exception_exit)
 sp = 0xe2a0baf0  fp = 0xe2a0bc10
 r4 = 0x  r5 = 0xe3f02a6a
 r6 = 0xe3f02a56  r7 = 0x0044
 r8 = 0x0044  r9 = 0xc0af955c
r10 = 0x0014
exception_exit() at exception_exit
 pc = 0xc05ca8e0  lr = 0xc0441884 (ip_input+0xa18)
 sp = 0xe2a0bb80  fp = 0xe2a0bc10
 r0 = 0x  r1 = 0x0001
 r2 = 0x0001  r3 = 0x0a0a
 r4 = 0x  r5 = 0xe3f02a6a
 r6 = 0xe3f02a56  r7 = 0x0044
 r8 = 0x0044  r9 = 0xc0af955c
r10 = 0x0014 r12 = 0x
udp_input() at udp_input+0x1c0
 pc = 0xc0475928  lr = 0xc0441884 (ip_input+0xa18)
 sp = 0xe2a0bc18  fp = 0xe2a0bc50
 r4 = 0x00022e75  r5 = 0x
 r6 = 0x0014  r7 = 0x00fb
 r8 = 0xc090d910  r9 = 0xc09457fc
r10 = 0xe3f02a56
ip_input() at ip_input+0xa18
 pc = 0xc0441884  lr = 0xc041426c (netisr_dispatch_src+0x100)
 sp = 0xe2a0bc58  fp = 0xe2a0bc80
 r4 = 0x0003a73b  r5 = 0xe3f02a00
 r6 = 0x  r7 = 0xc0b5b4b4
 r8 = 0xe4417ac0  r9 = 0x5e4a6f28
r10 = 0x0008
netisr_dispatch_src() at netisr_dispatch_src+0x100
 pc = 0xc041426c  lr = 0xc040b9a0 (ether_demux+0x1c8)
 sp = 0xe2a0bc88  fp = 0xe2a0bca0
 r4 = 0xe3244400  r5 = 0xe3f02a00
 r6 = 0x0800  r7 = 0xe3244400
 r8 = 0xe4417ac0  r9 = 0x5e4a6f28
r10 = 0x0008
ether_demux() at ether_demux+0x1c8
 pc = 0xc040b9a0  lr = 0xc040d22c (ether_nh_input+0x514)
 sp = 0xe2a0bca8  fp = 0xe2a0bd10
 r4 = 0xe3244400  r5 = 0xe3f02a00
 r6 = 0xe3f02a48  r7 = 0x
ether_nh_input() at ether_nh_input+0x514
 pc = 0xc040d22c  lr = 0xc041426c (netisr_dispatch_src+0x100)
 sp = 0xe2a0bd18  fp = 0xe2a0bd40
 r4 = 0x00050e88  r5 = 0xe3f02a00
 r6 = 0x  r7 = 0xc0b5b534
 r8 = 0x5e4a6f28  r9 = 0x0020
r10 = 0x
netisr_dispatch_src() at netisr_dispatch_src+0x100
 pc = 0xc041426c  lr = 0xc040be94 (ether_input+0x8c)
 sp = 0xe2a0bd48  fp = 0xe2a0bd80
 r4 = 0xe3244400  r5 = 0x
 r6 = 0xe3f02a00  r7 = 0x
 r8 = 0x5e4a6f28  r9 = 0x0020
r10 = 0x
ether_input() at ether_input+0x8c
 pc = 0xc040be94  lr = 0xe2fd8130 ($a.8+0x128)
 sp = 0xe2a0bd88  fp = 0xe2a0bdb8
 r4 = 0xc57f5c8c  r5 = 0x
 r6 = 0xe3244400  r7 = 0xc57f5c80
 r8 = 0xe2fe9170  r9 = 0xc0938328
r10 = 0xe2a0bd88
$a.8() at $a.8+0x128
 pc = 0xe2fd8130  lr = 0xc02a1ee0 (ithread_loop+0x268)
 sp = 

buildworld failed

2022-02-06 Thread qroxana
I know running make install for /usr/src/tools/build/test-includes can fix this,
but this still fails on a newly installed 14.0-CURRENT.

--- test-includes ---
cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64 MACHINE=arm64 
CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target 
aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target 
aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target 
aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target 
aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target 
aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" ELFCTL="elfctl" 
LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" 
STRIPBIN="strip" INSTALL="install -U" 
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
 SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make 
DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes
--- sys/abi_compat.c ---
--- sys/acct.c ---
--- sys/acl.c ---
--- sys/aio.c ---
--- sys/abi_compat.c ---
echo "#include " > sys/abi_compat.c
sh: cannot create sys/abi_compat.c: No such file or directory
*** [sys/abi_compat.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acct.c ---
echo "#include " > sys/acct.c
sh: cannot create sys/acct.c: No such file or directory
*** [sys/acct.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/aio.c ---
echo "#include " > sys/aio.c
sh: cannot create sys/aio.c: No such file or directory
*** [sys/aio.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acl.c ---
echo "#include " > sys/acl.c
sh: cannot create sys/acl.c: No such file or directory
*** [sys/acl.c] Error code 2

Re: jail fib no longer works after net.add_addr_allfibs=0

2021-01-13 Thread qroxana
‐‐‐ Original Message ‐‐‐
On Monday, January 11, 2021 7:37 PM, Alexander V. Chernikov  
wrote:

> 11.01.2021, 14:59, "qroxana" qrox...@protonmail.com:
>
> > On Mon, 11 Jan 2021 13:25:51 +, Alexander V. Chernikov melif...@ipfw.ru 
> > wrote:
> >
> > > Could you please consider clarifying the end result you want to achieve?
> > >  If you could include some more details of how it was configured earlier, 
> > > it would help as well.
> >
> > Thank you for the quick reply.
> > Let's say there are two jails defined in /etc/jail.conf
> > jail1 {
> > ...
> > ip4.addr = 192.168.1.101;
> > exec.fib = 1;
> > ...
> > }
> > jail2 {
> > ...
> > ip4.addr = 192.168.1.102;
> > exec.fib = 2;
> > ...
> > }
>
> Got it, thank you for the clarification.
>
> > All the traffic in jail1 goes to the default router defined in fib 1,
> > and traffic in jail2 goes to the default router defined in fib 2.
>
> Could you describe interface setup as well?
> In particular, I'm looking into details of setting up # of fibs, interface 
> configuration and default route setup.

Sure, the interface is em0 for both host and jails:

/etc/rc.conf
ipv4_addrs_em0="192.168.1.100/24"

static_routes="jail1 jail2"
route_jail1="default 192.168.1.10 -fib 1"
route_jail2="default 192.168.1.20 -fib 2"

/etc/jail.conf
jail1 {
...
interface = em0;
ip4.addr = 192.168.1.101;
exec.fib = 1;
...
}

jail2 {
...
interface = em0;
ip4.addr = 192.168.1.102;
exec.fib = 2;
...
}

I noticed net.add_addr_allfibs defaults to 0 after the
commit 2d39824195933c173bbfc9b31773070202d2e30e
svn path=/head/; revision=367491

I also noted that net.add_addr_allfibs=1 needs to be added into
/etc/sysctl.conf so it can be set before running /etc/rc.d/netif.

# setfib -F 2 route add default 192.168.1.20
route: writing to routing socket: Network is unreachable
add net default: gateway 192.168.1.20 fib 2: Network is unreachable

# sysctl net.add_addr_allfibs=1
net.add_addr_allfibs: 0 -> 1

# setfib -F 2 route add default 192.168.1.20
route: writing to routing socket: Network is unreachable
add net default: gateway 192.168.1.20 fib 2: Network is unreachable

# /etc/rc.d/netif restart
# setfib -F 2 route add default 192.168.1.20
add net default: gateway 192.168.1.20 fib 2

I'm just wondering what's the best practice for using jails
with fib when net.add_addr_allfibs=0?

Thanks.
___
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: jail fib no longer works after net.add_addr_allfibs=0

2021-01-11 Thread qroxana
On Mon, 11 Jan 2021 13:25:51 +, Alexander V. Chernikov  
wrote:

> Could you please consider clarifying the end result you want to achieve?
> If you could include some more details of how it was configured earlier, it 
> would help as well.

Thank you for the quick reply.
Let's say there are two jails defined in /etc/jail.conf

jail1 {
...
ip4.addr = 192.168.1.101;
exec.fib = 1;
...
}

jail2 {
...
ip4.addr = 192.168.1.102;
exec.fib = 2;
...
}

All the traffic in jail1 goes to the default router defined in fib 1,
and traffic in jail2 goes to the default router defined in fib 2.
And I could only see 127.0.0.1 after starting the jails:

# setfib -F 2 netstat -rn
Routing tables (fib: 2)

Internet:
DestinationGatewayFlags Netif Expire
127.0.0.1  link#2 UHS lo0

Internet6:
Destination   Gateway   Flags
Netif Expire
... ...

please let me know if you need more info. Thanks.


___
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"


jail fib no longer works after net.add_addr_allfibs=0

2021-01-11 Thread qroxana


I have exec.fib = 2 in /etc/jail.conf, but it seems the address of
the jail is not inserted into this fib. What's the best practice
for using jail with fib when net.add_addr_allfibs=0?

Thanks.
___
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"


OpenZFS: kldload zfs.ko freezes on i386 4GB memory

2020-10-26 Thread qroxana


Hi,

I have an old i386 machine running r364479. After upgrading to
r367045, running kldload zfs.ko freezes the whole system.

I also tried to replace the 4GB memory with another 2GB one
and kldload zfs.ko works without freezing the machine.

Thanks.
___
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"