Build failure: main-n271230-d909f06b907d -> main-n271238-75e1fea68aaa

[David Wolfskill]

Scanning the build typescript, I find:

...
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/w/uptime.1.gz
ld: error: undefined symbol: libzfs_core_init
>>> referenced by zdb.c:9207 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9207)
>>>   zdb.o:(main)
Building /common/S4/obj/usr/src/amd64.amd64/secure/lib/libcrypto/OSSL_CMP_MSG_ht
tp_perform.3.gz

ld: error: undefined symbol: lzc_get_props
>>> referenced by zdb.c:9216 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9216)
>>>   zdb.o:(main)
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-63x255-512-a
pm.qcow

ld: error: undefined symbol: libzfs_core_fini
>>> referenced by zdb.c:9242 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9242)
>>>   zdb.o:(main)
Building 
/common/S4/obj/usr/src/amd64.amd64/secure/lib/libcrypto/OSSL_CMP_SRV_CTX_new.3.gz
Building 
/common/S4/obj/usr/src/amd64.amd64/secure/lib/libcrypto/OSSL_CMP_STATUSINFO_new.3.gz
...
make[2]: stopped in /usr/src
*** [zdb.full] Error code 1

make[5]: stopped in /usr/src/cddl/usr.sbin/zdb
.ERROR_TARGET='zdb.full'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zdb/zdb.full.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
...

I have attached a copy of the referenced ERROR_META_FILE.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zdb/zdb.full.meta
CMD cc -target x86_64-unknown-freebsd15.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common 
-DIN_BASE -I/usr/src/sys/contrib/openzfs/include 
-I/usr/src/sys/contrib/openzfs/lib/libspl/include 
-I/usr/src/sys/contrib/openzfs/lib/libspl/include/os/freebsd 
-I/usr/src/sys/contrib/openzfs/lib/libspl/include/os/freebsd/spl -I/usr/src/sys 
-include /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h 
-DHAVE_ISSETUGID -g -DDEBUG=1 -DZFS_DEBUG=1 -DNEED_SOLARIS_BOOLEAN 
-DHAVE_STRLCAT -DHAVE_STRLCPY -fPIE -g -gz=zlib -std=iso9899:1999 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wdate-time 
-Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter 
-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 -Qunused-arguments  -Wl,-zrelro -pie-o zdb.full 
zdb.o zdb_il.o   -lnvpair  -lumem  -luutil  -lzdb  -lzfs  -lspl  -lavl  -lzutil 
 -lzpool  -lcrypto 
CWD /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zdb
TARGET zdb.full
OODATE zdb.o zdb_il.o
-- command output --
ld: error: undefined symbol: libzfs_core_init
>>> referenced by zdb.c:9207 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9207)
>>>   zdb.o:(main)

ld: error: undefined symbol: lzc_get_props
>>> referenced by zdb.c:9216 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9216)
>>>   zdb.o:(main)

ld: error: undefined symbol: libzfs_core_fini
>>> referenced by zdb.c:9242 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9242)
>>>   zdb.o:(main)
cc: error: linker command failed with exit code 1 (use -v to see invocation)

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 36883
# Start 1721299743.929216
V 5
E 49085 /bin/sh
R 49085 /etc/libmap.conf
R 49085 /var/run/ld-elf.so.hints
R 49085 /lib/libedit.so.8
R 49085 /lib/libc.so.7
R 49085 /lib/libtinfow.so.9
R 49085 /lib/libsys.so.7
R 49085 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 49085 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 49085 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 49085 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 49085 /usr/share/locale/en_US.UTF-8/LC_TIME
R 49085 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 49085 49144
E 49144 /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/cc
R 49144 /etc/libmap.conf
R 49144 /var/run/ld-elf.so.hints
R 49144 /lib/libz.so.6
R 49144 /usr/lib/libprivatezstd.so.5
R 49144 /usr/lib/libexecinfo.so.1
R 49144 /lib/libncursesw.so.9
R 49144 /lib/libtinfow.so.9
R 49144 /lib/libthr.so.3
R 49144 /lib/libc++.so.1
R 49144 /lib/libcxxrt.so.1
R 49144 /lib/libm.so.5
R 49144 /lib/libc.so.7
R 49144 /lib/libelf.so.2
R 49144 /lib/libgcc_s.so.1
R 49144 /lib/libsys.so.7
F 49144 49202
E 49202 /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/ld
R 49202 /etc/libmap.conf
R 49202 /var/run/ld-elf.so.hints
R 49202 /usr/lib/libexecinfo.so.1
R 49202 /lib/libtinfow.so.9
R 49202 /lib/libz.so.6
R 49202 /usr/lib/libprivatezstd.so.5
R 49202 /lib/libthr.so.3
R 49202 /lib/libc++.so.1
R 49202 /lib/libcxxrt.so.1
R 49202 /lib/libm.so.5
R 49202 /lib/libc.so.7
R 49202 /lib/libelf.so.2
R 49202 /lib/libgcc_s.so.1
R 49202 /lib/libsys.so.7
R 49202 /common/S4/obj/u

Re: Build issue with ncurses?

[David Wolfskill]

On Thu, Jun 27, 2024 at 03:12:47PM +0200, Baptiste Daroussin wrote:
> On Thu 27 Jun 05:29, David Wolfskill wrote:
> > ...
> > But my secondary laptop choked on ncurses while running
> > main-n270474-d2f1f71ec8c6, first after updating sources to
> > main-n270948-8521ea135f5b, then after the update to
> > main-n270979-cde6642431bb.
> ...
> This does not ring any bell to me, and I so nothing obvious here.
> 
> Best regards,
> Bapt

In the "get a bigger hammer" spirit, I moved /usr/obj aside, then
re-started the build.

It's got through "make buildworld" without issue, and is building the
kernel (which is considerably further along than it was when it had
failed, earlier).

Maybe that information will help someone else. 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In a collision, you don't get to choose which aspects of Physics apply.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build issue with ncurses?

[David Wolfskill]

I normally track FreeBSD daily, but was away from home for the first
coule of weeks of June, and am trying to get back into my usual update
cadence.

My (headless) build machine had no trouble updating:

main-n270474-d2f1f71ec8c6 (30 May) -> main-n270948-8521ea135f5b (25 June)
main-n270948-8521ea135f5b -> main-n270979-cde6642431bb (27 June)

But my secondary laptop choked on ncurses while running
main-n270474-d2f1f71ec8c6, first after updating sources to
main-n270948-8521ea135f5b, then after the update to
main-n270979-cde6642431bb.

I'm using meta-mode; I have attached a copy of the full meta file.  Here
is the part that I think is particularly relevant:

# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/new_pair.o.meta
CMD cc -target x86_64-unknown-freebsd15.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-D_XOPEN_SOURCE_EXTENDED -I. -I/usr/src/lib/ncurses/tinfo 
-I/usr/src/lib/ncurses/ncurses -I/usr/src/contrib/ncurses/include 
-I/usr/src/contrib/ncurses/ncurses 
-I/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/tinfo -Wall -DNDEBUG 
-DHAVE_CONFIG_H -g -gz=zlib -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member  -Qunused-arguments 
-c /usr/src/contrib/ncurses/ncurses/base/new_pair.c -o new_pair.o
CMD
CWD /common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses
TARGET new_pair.o
OODATE /usr/src/contrib/ncurses/ncurses/base/new_pair.c
-- command output --
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
In file included from /usr/src/contrib/ncurses/ncurses/curses.priv.h:425:
/usr/src/contrib/ncurses/ncurses/term.priv.h:141:16: error: redefinition of 
'term'
  141 | typedef struct term {   /* describe an actual terminal 
*/
  |^
./term.h:735:16: note: previous definition is here
  735 | typedef struct term {   /* describe an actual terminal */
  |^
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
In file included from /usr/src/contrib/ncurses/ncurses/curses.priv.h:425:
/usr/src/contrib/ncurses/ncurses/term.priv.h:153:3: error: typedef redefinition 
with different types ('struct (unnamed struct at 
/usr/src/contrib/ncurses/ncurses/term.priv.h:141:16)' vs 'struct term')
  153 | } TERMINAL;
  |   ^
./term.h:743:3: note: previous definition is here
  743 | } TERMINAL;
  |   ^
In file included from /usr/src/contrib/ncurses/ncurses/base/new_pair.c:40:
/usr/src/contrib/ncurses/ncurses/curses.priv.h:1248:3: error: redefinition of 
typedef 'SCREEN' is a C11 feature [-Werror,-Wtypedef-redefinition]
 1248 | } SCREEN;
  |   ^
./curses.h:394:24: note: previous definition is here
  394 | typedef struct screen  SCREEN;
  |^
3 errors generated.


I don't believe I have anything "suspect" in /etc/{src,make}*.conf:

g1-48(15.0-C)[22] foreach f ( /etc/{src,make}*.conf )
foreach? echo "${f}:" && grep -v '^#' $f; echo "==="; echo ""
foreach? end
/etc/src-env.conf:
WITH_META_MODE=yes
===

/etc/src.conf:
KERNCONF=CANARY
PORTS_MODULES+=x11/nvidia-driver
PORTS_MODULES+=graphics/drm-61-kmod
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
IWN_DEBUG=1
IEEE80211_DEBUG=1
BATCH_DELETE_OLD_FILES=1
WITHOUT_REPRODUCIBLE_BUILD=yes
WITHOUT_LLVM_TARGET_ALL=yes
===

/etc/make.conf:
NET_SNMP_SYS_CONTACT="da...@catwhisker.org"
NET_SNMP_SYS_LOCATION="variable"
NET_SNMP_LOGFILE=/var/log/snmpd.log
NET_SNMP_PERSISTENTDIR=/var/net-snmp
EXTRA_PATCH_TREE=/usr/local/port_patches
WITH_BSD_JDK=TRUE
WITHOUT_RUNTIME_CPUDETECTION=   YES
WITHOUT_CJK=YES
NO_SUID_XSERVER=YES
INSTALL_AS_NCFTP=yes
OPTIONS_SET=OPTIMIZED_CFLAGS
FORCE_PKG_REGISTER=YES
PKG_NOCOMPRESS=1
SENDMAIL_MC=/etc/mail/laptop.mc

.if ${.CURDIR:M*/graphics/drm-*kmod}
DISABLE_CONFLICTS=  YES
.endif
===

May I have the use of a clue, please?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In a collision, you don't get to choose which aspects of Physics apply.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/new_pair.o.meta
CMD cc -target x86_64-unknown-freebsd15.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-D_XOPEN_SOURCE_EXTENDED -I. -I/usr/src/lib/ncurses/tinfo 
-I/usr/src/lib/ncurses/ncurses -I/usr/src/

Re: main cadd2ca217 doesn't boot

[David Wolfskill]

On Sun, May 26, 2024 at 09:29:08AM +0200, Bojan Novković wrote:
> Hi,
> 
> da76d349b6b1 replaced a UMA-related symbol but missed three instances where
> the old one was used, ultimately causing the wrong UMA page allocator to get
> selected and crashing the machine.
> 
> I tested this patch as a part of a bigger series where it works fine, so
> this slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?

TL;DR: Yes, it fixes it (for 2 of my laptops, at least).

Details:
Laptops were running (e.g.):

FreeBSD 15.0-CURRENT #155 main-n270400-02d15215cef2: Sat May 25 14:19:27 UTC 
2024 
r...@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1500018 1500018

After updating sources to main-n270407-73eb53813fe3 and doing a normal
in-place source-based update (which owrked, as such), I (attempted)
rebooting, which exhibited the previously-documented failures.

I rebooted using the kernel from main-n270400-02d15215cef2, applied the
patch, rebuilt the kernel, and ... the reboot this time was successful:

FreeBSD 15.0-CURRENT #157 main-n270407-73eb53813fe3-dirty: Sun May 26 13:02:07 
UTC 2024 
r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1500018 1500018

(My 3rd "development" machine -- the fastest one -- is still bogged down
with Yet Another Chromium Rebuild on behalf of production machines that
are due to be updated once that completes.)

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
I will not be voting for a "unified reich" in the US.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

[David Wolfskill]

On Fri, May 17, 2024 at 08:00:05AM +0200, Emmanuel Vadot wrote:
> ...
>  Indeed, even if I know that I tested with GENERIC and amdgpu I think
> that I've only tested GENERIC-NODEBUG with i915kms.
>  Anyway, I've pushed both patches now. Sorry for the breakage.
> 
>  Cheers,
> 

Success:

g1-70(15.0-C)[1] uname -aUK
FreeBSD g1-70.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #147 
main-n270199-cd3681011001: Fri May 17 11:10:47 UTC 2024 
r...@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1500018 1500018

Thank you! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Please do not mistake "authoritarian" for "conservative" -- or vice versa.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

[David Wolfskill]

This is running main-n270174-abb1a1340e3f (built in-place from
main-n270163-154ad8e0f88f), with ports at main-n663685-3f732745ab06;
the ports-resident kernel modules were rebuilt with the kernel,
courtesy (e.g.):

g1-70(14.1-S)[4] grep '^PORT' /etc/src.conf
PORTS_MODULES+=graphics/drm-61-kmod

And since I dislike "sample sizes of one," I have this result on
two different laptops, each of which has both Nvidia & Intel graphics
(but for the older one (M4800), I stopped using (& building) the
Nvidia driver, since enabling it appears to disable GLX).

Anyway: photos of the backtraces are at
https://www.catwhisker.org/~david/FreeBSD/head/n270174/
as are copies of the build typescripts.

Unfortunately, the panic message itself had (just) scrolled off the
top at the time I took the photos, but I hand-typed it (from the
M4800) in the Subject.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Please do not mistake "authoritarian" for "conservative" -- or vice versa.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Resolved: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[David Wolfskill]

After the update to main-n269261-1e6db7be6921, head built & booted OK.

FreeBSD 15.0-CURRENT #45 main-n269261-1e6db7be6921: Wed Apr 10 11:11:50 UTC 
2024 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1500018 1500018

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[David Wolfskill]

On Tue, Apr 09, 2024 at 09:18:49AM -0700, Gleb Smirnoff wrote:
> ...
> D> db> 
> 
> This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.

Thanks! :-)

> Sorry for that!
> 

Glad it's idenitfied & addressed.

[Sorry for delay; commute this morning was a bit more turbulent than
usual.]

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[David Wolfskill]

Machine had been running:

FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr  8 11:19:58 UTC 
2024 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1500018 1500018

This was an in-place source update, after updating sources to
main-n269230-f6f67f58c19d.  On reboot (after "make installworld"
completed, I see this on the serial console (copy/pasted):

...
Starting lockd.


Fatal trap 12: page fault while in kernel mode
cpuid = 9; apic id = 09
fault virtual address   = 0x18
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b208c5
stack pointer   = 0x28:0xfe048c204920
frame pointer   = 0x28:0xfe048c204960
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 = 1208 (rpc.Starting automountd.
lockd)
rdi:  rsi: f801078b0740 rdx: 
rcx: 010a  r8: 818d30f0  r9: 
rax:  rbx: Starting powerd.0018 rbp: 
fe048c204960
r10: 0001 r11: 0001 r12: f80274e32c18
r13: 010a r14: f80274e32c00 r15: 812ae38a
trap number = 12
panic: page fault
cpuid = 9
time = 1712662362
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048c2045f0
vpanic() at vpanic+0x135/frame 0xfe048c204720
panic() at panic+0x43/frame 0xfe048c204780
trap_fatal() at trap_fatal+0x40b/frame 0xfe048c2047e0
trap_pfault() at trap_pfault+0xa0/frame 0xfe048c204850
calltrap() at calltrap+0x8/frame 0xfe048c204850
--- trap 0xc, rip = 0x80b208c5, rsp = 0xfe048c204920, rbp = 0xfe
048c204960 ---
__mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfe048c204960
clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfe048c204ab0
local_rpcb() at local_rpcb+0x11b/frame 0xfe048c204b50
rpcb_unset() at rpcb_unset+0x24/frame 0xfe048c204bb0
svc_tp_create() at svc_tp_create+0xee/frame 0xfe048c204c90
sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfe048c204e00
amd64_syscall() at amd64_syscall+0x158/frame 0xfe048c204f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe048c204f30
--- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00
96f7168, rbp = 0x3f0096f7230 ---
KDB: enter: panic
[ thread pid 1208 tid 101107 ]
Stopped at  kdb_enter+0x33: movq$0,0x104eb92(%rip)
db> 


Given suitable clues, I can poke at it a bit -- this is my "build
machine," so it doesn't have critical work to do at the moment.  (I
would normally have powered it down for the day: here's no need for
it to be wasting energy.)

Laptops are still building ports under stable/14 -- something seems
to want the llvm17 port, and they have firefox to build, so they
won't be testing CURRENT/head for a while, yet.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?

[David Wolfskill]

On Mon, Apr 01, 2024 at 10:51:10PM -0700, Kevin Oberman wrote:
> 
> I have a T16 and ran into that issue. It may be that BIOS changes have
> broken things, but I found that, by default, the F keys control volume,
> screen brightness, and many other things. I can use Fn+F[1-12] to perform
> traditional function key functions. I found that bios has an option to make
> the traditional functions the default which is how I am running today and
> have since shortly after I purchased the computer. One I set that BIOS
> option, everything worked "properly". I now use Fn+F[1-12] to adjust volume
> and screen brightness. I hope to get mute to work, but I need to figure out
> which event is set when Fn+F1 is pressed to write trivial devd support for
> it.

Another approach (for making use of quasi-random keys scattered
across a keyboard) is to utilize x11/xbindkeys (at least, within
an X11 environment).

> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Request for Testing: TCP RACK

[David Wolfskill]

On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> ...
> >> It would be so nice that we can have a sysctl tunnable for this patch
> >> so we could do more tests without recompiling kernel.
> > Thanks for testing!
> >
> > @gallatin: can you come up with a patch that is acceptable for Netflix
> > and allows to mitigate the performance regression.
> 
> Ideally, tcphpts could enable this automatically when it starts to be
> used (enough?), but a sysctl could select auto/on/off.
> 
>   Mike
> 

Or (at some risk of over-{complicat,engineer}ing things), perhaps
sysctl/tunable for high- and low-water marks?

Peace,
david   (who is quite unlikely to be writing the code, so "grain of salt")
-- 
David H. Wolfskill  da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[David Wolfskill]

[Closing the loop on this -- dhw]

On Tue, Jan 30, 2024 at 06:49:32AM -0800, David Wolfskill wrote:
> The machines where I track head (& stable/14) daily get powered off once
> they have finished their work for the day; this is done via "poweroff".
>  ...
> | 
> | The operating system has halted.
> | Please press any key to reboot.
> 
> So I hit "Enter" and then saw:
> 
> | 
> | acpi0: Powering system off
> 

As of main-n268079-e4ab361e5394, this is resolved.

See also the thread starting with
https://lists.freebsd.org/archives/dev-commits-src-main/2024-February/021637.html,
"git: e4ab361e5394 - main - fix poweroff regression from 9cdf326b4f by
delaying shutdown_halt"

Thanks, Andriy! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[David Wolfskill]

On Wed, Jan 31, 2024 at 07:53:07AM -0600, Mike Karels wrote:
> On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote:
> ... 
> > Same problem here.
> 
> I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed
> shutdown ordering.
> 

Yes; I have been corresponding with Andriy, and have confirmed that
backing out that change restores the previous behavior.

He's looking at some additional things, but he can speak to that.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[David Wolfskill]

On Tue, Jan 30, 2024 at 03:49:54PM +, Gary Jennejohn wrote:
> ...
> I use 'shutdown -p now' and it's never failed to power down my computers.
> 

I could say the same about "poweroff", up to the main-n267808-197944948e62
-> main-n267841-0b3f9e435f2b transition.  And I probably wouldn't
have mentioned anything, except that each of the 3 machines (one
headless build machine; 2 laptops) I tested exhibited the same change.

Note, too, from src/sbin/shutdown/shutdown.c:

/*
 * Test for the special case where the utility is called as
 * "poweroff", for which it runs 'shutdown -p now'.
 */
if ((p = strrchr(argv[0], '/')) == NULL)
p = argv[0];
else
++p;
if (strcmp(p, "poweroff") == 0) {
if (getopt(argc, argv, "") != -1)
usage((char *)NULL);
argc -= optind;
argv += optind;
if (argc != 0)
usage((char *)NULL);
dopower = 1;
offset = 0;
(void)time(&shuttime);
goto poweroff;

(So I believe we are referring to the same code paths, whether by
"shutdown -p now" or "poweroff".)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[David Wolfskill]

On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote:
> On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote:
> > The machines where I track head (& stable/14) daily get powered off once
> > they have finished their work for the day; this is done via "poweroff".
> >
> > I noticed (this morning) that one of them never actually powered off
> > yesterday.  After today's exercises (including the reboot & subsequent
> > poweroff), I saw on the (serial) console:
> 
> Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-)
> 

No; I don't mess with /boot/*.conf without a (plausibly good) reason.  :-)

But I can experiment... so I'm trying it now.
...
Hmm... I don't see any difference in behavior.

These systems each boot using BIOS (vs. UEFI), in case that's relevant.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[David Wolfskill]

The machines where I track head (& stable/14) daily get powered off once
they have finished their work for the day; this is done via "poweroff".

I noticed (this morning) that one of them never actually powered off
yesterday.  After today's exercises (including the reboot & subsequent
poweroff), I saw on the (serial) console:

| ...
| unknown: wake_prep disabled wake for \_SB_.PCI3.SR3A (S5)
| unknown: wake_prep disabled wake for \_SB_.PCI3.SR3B (S5)
| unknown: wake_prep disabled wake for \_SB_.PCI3.SR3C (S5)
| unknown: wake_prep disabled wake for \_SB_.PCI3.SR3D (S5)
| 
| The operating system has halted.
| Please press any key to reboot.

So I hit "Enter" and then saw:

| 
| acpi0: Powering system off

(and heard the fans stop spinning).

And that recurred this morning.

So I believe that the issue arose in the transition from what the
machine had built on Sunday:

FreeBSD 15.0-CURRENT #36 main-n267808-197944948e62: Sun Jan 28 16:22:34 UTC 
2024 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1500012 1500012

to what it built on Monday:

FreeBSD 15.0-CURRENT #37 main-n267841-0b3f9e435f2b: Mon Jan 29 12:17:47 UTC 
2024 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1500012 1500012

Glancing at the typescript from Monday's update/build
(197944948e62..0b3f9e435f2b), it looks to me as if there was a fair
amount of "churn" in boot-related code, so I will look further into
that as time permits.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem building world on current

[David Wolfskill]

On Thu, Dec 28, 2023 at 04:05:49PM +0100, Santiago Martinez wrote:
> Hi Everyone, I'm having issues building world from current (just now).
> 
> Same header missing on multiple parts.
> 
> Best regards.
> 
> Santiago
> 

It might be useful to know:
* What you are running at the time;
* what the most recent commit in your source tree is;
* whether this is a clean build, you are using make's META_MODE, or you
  are just setting -DNO_CLEAN.

I have not seen the issue you cite; my most recent builds of head:

FreeBSD 15.0-CURRENT #22 main-n267169-5bc10feacc9d: Tue Dec 26 12:14:41 UTC 
2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 158 158
FreeBSD 15.0-CURRENT #23 main-n267215-3334a537ed38: Wed Dec 27 15:52:04 UTC 
2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 158 158
FreeBSD 15.0-CURRENT #24 main-n267279-789480702e49: Thu Dec 28 12:18:34 UTC 
2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 158 158
(in my case, using make's META_MODE).

More details at https://www.catwhisker.org/~david/FreeBSD/history/.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38

[David Wolfskill]

On Wed, Dec 27, 2023 at 11:44:37PM +0300, Ruslan Makhmatkhanov wrote:
>Hello,

>I updated my tree to revision 3334a537ed38, made buildworld and kernel
>as usual.
> 
>Booting with new kernel leads to keyboard not working at system login
>prompt and the message "kernel: psm: keyboard controller failed" in
>/var/log/messages.
> 
>Reverting to boot the old kernel main-n266238-03e2fc4c4446 makes
>keyboard and system working again.
> 
>I failed to find similar problem in bug tracker and google. Does
>anybody also see this behavior?
> 
>Regards,
> 
>Ruslan
> 

I updated my "development" machines from main-n267169-5bc10feacc9d to
main-n267215-3334a537ed38 this morning; I did not see the problem you
cite.

One of those machines is a laptop (with which I interacted directly);
I used ssh to login to the other two (from that laptop).

I note, though, that that laptop (which I use the most) is (mostly)
over 9 years old, so it may not be caught up in some of the more recent
... "hardware fashions" that tend to make using such devices a bit more
"interesting" than one might expect.

(Gory details of updating process & history at
https://www.catwhisker.org/~david/FreeBSD/upgrade.html and
https://www.catwhisker.org/~david/FreeBSD/history/, respectively.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

[David Wolfskill]

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote:
> Hi.
> 
> Not tested, but does upgrading to commit ed88eef140a1 [1] and later
> help? (I'm still at commit 5d4f897f88ed on main.)
> 
> [1]
> https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809
> 
> Regards.
> 

Yes; thank you (and jhb@): after hand-applying the ed88eef140a1 commit &
rebuilding, the laptop rebooted OK:

g1-48(15.0-C)[1] uname -aUK
FreeBSD g1-48.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #530 
main-n266611-49a83b94395a-dirty: Sat Nov 25 20:04:25 UTC 2023 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
154 154

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The notion that anyone would perceive a need to "make neo-Nazis
look bad" is about as absurd as perceiving a need to "hydrate" water.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

[David Wolfskill]

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote:
> Hi.
> 
> Not tested, but does upgrading to commit ed88eef140a1 [1] and later
> help? (I'm still at commit 5d4f897f88ed on main.)
> 
> [1]
> https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809
> 
> Regards.
> 

Thanks!  That does look as if it addresses the problem, so I will try
it (& reoprt to the list).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The notion that anyone would perceive a need to "make neo-Nazis
look bad" is about as absurd as perceiving a need to "hydrate" water.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

[David Wolfskill]

After I saw this with both my headless "build machine" and a laptop (and
verified that there were no more recent commits to main), I figured it
might be worth reporting.

This was after a source update from:
FreeBSD 15.0-CURRENT #473 main-n266588-2a35f3cdf63d-dirty: Fri Nov 24 13:11:48 
UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 154 154

("-dirty" because I had hand-applied 50335b1ae4e4:

main-n266589-50335b1ae4e4
commit 50335b1ae4e48712f831e85ddfa7b00da0af382c
Author: Emmanuel Vadot 
Date:   Fri Nov 24 11:30:09 2023 +0100

sys/mutex.h: Reorder includes

Fixes:  2a35f3cdf63d ("sys/mutex.h: Include sys/lock.h instead of 
sys/_lock.h")

after seeing a build failure yesterday after updating to
main-n266588-2a35f3cdf63d.)

Here's a backtrace:

...
Event timer "HPET6" frequency 14318180 Hz quality 340
Event timer "HPET7" frequency 14318180 Hz quality 340
panic: bus_generic_rman_activate_resource: rman 0x81b0b0e8 doesn't 
match for resource 0xf801092b9280
cpuid = 20
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82eaf8b0
vpanic() at vpanic+0x132/frame 0x82eaf9e0
panic() at panic+0x43/frame 0x82eafa40
bus_generic_rman_activate_resource() at 
bus_generic_rman_activate_resource+0x146/frame 0x82eafaa0
acpi_alloc_sysres() at acpi_alloc_sysres+0x83/frame 0x82eafae0
acpi_alloc_resource() at acpi_alloc_resource+0x108/frame 0x82eafba0
bus_alloc_resource() at bus_alloc_resource+0x9b/frame 0x82eafc00
acpi_timer_probe() at acpi_timer_probe+0xaa/frame 0x82eafc80
device_probe_child() at device_probe_child+0x16f/frame 0x82eafcd0
device_probe() at device_probe+0x8a/frame 0x82eafcf0
device_probe_and_attach() at device_probe_and_attach+0x32/frame 
0x82eafd20
bus_generic_attach() at bus_generic_attach+0x18/frame 0x82eafd40
acpi_probe_children() at acpi_probe_children+0x226/frame 0x82eafda0
acpi_attach() at acpi_attach+0x97b/frame 0x82eafe30
device_attach() at device_attach+0x3bc/frame 0x82eafe70
device_probe_and_attach() at device_probe_and_attach+0x70/frame 
0x82eafea0
bus_generic_attach() at bus_generic_attach+0x18/frame 0x82eafec0
device_attach() at device_attach+0x3bc/frame 0x82eaff00
device_probe_and_attach() at device_probe_and_attach+0x70/frame 
0x82eaff30
bus_generic_new_pass() at bus_generic_new_pass+0xed/frame 0x82eaff60
bus_set_pass() at bus_set_pass+0x36/frame 0x82eaff90
configure() at configure+0x9/frame 0x82eaffa0
mi_startup() at mi_startup+0x1c8/frame 0x82eafff0
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x32: movq$0,0xe3cf53(%rip)
db>

I can leave this machine in this state for a few hours, so if there's
any diagnostic information to be gained, I'm happy to do that, but I'll
need clues as to what to do.

If I can get a dump, I'm happy to make it available (but I'll hold off
on trying that for now, as I expect the attempt could disturb evidence).

Information about the machine(s) & update history may be found at
https://www.catwhisker.org/~david/FreeBSD/history/ in case that's
of use.  (This includes a copy of /var/run/dmesg.boot from the last
successful verbose boot, which was from yesterday.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The notion that anyone would perceive a need to "make neo-Nazis
look bad" is about as absurd as perceiving a need to "hydrate" water.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"make installworld" fails for main-n265819-af5e348c61da

[David Wolfskill]

This is for an in-place source update; machine is currently running:

freebeast(15.0-C)[15] uname -aUK
FreeBSD freebeast.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #427 
main-n265811-38ecc80b2a4e: Sun Oct  8 17:42:28 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 151 151


Sources were updated to main-n265819-af5e348c61da.

Excerpt from the build typescript:

...
>>> Installing everything started on Mon Oct  9 11:26:45 UTC 2023
make[3]: "/common/S4/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: 
Using cached toolchain metadata from build at freebeast.catwhisker.org on Mon 
Oct  9 10:49:37 UTC 2023
...
install  -o root -g wheel -m 444 rk_grf.4.gz  /usr/share/man/man4/
install  -o root -g wheel -m 444 rk_i2c.4.gz  /usr/share/man/man4/
install  -o root -g wheel -m 444 rk_pinctrl.4.gz  /usr/share/man/man4/
rm -f /usr/share/man/man4/aarch64/armv8crypto.4 
/usr/share/man/man4/aarch64/armv8crypto.4.gz;  install -l h -o root -g wheel -m 
444  /usr/share/man/man4/armv8crypto.4.gz 
/usr/share/man/man4/aarch64/armv8crypto.4.gz
install: link /usr/share/man/man4/armv8crypto.4.gz -> 
/usr/share/man/man4/aarch64/armv8crypto.4.gz: No such file or directory
*** Error code 71

Stop.
make[7]: stopped in /usr/src/share/man/man4/man4.aarch64
*** Error code 1


So... a couple of things:
* This is an amd64 machine, building native.  I didn't specify anything
  with respect to aarch64, and have nothing about aarch64 mentioned in
  /etc/*.conf.

* While my build procedure is based on the information in src/UPDATING, I
  took the liberty (over a decade ago) to augment those instructions
  with a couple of additional steps just prior to issuing "make
  installworld":
  * One of those is to move /usr/include aside;
  * The other is to just completely remove /usr/share/man (recursively).

  In each case, this is not because I don't want the hierarchy in
  question; rather, it is because I want to be sure there is nothing
  extraneous in either.  "make hierarchy" has (in the past) been
  invoked by "make installworld" and everything has been fine.

  Prior to the above-described failure, I had an earlier one:

...
>> etcupdate -p OK
Mon Oct  9 11:10:29 UTC 2023
>> /usr/include.old removed
Mon Oct  9 11:10:29 UTC 2023
>> /usr/include moved aside
Mon Oct  9 11:10:29 UTC 2023
>> /usr/share/man removed
Mon Oct  9 11:10:29 UTC 2023
make[1]: "/common/S4/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: 
Using cached toolchain metadata from build at freebeast.catwhisker.org on Mon 
Oct  9 10:49:37 UTC 2023
--
>>> Install check world
--
...
installing DIRS CONFSDIR
install  -d -m 0755 -o root  -g wheel  /etc
installing DIRS NLSDIR
install  -d -m 0755 -o root  -g wheel  /usr/share/nls
install  -o root -g wheel -m 444 btree.3.gz  /usr/share/man/man3/
install: /usr/share/man/man3/: No such file or directory
*** Error code 71

Stop.
make[5]: stopped in /usr/src/lib/libc
*** Error code 1


I checked src/Makefile.inc1; it was last updated by:
| commit 1a18383a52bc373e316d224cef1298debf6f7e25
| Author: Pierre Pronchery 
| Date:   Fri Sep 15 17:14:16 2023 +0200
| 
| libcrypto: link engines and the legacy provider to libcrypto

Since I didn't see anything obvious that might have caused the observed
failure, I tweaked my procedure so that after removing /usr/share/man,
it then issued:

mkdir -p /usr/share/man/man{1,2,3{,lua},4,5,6,7,8,9}

Which appears to have got me through the initial issue.

I mention this in case there's a chance it might possibly be relevant.


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am not a member of any organized political party — I am a Democrat."
 - Will Rogers  (Huh.  Wonder what he'd say given recent events)

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: problems on new -current install with pkg/ssl

[David Wolfskill]

On Sun, Jul 09, 2023 at 05:17:38PM +0100, void wrote:
> Hi,
> 
> On a fresh 14-current install (main-n263444-653738e895ba) I try to use pkg
> for anything and this error
> happens:
> 
> # pkg install doas
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
> please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
> done
> Installing pkg-1.19.2...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400092
> - running kernel: 1400090

That's warning you that the "pkg" version you're selecting is for
FreeBSD 14 with a "FreeBSD version" of 1400092, but what you're running
is at "1400090".

> Ignore the mismatch and continue? [y/N]: y
> Extracting pkg-1.19.2: 100%
> ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

So your FreeBSD installtion appears to have been from before the import
of OpenSSL 3, while the "pkg" you just installed requires OpenSSL 3.

> How can I fix?

Either upgrade your FreeBSD installation to some point after the OpenSSL
3 import -- here's the src/UPDATING entry:

20230623:
OpenSSL has been updated to version 3.0, including changes throughout
the base system.  It is important to rebuild third-party software
after upgrading.


The commit was at main-n263775-b077aed33b7b, but there was a bit
of "turbulence"for a few days after that, so I suggest updating to
something more recent.  (My latest successful was
main-n264066-e64780fbc394, FWIW.)

Or downgrade to an older "pkg".  In your position, I'd do the former.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: debug.verbose_sysinit=1

[David Wolfskill]

On Sun, Jun 25, 2023 at 09:20:40PM +0100, Graham Perrin wrote:
> When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to _not_
> have BOOT and copyright messages?

It's normal (in that situation) to require a higher value in
kern.msgbufsize if you want the entire dmesg output saved in
/var/run/dmesg.boot, yes.

I use a shell script to modify that (in /boot/loader.conf.d/) in
conjunction with requesting a "verbose" (or not) boot.

E.g., on my laptop, the default value is 98304, which is fine for a
"normal" boot; for a "verbose" boot, I set it to 196608 (which works in
this case).

> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

On Sat, Jun 24, 2023 at 09:09:00AM -0700, David Wolfskill wrote:
> On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> > ...
> > > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > > #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility 
> > > level"
> > >^
> > 
> > This could be a dependency issue; would you check if removing the
> > following $OBJTOP subdirs addresses the issue:
> > 
> > secure/lib/libcrypto
> > secure/lib/libssl
> > obj-lib32/secure/lib/libcrypto
> > obj-lib32/secure/lib/libssl
> > 
> > If so I'll see if we can add a rule to tools/build/depend-cleanup.sh
> 
> After:
> ... 
> rm -fr /usr/obj/usr/src/amd64.amd64/{,obj-lib32/}secure/lib/lib{crypto,ssl}
> 
> then re-starting the "make buildworld", that process has completed the
> 
> >>> stage 4.2: building libraries
> 
> phase (and is now "building lib32 shim libraries").
> 

The build was successful; after the reboot, we see:

g1-48(14.0-C)[1] uname -aUK
FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #469 
main-n263782-59833b089e78: Sat Jun 24 16:28:56 UTC 2023 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1400092 1400092


So: I believe we have a winner! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> ...
> > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility 
> > level"
> >^
> 
> This could be a dependency issue; would you check if removing the
> following $OBJTOP subdirs addresses the issue:
> 
> secure/lib/libcrypto
> secure/lib/libssl
> obj-lib32/secure/lib/libcrypto
> obj-lib32/secure/lib/libssl
> 
> If so I'll see if we can add a rule to tools/build/depend-cleanup.sh

After:

g1-48(14.0-C)[1] ls -lTd 
/usr/obj/usr/src/amd64.amd64/^G{,obj-lib32/}secure/lib/lib{crypto,ssl}
drwxrwxr-x  4 root  wheel   62464 Jun 23 06:08:19 2023 
/usr/obj/usr/src/amd64.amd64/obj-lib32/secure/lib/libcrypto
drwxrwxr-x  2 root  wheel5120 Jun 23 06:08:38 2023 
/usr/obj/usr/src/amd64.amd64/obj-lib32/secure/lib/libssl
drwxrwxr-x  5 root  wheel  132608 Jun 24 04:11:55 2023 
/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto
drwxrwxr-x  2 root  wheel5632 Jun 24 04:11:56 2023 
/usr/obj/usr/src/amd64.amd64/secure/lib/libssl
g1-48(14.0-C)[2] rm -fr !$
rm -fr /usr/obj/usr/src/amd64.amd64/{,obj-lib32/}secure/lib/lib{crypto,ssl}

then re-starting the "make buildworld", that process has completed the

>>> stage 4.2: building libraries

phase (and is now "building lib32 shim libraries").

So: definite progress.  (Build machine is busy with other stuff, so the
above was on a laptop; it will be a bit slow).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405 
main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400091 1400091

after updating sources to main-n263782-59833b089e78, then starting
make -j 64 buildworld (in META mode)

...
>>> stage 4.2: building libraries
...
Building /common/S4/obj/usr/src/amd64.amd64/cddl/lib/libzfs/os/freebsd/nfs.o
In file included from /usr/src/sys/contrib/openzfs/lib/libzfs/libzfs_crypto.c:28
:
In file included from /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl
/evp.h:14:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:155:4: error
: "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
#  error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
   ^
*** [radlib.o] Error code 1

make[4]: stopped in /usr/src/lib/libradius
.ERROR_TARGET='radlib.o'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/lib/libradius/radlib.o.meta'
.MAKE.LEVEL='4'


The cited meta file pretty much re-states the above, but I have
attached a copy anyway.

Subsequently, one of my laptops has reproduced the failure (though with
only -j 16).

As of this writing, I see no more rec ent commits to head.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file /common/S4/obj/usr/src/amd64.amd64/lib/libradius/radlib.o.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   -Wall 
-DOPENSSL_API_COMPAT=0x1010L -DWITH_SSL -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/lib/libradius/radlib.c -o radlib.o
CMD 
CWD /common/S4/obj/usr/src/amd64.amd64/lib/libradius
TARGET radlib.o
-- command output --
In file included from /usr/src/lib/libradius/radlib.c:38:
In file included from 
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/hmac.h:14:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:139:4: 
error: "The requested API level higher than the configured API compatibility 
level"
#  error "The requested API level higher than the configured API compatibility 
level"
   ^
1 error generated.

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 20051
# Start 1687604049.922333
V 5
E 20054 /bin/sh
R 20054 /etc/libmap.conf
R 20054 /var/run/ld-elf.so.hints
R 20054 /lib/libedit.so.8
R 20054 /lib/libc.so.7
R 20054 /lib/libtinfow.so.9
R 20054 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 20054 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 20054 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 20054 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 20054 /usr/share/locale/en_US.UTF-8/LC_TIME
R 20054 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 20054 20056
E 20056 /usr/bin/cc
R 20056 /etc/libmap.conf
R 20056 /var/run/ld-elf.so.hints
R 20056 /lib/libz.so.6
R 20056 /usr/lib/libprivatezstd.so.5
R 20056 /usr/lib/libexecinfo.so.1
R 20056 /lib/libncursesw.so.9
R 20056 /lib/libtinfow.so.9
R 20056 /lib/libthr.so.3
R 20056 /lib/libc++.so.1
R 20056 /lib/libcxxrt.so.1
R 20056 /lib/libm.so.5
R 20056 /lib/libc.so.7
R 20056 /lib/libelf.so.2
R 20056 /lib/libgcc_s.so.1
R 20056 /usr/src/lib/libradius/radlib.c
R 20056 radlib-51f1ada4.o.tmp
W 20056 radlib-51f1ada4.o.tmp
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/cdefs.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_limits.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_limits.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_pthreadtypes.h
R 20056 /common/S4/obj/usr/src/amd64

Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[David Wolfskill]

This is from an in-place source update from main-n263073-634a770a5e16 to
main-n263112-ad513b4dba3e:

...
Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
Building 
/common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
/usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
[-Werror,-Wincompatible-pointer-types]
error = vm_run(vcpu, &vmexit);
 ^~~
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
passing argument to parameter 'vmrun' here
int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
 ^
1 error generated.


Given that yesterday's update was uneventful, and that
src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
I'm guessing that perhaps a recent change to a header, possibly
involving vmexit, may be at issue here.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Folks who wish to control what others do with their bodies are often
called "conservative," when they are actually "authoritarian."

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Buildworld failure at main-n261978-44312c28fe2d in /usr/src/usr.sbin/bhyve

[David Wolfskill]

Resolved by  76fa62b5232e67ef10476cf1329aaceb9cbc2ff5; ref.
https://cgit.freebsd.org/src/commit/?id=76fa62b5232e67ef10476cf1329aaceb9cbc2ff5

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin claimed he wanted to avoid expansion of NATO.  See how well THAT worked.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Buildworld failure at main-n261978-44312c28fe2d in /usr/src/usr.sbin/bhyve

[David Wolfskill]

Running:

freebeast(14.0-C)[4] uname -aUK
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #328 
main-n261961-7ae0972c7b8c: Mon Apr  3 11:41:40 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400085 1400085

in meta mode after updating /usr/src to main-n261978-44312c28fe2d:

...
Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve.8.gz
Building /common/S4/obj/usr/src/amd64.amd64/share/man/man4/pst.4.gz
/usr/src/usr.sbin/bhyve/qemu_fwcfg.c:237:28: error: use of undeclared 
identifier 'guest_ncpus'
*fwcfg_max_cpus = htole16(guest_ncpus);
  ^
1 error generated.
*** [qemu_fwcfg.o] Error code 1

make[4]: stopped in /usr/src/usr.sbin/bhyve
.ERROR_TARGET='qemu_fwcfg.o'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/bhyve/qemu_fwcfg.o.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-I/usr/src/usr.sbin/bhyve/../../contrib/lib9p -I/usr/src/sys -DINET -DINET6 
-DNETGRAPH -I/usr/src/sys/dev/e1000 -I/usr/src/sys/dev/mii 
-I/usr/src/sys/dev/usb/controller -fPIE -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wstrict-prototypes -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=array-parameter 
-Wno-error=deprecated-non-prototype -Wno-error=unused-but-set-parameter  
-Qunused-arguments-c /usr/src/usr.sbin/bhyve/qemu_fwcfg.c -o qemu_fwcfg.o; 
;'
.CURDIR='/usr/src/usr.sbin/bhyve'




I will attach a copy of the meta file.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin claimed he wanted to avoid expansion of NATO.  See how well THAT worked.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/amd64.amd64/usr.sbin/bhyve/qemu_fwcfg.o.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-I/usr/src/usr.sbin/bhyve/../../contrib/lib9p -I/usr/src/sys -DINET -DINET6 
-DNETGRAPH -I/usr/src/sys/dev/e1000 -I/usr/src/sys/dev/mii 
-I/usr/src/sys/dev/usb/controller -fPIE -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wstrict-prototypes -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=array-parameter 
-Wno-error=deprecated-non-prototype -Wno-error=unused-but-set-parameter  
-Qunused-arguments-c /usr/src/usr.sbin/bhyve/qemu_fwcfg.c -o qemu_fwcfg.o
CMD 
CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/bhyve
TARGET qemu_fwcfg.o
OODATE /usr/src/usr.sbin/bhyve/qemu_fwcfg.c
-- command output --
/usr/src/usr.sbin/bhyve/qemu_fwcfg.c:237:28: error: use of undeclared 
identifier 'guest_ncpus'
*fwcfg_max_cpus = htole16(guest_ncpus);
  ^
1 error generated.

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 62670
# Start 1680605471.854440
V 5
E 63254 /bin/sh
R 63254 /etc/libmap.conf
R 63254 /var/run/ld-elf.so.hints
R 63254 /lib/libedit.so.8
R 63254 /lib/libc.so.7
R 63254 /lib/libtinfow.so.9
R 63254 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 63254 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 63254 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 63254 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 63254 /usr/share/locale/en_US.UTF-8/LC_TIME
R 63254 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 63254 63258
E 63258 /usr/bin/cc
R 63258 /etc/libmap.conf
R 63258 /var/run/ld-elf.so.hints
R 63258 /lib/libz.so.6
R 63258 /usr/lib/libexecinfo.so.1
R 63258 /lib/libncursesw.so.9
R 63258 /lib/libtinfow.so.9
R 63258 /lib/libthr.so.3
R 63258 /lib/libc++.so.1
R 63258 /lib/libcxxrt.so.1
R 63258 /lib/libm.so.5
R 63258 /lib/libc.so.7
R 63258 /lib/libelf.so.2
R 63258 /lib/libgcc_s.so.1
R 63258 /usr/src/usr.sbin/bhyve/qemu_fwcfg.c
R 63258 qemu_fwcfg-bba7f35e.o.tmp
W 63258 qemu_fwcfg-bba7f35e.o.tmp
R 63258 /usr/src/sys/sys/param.h
R 63258 /usr/src/sys/sys/_null.h
R 63258 /usr/src/sys/sys/types.h
R 63258 /usr/src/sys/sys/cdefs.h
R 6325

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[David Wolfskill]

On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> looks like we may need another 'unclean' workaround for this?
> 
> Warner
> 
> On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:
> ... 
> > I had this problem also.  After deleting obj/usr the buildworld succeeded.
> >
> 

Empirically:
rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic

got through the issue on my build machine.  (I expect that it will also
do so on the others where I track head, but they are presently building
lang/rust.)

Perhaps an UPDATING entry would suffice?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[David Wolfskill]

Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275 
main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

and performing an in-place source update to main-n260011-40bb52c89b87
using META mode, I encountered:

Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/tar/tests/test_option_k.o
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/calendar/tests/legacy_test
Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic
objcopy: open zic failed: Is a directory
*** [zic] Error code 1

make[4]: stopped in /usr/src/usr.sbin/zic
.ERROR_TARGET='zic'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic;'
.CURDIR='/usr/src/usr.sbin/zic'
.MAKE='make'
.OBJDIR='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic'
.TARGETS='all'
DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20220726'

Contents of the META_FILE:
# Meta data file /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta
CMD objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic
CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic
TARGET zic
OODATE zic.full zic.debug
-- command output --
objcopy: open zic failed: Is a directory

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 76995
# Start 1673437990.835926
V 5
E 84537 /bin/sh
R 84537 /etc/libmap.conf
R 84537 /var/run/ld-elf.so.hints
R 84537 /lib/libedit.so.8
R 84537 /lib/libc.so.7
R 84537 /lib/libtinfow.so.9
R 84537 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 84537 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 84537 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 84537 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 84537 /usr/share/locale/en_US.UTF-8/LC_TIME
R 84537 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 84537 84538
E 84538 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin/objcopy
R 84538 zic.full
X 84538 1 0
X 84537 1 0
# Stop 1673437990.838926
# Bye bye

This is on a 32-core amd64 machine with 256GiB RAM (in case that's
relevant).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: cant login after make installworld: pam_opie.so.6 not found

[David Wolfskill]

On Tue, Jan 03, 2023 at 09:39:31PM +, Ivan Quitschal wrote:
> ...
> I am having a problem here after doing a:
> make installworld
> and
> make delete-old-libs
> 
> now I cant login (only thru single user)
> looks like the "make delete-old-libs"  has deleted that lib pam_opie.so.6 and 
> now I cannot pass the login prompt
> says the error "pam_opie.so: not found
> 
> how can I get it back? I tried everything and nothing brought it back , not 
> even another make installworld
> any insights?
> 

I believe that the issue is a result of:

| commit 0aa2700123e22c2b0a977375e087dc2759b8e980
| Author: Dag-Erling Smørgrav 
| Date:   Sun Oct 2 03:37:29 2022 +0200
| 
| Put OPIE to rest.
| 
| Differential Revision: https://reviews.freebsd.org/D36592

(in src/lib/libpam/modules).

OPIE is (thus) no longer part of FreeBSD current.  I expect it would
be best if you arranged things so you no longer depend on it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build error in FreeBSD head, main-n259058-105019e0d6c -> main-n259061-b1258b76435

[David Wolfskill]

And the only commit after main-n259061-b1258b76435 so far is
004bb636ca65f3239da284c20abb7f9d1d953dee, which claims:

| tcp: Move sysctl OIDs related to ECN to tcp_ecn.
| Keep all ECN related code in (mostly) one place.
| 
| No functional change.

I'm seeing:

...
building shared library libBIG5.so.5
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/DECHanyu/libDECHanyu.so.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:56:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
warning: declaration of 'struct tcpcb' will not be visible outside of this 
function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/googletest/gtest/libprivategtest.a
building static gtest library
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
   ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
 ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
1 warning and 4 errors generated.
building static devdctl library
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/EUC/libEUC.so.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:56:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
warning: declaration of 'struct tcpcb' will not be visible outside of this 
function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
   ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30: 
error: incomplete definition of type 'struct tcpcb'
Building /common/S4/obj/usr/src/amd64.amd64/lib/libwrap/libwrap.a
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
 ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_funcs.pico
building static wrap library
building shared library libD

Re: Problem with NVIDIA drivers 390 and 470 on current

[David Wolfskill]

On Sun, Sep 25, 2022 at 11:30:07PM -0300, Nilton Jose Rizzo wrote:
> Hi all,
> 
> I'm updated my box to last 14-current today and I get error on ports 
> compialtion.
> 

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266561

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In 2022, the governors of Texas and Florida resurrect the racist
ploys of the "White Citizens’ Council" of 1962 -- at taxpayers' expense.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Good practices with bectl

[David Wolfskill]

On Wed, Sep 21, 2022 at 11:27:06AM +0200, Alexander Leidinger wrote:
>   ...
> make DESTDIR=${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old delete-old-libs
> 
> Usually I replace the delete-old-libs with check-old, as I don't want  
> to blindly delete them (some ports may depend on them... at least for  
> the few libs which don't have symbol versioning).
> 

A way to address that issue that may work for you is to install
appropriate misc/compat* ports/packages.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
In 2022, the governors of Texas and Florida resurrect the racist
ploys of the "White Citizens’ Council" of 1962 -- at taxpayers' expense.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic after update from main-n258027-c9baa974717a to main-n258075-5b5b7e2ca2fa

[David Wolfskill]

Not reproducible on reboot; only happened on one machine (main laptop)
out of 3 that I updated this morning.  No dump. :-/

A screenshot, a copy of the full dmesg.boot from the
immediately-following successful (verbose) boot, and a copy of the
uname output:

FreeBSD 14.0-CURRENT #589 main-n258075-5b5b7e2ca2fa: Sat Sep 17 12:22:57 UTC 
2022 
r...@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1400068 1400068

may be found at https://www.catwhisker.org/~david/FreeBSD/head/n258075/

The screenshot includes a backtrace; a hand-transcription:

Trying to mount root from ufs:/dev/ada0s4a [rw]...
panic: Assertion _ndp->ni_cnd.cn_pnbuf != NULL failed at 
/usr/src/sys/kern/vfs_mountroot.c:731
cpuid = 1
time = 2
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804b9dfb = 
db_trace_self_wrapper+0x2b/frame 0xfe0fba5d4af0
vpanic() at 0x80bd90f1 = vpanic+0x151/frame 0xfe0fba5d4b40
panic() at 0x80bd8ec3 = panic+0x43/frame 0xfe0fba5d4ba0
parse_mount_dev_present() at 0x80cc7f76 = 
parse_mount_dev_present+0x116/frame 0xfe0fba5d4c90
parse_mount() at 0x80cc7c49 = parse_mount+0x5c9/frame 0xfe0fba5d4d00
vfs_mountroot() at 0x80cc60c3 = vfs_mountroot+0x7c3/frame 
0xfe0fba5d4e60
start_init() at 0x80b60093 = start_init+0x23/frame 0xfe0fba5d4ef0
fork_exit() at 0x80b8f770 = fork_exit+0x80/frame 0xfe0fba5d4f30
fork_trampoline() at 0x810c264e = fork_trampoline+0xe/frame 
0xfe0fba5d4f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 1 tid 12 ]
Stopped at  0x80c26ac2 = kdb_enter+0x32:movq
$0,0x12ab643(%rip)
db> 



For all I know, the machine may be a little flaky -- it is the
oldest of the 3.  But I thought it might be worth mentioning.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"In my administration, I'm going to enforce all laws concerning the
protection of classified information. No one will be above the law."
 -- D. Trump, August, 2016

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: A kernel crash after compiling a fresh kernel

[David Wolfskill]

On Wed, Jun 08, 2022 at 08:50:28AM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> Does this patch fix your issue?
> 
> --HPS
> 

(As you noted later, that patch had been committed to head by the time I
got around to checking, as:

commit ce2525c8108a830d08d75771621d1bc580edd82c (HEAD -> main, origin/main, 
origin/HEAD)
Author: Richard Scheffenegger 
Date:   Wed Jun 8 09:14:16 2022 +0200

tcp: remove goto and address another NULL deref in SACK
...

)

In any case, after updating sources to main-n256043-ce2525c8108a &
rebuilding, each of the 3 machines passed that smoke test (including
my day-to-day laptop, which was the one that had provided evidence
of a problem earlier).

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: A kernel crash after compiling a fresh kernel

[David Wolfskill]

On Tue, Jun 07, 2022 at 09:37:52PM -0400, Oleg Lelchuk wrote:
> The 14-CURRENT running a fresh kernel crashes with these messages:
> 
> __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  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401
> #2  0x80be8ba5 in dumpsys (di=0x0)
> at /usr/src/sys/x86/include/dump.h:87
> #3  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:430
> #4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537
> #5  0x80be8fee in vpanic (fmt=,
> ap=ap@entry=0xfe01042395a0) at
> /usr/src/sys/kern/kern_shutdown.c:975
> #6  0x80be8d53 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:899
> #7  0x810c0877 in trap_fatal (frame=0xfe0104239690, eva=0)
> at /usr/src/sys/amd64/amd64/trap.c:942
> #8  0x810c092b in trap_pfault (frame=0xfe0104239690,
> usermode=false, signo=, ucode=)
> at /usr/src/sys/amd64/amd64/trap.c:761
> #9  
> #10 tcp_sack_output (tp=tp@entry=0xfe0187312140,
> sack_bytes_rexmt=sack_bytes_rexmt@entry=0xfe010423983c)
> at /usr/src/sys/netinet/tcp_sack.c:970
> #11 0x80dd47a2 in tcp_default_output (tp=0xfe0187312140)
> at /usr/src/sys/netinet/tcp_output.c:310
> #12 0x80dcd240 in tcp_output (tp=tp@entry=0xfe0187312140)
> at /usr/src/sys/netinet/tcp_var.h:407
> #13 0x80dcc81a in tcp_do_segment (m=0xf80203467700,
> th=0xf8001f190022, so=0xf80015d0fb40,
> tp=0xfe0187312140,
> drop_hdrlen=64, tlen=, iptos=0 '\000')
> at /usr/src/sys/netinet/tcp_input.c:2788
> #14 0x80dc8def in tcp_input_with_port (mp=,
> offp=, proto=, port=port@entry
> =0)
> at /usr/src/sys/netinet/tcp_input.c:1397
> #15 0x80dc9c8b in tcp_input (mp=0xf8011c764010, offp=0x4,
> proto=-2128851986) at /usr/src/sys/netinet/tcp_input.c:1492
> #16 0x80db8cd7 in ip_input (m=0x0)
> at /usr/src/sys/netinet/ip_input.c:840
> #17 0x80d3842f in netisr_dispatch_src (proto=1,
> source=source@entry=0, m=0xf80203467700)
> at /usr/src/sys/net/netisr.c:1153
> #18 0x80d3878f in netisr_dispatch (proto=477511696,
> m=0x811c4bee) at /usr/src/sys/net/netisr.c:1244
> #19 0x80d1a7cc in ether_demux (ifp=ifp@entry=0xf80002873800,
> m=0x4) at /usr/src/sys/net/if_ethersubr.c:925
> #20 0x80d1be53 in ether_input_internal (ifp=0xf80002873800,
> m=0x4)
> at /usr/src/sys/net/if_ethersubr.c:711
> #21 ether_nh_input (m=) at
> /usr/src/sys/net/if_ethersubr.c:741
> #22 0x80d3842f in netisr_dispatch_src (proto=proto@entry=5,
> source=source@entry=0, m=m@entry=0xf80203467700)
> at /usr/src/sys/net/netisr.c:1153
> #23 0x80d3878f in netisr_dispatch (proto=477511696, proto@entry=5,
> m=0x811c4bee, m@entry=0xf80203467700)
> at /usr/src/sys/net/netisr.c:1244
> #24 0x80d1ac89 in ether_input (ifp=0xf80002873800,
> m=0xf80203467700) at /usr/src/sys/net/if_ethersubr.c:832
> #25 0x808f41f7 in re_rxeof (sc=sc@entry=0xfe00e1cce000,
> rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2386
> #26 0x808f1a16 in re_intr_msi (xsc=0xfe00e1cce000)
> at /usr/src/sys/dev/re/if_re.c:2682
> #27 0x80ba3d49 in intr_event_execute_handlers
> (ie=0xf800020fde00,
> p=) at /usr/src/sys/kern/kern_intr.c:1205
> #28 ithread_execute_handlers (ie=0xf800020fde00, p=)
> at /usr/src/sys/kern/kern_intr.c:1218
> #29 ithread_loop (arg=arg@entry=0xf800020fbf80)
> at /usr/src/sys/kern/kern_intr.c:1306
> #30 0x80ba03e0 in fork_exit (
> callout=0x80ba3ad0 ,
> arg=0xf800020fbf80,
> frame=0xfe0104239f40) at
> /usr/src/sys/kern/kern_fork.c:1102
> #31 

I had a ... vaguely-similar panic on one laptop, after updating sources
from main-n256013-85d7875d4291 to main-n256025-91d6afe6e2a9.  I placed
a screenshot of the backtrace at
https://www.catwhisker.org/~david/FreeBSD/head/n256025/console.jpg

The files updated were:

Updating 85d7875d4291..91d6afe6e2a9
Fast-forward
 contrib/bsddialog/lib/lib_util.c|  7 +--
 sys/arm64/arm64/identcpu.c  | 85 +
 sys/arm64/include/armreg.h  | 30 
 sys/dev/alc/if_alc.c|  5 +-
 sys/dev/hwpmc/hwpmc_logging.c   | 21 
 sys/dev/hwpmc/hwpmc_mod.c   | 17 ---
 sys/dev/iommu/iommu_gas.c   | 13 -
 sys/fs/fdescfs/fdesc_vnops.c   

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, Jun 06, 2022 at 09:46:21AM +, Filippo Moretti wrote:
>  
> Is it now safe to attempt updating current with UFS?SincerelyFilippo
> 

Yes.

Kirk committed a fix:

commit bc218d89200faa021def77732f3d9fde4f4dee13
Author: Kirk McKusick 
Date:   Tue May 31 19:55:54 2022 -0700

Two bug fixes to UFS/FFS superblock integrity checks when reading a 
superblock.

Two bugs have been reported with the UFS/FFS superblock integrity
checks that were added in commit 076002f24d35.


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 08:06:32AM -0600, Warner Losh wrote:
> ...
> > On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > > ...
> > > Does loader_4th have same issue?
> > > 
> >
> > I don't know; I hadn't tried it.  I will do so later today & report
> > back.
> >
> 
> So if it's only one system, and it's only UFS, then what does fsck of that
> UFS system tell you?

fsck reports that all is well.

> The loader can't find its UFS filesystem to read the configuration from. So
> either its having trouble
> finding the device (unlikely since that code hasn't changed in a long
> time), or its having heartburn
> with the UFS system for some reason it's being silent about (within the
> realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity
> changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.

Pretty much, yeah.  And loader's "lsdev" shows the devices, slices, and
partitions just fine.  But loaders's "ls" doesn't find /.

Toomas has recieved a "dd" image for the first 5 MB of the file system,
and has reproduced the issue in hist test environment, so I'm hoping he
will be able to figure out a bit more.  (It's at
https://www.catwhisker.org/~david/FreeBSD/head/loader/ada0s4a, in case
anyone else wants a peek.)

> Others have reported issues with GELI, but that's not in play here, If I'm
> reading this correctly. Right?

Right: no GELI for any file systems on this machine (only for swap).

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> I have not been able to use a new /boot/loader.efi (following -CURRENT)
> since 
> mid to late 2021, and your symptoms look the same; fortunately, I found
> bug 
> report 264282[0] last night, which I think is related. Yamagi has
> already done 
> the investigation, and found a possible cause. For the time being, in
> the case 
> of a GELI backed UFS mount, after GELI decrypts the mount, one has to
> manually 
> set currdev back to the correct disk.
> 
> 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282
> 

I (just) checked; after switching back to the Lua loader, the currdev
variable is set to "disk0s4a:", which is correct for my case.

Trying loader's "lsdev" command shows the expected disks, slices, and
partitions, correctly identified as FreeBSD UFS, swap, or ZFS.

Trying to (e.g.) "ls disk0s4a:" fails, saying that it can't find /.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> I have not been able to use a new /boot/loader.efi (following -CURRENT)
> since 
> mid to late 2021, and your symptoms look the same; fortunately, I found
> bug 
> report 264282[0] last night, which I think is related. Yamagi has
> already done 
> the investigation, and found a possible cause. For the time being, in
> the case 
> of a GELI backed UFS mount, after GELI decrypts the mount, one has to
> manually 
> set currdev back to the correct disk.
> 
> 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282
> 

Thanks!  I'll take a look -- though I am not using GELI-encryption on
anything needed up to the transition to multi-user mode (except for
swap).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 03:26:45AM -0700, David Wolfskill wrote:
> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ... 
> > Does loader_4th have same issue?
> > 
> 
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
> 

After updating sources from main-n255867-245b056556e to
main-n255871-7468332f551, the behavior with the Lua loader was the same:
it whined that it couldn't find /boot/lua/loader.lua, claiming "No such
file or directory" and it had not loaded anything.

I rebooted from one of the stabe/* slices and removed "loader"
and "zfsloader," then made them (hard) links to loader_4th.

On reboot, the (Forth) loader whined that it couldn't load "kernel" --
and as was the case with the Lua loader, it had not loaded anything.

So while the messages were a little different, the aspect of the
behavior that the loader was unable to load anything -- apparently
because it was unable to find anything to load -- remains quite similar,
AFAICT.

I had (as mentioned yesterday) run a manual "fsck" on the head / and
/usr file systems.  fsck asked me if I wanted to "ADD SUPERBLOCK
CHECK-HASH PROTECTION"; after a bit of dithering on my part, I told it
"yes."

I should also mention that the file systems are UFS+SU -- and not
(e.g.), UFS+SUJ.

Finally, I remind folks that I am not seeing this at all on the laptops
-- they Just Work (as usual).

Thanks again for spending time on this!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> ... 
> Does loader_4th have same issue?
> 

I don't know; I hadn't tried it.  I will do so later today & report
back.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> Sorry for top posting...
> 
> Did you upgrade your boot blocks?

Thanks for the reply!

Hmmm  Well, every time I rebuild FreeBSD head, the last step
just after "make installworld" and before the reboot is:

# gpart bootcode -b /boot/boot /dev/ada0s4

So *those* get updated.

I haven't updated from /boot/boot0 recently (and have a requirement that
whatever is in the MBR is able to boot stable/12, stable/13, and head).

Is updating (from head's /boot/bot0) recommended at this point?
> 

(And in case it wasn't obvious, I made a silly typo in the Subject; it
should have read:

| Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
|  main-n255828-18054d0220c

Sorry: I don't have loader messages showing up on serial console on that
machine at this point, so I had hand-typed it from memory and managed to
elide a letter.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

-- but only on one machine (of the 3 that I use for daily tracking head
(and stable/12 & stable/13) -- the build machine ("freebeast").

Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has
generally been functionally stable for the last couple of decades.

So for yesterday and today, I've moved the new loader aside and copied
the one from Friday, which works just fine.

The build machine ("freebeast") uses a GENERIC kernel; the other 2 are
laptops, and use a kernel that includes GENERIC, then tweaks things a
bit (e.g., dropping support for tape drives; adding IPFIREWALL and
explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).

Info on the update history & copies of stuff like most recent
(verbosely-booted) dmesg.boot should be available at
https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get
through, please send a note to d...@freebsd.org and I'll do what I can to
fix it).

(Of the 2 laptops, I only have the one that I actuaqlly use in
day-to-day work represented.)

(I note that to recover, I boot from one the stable/* slices, move the
"head" slice's files around, then reboot from the "head" slice.)

AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),
there were some changes to sys/ufs/ffs/ffs_subr.c (from
main-n255835-076002f24d35:

commit 076002f24d35962f0d21f44bfddd34ee4d7f015d
Author: Kirk McKusick 
Date:   Fri May 27 12:21:11 2022 -0700

Do comprehensive UFS/FFS superblock integrity checks when reading a 
superblock.

Historically only minimal checks were made of a superblock when it
was read in as it was assumed that fsck would have been run to...

-- which doesn't seem a likely culprit to me).

That said, I am powering freebeast up, and plan to run a manual
full fsck on the "head" slice's root file system  Maybe a few
others, while I'm here. :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: pciconf -lbvV crashes kernel main-8d72c409c

[David Wolfskill]

On Sun, Feb 06, 2022 at 12:19:59AM +, Michael Jung wrote:
> Dump header from device: /dev/ada0p2
>   Architecture: amd64
>   Architecture Version: 2
> 

As a reality check, I just tried the "pciconf -lbvV" command on my
newer laptop, which was running:

FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #84 
main-n252957-34478b73bf18: Sat Feb  5 05:22:21 PST 2022 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400051 1400051

(thus, a bit more recent than the main-n252894-8d72c409cd85 you tested);
it completed without issue.

I then fired up a newer build machine and tried the command, again without
problems.  It was running:

FreeBSD freetest.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #11 
main-n252957-34478b73bf1: Sat Feb  5 04:04:51 PST 2022 
r...@freetest.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1400051 1400051

For what it's worth.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"No person shall ... hold any office ... who, having previously taken an
oath ... to support the Constitution of the United States, shall have
engaged in insurrection or rebellion against the same" [14th amendment]

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic main-n252563-eb815a741940: Bad tailq NEXT(0xfffffe001d7a3ad8->tqh_last) != NULL

[David Wolfskill]

On Fri, Jan 21, 2022 at 04:32:56AM -0800, David Wolfskill wrote:
> This is for main-n252563-eb815a741940, after an update from yesterday's
> main-n252546-e0282802a6ec:
> 
> FreeBSD 14.0-CURRENT #401 main-n252546-e0282802a6ec: Thu Jan 20 04:15:42 PST 
> 2022 
> r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1400048 1400048
> 
> Screenshots (from each of 2 laptops) are in
> https://www.catwhisker.org/~david/FreeBSD/head/n252563/
> ... 
> I'm happy to provide more information, once I know what to provide.
> 

Reverting 9ce46cbc95d7a6fccb55af0d42cbb85c29f10639, then rebuilding the
kernel, avoids the panic on the 2nd laptop.  (I'm using the first one,
as usual.)

Ref.
https://cgit.freebsd.org/src/commit/?id=9ce46cbc95d7a6fccb55af0d42cbb85c29f10639

Given that the laptops (which use ipfw) saw the panic and the build
machine (which does not) did not, there may be a relationship.

I'm happy to test possible fixes (on the 2nd laptop).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"We can either be loyal to Donald Trump or we can be loyal to the
Constitution, but we cannot be both." - Elizabeth ("Liz") Cheney

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic main-n252563-eb815a741940: Bad tailq NEXT(0xfffffe001d7a3ad8->tqh_last) != NULL

[David Wolfskill]

This is for main-n252563-eb815a741940, after an update from yesterday's
main-n252546-e0282802a6ec:

FreeBSD 14.0-CURRENT #401 main-n252546-e0282802a6ec: Thu Jan 20 04:15:42 PST 
2022 
r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400048 1400048

Screenshots (from each of 2 laptops) are in
https://www.catwhisker.org/~david/FreeBSD/head/n252563/

The first mentions dummynet, while the second does not.  My build
machine did not see this -- but I don't run ipfw on it, either (as it
doesn't directly connect to networks I don't control).

The first laptop happened to be connected via iwn(4); the second,
via em(4).

I'm happy to provide more information, once I know what to provide.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"We can either be loyal to Donald Trump or we can be loyal to the
Constitution, but we cannot be both." - Elizabeth ("Liz") Cheney

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: latest current fails to boot.

[David Wolfskill]

On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:
> I did a git pull this morning and it fails to boot.
> I hangs at Setting hostid : 0x917bf354
> 
> This is a vm running on vmware.
> If i boot the old kernel from yesterday it boots normally.
> 
> uname -a
> FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
> main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021 
> root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
> 

I had no issues with my build machine or either of two laptops, either
from yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #358 
main-n249518-5572fda3a2f3: Tue Sep 21 05:15:22 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

or today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #359 
main-n249556-c96da1994587: Wed Sep 22 04:24:17 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

[uname strings from my main laptop shown, but I keep the machines
in sync rather aggressively.]

Perhaps the issue you are encountering involves things not in my
environment (such as VMs or ZFS)?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[David Wolfskill]

On Tue, Sep 07, 2021 at 10:13:23AM +0200, Jakob Alvermark wrote:
> ... 
> wlan0 does not associate after boot. (This is with iwm, AC 9260)
> 
> My workaround is simply 'ifconfig wlan0 up'.
> 
> After a few seconds wpa_supplicant associates and another few secods 
> later I have a DHCP IP address.
> 

I just tried that (running main-n249159-bb61ccd530b7), and that (also)
works for me -- in case that data point is of use.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[David Wolfskill]

On Sun, Sep 05, 2021 at 02:22:58PM +0100, Graham Perrin wrote:
> 
> > … I note that the subject update also included updates to
> > contrib/wpa/wpa_supplicant, as well as some files in sys/net80211,
> > but I have not started chasing that down. …
> 
> Can you share relevant lines from your /boot/loader.conf and 
> /etc/rc.conf files? They're probably not a factor, but might be of 
> interest. Thanks.

head boot/loader.conf:
g1-55(12.2-S)[2] grep -i '^[a-z]' boot/loader.conf
dumpdev="/dev/ada0s4b"
ahci_load="YES"
coretemp_load="YES"
iwn5000fw_load="YES"
cuse_load="YES"
geom_eli_load="YES"
filemon_load="YES"
kernels="kernel kernel.old kernel.save"
hint.hdaa.0.nid33.config="as=1 seq=15 device=Headphones"
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
machdep.hyperthreading_intr_allowed=1
vm.debug.divisor=4
vbe_max_resolution=1920x1080
nvidia-modeset_load="YES"

(I just checked, and the only difference between the "head" version of
the file and the "stable/13" version is a comment line.)


head etc/rc.conf relevant lines:

ifconfig_em0="DHCP"
wlans_iwn0=wlan0
ifconfig_wlan0="WPA DHCP -ht"
synchronous_dhclient="YES"

(which is the same as for stable/13)

> iwn(4) here, too, but I'm still on n248984-08b9cc316a3 
>  from around 
> eight days ago. I might update later (with a new boot environment).
> 

If you do, a reality check would almost certainly be helpful. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[David Wolfskill]

Sorry I hadn't noticed this yesterday (so I could have repported it
then), but after updating the "head" slice of my laptopp from:

FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340 
main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400032 1400032

to:

FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341 
main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021 
r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400032 1400032

I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
the WLAN LED doesn't light up.

After the update from:

FreeBSD localhost 14.0-CURRENT FreeBSD 14.0-CURRENT #341 
main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021 
r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400032 1400032

to:

FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #342 
main-n249159-bb61ccd530b7: Sun Sep  5 04:44:48 PDT 2021 
root@localhost:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 1400032 
1400032

(from this morning), that behavior remains the same.  The page
https://www.catwhisker.org/~david/FreeBSD/history/ has links to
various bits, some of which may be relevant; dmesg.boot from a
verbose boot of that laptop from this morning (after the update to
main-n249159-bb61ccd530b7) (for example) is at
https://www.catwhisker.org/~david/FreeBSD/history/laptop.14_dmesg.txt, and
shows:

...
pcib3: slot 0 INTA hardwired to IRQ 18
iwn0:  mem 0xf700-0xf7001fff irq 18 at 
device 0.0 on pci3
iwn0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 37 to local APIC 1 vector 49
iwn0: using IRQ 37 for MSI
iwn0: MIMO 3T3R, MoW, address 3c:a9:f4:ba:87:c4
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
iwn0: 2T2R
iwn0: 11na MCS 20MHz
iwn0: MCS 0-7: 6.5Mbps - 65Mbps
iwn0: MCS 8-15: 13Mbps - 130Mbps
iwn0: 11na MCS 20MHz SGI
iwn0: MCS 0-7: 7Mbps - 72Mbps
iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps
iwn0: 11na MCS 40MHz:
iwn0: MCS 0-7: 13.5Mbps - 135Mbps
iwn0: MCS 8-15: 27Mbps - 270Mbps
iwn0: 11na MCS 40MHz SGI:
iwn0: MCS 0-7: 15Mbps - 150Mbps
iwn0: MCS 8-15: 30Mbps - 300Mbps
iwn0: 11ng MCS 20MHz
iwn0: MCS 0-7: 6.5Mbps - 65Mbps
iwn0: MCS 8-15: 13Mbps - 130Mbps
iwn0: 11ng MCS 20MHz SGI
iwn0: MCS 0-7: 7Mbps - 72Mbps
iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps
iwn0: 11ng MCS 40MHz:
iwn0: MCS 0-7: 13.5Mbps - 135Mbps
iwn0: MCS 8-15: 27Mbps - 270Mbps
iwn0: 11ng MCS 40MHz SGI:
iwn0: MCS 0-7: 15Mbps - 150Mbps
iwn0: MCS 8-15: 30Mbps - 300Mbps
pcib4:  irq 19 at device 28.3 on pci0


I note that the subject update also included updates to
contrib/wpa/wpa_supplicant, as well as some files in sys/net80211,
but I have not started chasing that down.

I note that exactly the same hardware works OK in stable/12 and stable/13.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Encrypted swap partition no longer encrypted

[David Wolfskill]

On Fri, Aug 27, 2021 at 11:10:26AM +0200, Ronald Klop wrote:
> Hi,
> 
> For encrypted swap you can put ".eli" behind the device name in fstab.
> 
> So change "/dev/ada0p2" to "/dev/ada0p2.eli" in the new fstab and reboot.
> NB: after encryption is enabled the device is not available as dumpdev 
> anymore.

If one uses "sw,late" in the "Options" field of the swap fstab entry, thus:

# DeviceMountpoint  FStype  Options DumpPass#
/dev/ada0s4b.elinoneswapsw,late 0   0

I find that it permits (in this case) /dev/ada0s4b to be used for the
dumpdev, whlie using /dev/ada0s4b.eli for swap.

(This is for stable/12, stable/13, and head -- though I haven't updated
since 10 August.)

> ...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic with no keyboard after update to main-n248404-60fb9e10c74c

[David Wolfskill]

On Sun, Aug 01, 2021 at 05:03:32PM +0300, Konstantin Belousov wrote:
> On Sun, Aug 01, 2021 at 06:01:56AM -0700, David Wolfskill wrote:
> > Once I was able to complete the "make installworld" after updating
> > from main-n248391-f7f76c200a8c to main-n248404-60fb9e10c74c, the
> > subsequent reboot yielded a panic with the keyboard inoperable.
> > ... 
> 
> It seems you block my home external ip address (or country?).

I apologize: I believe that's been remedied (recently).

> Your issue with the kernel.old is that nvidia.ko was rebuilt against newer
> kernel, so it cannot be loaded together with older kernel.

OK; effectively copying the modules from /boot/modules.old to
/boot/modules got past that.  (Should loader be loding modules from
/boot/modules (vs. /boot/modules.old) if it's booting kernel.old?)

> Anyway, please update past 1a55a3a729cd4424e17308d3 _and_ apply the following
> patch:
> 
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 8599dc2fa8f6..144b4a522bcc 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1209,7 +1209,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
>* Tell the physical memory allocator about pages used to store
>* the kernel and preloaded data.  See kmem_bootstrap_free().
>*/
> - vm_phys_early_add_seg((vm_paddr_t)kernphys, trunc_page(first));
> +//   vm_phys_early_add_seg((vm_paddr_t)kernphys, trunc_page(first));
>  
>   bzero(physmap, sizeof(physmap));
>   physmap_idx = 0;
> 

OK; did that; rebuilt.  Subsequent reboot shows (copy/paste from serial
console, as this is from my headless build machine):

SMP: passed TSC synchronization test
TSC timecounter discards lower 1 bit(s)
Timecounter "TSC-low" frequency 1795879156 Hz quality 1000
KTLS: Initialized 8 threads
panic: vm_phys_free_pages: page 0xfe0f4fe8 has unexpected order 0
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82b2ead0
vpanic() at vpanic+0x187/frame 0x82b2eb30
panic() at panic+0x43/frame 0x82b2eb90
vm_phys_free_pages() at vm_phys_free_pages+0x27d/frame 0x82b2ebd0
kmem_bootstrap_free() at kmem_bootstrap_free+0xfe/frame 0x82b2ec20
preload_delete_name() at preload_delete_name+0x70/frame 0x82b2ec40
ucode_release() at ucode_release+0x8a/frame 0x82b2ec60
mi_startup() at mi_startup+0x1f0/frame 0x82b2ecb0
btext() at btext+0x22
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x127af3e(%rip)
db> 

I can leave it as-is for a bit, and poke at it (given sufficient
clues), if that might be helpful.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic with no keyboard after update to main-n248404-60fb9e10c74c

[David Wolfskill]

Once I was able to complete the "make installworld" after updating
from main-n248391-f7f76c200a8c to main-n248404-60fb9e10c74c, the
subsequent reboot yielded a panic with the keyboard inoperable.

I needed to power-cycle the laptop to get it to respond; once I did, I
tried requesting that the loader laod & boot kernel.old.  It loaded it,
with the whinie "module 'kernel' exists but with wron version" and
didn't seem to pass control to it.

Screen shots in http://www.catwhisker.org/~david/FreeBSD/head/n248404/
-- named "panic.jpg" and "kernel.old.jpg" (respectively).


I'm heading out for a couple of hours, but should be able to respond
upon my return.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: git: 99feb137f5f6 - main - `make buildworld' with time logging for each stage

[David Wolfskill]

On Sun, Aug 01, 2021 at 02:35:22PM +0200, Wolfram Schneider wrote:
> Hi David,
> 
> Thanks for the investigation. I will prepare a fix soon.

Cool; thanks.

That said, the actual reboot got a panic with the keyboard inoperable,
so there are likely other issues.  I'll try to get some information on
that up shortly.

> BTW, should we care about the error message
> 
> "sh: pkg: not found" ?

I wondered the same thing.  I suspect that (in the case of my laptop),
it's because I have at least one kernel module from ports
(x11/nvidia-driver), so I have:

PORTS_MODULES+=x11/nvidia-driver

in /etc/src.conf.

However, I have not tried adding pkg to the list of "install tools" (and
suspect that the whine about pkg has been there for a very long time).

> -Wolfram
> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: git: 99feb137f5f6 - main - `make buildworld' with time logging for each stage

[David Wolfskill]

I believe that src/Makefile.inc1 needs a tweak to add "time" to the list
of "Required install tools to be saved in a scratch dir for safety" --
something like:

diff --git a/Makefile.inc1 b/Makefile.inc1
index 3d54a088d070..213b32a97ed3 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1300,7 +1300,7 @@ _sysctl=sysctl
 ITOOLS=[ awk cap_mkdb cat chflags chmod chown cmp cp \
date echo egrep find grep id install ${_install-info} \
ln make mkdir mtree mv pwd_mkdb \
-   rm sed services_mkdb sh sort strip ${_sysctl} test true uname wc \
+   rm sed services_mkdb sh sort strip ${_sysctl} test time true uname wc \
${_zoneinfo} ${LOCAL_ITOOLS}
 
 # Needed for share/man


Because when I tried to update from main-n248391-f7f76c200a8c to
main-n248404-60fb9e10c74c, I saw:

...
===> etc (install)
===> etc/sendmail (install)
cd /usr/src/share/man; make makedb
makewhatis /usr/share/man
makewhatis /usr/share/openssl/man
cd /usr/src; make -f Makefile.inc1 install32
sh: pkg: not found
cd /usr/src/lib; time env MACHINE_CPU="i686 mmx sse sse2" MACHINE=i386 
MACHINE_ARCH=i386 
PATH=/common/S4/obj/usr/src/amd64.amd64/tmp/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/common/S4/obj/usr/src/amd64.amd64/tmp/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/tmp/install.Z8rMzNyp
 SYSROOT=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp LIBDIR=/usr/lib32 
SHLIBDIR=/usr/lib32 DTRACE="dtrace" make AS="as --32" LD="ld -m elf_i386_fbsd" 
NM="nm" OBJCOPY="objcopy" -DCOMPAT_32BIT CC="cc -target 
x86_64-unknown-freebsd14.0 --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32  
--sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp  
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin 
-B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" CXX="c++  -target 
x86_64-unknown-freebsd14.0 --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32  
--sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp  
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin 
-B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" CPP="cpp -target 
x86_64-unknown-freebsd14.0 --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32  
--sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp  
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin 
-B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" -DNO_CPU_CFLAGS 
MK_CTF=no -DNO_LINT MK_TESTS=no 
OBJTOP=/common/S4/obj/usr/src/amd64.amd64/obj-lib32 OBJROOT='${OBJTOP}/' 
MAKEOBJDIRPREFIX= MK_MAN=no MK_HTML=no-DLIBRARIES_ONLY install
/tmp/install.Z8rMzNyp/sh: time: not found
*** Error code 127

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
  149.85 real65.62 user35.05 sys
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Command exit status: 1
Script done on Sun Aug  1 05:17:29 2021


Making the above change, then re-running the "make installworld" has worked.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Wake from sleep with nvidia-modeset

[David Wolfskill]

On Thu, Jul 29, 2021 at 06:15:19PM +0100, Graham Perrin wrote:
> nvidia-driver-460.84 from ports, nvidia-modeset, NVIDIA Quadro K1100M 
> (GK107GLM), HP ZBook 17 G2, KDE Plasma.
> 
> 
> 
> An initial wake from sleep was almost entirely successful, one exception:
> 
> * title bars of windows lacked colour.
> 
> Since then: all sleeps succeed, however I can never wake the computer. 
> There's an (immediate) dimly lit screen but nothing visible, and no 
> response to keyboard or trackpad input. It's necessary to force off the 
> computer.
> 
> I experimented with nvidia-driver-390-390.144, no better.
> 
> Any other suggestions?
> 
> I'd _love_ it to work, and the one near-success makes me believe that 
> it's possible.

I presume (since this is to current@) that you are workiing with head
(FreeBSD 14).

My older laptop is also using nvidia-modest from nvidia-driver-460.84;
hardware is NVIDIA GPU Quadro K2100M (GK106GL) (on a Dell PRecision
M4800).

Suspend/resume almost always works while running stable/12, tested most
recently running:

FreeBSD 12.2-STABLE #1099 stable/12-n233460-ac56cd3ba62: Tue Jul 27 03:32:24 
PDT 2021 
r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1202508 1202508

but last I checked, resume fails for stable/13 and head (I track
each of the 3 daily).

One possibly-salient difference is that I had been running with

kern.vty="sc"

(and still do, for stable/12), but since the VBE changes earlier
this year, I let kern.vty take the default value (which I am not
recalling at the moment) for stable/13 and head.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

wpa_supplicant: SIGBUS after main-n247052-d40cd26a86a7 -> main-n247092-ec7b47fc81b2

[David Wolfskill]

Reading symbols from 
/usr/obj/usr/src/amd64.amd64/usr.sbin/wpa/wpa_supplicant/wpa_supplicant...
(No debugging symbols found in 
/usr/obj/usr/src/amd64.amd64/usr.sbin/wpa/wpa_supplicant/wpa_supplicant)
[New LWP 100168]
Core was generated by `/usr/sbin/wpa_supplicant -s -B -i wlan0 -c 
/etc/wpa_supplicant.conf -D bsd -P /v'.
Program terminated with signal SIGBUS, Bus error.
--Type  for more, q to quit, c to continue without paging--
#0  0x010fb34f in wpa_sm_rx_eapol ()
(gdb) bt
#0  0x010fb34f in wpa_sm_rx_eapol ()
#1  0x010f3afe in l2_packet_receive ()
#2  0x01122ef3 in eloop_run ()
#3  0x010b44a8 in wpa_supplicant_run ()
#4  0x0109fdec in main ()
(gdb) 

wlan0 is an iwn(4) device, in this case.  Not yet sure how reproducible
this is, but wpa_supplicant's issue(s) do not (yet) seem to prevent the
machine from using teh network (as I'm typing on the laptop's keyboard
to write this).

uname strings: yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #258 
main-n247052-d40cd26a86a7: Mon May 31 05:48:18 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400018 1400018

today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #259 
main-n247092-ec7b47fc81b2: Tue Jun  1 04:49:26 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400018 1400018

(Though the laptop did just lose connectivity; checking /var/log/messages:

<6>1 2021-06-01T12:06:15.336865+00:00 g1-55.catwhisker.org kernel - - - wlan0: 
link state changed to DOWN
<2>1 2021-06-01T12:09:26.811751+00:00 g1-55.catwhisker.org kernel - - - 
if_delmulti_locked: detaching ifnet instance 0xf800126d6800
<2>1 2021-06-01T12:09:26.811773+00:00 g1-55.catwhisker.org syslogd - - - last 
message repeated 5 times
<6>1 2021-06-01T12:09:26.811774+00:00 g1-55.catwhisker.org kernel - - - lo0: 
link state changed to DOWN
<27>1 2021-06-01T12:09:27.317032+00:00 g1-55.catwhisker.org dhclient 441 - - My 
address (172.17.1.55) was deleted, dhclient exiting
<2>1 2021-06-01T12:09:27.317474+00:00 g1-55.catwhisker.org kernel - - - 
if_delmulti_locked: detaching ifnet instance 0xf800129a1800

I tried "sudo service netif restart" and that brought the connection back
(for now, anyway).

As the laptop is a machine that I connect to networks I do not
control, it uses packet filtering (ipfw, which I've been using since
Whistle Communications, ca. 1998).

The build typescript will be up at
https://www.catwhisker.org/~david/FreeBSD/history/laptop.14_build_typescript.txt
shortly.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claiming that Donald Trump won the 2020 election is the opposite of
patriotism.  Make of that what you will.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build fails with Filesize limit exceeded

[David Wolfskill]

On Fri, May 28, 2021 at 01:11:06PM +0200, Jakob Alvermark wrote:
> Hi,
> 
> 
> Building -current fails like this:
> 
> --- kerberos5/lib/libasn1__L ---
> Building 
> /usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/asn1_kx509_asn1.x
> Building 
> /usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/asn1_rfc2459_asn1.c
> Building /usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/rfc2459_asn1.h
> Building 
> /usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/rfc2459_asn1-priv.h
> --- rfc2459_asn1-priv.h ---
> Filesize limit exceeded
> *** [rfc2459_asn1-priv.h] Error code 153
> make[4]: *** rfc2459_asn1-priv.h removed
> 
> make[4]: stopped in /usr/src/kerberos5/lib/libasn1
> .ERROR_TARGET='rfc2459_asn1-priv.h'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/rfc2459_asn1-priv.h.meta'
> .MAKE.LEVEL='4'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='cp -f rfc2459_asn1-priv.hx rfc2459_asn1-priv.h;'
> .CURDIR='/usr/src/kerberos5/lib/libasn1'
> ...
> 
> make: stopped in /usr/src
> 
> 
> 
> I have tried clearing /usr/obj and restarting the build. I does not help.
> 
> I checked out c235059bb7e, which is what I'm currently running, but 
> that's not building either, same error, which I find strange since I 
> obviously build it before.
> 
> What's going on here?
> 

Not sure; I don't see that, and I just finished doing in-place source
updates from main-n246951-38e7025a60b2 to main-n246995-c0f171736a70 on 3
machines without issue -- also using META_MODE, as you are.

You might want to see if that .ERROR_META_FILE has any useful hints in
it.

FWIW, looks as if c235059bb7e corresponds to main-n246842-c235059bb7e6;
checking my update history, I updated from main-n246829-42881526d401 to
main-n246861-ef0f7ae934b0 last Sunday (23 May).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"...the canard that the election was stolen is being repeated daily
on major news outlets ... not to mention in the near-daily fulminations
of the former President." - Federal Judge Amy Berman Jackson

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic: device_unbusy: called for non-busy device iichid0

[David Wolfskill]

This was on the new(er) laptop with which I have been experimenting; it
uses iichid to controll/access the built-in mouse/touchpad.

The machine was running:

FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #252 
main-n246951-38e7025a60b2: Wed May 26 04:56:25 PDT 2021 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400017 1400017

at the time.  Note that the reboot after building the above (yesterday)
was without issue, and the reboot after the panic was also without issue
-- so this would seem to have elements of timing/racing involved.  (And
it's likely to be distinctly unpleasant to debug, as it seems that
reproduction may be rather "iffy.")

I took a photo of the displayed backtrace; it's at
https://www.catwhisker.org/~david/FreeBSD/head/n246951/device_unbusy.jpg

Here's a slightly-abbreviated hand-transcribed version:

panic: device_unbusy: called for non-busy device iichid0
cpuid = 8
time = 1622113818
KDB: stack backtrace:
db_trace_self_wrapper()
vpanic()
panic()
device_unbusy()
iicbus_release_bus()
iichid_intr()
ithread-loop()
fork_exit()
fork_trampoline()
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 12 tid 100170 ]
Stopped at  0x80c36867 = kdb_enter+ 0x37:$0,0x12a0b9e(%rip)
db> 


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Republican Congressional leaders are giving support to those who took up
arms against the government of the United States on 06 January 2021.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build fail updating from n246398-388c0cde1029 -> n246413-c78ad207baed

[David Wolfskill]

Per the ERROR_META_FILE:

# Meta data file /common/S4/obj/usr/src/amd64.amd64/sbin/sysctl/sysctl.o.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   -fPIE 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/sbin/sysctl/sysctl.c -o sysctl.o
CMD 
CWD /common/S4/obj/usr/src/amd64.amd64/sbin/sysctl
TARGET sysctl.o
-- command output --
/usr/src/sbin/sysctl/sysctl.c:798:32: error: format specifies type 'void *' but 
the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
(uintmax_t)map->md_phys, map->md_virt,
 ^~~~
1 error generated.

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 94559
# Start 1619869639.590308
V 5
E 94581 /bin/sh
R 94581 /etc/libmap.conf
R 94581 /var/run/ld-elf.so.hints
R 94581 /lib/libedit.so.8
R 94581 /lib/libc.so.7
R 94581 /lib/libncursesw.so.9
R 94581 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 94581 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 94581 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 94581 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 94581 /usr/share/locale/en_US.UTF-8/LC_TIME
R 94581 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 94581 94587
E 94587 /usr/bin/cc
R 94587 /etc/libmap.conf
R 94587 /var/run/ld-elf.so.hints
R 94587 /lib/libz.so.6
R 94587 /usr/lib/libexecinfo.so.1
R 94587 /lib/libncursesw.so.9
R 94587 /lib/libthr.so.3
R 94587 /usr/lib/libc++.so.1
R 94587 /lib/libcxxrt.so.1
R 94587 /lib/libm.so.5
R 94587 /lib/libc.so.7
R 94587 /lib/libelf.so.2
R 94587 /lib/libgcc_s.so.1
R 94587 /usr/src/sbin/sysctl/sysctl.c
R 94587 sysctl-a47e0ae5.o.tmp
W 94587 sysctl-a47e0ae5.o.tmp
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/cdefs.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/param.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_null.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_pthreadtypes.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_stdint.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/select.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_sigset.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_timeval.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/timespec.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_timespec.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/syslimits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/param.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_align.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_align.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/xlocale/_time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/resource.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/stat.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/sysctl.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/vmmeter.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/dev/evdev/input.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ioccom.h
R 94587 
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/dev/evdev/input-event-codes.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/s

Re: DHCP no longer working for em(4)

[David Wolfskill]

On Tue, Apr 27, 2021 at 12:19:32PM +0100, Graham Perrin wrote:
> DHCP recently stopped working for em0.
> 
> HP EliteBook 8570p, recently probed:
> 
> 
> Any ideas?
> 
> For what its worth, the problem _might_ have begun after a package 
> upgrade routine on Tuesday 20th April:
> 
> 
> 
> I updated the sytem (from n246123-21afed4b1d1 to n246330-5eb9c93a20d), 
> no improvement.

I am not seeing the issue.

In addition to my older laptop, I have been tracking head. stable/13,
and stable/12 on a newer laptop (a Dell Precision 7520); as its wireless
NIC is not currently supported in FreeBSD, I have been using its wired
NIC:

em0@pci0:0:31:6:class=0x02 rev=0x31 hdr=0x00 vendor=0x8086 
device=0x15e3 subvendor=0x1028 subdevice=0x07b0
vendor = 'Intel Corporation'
device = 'Ethernet Connection (5) I219-LM'
class  = network
subclass   = ethernet

g1-48(14.0-C)[2] ifconfig em0
em0: flags=8863 metric 0 mtu 1500

options=481249b
ether 8c:ec:4b:e9:91:81
inet 172.17.1.48 netmask 0x broadcast 172.17.255.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29
g1-48(14.0-C)[3] 

As I type, it is running:

g1-48(14.0-C)[3] uname -aUK
FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #222 
main-n246319-cd17774d30c6: Mon Apr 26 03:54:11 PDT 2021 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400010 1400010

and in the middle of a source update to main-n246349-daa5350d0e0c.


> /etc/rc.conf
> 
> – includes the following lines:
> 
> ifconfig_em0="DHCP"
> create_args_wlan0="country GB regdomain etsi"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="NOAUTO WPA SYNCDHCP"

g1-48(14.0-C)[7] egrep 'ifconfig|wlan' /etc/rc.conf | grep -v '^#'
ifconfig_em0="DHCP"
wlans_iwn0=wlan0
ifconfig_wlan0="WPA DHCP -ht"
netif_nic_seq="wlan0 em0"   # Try these NICs in this sequence,
g1-48(14.0-C)[8] 

>  

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The same folks who champion the "rights" of corporations to influence
elections by money (as an exercise of free speech) are now also decrying
corporations' speaking out against voter suppression laws...?  Right.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"etcupdate -p" vs. $OLDTREE?

[David Wolfskill]

After the set of updates to etcupdate (main-n246232-0611aec3cf3a ..
main-n246235-ba30215ae0ef), I find that "etcupdate -B -p" is working as
expected, but after the following "make installworld", a subsequent
"etcupdate -B" chugs along for a bit, then stops, whining:

No previous tree to compare against, a sane comparison is not possible.

and inspection of the $WORKDIR before:

freebeast(14.0-C)[1] ls -lT /var/db/s4/etcupdate/
total 260
-rw-r--r--  1 root  wheel   0 Apr 22 05:17:54 2021 added.files
-rw-r--r--  1 root  wheel8556 Apr 22 05:17:54 2021 both.files
drwxr-xr-x  2 root  wheel 512 Apr 22 05:17:54 2021 conflicts
drwxr-xr-x  7 root  wheel 512 Apr 22 05:17:54 2021 current
-rw-r--r--  1 root  wheel  212793 Apr 22 05:17:54 2021 log
-rw-r--r--  1 root  wheel8556 Apr 22 05:17:54 2021 new.files
drwxr-xr-x  7 root  wheel 512 Apr 22 05:15:33 2021 old
-rw-r--r--  1 root  wheel8556 Apr 22 05:17:54 2021 old.files
drwxr-xr-x  4 root  wheel 512 Apr 22 04:03:20 2021 preworld
-rw-r--r--  1 root  wheel   0 Apr 22 05:17:54 2021 removed.files

and after (the "make installworld"):

freebeast(14.0-C)[2] ls -lT /var/db/s4/etcupdate/
total 36
-rw-r--r--  1 root  wheel 0 Apr 23 03:53:41 2021 added.files
-rw-r--r--  1 root  wheel36 Apr 23 03:53:41 2021 both.files
drwxr-xr-x  2 root  wheel   512 Apr 23 03:53:41 2021 conflicts
-rw-r--r--  1 root  wheel   198 Apr 23 03:53:41 2021 log
-rw-r--r--  1 root  wheel36 Apr 23 03:53:41 2021 new.files
drwxr-xr-x  7 root  wheel   512 Apr 22 05:15:33 2021 old
-rw-r--r--  1 root  wheel  8556 Apr 23 03:53:41 2021 old.files
drwxr-xr-x  5 root  wheel   512 Apr 23 03:53:41 2021 preworld
-rw-r--r--  1 root  wheel 0 Apr 23 03:53:41 2021 removed.files

shows the lack of a "current" subdirectory.

After invoking "etcupdate extract", then "etcupdate -B":

freebeast(14.0-C)[3] ls -lT /var/db/s4/etcupdate/
total 260
-rw-r--r--  1 root  wheel   0 Apr 23 03:58:59 2021 added.files
-rw-r--r--  1 root  wheel8556 Apr 23 03:58:59 2021 both.files
drwxr-xr-x  2 root  wheel 512 Apr 23 03:58:59 2021 conflicts
drwxr-xr-x  7 root  wheel 512 Apr 23 03:58:59 2021 current
-rw-r--r--  1 root  wheel  212793 Apr 23 03:59:00 2021 log
-rw-r--r--  1 root  wheel8556 Apr 23 03:58:59 2021 new.files
drwxr-xr-x  7 root  wheel 512 Apr 23 03:57:58 2021 old
-rw-r--r--  1 root  wheel8556 Apr 23 03:58:59 2021 old.files
drwxr-xr-x  5 root  wheel 512 Apr 23 03:53:41 2021 preworld
-rw-r--r--  1 root  wheel   0 Apr 23 03:58:59 2021 removed.files


Am I missing something?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The same folks who champion the "rights" of corporations to influence
elections by money (as an exercise of free speech) are now also decrying
corporations' speaking out against voter suppression laws...?  Right.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

On Wed, Mar 17, 2021 at 02:11:48PM +0100, Gary Jennejohn wrote:
> ...
> Well, I have obj under my home directory and do all my builds as a
> normal user rather than as root.  I suspect that's why it always fails
> for me.  Root owns /usr/src and /usr/ports.

Hmm... I won't claim a causal relationship, but note that our approaches
differ.  And a bit of variety is a Good Thing. :-)

In my case, I own /usr/src, but do the builds as root (via "sudo").  The
owner for ports is the user I set up to maintain my repository mirrors;
I update installed ports (or install/delete ports) as root.

> But I don't rebuild the driver until the kldload fails at boot time. 
> I'd guess that > 90% of kernel changes do not impact the driver's
> functionality.

Probably, though that number is likely higher in head than in one of the
stable/* branches.  And the driver itself gets an update on occasion.

> -- 
> Gary Jennejohn

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

On Wed, Mar 17, 2021 at 01:18:37PM +0100, Gary Jennejohn wrote:
> On Wed, 17 Mar 2021 05:08:50 -0700
> David Wolfskill  wrote:
> ... 
> > Indeed, it appears that the n245494-6827435548d2 change was intended to
> > fix the issue that I am now just seeing.
> >  ...
> > So...  help?  What do I need to do to be able to build the kernel now?
> > 
> > (E.g., if I need to just skip building x11/nvidia-driver once, get
> > everything installed, then build "normally" (with x11/nvidia-driver)
> > -- that's fine; I just need a clue.)
> > 
> 
> For me trying to build nvidia-driver along with the kernel always fails
> miserably.

Huh.  That has not been my experience: I have

PORTS_MODULES+=x11/nvidia-driver

in /etc/src.conf, and it almost always Just Works.  (I'm tracking head,
stable/12, and (now) stable/13 daily, so that's quite a number of
build/installs.)

> My tree is at 096a8472167..c96151d3350  main.
> 
> Building the kernel on its own followed by building nvidia-driver in
> the ports tree worked for me with no problems (but I didn't install
> either one of them yet).
> 

I did go ahead and comment out the above-quoted /etc/src.conf line,
re-started hte build/install (which worked without incident).

I have restored the

PORTS_MODULES+=x11/nvidia-driver

line in /etc/src.conf, and I'm rebuilding again.

I suspect that I could merely have copied (installed) the updated
share/mk/* files... but it's my perception that there are some exposed
sharp edges there. :-}

OK; the rebuild that includes x11/nvidia-driver appears to have
succeeded, so that appears to be *a* way to address it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

My laptop is currently running main-n245489-15b82e00a164; after updating
sources to n245498-096a84721670, I am performing a source-based update.

A simialr update on my build machine (which is headless, and thus does
not use anything related to X11) was successful.

The laptop is set up to rebuild x11/nvidia-driver when the kernel
is updated.

The buildkernel step on it fails with:

...
awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | xargs 
-J% objcopy % nvidia-modeset.ko
===> lib (all)
===> lib/libglvnd (all)
...
===> x11/driver (all)
===> x11/extension (all)
===> doc (all)
make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
*** Error code 1

Stop.


On reviewing the list of files changed in 15b82e00a164..096a84721670, I
note a couple of promising-looking candidates:

 share/mk/bsd.opts.mk|   1 +
 share/mk/src.opts.mk|   1 -

Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
recent entry is:

| commit 6827435548d257c672f934db5c6ff01012d96995
| Author: Jung-uk Kim 
| Date:   Tue Mar 16 14:16:10 2021 -0400
| 
| pkgbase: Fix building out-of-tree manual pages
| 
| c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
| building out-of-tree manual pages.  For example, x11/nvidia-driver fails
| with the following error:
| 
| ===> doc (all)
| make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")
| make[3]: Fatal errors encountered -- cannot continue
| 
| Move the definition from src.opts.mk to bsd.opts.mk to make it visible.

which looks ... apropos.

Indeed, it appears that the n245494-6827435548d2 change was intended to
fix the issue that I am now just seeing.

But I readily confess that I have neither familairity nor expertise
with share/mk/* (and that delving into it reminds me of "You are
in a mazy twist of passages, all different")

So...  help?  What do I need to do to be able to build the kernel now?

(E.g., if I need to just skip building x11/nvidia-driver once, get
everything installed, then build "normally" (with x11/nvidia-driver)
-- that's fine; I just need a clue.)

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Recent if_wg work: Should DIAGNOSTIC imply KASSERT is available?

[David Wolfskill]

On Mon, Mar 15, 2021 at 07:36:51AM -0500, Kyle Evans wrote:
> On Mon, Mar 15, 2021 at 6:20 AM David Wolfskill  wrote:
> ...
> > So: Is DIAGNOSTIC intended to necessarily imply that KASSERT is
> > available for use?
> >
> 
> This is fixed in ff92a03616c5, thanks for the report!
> 
> Kyle Evans
> 

Ah, cool -- I wasn't sure if I may have been doing something ... kinda
dumb (again). :-}

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Recent if_wg work: Should DIAGNOSTIC imply KASSERT is available?

[David Wolfskill]

For my laptop, the kernel config includes GENERIC, does not have

options   INVARIANTS

but does have

options DIAGNOSTIC

which has not been a problem until today.

In src/sys/dev/if_wg/wg_noise.c, as of main-n245465-16b2290447de, I see:

...
778 static void
779 noise_kdf(uint8_t *a, uint8_t *b, uint8_t *c, const uint8_t *x,
780 size_t a_len, size_t b_len, size_t c_len, size_t x_len,
781 const uint8_t ck[NOISE_HASH_LEN])
782 {
783 uint8_t out[BLAKE2S_HASH_SIZE + 1];
784 uint8_t sec[BLAKE2S_HASH_SIZE];
785 
786 #ifdef DIAGNOSTIC
787 KASSERT(a_len <= BLAKE2S_HASH_SIZE && b_len <= 
BLAKE2S_HASH_SIZE787  &&
788 c_len <= BLAKE2S_HASH_SIZE);
789 KASSERT(!(b || b_len || c || c_len) || (a && a_len));
790 KASSERT(!(c || c_len) || (b && b_len));
791 #endif
792 


which the compiler helpfully pointed out to me attempts to use KASSERT
without having it defined.

So: Is DIAGNOSTIC intended to necessarily imply that KASSERT is
available for use?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)

[David Wolfskill]

On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote:
> Turns out, EFI boot stopped working. The following boots but fails with
> ... 
> umass0:  SCSI over Bulk-Only; quirks = 0x4001
> umass0:6:0: Attached to scbus6
> Root mount waiting for: usbus5 CAM
> panic: malloc(M_WAITOK) with sleeping prohibited
> cpuid = 0
> time = 4
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe0081dcf5f0
> vpanic() at vpanic+0x181/frame 0xfe0081dcf640
> panic() at panic+0x43/frame 0xfe0081dcf6a0
> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0
> malloc() at malloc+0x34/frame 0xfe0081dcf720
> disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740
> daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0
> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90
> daasync() at daasync+0x2c2/frame 0xfe0081dcfb00
> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame
> 0xfe0081dcfb50
> xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60
> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0
> xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0
> fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> 

You may find the change that's in https://reviews.freebsd.org/D29210
helps -- the trace looks similar to what I saw, and it has worked for
me.

Note that I only saw the panic while running a kernel with INVARIANTS.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Wed, Mar 10, 2021 at 08:25:00AM -0700, Warner Losh wrote:
> ...
> > Also (as yesterday), neither laptop exhibited a problem after the
> > corresponding update.
> >
> 
> Yes it "works" without invariants. I'm working on a better fix that isn't
> such a huge game of whack-a-mole that defers the async messages to an
> taskqueue where they can sleep for memory, if need be.
> 

Fair enough -- we see that ("works" without INVARIANTS option) often
enough at work. :-}

I'm happy to test

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"So much money is being raised and completely wasted by people that do not
have the GOP's best interests in mind." - D. Trump, who would know firsthand.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote:
> On Tue, Mar 9, 2021 at 2:46 PM David Wolfskill  wrote:
> ...
> > uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2
> >  with the following non-sleepable locks held:
> > umass0:  on usbus0
> > exclusive sleep mutex CAM device lockumass0:  SCSI over Bulk-Only; quirks
> > = 0x4000
> >  (CAM device lock) r = 0 (0xf800122c9cd0) locked @
> > /usr/src/sys/cam/cam_xpt.c:2333
> > umass0:6:0: Attached to scbus6
> > stack backtrace:
> > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
> > #0 0x80c7cce1 at witnesuhub3: 6 ports with 6 removable, self
> > powered
> > s_debugger+0x71
> > pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0
> > #1 0x80pass6: uhub4: 8 ports with 8 removable, self powered
> > c7ddfd at witness_warn+0x40d
> > #2 Removable Direct Access SCSI device
> >  0x80f42fe6 at uma_zallpass6: Serial Number 2010081884130
> > oc_arg+0x46
> > #3 0x80be34pass6: 40.000MB/s transfers
> > panic: malloc(M_WAITOK) with sleeping prohibited
> > cpuid = 1
> > time = 22
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe00e157a2d0
> > vpanic() at vpanic+0x181/frame 0xfe00e157a320
> > panic() at panic+0x43/frame 0xfe00e157a380
> > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e157a3a0
> > malloc() at malloc+0x34/frame 0xfe00e157a400
> > g_post_event_x() at g_post_event_x+0x5a/frame 0xfe00e157a450
> > g_post_event() at g_post_event+0x48/frame 0xfe00e157a4b0
> > disk_create() at disk_create+0x16f/frame 0xfe00e157a600
> > daregister() at daregister+0x70a/frame 0xfe00e157a880
> > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe00e157a950
> > daasync() at daasync+0x2c2/frame 0xfe00e157a9c0
> > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame
> > 0xfe00e157aa10
> > xpt_async_process() at xpt_async_process+0x334/frame 0xfe00e157ab20
> > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe00e157ab60
> > xpt_done_td() at xpt_done_td+0xf5/frame 0xfe00e157abb0
> > fork_exit() at fork_exit+0x80/frame 0xfe00e157abf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e157abf0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > KDB: enter: panic
> > [ thread pid 17 tid 100095 ]
> > Stopped at  kdb_enter+0x37: movq$0,0x128b8ce(%rip)
> > db>
> >
> I'm willing to "poke at it" a bit, given a hint or two...
> >
> 
> OK. I know what's happening here. disk_create() posts an event and also
> expects to sleep to get memory. I can fix that too, but then that's one
> more 'no memory' hole.
> 
> I'm unsure if we should keep playing whack-a-mole, or just defer this
> creation to the taskqueue we already have hanging around...
> 
> Warner
> 

Same (build) machine had a similar panic after updating source to
main-n245372-d1cbe7908986 & rebuilding.  FWIW.

Also (as yesterday), neither laptop exhibited a problem after the
corresponding update.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote:
> ...
> > The build nmachine (still?) panics:
> > ...
> I'm willing to "poke at it" a bit, given a hint or two...
> 
> OK. I know what's happening here. disk_create() posts an event and also
> expects to sleep to get memory. I can fix that too, but then that's one
> more 'no memory' hole.
> 
> I'm unsure if we should keep playing whack-a-mole, or just defer this
> creation to the taskqueue we already have hanging around...
> 
> Warner

?  I'll need to get the "head" slice for my build machine in a
usable state soonish (within a few hours); at this point, it's looking
as if using yesterday's kernel is my best bet.

If here's something more useful I can do within the "within a few hours"
time constraint, I'm game.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Tue, Mar 09, 2021 at 01:23:16PM -0800, David Wolfskill wrote:
> On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote:
> > ...
> > The following reviews should fix this. It introduces a no-wait variant for
> > disk_alloc(), provides a way to free allocated, but not created, disks  and
> > changes CAM to use the new routines and take some care for not leaking when
> > an allocation fails.
> > 
> > https://reviews.freebsd.org/D29161
> > https://reviews.freebsd.org/D29162
> > https://reviews.freebsd.org/D29163
> > 
> > Maybe you can try it? I got similar tracebacks when I booted w/o these
> > changes, but not a peep with them...
> > ...
> 
> Thanks!
> 
> They applied cleanly; building now --  both on the build machine (which
> failed earlier) and on the newer laptop (which did not fail earlier, as
> it's good to find out if a change has broken somehing that had been
> working).
> 

The laptop still works:

FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #169 
main-n245338-221622ec0c8e-dirty: Mon Mar  8 03:50:50 PST 2021 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
145 145

FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 
main-n245363-b3dac3913dc9-dirty: Tue Mar  9 05:06:34 PST 2021 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
145 145

FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 
main-n245363-b3dac3913dc9-dirty: Tue Mar  9 05:06:34 PST 2021 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
145 145


The build nmachine (still?) panics:

...
pass3: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
pass3: Command Queueing enabled
pass4 at ahcich4 bus 0 scbus4 target 0 lun 0
pass4:  ACS-2 ATA SATA 3.x device
pass4: Serial Number 1242091982C2
pass4: 600.000MB/s transfers (SATA 3.x, ugen2.2:  
at usbus2
UDMA5, PIO 8192bytes)
pass4: Command Queueing enabled
uhub4 on uhub1
pass5 at ahciem0 bus 0 scbus5 target 0 lun 0
uhub4:  on 
usbus2
Root mount waiting for:pass5:  usbus0 usbus1 
usbus2ugen0.2:  at usbus0
 CAM SEMB S-E-S 2.00 device

uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2
 with the following non-sleepable locks held:
umass0:  on usbus0
exclusive sleep mutex CAM device lockumass0:  SCSI over Bulk-Only; quirks = 
0x4000
 (CAM device lock) r = 0 (0xf800122c9cd0) locked @ 
/usr/src/sys/cam/cam_xpt.c:2333
umass0:6:0: Attached to scbus6
stack backtrace:
(probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
#0 0x80c7cce1 at witnesuhub3: 6 ports with 6 removable, self powered
s_debugger+0x71
pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0
#1 0x80pass6: uhub4: 8 ports with 8 removable, self powered
c7ddfd at witness_warn+0x40d
#2 Removable Direct Access SCSI device
 0x80f42fe6 at uma_zallpass6: Serial Number 2010081884130
oc_arg+0x46
#3 0x80be34pass6: 40.000MB/s transfers
panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 1
time = 22
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e157a2d0
vpanic() at vpanic+0x181/frame 0xfe00e157a320
panic() at panic+0x43/frame 0xfe00e157a380
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e157a3a0
malloc() at malloc+0x34/frame 0xfe00e157a400
g_post_event_x() at g_post_event_x+0x5a/frame 0xfe00e157a450
g_post_event() at g_post_event+0x48/frame 0xfe00e157a4b0
disk_create() at disk_create+0x16f/frame 0xfe00e157a600
daregister() at daregister+0x70a/frame 0xfe00e157a880
cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe00e157a950
daasync() at daasync+0x2c2/frame 0xfe00e157a9c0
xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfe00e157aa10
xpt_async_process() at xpt_async_process+0x334/frame 0xfe00e157ab20
xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe00e157ab60
xpt_done_td() at xpt_done_td+0xf5/frame 0xfe00e157abb0
fork_exit() at fork_exit+0x80/frame 0xfe00e157abf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e157abf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 17 tid 100095 ]
Stopped at  kdb_enter+0x37: movq$0,0x128b8ce(%rip)
db> 

I'm willing to "poke at it" a bit, given a hint or two...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote:
> ...
> The following reviews should fix this. It introduces a no-wait variant for
> disk_alloc(), provides a way to free allocated, but not created, disks  and
> changes CAM to use the new routines and take some care for not leaking when
> an allocation fails.
> 
> https://reviews.freebsd.org/D29161
> https://reviews.freebsd.org/D29162
> https://reviews.freebsd.org/D29163
> 
> Maybe you can try it? I got similar tracebacks when I booted w/o these
> changes, but not a peep with them...
> ...

Thanks!

They applied cleanly; building now --  both on the build machine (which
failed earlier) and on the newer laptop (which did not fail earlier, as
it's good to find out if a change has broken somehing that had been
working).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

On Tue, Mar 09, 2021 at 04:09:18AM -0800, David Wolfskill wrote:
> ...
> I can afford to leave it that way for a bit, in case anyone has
> suggestions for poking at it to get more information.  I expect to
> be attempting the same upgrade on a couple of laptops -- after they
> finish building firefox.
> 
Neither laptop reported an issue -- each came up to multi-user mode just
fine;' e.g.:

Yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #174 
main-n245338-221622ec0c8e-dirty: Mon Mar  8 03:52:29 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
145 145

today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #175 
main-n245363-b3dac3913dc9-dirty: Tue Mar  9 05:08:07 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
145 145

The build machine's most recent dmesg (from yesterday's verbose
boot of head) is at
https://www.catwhisker.org/~david/FreeBSD/history/freebeast.14_dmesg.txt


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

[David Wolfskill]

Just did a source-based  update from:

FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar  8 03:49:58 PST 
2021 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 145 145

to:

FreeBSD 14.0-CURRENT #1206 main-n245363-b3dac3913dc9: Tue Mar  9 03:55:00 PST 
2021

r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

[latter scraped from the console]

and:

...
pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0
pass6: uhub3: 6 ports with 6 removable, self powered
 Removable Direct Access SCSI device
pass6: Serial Number 2010081884130
pass6: 40.000MB/s transfersuhub4: 8 ports with 8 removable, self powered

panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 0
time = 22
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e157a4b0
vpanic() at vpanic+0x181/frame 0xfe00e157a500
panic() at panic+0x43/frame 0xfe00e157a560
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e157a580
malloc() at malloc+0x34/frame 0xfe00e157a5e0
disk_alloc() at disk_alloc+0x1c/frame 0xfe00e157a600
daregister() at daregister+0x3f4/frame 0xfe00e157a880
cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe00e157a950
daasync() at daasync+0x2c2/frame 0xfe00e157a9c0
xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfe00e157aa10
xpt_async_process() at xpt_async_process+0x334/frame 0xfe00e157ab20
xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe00e157ab60
xpt_done_td() at xpt_done_td+0xf5/frame 0xfe00e157abb0
fork_exit() at fork_exit+0x80/frame 0xfe00e157abf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e157abf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 17 tid 100095 ]
Stopped at  kdb_enter+0x37: movq$0,0x128b97e(%rip)
db> 


I can afford to leave it that way for a bit, in case anyone has
suggestions for poking at it to get more information.  I expect to
be attempting the same upgrade on a couple of laptops -- after they
finish building firefox.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: HEADS-UP: PIE enabled by default on main

[David Wolfskill]

On Thu, Feb 25, 2021 at 09:22:43PM -0500, Ed Maste wrote:
> On Thu, 25 Feb 2021 at 19:23, John Kennedy  wrote:
> >
> >   Not sure if Ed Maste just wants to make sure that all the executables
> > are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
> > he knows about.
> 
> The issue is that without a clean build you may have some .o files
> left around that are built without PIE enabled (i.e., compiled without
> -fPIE), and attempting to link them into a PIE executable will fail
> with an error like:
> 
> ld: error: can't create dynamic relocation R_X86_64_32 against local
> symbol in readonly segment; recompile object files with -fPIC or pass
> '-Wl,-z,notext' to allow text relocations in the output
> 

FWIW, my source update from:

FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1194 
main-n245061-c861373bdff9: Thu Feb 25 04:09:17 PST 2021 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 145 145

to:

FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1195 
main-n245107-172f2fc11cc5: Fri Feb 26 04:01:22 PST 2021 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 145 145

this morning was quite uneventful.  I did nothing special -- just
the normal META_MODE build I always do.  Rebooted; started X11
(built under stable/12, as with all of the ports save x11/nvidia-driver)...
things Just Worked. :-)

(Above was from one machine; I actually updated 3 machines in parallel.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

/usr/local/lib/compat no longer searched?

[David Wolfskill]

This is after an update from main-n244973-c02a28754bc2 ->
main-n245005-77e1ccbee3ed.

Before the update:

ldconfig -r | grep curses 
51:-lncursesw.9 => /lib/libncursesw.so.9
811:-lncursesw.8 => /usr/local/lib/compat/libncursesw.so.8
812:-lncurses.8 => /usr/local/lib/compat/libncurses.so.8

after:

g1-48(14.0-C)[9] ldconfig -r | grep curses
33:-lncursesw.9 => /lib/libncursesw.so.9
g1-48(14.0-C)[10] 

Circumvention:

g1-48(14.0-C)[10] sudo ldconfig -m /usr/local/lib/compat/
Password:
g1-48(14.0-C)[11] ldconfig -r | grep curses
33:-lncursesw.9 => /lib/libncursesw.so.9
807:-lncurses.8 => /usr/local/lib/compat//libncurses.so.8
808:-lncursesw.8 => /usr/local/lib/compat//libncursesw.so.8
g1-48(14.0-C)[12] 

Was this intentional?  Or am I missing something I ought not?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: testers needed: loader: use display pixel density for font autoselection

[David Wolfskill]

I will plan on testing later today, using the laptop that has a mouse
that doesn't work under FreeBSD. :-}

As time permits between meeetings & stuff...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It is supremely disingenuous to claim a lack of jurisdiction, then 
proceed to participate in a decision on the same matter.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: svnlite behaviour changed?

[David Wolfskill]

On Tue, Jan 26, 2021 at 09:52:15AM +, M&S - Krasznai András wrote:
> Good morning!
> 
> I regularly sync my FreeBSD source tree with the central repository using svn 
> update. I use a one-lis script to synchonize, which  sends the output of svn 
> to a file, and also copies to the console. This list contained - according to 
> the 'svn help update' - one line for any item which was updated or inserted, 
> deleted etc and at the end it shows the (new) revision number of the 
> repository.
> 
> Some time ago during december this changed: the svn output contained one line 
> only, which informed me the new revision number but I did not get listing of 
> the updated items. If there are no updated items then why is the revision 
> number increasing, or if there are updates the why aren't they listed?
> 
> A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn 
> update changes the revision number of the source tree, and the newly compiled 
> kernel has that revision number, but no listing of updates.  svn checkout 
> listed the files as they were read from the central repository.
> 
> Is this a change of svn while the help text remained the old one,  or there 
> is a change in the svn repositories, or is this part of the move to git?
> Üdvözlettel
> 
> Krasznai András
> rendszermérnök

First, please note that this list is "freebsd-current@" -- by
definition, a "release" (such as FreeBSD-12.2-RELEASE) is not "current."

Second, the revision number at the end of "svn update" is the last
revision for the entire repository -- which is NOT the same thing as
"the last revision for the branch" (that you are using).

Thus, if there are changes to other branches (but not the one you are
tracking), the revision number reported will continue to go up, but
there will be no changes to the files in your branch.

Finally, please be aware that the svn repository is no longer the
"Source of Truth" for FreeBSD.  Rather, for (recent) stable branches (<=
12), committed changes to the Source of Truth are subsequently
"replayed" into the subversion repository.  As I understand it, there
are no plans to provide this for stable/13 or subsequent branches (or
for current).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Some "Republicans" seem bound and determined to turn the party known for
touting "law and order" into one that supports mob rule and insurrection.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Getting /usr/src to match specific git hash?

[David Wolfskill]

On Sun, Jan 24, 2021 at 11:14:45AM -0800, Steve Kargl wrote:
> ...
> Any advice on how to jump, say, 4 days ahead of the current
> date of the src/ tree?  That is, I have src/ that should
> correspond to 24 Dec 2020.  How do I jump to 28 Dec 2020?

I (happen to) track FreeBSD head, stable/12 (and now, stable/13) daily
on a couple of machines.  In the course of that effort, the machines are
set up to append the output of

uname -vpUK

to a file that gets copied to where my Web server can see it.

(Other files are also copied, in case they might prove useful.)

These are accessible from
https://www.catwhisker.org/~david/FreeBSD/history/

I believe that the file that would address your immediate concern is
https://www.catwhisker.org/~david/FreeBSD/history/freebeast_uname_amd64.13.txt

(There is no update for stable/13 today, as there were no chnages to
stable/13 sources since stable/13-c256208-gf76393a6305b at the time I
updated my local private git mirrors his morning.)

>  

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Note that political parties are not mentioned in the US Constitution at all.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Which branch in git is 13.0-current?

[David Wolfskill]

On Sun, Jan 24, 2021 at 06:11:04AM -0600, donaldwillin...@gmail.com wrote:
> I'm happy the number was changed.  To many, the number "13" is
> considered to be bad luck.
> 

It was not "changed" for that reason.

It's a natural progression from 11 to 12 to 13 to 14 (to 15 ...).

It's the way stable/* branches of FreeBSD are created: they are branched
off of head ("main") in sequence.

"13" is the most recent (and still nascent, at this stage of
development) stable branch; as a result, head is now designated as
"14".

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
So Lindsey Graham thinks that Trump's incitement of the Capitol mob on 6 Jan
should be without consequences?  Graham suppoprts what the mob did??!?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Which branch in git is 13.0-current?

[David Wolfskill]

On Sat, Jan 23, 2021 at 07:52:57PM -0600, Donald Willinger wrote:
> Look for 14-current.  There is no more 13. as I understand it.
> 

head is 14.  stable/13 and stable/12 also exist:

FreeBSD freebeast.catwhisker.org 12.2-STABLE FreeBSD 12.2-STABLE #1144 
stable/12-c243280-g4493b69d4aa: Sat Jan 23 03:33:26 PST 2021 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1202505 1202505

FreeBSD freebeast.catwhisker.org 13.0-ALPHA2 FreeBSD 13.0-ALPHA2 #1162 
stable/13-c256208-gf76393a6305b: Sat Jan 23 07:09:19 PST 2021 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1300136 1300136

FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1162 
main-c256217-g6c789c55c4ba: Sat Jan 23 05:10:49 PST 2021 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 140 140


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
So Lindsey Graham thinks that Trump's incitement of the Capitol mob on 6 Jan
should be without consequences?  Graham suppoprts what the mob did??!?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Which branch in git is 13.0-current?

[David Wolfskill]

On Sat, Jan 23, 2021 at 06:34:58PM -0700, Russell L. Carter wrote:
> ...
> > That is correct, 13-stable has been branched from 13-current which has now
> > been bumped to 14-current.
> > Because it's a major version change going from 13 to 14, pkg is a bit
> > agitated regarding the ABI.
> 
> So has anyone tracking stable/12 and ports successfully completed the
> git checkout stable/13; make buildworld; make installworld; mergemaster
> drill?  I see I can checkout stable/13.

With the substitution of "etcupdate" for "mergemaster," yes.

Mind, I am using ports built under stable/12: I have installed the
misc/compat12x port.

(My build machine is presently running poudriere under:

FreeBSD freebeast.catwhisker.org 13.0-ALPHA2 FreeBSD 13.0-ALPHA2 #1162 
stable/13-c256208-gf76393a6305b: Sat Jan 23 07:09:19 PST 2021 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1300136 1300136

building packages for stable/13.  I don't plan to use them right
away; this is mostly a bit of a stress-test for stable/13: bapt@
called it "poudriere" for at least one good reason.)

Current status:

[13amd64-ports-home] [2021-01-23_22h27m11s] [parallel_build:] Queued: 1038 
Built: 568  Failed: 0Skipped: 0Ignored: 0Tobuild: 470   Time: 
03:21:46


> Do make.conf | src.conf | GENERIC have silent breaking changes?
> I usually, recklessly, assume no.

My build machine (builds and) runs a GENERIC kernel.  It also builds
a couple of other kernels for stable/12 and stable/13; no issues
with either.

> Ima throw the build->install as soon as the drill looks good.
> 
> Russell
> 

I admit to having cheated a fair bit: I have also been tracking head.

So last night, I "cloned" my "head" slice for use for stable/13; there
was little to change, once that was done.  (Yes, I use MBR/BIOS
booting.)

Boring details:

* History: https://www.catwhisker.org/~david/FreeBSD/history/

* How I do stuff: https://www.catwhisker.org/~david/FreeBSD/upgrade.html

* How I keep sources in sync:
  https://www.catwhisker.org/~david/FreeBSD/repo-sync.html

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
So Lindsey Graham thinks that Trump's incitement of the Capitol mob on 6 Jan
should be without consequences?  Graham suppoprts what the mob did??!?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

wlan0 (iwn(4)) needed encouragement to associate

[David Wolfskill]

After this morning's update of head from:

FreeBSD g1-55.catwhisker.org 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #124 
main-c256006-g8ca9ff4f28d2-dirty: Sat Jan 16 05:47:48 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300135 1300135


to:

FreeBSD g1-55.catwhisker.org 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #125 
main-c256026-gb7ab6832cd98-dirty: Sun Jan 17 04:49:26 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300135 1300135

on my laptop, the wireless link failed to associate by the time the
xdm login screen came up.  But when I logged in (on vty1) and issued:

service netif restart wlan0

it associated right away.  (There was no issue with the corresponding
update for stable/12, so I have no reason to believe that there is an
issue with the access point or the laptop -- with respect to associating
properly, at least).  And whether in head or stable/12, the woreless
link has (for the past several months of daily tracking both head and
stable/12) almost always associated by the time the xdm login screen
comes up.

I tried it 3 times; each time, it failed to associate.  (I only tried
the "service netif restart wlan0" the last 2 times -- the first time,
vty1 wasn't usable because I had experimented with a /boot/loader.conf
setting, which (as far as I know) is not relevant to this issue.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Mr. Trump: We did not need you to demonstrate the efficacy of the "big
lie" propaganda technique quite so well -- really.  Please stop.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Current kernel build broken with linuxkpi?

[David Wolfskill]

On Wed, Jan 13, 2021 at 02:52:32PM -0500, Robert Huff wrote:
> 
> Hans Petter Selasky :
> 
> >   You need to update that DRM port you are using before the issue
> >   will be fixed.
> 
>   I'm confused.
>   I have drm-current-kmod listed in PORTS_MODULES; things on that
> list get built _after_ buildkernel (installkernel??) for reasons I
> thought I understood.
>   You are telling me I need to update this _before_ buildkernel?
> 
> 
>   Perplexedly,
> 

He telling you to update the port itself -- e.g.,
/usr/ports/graphics/drm-kmod, as the port was recently updated:


r561457 | manu | 2021-01-13 03:22:25 -0800 (Wed, 13 Jan 2021) | 6 lines

graphics/drm-{current,devel}-kmod: Update to latest source

This fix a compilation problem with a pre 1300135 source tree.

Reported by:Filippo Moretti 


So you need to update the "ports files" to get that update, then rebuild
the port (in concert with rebuilding the kernel, as you are doing).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote:
> ...
> > I believe that this is evidence in favor of a "race condition" diagnosis.
> > (In precisely what, I don't know,)
> 
> I haven't followed source changes too closely as of recent.
> It might be a good idea to check for recent imports of ACPICA updates.
> 

Most recent of those in head was:

| commit fbde34778ba0ba31fcae99e992f353d989433dba
| Merge: a2fe464c81de 960614968e0d
| Author: Jung-uk Kim 
| Date:   Fri Nov 13 22:45:26 2020 +
| 
| MFV:r367652
| 
| Merge ACPICA 20201113.
| 
| Notes:
| svn path=/head/; revision=367654

and I certainly had not been seeing the symptom at all until I
mentioned it on 11 January.  (And I have been tracking head daily,
including the "poweroff" at the end).

FWIW.

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote:
> On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote:
> > On 2021-01-11 14:55, David Wolfskill wrote:
> > > pci3: unknown notify 0x2
> > > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex 
> > > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434)
> > 
> > Looks like that was some sort of a race or otherwise transient condition
> > that lead to the _PTS (prepare-to-sleep) failure.
> > 
> > > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) 
> > > (20201113/psparse-689)
> > > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
> > 
> 
> That's certainly plausible -- as I noted a bit earlier today, there was
> no recurrence  after this morning's main-c255850-g16079c7233be ->
> main-c255894-g8b1839548750 update.
> 
> Should I encounter a recurrence, I will plan to get another screenshot,
> then bring the machine back up and re-try the poweroff (and then report
> my findings).
> 

I had a recurrence this morninig, after the update from:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 
main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134

to:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #121 
main-c255921-gec2700e01532-dirty: Wed Jan 13 05:06:22 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300135 1300135


New swcreenshot is in https://www.catwhisker.org/~david/FreeBSD/head/c255921;
the previous one is in https://www.catwhisker.org/~david/FreeBSD/head/c255850.

They look quite similar to me.

After grabbing the screenshot, I rebooted again, but the poweroff
just worked normally on re-try.

I believe that this is evidence in favor of a "race condition" diagnosis.
(In precisely what, I don't know,)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote:
> On 2021-01-11 14:55, David Wolfskill wrote:
> > pci3: unknown notify 0x2
> > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex 
> > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434)
> 
> Looks like that was some sort of a race or otherwise transient condition
> that lead to the _PTS (prepare-to-sleep) failure.
> 
> > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) 
> > (20201113/psparse-689)
> > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
> 

That's certainly plausible -- as I noted a bit earlier today, there was
no recurrence  after this morning's main-c255850-g16079c7233be ->
main-c255894-g8b1839548750 update.

Should I encounter a recurrence, I will plan to get another screenshot,
then bring the machine back up and re-try the poweroff (and then report
my findings).

Thanks for looking at it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Mon, Jan 11, 2021 at 04:55:13AM -0800, David Wolfskill wrote:
> At the conclusion of each morning's "update cycle," I have (for
> some time) been in the habit of powering the laptop off, leaving
> it powered off for about 15 seconds, then powering it back up.  (The
> build machine also gets powered off, but doesn't get powered back
> up until a bit before midnight.)  This is usually the only time the
> laptop is powered off (which may reflect ... something :-} ).
> 
> Today's update was from:
> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #118 
> main-c255826-g81b3a0a34145-dirty: Sun Jan 10 04:02:54 PST 2021 
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300134 1300134
> 
> to:
> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119 
> main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021 
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300134 1300134
> 

After today's update -- from:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119 
main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134

to:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 
main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134


poweroff was normal; I did not see a recurrence of the original issue.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

At the conclusion of each morning's "update cycle," I have (for
some time) been in the habit of powering the laptop off, leaving
it powered off for about 15 seconds, then powering it back up.  (The
build machine also gets powered off, but doesn't get powered back
up until a bit before midnight.)  This is usually the only time the
laptop is powered off (which may reflect ... something :-} ).

Today's update was from:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #118 
main-c255826-g81b3a0a34145-dirty: Sun Jan 10 04:02:54 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134

to:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119 
main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134

(and yes, while the tree was "dirty," that's because none of my
local changes are committed; the counts & hashes correspond with
what's on git.freebsd.org).

I have place a photo of the screen in
https://www.catwhisker.org/~david/FreeBSD/head/c255850/

Here is a hand-transcription of the final few lines:

acpi_button0: wake_prep disabled wake for \_SB_.PBBTN (S5)
nvidia-modeset: Unloading
pci3: unknown notify 0x2
ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex [ACPI_MTX_Caches] 
(0c4) (20201113/utmutex-434)
ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) 
(20201113/psparse-689)
acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY

The operating system has halted.
Please press any key to reboot.


[At that point, after getting the photo, I pressed the power burtton
long enough to power the machine off, waited about 15 seconds, then
powered it back up.]

A copy of the (verbose) dmesg.boot (grabbed just before the attempted
power-off) may be found at
https://www.catwhisker.org/~david/FreeBSD/history/laptop.13_dmesg.txt

Normal and gzipped copies of the kernel config file ("CANARY") are at
https://www.catwhisker.org/~david/FreeBSD/head/

As may be seen, the config includes GENERIC, and tweaks it a bit --
but hasn't been changed since 01 December 2020.

While I won't be able to do much testing with the laptop for several
hours (as I use it for work), I'm happy to test when I can.

The build machine seems to have powered off without complaint, FWIW.

What may I do to help figure out what's wrong?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I want him to resign. I want him out. He has caused enough damage."
 - Senator Lisa Murkowski (R-AK)

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: src: continued use of Subversion for getting updates

[David Wolfskill]

On Sat, Jan 09, 2021 at 10:23:56AM -0500, Frank Seltzer wrote:
> ...
> Is there a cookbook guide to converting to git from svn for people who just
> want to checkout source to buildworld and keep the ports tree up to date?
> 

While it is not a cookbook, I wrote up what I do at
https://www.catwhisker.org/~david/FreeBSD/repo-sync.html

Note that since 19 December, I switched from svn to git for sources, but
ports remains on svn (until March, IIRC).

Also, I have some (perceived) requirements that are unlikely to be
especially common; that said, I believe that it's easy enough to just
"not do" certain things.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I want him to resign. I want him out. He has caused enough damage."
 - Senator Lisa Murkowski (R-AK)

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem compiling custom kernel

[David Wolfskill]

On Sat, Jan 09, 2021 at 02:33:58PM +, Filippo Moretti wrote:
> I tried to compile my custom kernel but I did get the following error,I 
> enclose the beginning of dmesg output.So far I could always build kernel 
> STING.I did switch to git and previously I could build it without 
> issues.sincerelyFilippo
> 
> ...
> --- kernel.full ---linking kernel.full
> ld: error: undefined symbol: hid_is_keyboard
> >>> referenced by ukbd.c:957 (/usr/src/sys/dev/usb/input/ukbd.c:957)
> >>>   ukbd.o:(ukbd_probe)
> ld: error: undefined symbol: hid_is_mouse
> >>> referenced by ukbd.c:958 (/usr/src/sys/dev/usb/input/ukbd.c:958)
> 

Looks as if you need some of these:

g1-55(12.2-S)[2] tail sys/amd64/conf/GENERIC
device  evdev   # input event device support
device  uinput  # install /dev/uinput cdev

# HID support
options HID_DEBUG   # enable debug msgs
device  hid # Generic HID support
options IICHID_SAMPLING # Workaround missing GPIO INTR support
#device usbhid  # USB transport support.
#device hidbus  # HID bus (required by usbhid/iichid)
#optionsUSBHID_ENABLED  # Prefer usbhid to other USB drivers
g1-55(12.2-S)[3] 


FWIW, I find it useful to construct my custom kernel configurations
by starting with "include GENERIC", then adjust from there.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I want him to resign. I want him out. He has caused enough damage."
 - Senator Lisa Murkowski (R-AK)

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Reinstalling libncurses.so.9

[David Wolfskill]

On Thu, Jan 07, 2021 at 03:58:07AM -0800, David Wolfskill wrote:
> ...
> > I think the commit message explains everything:
> > 
> > https://cgit.freebsd.org/src/commit/?id=821aa63a09402935da0a73abf20ba0441562aa07
> > 
> 
> Seems to me that an update to the misc/compat12x port might be in order:
> 

I was wrong about that; sorry.  As the commit message notes:

|   Since the .9 version only lived in the dev branch and never ended in a
|   release, it is simply removed and not added to any binary compat
|   package.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"President Donald Trump caused this insurrection with his lies and
conspiracy theories about the election process being rigged against him."
 - Scott Jennings

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Reinstalling libncurses.so.9

[David Wolfskill]

On Thu, Jan 07, 2021 at 11:24:25AM +0100, Herbert J. Skuhra wrote:
> On Thu, 07 Jan 2021 11:07:57 +0100, Filippo Moretti wrote:
> > 
> > I just upgraded current and was prompted to delete libncurses.so.9
> > which I did.I could not find another version in lib so I need to
> > reinstall libncurses.so.9.Let me please know hot tothank youFilippo
> 
> Why? What's broken?
> 
> I think the commit message explains everything:
> 
> https://cgit.freebsd.org/src/commit/?id=821aa63a09402935da0a73abf20ba0441562aa07
> 

Seems to me that an update to the misc/compat12x port might be in order:

g1-55(12.2-S)[7] cat /usr/ports/misc/compat12x/pkg-descr
This package allows you to install the compat12x libraries on your
system, so you can use legacy binaries that depend on them.

Ports usage example:

--
.include 

.if ${OSVERSION} >= 130
LIB_DEPENDS+=   libncurses.so.8:misc/compat12x
.endif
--
g1-55(12.2-S)[8] 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"President Donald Trump caused this insurrection with his lies and
conspiracy theories about the election process being rigged against him."
 - Scott Jennings

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: boot loader blank screen

[David Wolfskill]

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:
> ... 
> > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would 
> > be cool if you can verify:)
> > 
> > thanks,
> > toomas
> 
> I think, I got it fixed (at least idwer did confirm for his system, thanks). 
> If you can test this patch: 
> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
>  
> it would be really nice.
> 
> thanks,
> toomas

I tested with each of the following "stanzas' in /boot/loader.conf,
using vt (vs. syscons) in each case (though that breaks video reset
on resume after suspend):

# hw.vga.textmode="0"
vbe_max_resolution=1280x800

This works, and provides a graphical console (depth 32).


hw.vga.textmode="0"
# vbe_max_resolution=1280x800

This also works, and provides a low-resolution (and depth 16)
graphical console (800x320 or something similar, IIRC).


# hw.vga.textmode="0"
# vbe_max_resolution=1280x800

(That is, not specifying anything for hw.vga.textmode or
vbe_max_resolution.)

This boots OK, but I see no kernel probe messages or single- to
multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
vty1, see a "login: " prompt, and that (also) works.  (This is the
initial symptom I had reported.)


hw.vga.textmode="1"
# vbe_max_resolution=1280x800

This works -- boots OK, and I see kernel probe (&c.) messages; this is a
text console (mostly blue text; some white, against a dark background.
It's a medium-light blue, so it's easy enough to read (unlike a navy
blue, for example).


FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 
main-c255601-g9fd96b416c45-dirty: Tue Jan  5 17:24:45 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Defense against criminal charges for Trump's call to "find 11,780 votes":
he's delusional.  That must be why he should be making life-or-death decisions.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[David Wolfskill]

On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
> ... 
> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
> tests. Once I switched to etcupdate a few years back I never looked back at 
> mergemaster.
> 
> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
> been several major releases since it’s been unofficially deprecated.
> 
> -Enji
> 

All of which is fine, but at some point prior to that, perhaps
src/UPDATING's instructions that cite its use might merit a change to
reflect the use of a supported tool?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Real "RINOs": Donald Trump and his acolytes (e.g., Ted Cruz; Josh Hawley).

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature