Re: Alt+Fn isn't functional. Has this been removed?

[Michael Gmelin]

> On 30. Mar 2024, at 07:30, Chris  wrote:
> 
> On 2024-03-29 23:06, Michael Schuster wrote:
>> Two ideas:
>> - does CTL-ALT-Fn work?
> Thanks. But no, I tried that.
> 
>> - perhaps the number of predefined ttys was overwritten/set to 0 somewhere?
> I'm only aware of /etc/ttys, and they're all available (uncommented) and
> ps(1) indicates getty(8) is running on all the normally assigned ttyv(n)'s.
> 
> Thanks for the reply!
> 
> --Chris

In case you have a keymap defined on rc.conf, try commenting that out, reboot 
amd see if it makes a difference (as a debugging measure). 

Cheers
Michael


>> HTH
>> Michael
>>> On Sat, Mar 30, 2024, 03:03 Chris  wrote:
>>> I just poured the dist files onto an earlier 15 (after removing
>>> the earlier version). After booting into the new install, I no longer
>>> had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only
>>> getting ttyv0. getty(8) is running, and a ps waux | grep getty shows
>>> they're all up. Only things I saved from the older install were the
>>> user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf.
>>> What do I need to do to further isolate this problem?
>>> Thanks.
>>> System info:
>>> FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0
>>> main-n268793-220ee18f1964:
>>> Thu Mar 14 02:58:39 UTC 2024
>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>>> amd64
>>> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)
>>> IdeaPad 3 17IAU7
>>> Id Refs AddressSize Name
>>>  1   95 0x8020  1d527c0 kernel
>>>  21 0x81f54000287e8 fusefs.ko
>>>  31 0x82d8f000   1e3228 i915kms.ko
>>>  42 0x82f7300085090 drm.ko
>>>  51 0x82ff9000 22b8 iic.ko
>>>  62 0x82ffc000 40e9 linuxkpi_video.ko
>>>  73 0x83001000 7358 dmabuf.ko
>>>  83 0x83009000 3378 lindebugfs.ko
>>>  91 0x8300d000 c338 ttm.ko
>>> 101 0x8301a000 5760 cuse.ko
>>> 111 0x8302 3390 acpi_wmi.ko
>>> 121 0x83024000 4250 ichsmb.ko
>>> 131 0x83029000 2178 smbus.ko
>>> 141 0x8302c00091260 if_iwlwifi.ko
>>> 151 0x830be000 5f90 ig4.ko
>>> 161 0x830c4000 4d20 ng_ubt.ko
>>> 173 0x830c9000 bbb8 netgraph.ko
>>> 182 0x830d5000 a250 ng_hci.ko
>>> 192 0x830e 2670 ng_bluetooth.ko
>>> 201 0x830e3000 3218 iichid.ko
>>> 215 0x830e7000 3380 hidbus.ko
>>> 221 0x830eb000 21e8 hms.ko
>>> 231 0x830ee000 40a8 hidmap.ko
>>> 241 0x830f3000 3355 hmt.ko
>>> 251 0x830f7000 22cc hconf.ko
>>> 261 0x830fa000 2260 pflog.ko
>>> 271 0x830fd00056540 pf.ko
>>> 281 0x83154000 3560 fdescfs.ko
> 

kernel build w/o DDB broken after c21bc6f

[Michael Butler]

When a kernel is built without KDB and DDB, it fails with:

--- kernel.full ---
linking kernel.full
ld: error: undefined symbol: db_ctf_lookup_typename
>>> referenced by kern_ctf.c:329 (/usr/src/sys/kern/kern_ctf.c:329)
>>>   link_elf_obj.o:(link_elf_ctf_lookup_typename)
>>> referenced by kern_ctf.c:329 (/usr/src/sys/kern/kern_ctf.c:329)
>>>   link_elf.o:(link_elf_ctf_lookup_typename)
*** [kernel.full] Error code 1

after commit 5e248c2, kernel module build is broken

[Michael Butler]

Building 
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine

machine -> /usr/src/sys/amd64/include
Building 
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86

x86 -> /usr/src/sys/x86/include
Building 
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/i386

i386 -> /usr/src/sys/i386/include
Building 
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/opt_acpi.h
Building 
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/opt_ddb.h

Building /usr/obj/usr/src/amd64.amd64/sys/VM01-new/cc.o
/usr/src/sys/netinet/cc/cc.c:475:10: error: 6 enumeration values not 
handled in switch: 'CC_ACK', 'CC_DUPACK', 'CC_PARTIALACK'... 
[-Werror,-Wswitch]

  475 | switch (type) {
  | ^~~~
1 error generated.
*** [cc.o] Error code 1

commit f74352f breaks world

[Michael Butler]

Moving these definitions breaks world outside the kernel :-(

building shared library libmapper_std.so.5
Building 
/usr/obj/usr/src/amd64.amd64/lib/libiconv_modules/mapper_zone/libmapper_zone.so.5

building shared library libmapper_zone.so.5
Building /usr/obj/usr/src/amd64.amd64/lib/libstats/tcp_stats.o
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use 
of undeclared identifier 'CC_ECN'
  137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), 
DVBKT(CC_RTO),

  |^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use 
of undeclared identifier 'CC_ECN'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use 
of undeclared identifier 'CC_RTO'
  137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), 
DVBKT(CC_RTO),

  |   ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use 
of undeclared identifier 'CC_RTO'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use 
of undeclared identifier 'CC_RTO_ERR'

  138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0)
  |   ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use 
of undeclared identifier 'CC_RTO_ERR'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use 
of undeclared identifier 'CC_NDUPACK'

  138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0)
  |  ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use 
of undeclared identifier 'CC_NDUPACK'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use 
of undeclared identifier 'CC_ECN'
  137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), 
DVBKT(CC_RTO),

  |^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use 
of undeclared identifier 'CC_ECN'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use 
of undeclared identifier 'CC_RTO'
  137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), 
DVBKT(CC_RTO),

  |   ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use 
of undeclared identifier 'CC_RTO'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use 
of undeclared identifier 'CC_RTO_ERR'

  138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0)
  |   ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use 
of undeclared identifier 'CC_RTO_ERR'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use 
of undeclared identifier 'CC_NDUPACK'

  138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0)
  |  ^
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use 
of undeclared identifier 'CC_NDUPACK'
/usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:142:6: error: 
invalid application of 'sizeof' to an incomplete type 'struct voistatspec[]'

  142 | NVSS(vss_congsig), vss_congsig, 0);
  | ^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/stats.h:440:32: note: 
expanded from macro 'NVSS'
  440 | #define NVSS(vss_slots) (sizeof((vss_slots)) / sizeof(struct 
voistatspec))

  |^
17 errors generated.
*** [tcp_stats.o] Error code 1

make[5]: stopped in /usr/src/lib/libstats
ERROR_TARGET='tcp_stats.o'

Re: WITHOUT_CASPER ghost?

[Michael Dexter]

On 2/23/24 9:13 AM, Brooks Davis wrote:

Things are in a somewhat messy state.  CASPER and CAPSICUM were moved to
a new __REQUIRED_OPTIONS list, but the various bits still exist and
there's even one use of MK_CASPER=no in Makefile.inc1.  The commit
message (c24c117b9644) suggests that the intent was to finish removal
after 14 branched and it just hasn't happened yet.


Understood.


I do wonder if the tool would also benefit from learning about
__REQUIRED_OPTIONS.


By required do you mean WITHOUT_AUTO_OBJ, WITHOUT_UNIFIED_OBJDIR, 
WITHOUT_INSTALLLIB which I manually skip/mask my build option testing?


If so, what syntax would use __REQUIRED_OPTIONS and what branches 
support it?


Michael

WITHOUT_CASPER ghost?

[Michael Dexter]

All,

The WITHOUT_CASPER build option was deprecated in main and 14-stable 
branches but is still showing up and will trip up the build option survey:


sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER
WITHOUT_CASPER

--- all_subdir_sbin/mdconfig ---
===> sbin/mdconfig (all)
make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: 
WITHOUT_CAPSICUM option ignored: it is no longer supported
make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: 
WITHOUT_CASPER option ignored: it is no longer supported

--- .depend ---
echo mdconfig: 
/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libc.a 
/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libutil.a 
/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libgeom.a 
/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libbsdxml.a 
/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libsbuf.a >> 
depend

--- mdconfig.o ---
cc -target x86_64-unknown-freebsd14.0 
--sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp 
-B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-fno-common   -DNDEBUG -MD  -MF.depend.mdconfig.o -MTmdconfig.o 
-std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter 
/usr/lib/clang/16/include -Qunused-arguments   -c 
/b/stable/14/src/sbin/mdconfig/mdconfig.c -o mdconfig.o

--- all_subdir_sbin/md5 ---
4 warnings generated.
--- md5 ---
cc -target x86_64-unknown-freebsd14.0 
--sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp 
-B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin -O2 -pipe 
-fno-common -DHAVE_CAPSICUM -DWITH_CASPER -DNDEBUG -std=gnu99 
-Wno-format-zero-length -nobuiltininc -idirafter 
/usr/lib/clang/16/include -Qunused-arguments  -Wl,-znorelro -static   -o 
md5 md5.o   -lmd  -lcasper  -lnv  -lcap_fileargs  -lnv

ld: error: unable to find library -lcasper
ld: error: unable to find library -lcap_fileargs
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [md5] Error code 1

make[4]: stopped in /b/stable/14/src/sbin/md5
1 error

I am tracking the build options here:

https://callfortesting.org/results/bos-ci/

My apologies if this is a false positive.

Michael

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Michael Butler]

On 2/12/24 13:44, Michael Butler wrote:

On 2/12/24 12:36, John Baldwin wrote:

  [ .. trimmed .. ]


Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
/boot/kernel/kernel' and then 'l *',
e.g. from above: 'l *0x80acb962'


I still didn't manage to get a core but .. does this make any sense in 
htis context?


I apologize .. too many crashes and I grabbed the wrong instruction 
pointer; this was the most recent attempt. I have no idea why this 
networking code and PCI configurations are seemingly related :-(


(kgdb) l *0x80acbc02
0x80acbc02 is in cc_cong_signal 
(/usr/src/sys/netinet/tcp_input.c:465).

460 tp->t_flags &= ~TF_PREVVALID;
461 tp->t_badrxtwin = 0;
462 break;
463 }
464
465 if (CC_ALGO(tp)->cong_signal != NULL) {
466 if (th != NULL)
467 tp->t_ccv.curack = th->th_ack;
468 CC_ALGO(tp)->cong_signal(>t_ccv, type);
469 }

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Michael Butler]

On 2/12/24 12:36, John Baldwin wrote:

 [ .. trimmed .. ]


Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
/boot/kernel/kernel' and then 'l *',
e.g. from above: 'l *0x80acb962'


I still didn't manage to get a core but .. does this make any sense in 
htis context?


(kgdb) l *0x80acb962
0x80acb962 is in cc_conn_init 
(/usr/src/sys/amd64/include/counter.h:92).

87  static inline void
88  counter_u64_add(counter_u64_t c, int64_t inc)
89  {
90
91  KASSERT(IS_BSP() || c != EARLY_COUNTER, ("EARLY_COUNTER 
used on AP"));

92  zpcpu_add(c, inc);
93  }
94
95  #endif  /* ! __MACHINE_COUNTER_H__ */
96

    Michael

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Michael Butler]

On 2/12/24 12:36, John Baldwin wrote:

On 2/10/24 2:09 PM, Michael Butler wrote:

I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).

Reverting to 36efc64 seems to work reliably (after ACPI changes but
before the problematic PCI one)

kernel: Fatal trap 12: page fault while in kernel mode
kernel: cpuid = 2; apic id = 02
kernel: fault virtual address = 0x48
kernel: fault code    = supervisor read data, page not 
present

kernel: instruction pointer   = 0x20:0x80acb962
kernel: stack pointer = 0x28:0xfe00c4318d80
kernel: frame pointer = 0x28:0xfe00c4318d80
kernel: code segment  = base 0x0, limit 0xf, type 0x1b
kernel:   = DPL 0, pres 1, long 1, def32 0, gran 1
kernel: processor eflags  = interrupt enabled, resume, IOPL = 0
kernel: current process   = 2 (clock (0))
kernel: rdi: f802e460c000 rsi:  rdx: 0002
kernel: rcx:   r8: 001e  r9: fe00c4319000
kernel: rax: 0002 rbx: f802e460c000 rbp: fe00c4318d80
kernel: r10: 1388 r11: 7ffc765d r12: 000f
kernel: r13: 0002 r14: f8000193e740 r15: 
kernel: trap number   = 12
kernel: panic: page fault
kernel: cpuid = 2
kernel: time = 1707573802
kernel: Uptime: 6m19s
kernel: Dumping 942 out of 16242
MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..92%
kernel: Dump complete
kernel: Automatic reboot in 15 seconds - press a key on the console to 
abort


Without a stack trace it is pretty much impossible to debug a panic like 
this.
Do you have KDB_TRACE enabled in your kernel config?  I'm also not sure 
how the
PCI changes can result in a panic post-boot.  If you were going to have 
problems

they would be during device attach, not after you are booted and running X.

Short of a stack trace, you can at least use lldb or gdb to lookup the 
source
line associated with the faulting instruction pointer (as long as it 
isn't in
a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' 
and then
'l *', e.g. from above: 'l 
*0x80acb962'


I suspect the absence of a core dump was due to my use of tmpfs for /tmp 
and /var/tmp while still having clear_tmp enabled in rc.conf (that may 
touch swap on restart).


Since then, I've removed tmpfs, everything under /usr/obj am rebuilding 
from scratch. I'll update when it finally finishes (i5-3340s are quick :-()


Michael

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Michael Butler]

I have stability problems with anything at or after this commit 
(b377ff8) on an amd64 laptop. While I see the following panic logged, no 
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE 
(X).


Reverting to 36efc64 seems to work reliably (after ACPI changes but 
before the problematic PCI one)


kernel: Fatal trap 12: page fault while in kernel mode
kernel: cpuid = 2; apic id = 02
kernel: fault virtual address = 0x48
kernel: fault code= supervisor read data, page not present
kernel: instruction pointer   = 0x20:0x80acb962
kernel: stack pointer = 0x28:0xfe00c4318d80
kernel: frame pointer = 0x28:0xfe00c4318d80
kernel: code segment  = base 0x0, limit 0xf, type 0x1b
kernel:   = DPL 0, pres 1, long 1, def32 0, gran 1
kernel: processor eflags  = interrupt enabled, resume, IOPL = 0
kernel: current process   = 2 (clock (0))
kernel: rdi: f802e460c000 rsi:  rdx: 0002
kernel: rcx:   r8: 001e  r9: fe00c4319000
kernel: rax: 0002 rbx: f802e460c000 rbp: fe00c4318d80
kernel: r10: 1388 r11: 7ffc765d r12: 000f
kernel: r13: 0002 r14: f8000193e740 r15: 
kernel: trap number   = 12
kernel: panic: page fault
kernel: cpuid = 2
kernel: time = 1707573802
kernel: Uptime: 6m19s
kernel: Dumping 942 out of 16242 
MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..92%

kernel: Dump complete
kernel: Automatic reboot in 15 seconds - press a key on the console to abort

On 2/10/24 13:04, Mark Millard wrote:



On Feb 9, 2024, at 23:44, Bakul Shah  wrote:


$ git bisect good
b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit


On Feb 9, 2024, at 8:13 PM, Mark Millard  wrote:

Summary:

pcib0:  mem 0x7d50-0x7d50930f 
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0:  PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
. .
rman_manage_region:  request: start 0x6, end 
0x6000f
panic: Failed to add resource to rman


Detail:


. .
pcib0:  mem 0x7d50-0x7d50930f 
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: Bus is not cache-coherent
rman_reserve_resource_bound:  request: [0xfd50, 
0xfd50930f], length 0x9310, flags 100, device pcib0
rman_reserve_resource_bound: trying 0x1fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x1fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x31bf <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x33296fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39bf1fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c02fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c06fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c07fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c08fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c2afff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c36fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x39c37fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3b03 <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3b04 <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3b2f <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3ee61fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3ee63fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0x3fff <0xfd50,0x930f>
rman_reserve_resource_bound: tried 0xfbff <0xfd50,0x930f>
considering [0xfc00, 0xfd5d1fff]
truncated region: [0xfd50, 0xfd50930f]; size 0x9310 (requested 0x9310)
candidate region: [0xfd50, 0xfd50930f], size 0x9310
splitting region in three parts: [0xfc00, 0xfd4f]; [0xfd50, 
0xfd50930f]; [0xfd509310, 0xfd5d1fff]
rman_manage_region:  request: start 0xc000, end 0x
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
rman_reserve_resource_bound:  request: [0x51, 0x51], length 0x1, 
flags 0, device pcib0
rman_reserve_resource_bound: trying 0 <0x51,0>

Re: Proposal: Disable compression of newsyslog by default

[Michael Gmelin]

> On 23. Dec 2023, at 16:10, Enji Cooper  wrote:
> 
> 
>> On Dec 22, 2023, at 23:18, Xin Li  wrote:
>> 
>> Hi,
>> 
>> Inspired by D42961, I propose that we move forward with disabling the 
>> compression by default in newsyslog, as implemented in 
>> https://reviews.freebsd.org/D43169
>> 
>> Historically, newsyslog has compressed rotated log files to save disk space. 
>> This approach was valuable in the early days where storage space was 
>> limited.  However, the landscape has changed significantly.  Modern file 
>> systems, such as ZFS, now offer native compression capabilities. 
>> Additionally, the widespread availability of larger hard drives has 
>> diminished the necessity for additional compression.  Notably, the need to 
>> decompress log files for pattern searches poses a significant inconvenience, 
>> further questioning the utility of this legacy feature.
>> 
>> In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is 
>> eligible for compression rather than directly enforcing it. It allows for a 
>> more flexible approach, wherein the actual compression method can be set to 
>> "none" or specified as one among bzip2, gzip, xz, or zstd.
>> 
>> Therefore I would propose that we change the default compression setting to 
>> "none" in FreeBSD 15.0.  This change reflects our adaptation to the evolving 
>> technological environment and user needs.  It also aligns with the broader 
>> initiative to modernize our systems while maintaining flexibility and 
>> efficiency.
>> 
>> I look forward to your thoughts and feedback on this proposal.
> 
> This impacts embedded systems or jails which use UFS as the default /var/log 
> backed device. There are quite a few larger consumers of FreeBSD out there 
> that still use UFS instead of ZFS.
> 
> Adding this instead into bsdinstall and the documentation as a suggested knob 
> seems like a good way to go.
> 
> Just something to keep in mind when making this change.

I would not change the default behavior (POLA violation), but adding an easy to 
change knob to disable compression sounds like a reasonable approach.

-m

mrsas scatter/gather tunable?

[Michael Butler]

I have a couple of RAID arrays attached to an old(-ish) LSI 9285CV-8e 
controller and, while doing a backup between them, I seem to be running 
into a driver/controller resource issue :-(


Every 5 minutes when a 'health check' runs, it logs a shower of "mrsas0: 
Cannot allocate ioctl data mem" messages. This seems to be as a result 
of running into the 16 s/g buffer limit for pass-through IOCTLs used by 
smartd and/or storcli.


There doesn't appear to be any data corruption, just annoying log lines.

Has anyone else run into this?

    Michael

status of openssl 3.0.11 in stable/14?

[Michael Grimm]

Hi

About two weeks ago openssl 3.0.11 has been imported into git: 

https://cgit.freebsd.org/src/commit/?h=vendor/openssl/3.0.11=315108b81694de474bbc273c0050b195047f5eed

I do only want to understand if this means that openssl 3.0.11 has yet to 
become committed?

And, where are those files stored in git after import?

Sorry, I am still not understanding git repositories well enough.

Thanks and regards,
Michael

WITHOUT_CAPSICUM|CASPER option ignored: it is no longer supported

[Michael Dexter]

In exercising the build options on 14.0-BETA4, WITHOUT_CAPSICUM and 
WITHOUT_CASPER appear to be in an ambiguous state: They are present but 
ignored. Fortunately src.conf(5) now reports "This option has no effect."


Will these be removed prior to the final release? Are they staying to be 
reimplemented?


Thank you!

Michael

Re: something magic about the size of a ports tree

[Michael Gmelin]

> On 3. Oct 2023, at 18:27, Matthias Apitz  wrote:
> 
> El día martes, octubre 03, 2023 a las 06:14:23p. m. +0200, Olivier Certner 
> escribió:
> 
>> Hi Matthias,
>> 
>> Some ZFS dataset with zstd compression on jet, and no compression on 
>> c720-1400094?
>> 
> 
> Yes, on jet it is ZFS:
> 
> root@jet:/usr/local/poudriere/ports # mount | grep ports2023
> poudriere/poudriere/ports/ports20230806 on 
> /usr/local/poudriere/ports/ports20230806 (zfs, local, noatime, nfsv4acls)
> 
> on c720-1400094 it is only plain UFS.
> 

Try

du -hA file

Also, to experience the difference, try:

dd if=/dev/zero of=tempfile bs=1m count=10

and compare the results of ls, du -h, du -hA on the different filesystems.

   zfs get all | grep compr

can also be quite enlightening.

Cheers


>matthias
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> 

Re: changes to ps -d?

[Michael Gmelin]

> On 19. Sep 2023, at 12:30, Ronald Klop  wrote:
> 
> Hi,
> 
> In current the way ps -p works has been changed [1].
> I could use "ps axd -p " to see the process tree of some ongoing task.
> In current this has changed to always need an extra option "ps axd -p  
> -D down". Can this become the default again? At least when -d is used.
> 

There was a discussion on the FreeBSD-current mailing list that lead to the 
decision to make this change:

https://lists.freebsd.org/archives/freebsd-current/2023-July/004071.html

Best

Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core

[Michael Butler]

On 9/18/23 14:27, Mike Karels wrote:

 [ .. snip .. ]


avail memory = 16363008000 (15604 MB)
CPU microcode: updated from 0xc to 0x10


With the most recent microcode update, this device reports ..

CPU microcode: updated from 0xc to 0x11

  .. and is now stable with vm.pmap.pcid_enabled=0, 
vm.pmap.pcid_invlpg_workaround=1, and CPUTYPE?=alderlake set in /etc/make.conf 
over multiple full system builds.

I have not tested with vm.pmap.pcid_invlpg_workaround=0.


 .. sorry that was a typo .. I'm actually using ..

vm.pmap.pcid_invlpg_workaround: 1
vm.pmap.invpcid_works: 1
vm.pmap.pcid_enabled: 1


I believe that vm.pmap.pcid_invlpg_workaround does not matter if
vm.pmap.pcid_enabled=0.  Enabling the workaround or disabling pcid should
be basically the same for this CPU, so I don't understand why that isn't
true.  It might be interesting to test with pcid enabled with the new
microcode, although I don't see why that would affect the results (pcid
should still not be used on any CPU).

The CPUTYPE for the compiler should not affect the pcid vm issues, just
change the optimization by the compiler.


Agreed. However, I was previously using CPUTYPE?=tremont so I just 
wanted to note that two things had changed in my testing, microcode and 
CPUTYPE, not just one,


Michael

Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core

[Michael Butler]

On 8/8/23 13:50, Michael Butler wrote:

On 8/8/23 10:56, Tomoaki AOKI wrote:

On Tue, 8 Aug 2023 17:02:32 +0300
Konstantin Belousov  wrote:


  [ .. snip .. ]

The workaround is switched on automatically, when kernel detects 
'small cores'

reported by CPUID.


If I read the code correctly, vm.pmap.pcid_invlpg_workaround
(precicely, the corresponding variable) is set to non-zero when the
workaround is enabled. Not sure it was detected correctly at the
original reporter's environment, but forcibly setting the tunable to 1
didn't reported to help sufficiently.
Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help.


I'm seeing similar stability problems on an N95-based device. This too 
is an Alderlake-N device with only E-cores although I'm running it with 
a compilation with CPUTYPE=tremont .. from an older, verbose start-up ..


PPIM 0: PA=0x40, VA=0x8271, size=0x1d5000, mode=0x1
pmap: large map 8 PML4 slots (4096 GB)
VT(efifb): resolution 800x600
Preloaded elf kernel "/boot/kernel.new/kernel" at 0x8234e000.
Preloaded boot_entropy_cache "/boot/entropy" at 0x82357d08.
Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at 
0x82357d60.

Preloaded hostuuid "/etc/hostid" at 0x82357dc0.
Preloaded TSLOG data "TSLOG" at 0x82357e10.
CPU: Intel(R) N95 (1689.60-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0xb06e0  Family=0x6  Model=0xbe  Stepping=0

Features=0xbfebfbff

Features2=0x7ffafbbf
   AMD Features=0x2c100800
   AMD Features2=0x121
   Structured Extended 
Features=0x239ca7eb
   Structured Extended 
Features2=0x98c007bc
   Structured Extended 
Features3=0xfc184410

   XSAVE Features=0xf
   IA32_ARCH_CAPS=0x180fd6b
   VT-x: Basic Features=0x3da0500
     Pin-Based Controls=0xff
     Primary Processor 
Controls=0xfffbfffe
     Secondary Processor 
Controls=0x75d7fff

     Exit Controls=0x3da0500
     Entry Controls=0x3da0500
     EPT Features=0x6f34141
     VPID Features=0xf01
   TSC: P-state invariant, performance statistics
64-Byte prefetching
L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line
real memory  = 17179869184 (16384 MB)
Physical memory chunk(s):
0x0001 - 0x0009dfff, 581632 bytes (142 pages)
0x0009f000 - 0x0009, 4096 bytes (1 pages)
0x0010 - 0x5fff, 1609564160 bytes (392960 pages)
0x62401000 - 0x7264dfff, 270848000 bytes (66125 pages)
0x75fff000 - 0x75ff, 4096 bytes (1 pages)
0x00011000 - 0x000462497fff, 14533881856 bytes (3548311 pages)
0x00047fa0 - 0x00047fb68fff, 1478656 bytes (361 pages)
avail memory = 16363008000 (15604 MB)
CPU microcode: updated from 0xc to 0x10


With the most recent microcode update, this device reports ..

CPU microcode: updated from 0xc to 0x11

 .. and is now stable with vm.pmap.pcid_enabled=0, 
vm.pmap.pcid_invlpg_workaround=1, and CPUTYPE?=alderlake set in 
/etc/make.conf over multiple full system builds.


I have not tested with vm.pmap.pcid_invlpg_workaround=0.

On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random 
faults still occurred under load, for example, 'make buildworld'. 
Apparent misreads of source-files resulting in syntax errors were the 
most common symptom. Compilation reattempts (mostly) succeed.


Initially, I put this down to an inadequate power-supply but setting 
vm.pmap.pcid_enabled=0 seems to have stabilised it.


I guess there's another dragon in there .. :-(

 Michael

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

As this is the continuation of a thread I started in June,
let me top post again the solution I used back then:

"""
For completeness sake, this is how I boot 14.0 on 13.2 using
  sysutils/vm-bhyve:

  ISO=FreeBSD-14.0-CURRENT-amd64-20230608-653738e895ba-263444-bootonly.iso
  export ISO

  cd /mountpoint/for/pool/vm

  vm iso https://download.freebsd.org/snapshots/ISO-IMAGES/14.0/$ISO
  mkdir .loaders
  tar --strip-components 1 -C .loaders -xf .iso/$ISO boot/userboot.so
  mv .loaders/userboot.so .loaders/userboot14.so

  vm create test14
  sysrc -f test14/test14.conf memory=1G
  sysrc -f test14/test14.conf \
bhyveload_loader="$(realpath .loaders/userboot14.so)"

OS installation is done the usual way (using tmux instead of cu in this
example):

  pkg install -y tmux
  sysrc -f .config/system.conf console=tmux
  vm install test14 $ISO
  tmux attach -t test14
"""

You can find thew whole thread here:
https://lists.freebsd.org/archives/freebsd-current/2023-June/003835.html


Best
Michael



On Sat, 16 Sep 2023 17:22:20 +0100
Warner Losh  wrote:

> On Sat, Sep 16, 2023 at 5:11 PM Toomas Soome  wrote:
> 
> >
> >  
> > > On 16. Sep 2023, at 18:43, Mark Millard  wrote:
> > >
> > > void  wrote on
> > > Date: Sat, 16 Sep 2023 12:12:02 UTC :
> > >  
> > >> On Sat, Sep 16, 2023 at 12:55:19PM +0100, Warner Losh wrote:
> > >>  
> > >>> Yes. The boot loader comes from the host. It must know how to
> > >>> read  
> > ZFS.  
> > >>
> > >> It knows how to read zfs.  
> > >
> > > I expect Warner was indicating: you have a (efi?) loader that
> > > knows how to deal with the features listed in:
> > >
> > > sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd
> > >
> > > being active but not with some new feature(s) listed in:
> > >
> > > sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2
> > >
> > > being active.
> > >
> > > The following are the "read-only-compatibile no" features
> > > that are new in openzfs-2.2 compared to openzfs-2.1-freebsd :
> > >
> > > blake3
> > > ednor
> > > head_errlog
> > > vdev_zaps_v2
> > >
> > > So any of those being active leads to lack of even read-only
> > > activity being compatible. (Although, the loader's subset
> > > of the potential overall activity might allow ignoring some
> > > specific "read-only-compatibile no" status examples.)
> > >
> > > For reference:
> > >
> > > # diff -u99  
> > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd
> > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2
> >  
> > > ---  
> > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd
> > 2021-06-24 20:08:57.206621000 -0700  
> > > +++  
> > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2
> > 2023-06-10 15:59:25.354999000 -0700  
> > > @@ -1,34 +1,40 @@
> > > -# Features supported by OpenZFS 2.1 on FreeBSD
> > > +# Features supported by OpenZFS 2.2 on Linux and FreeBSD
> > > allocation_classes
> > > async_destroy
> > > +blake3
> > > +block_cloning
> > > bookmark_v2
> > > bookmark_written
> > > bookmarks
> > > device_rebuild
> > > device_removal
> > > draid
> > > +edonr
> > > embedded_data
> > > empty_bpobj
> > > enabled_txg
> > > encryption
> > > extensible_dataset
> > > filesystem_limits
> > > +head_errlog
> > > hole_birth
> > > large_blocks
> > > large_dnode
> > > livelist
> > > log_spacemap
> > > lz4_compress
> > > multi_vdev_crash_dump
> > > obsolete_counts
> > > project_quota
> > > redacted_datasets
> > > redaction_bookmarks
> > > resilver_defer
> > > sha512
> > > skein
> > > spacemap_histogram
> > > spacemap_v2
> > > userobj_accounting
> > > +vdev_zaps_v2
> > > +zilsaxattr
> > > zpool_checkpoint
> > > zstd_compress
> > >
> > > (Last I checked, /usr/share/zfs/compatibility.d/openzfs-2.2 does
> > > not exist yet. Thus were I had the diff look.)
> > >  
> > >> On the host in question, there are many guests,
> > >> some with zfs-boot, some not, just file-based.  
> > >
> > > But with what openzfs features active vs. not a

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

> On 4. Sep 2023, at 19:34, Matthias Apitz  wrote:
> 
> El día lunes, septiembre 04, 2023 a las 07:29:41p. m. +0200, Michael Gmelin 
> escribió:
> 
>> 
>> 
>>>> On 4. Sep 2023, at 19:23, Matthias Apitz  wrote:
>>> 
>>> 
>>> Added Alexander Motin  to To: as the origin of the CI;
>>> 
>>> Neither hw.atkbd.hz=1 nor hw.atkbd.hz=10 makes the keyboard working on
>>> my beloved Acer C720. Should I file a new PR?
>>> 
>> 
>> Filing a PR makes sense, could you please Cc me on it?
>> 
>> Do you know which version of FreeBSD was the last that worked for you?
> 
> I'm actually using (and typing this on it) r368166. Will file a PR
> tomorrow. Thanks
> 

This could also be related:

https://cgit.freebsd.org/src/commit/?id=319d2bf407b3762da6f1c67ffe8dce2fee587aaf

You could try to undo that patch and build a new kernel.

Best
Michael



>matthias
> 
>>>> El día lunes, septiembre 04, 2023 a las 06:55:52p. m. +0200, Michael 
>>>> Gmelin escribió:
>>>> 
>>>> 
>>>> 
>>>> On Mon, 4 Sep 2023 18:43:11 +0200
>>>> Matthias Apitz  wrote:
>>>> 
>>>>> I have a 14.0-CURRENT compiled from sources of head from August 4,
>>>>> which boots fine from a produced USB key, but the keyboard does not
>>>>> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
>>>>> 
>>>>> The keyboard works during the boot menu (for example to enable verbose
>>>>> boot messages) but not on the login: prompt of the booted system.
>>>>> 
>>>>> I've enabled SSH access into the C720 (if someone need more
>>>>> information) and I'm attaching /var/log/messages of the booted system.
>>>> 
>>>> Hi Matthias,
>>>> 
>>>> The C720 required special patches for the keyboard to work, which I
>>>> originally added here:
>>>> https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b
>>>> 
>>>> I assume that something in that area changed recently.
>>>> 
>>>> Without digging into it, this looks like a possible cause:
>>>> 
>>>> https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585
>>>> 
>>>> atkbd: Disable periodic polling by default.
>>>> It is one of the few remaining Giant-locked callouts.  It would be
>>>> good to remove it, not mentioning that polling itself is not good.
>>>> 
>>>> If this cause keyboard/mouse freezes on some hardware, please set
>>>> loader tunable hw.atkbd.hz=1 as workaround and report the issue.
>>>> 
>>>> So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
>>>> /boot/loader.conf, then reboot and see if it helps.
>>>> 
>>>> Best
>>>> Michael
>>>> 
>>>> -- 
>>>> Michael Gmelin
>>>> 
>>> 
>>> -- 
>>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
>>> Public GnuPG key: http://www.unixarea.de/key.pub
>> 
>> 
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

> On 4. Sep 2023, at 19:23, Matthias Apitz  wrote:
> 
> 
> Added Alexander Motin  to To: as the origin of the CI;
> 
> Neither hw.atkbd.hz=1 nor hw.atkbd.hz=10 makes the keyboard working on
> my beloved Acer C720. Should I file a new PR?
> 

Filing a PR makes sense, could you please Cc me on it?

Do you know which version of FreeBSD was the last that worked for you?

Cheers


> 
> 
>> El día lunes, septiembre 04, 2023 a las 06:55:52p. m. +0200, Michael Gmelin 
>> escribió:
>> 
>> 
>> 
>> On Mon, 4 Sep 2023 18:43:11 +0200
>> Matthias Apitz  wrote:
>> 
>>> I have a 14.0-CURRENT compiled from sources of head from August 4,
>>> which boots fine from a produced USB key, but the keyboard does not
>>> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
>>> 
>>> The keyboard works during the boot menu (for example to enable verbose
>>> boot messages) but not on the login: prompt of the booted system.
>>> 
>>> I've enabled SSH access into the C720 (if someone need more
>>> information) and I'm attaching /var/log/messages of the booted system.
>> 
>> Hi Matthias,
>> 
>> The C720 required special patches for the keyboard to work, which I
>> originally added here:
>> https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b
>> 
>> I assume that something in that area changed recently.
>> 
>> Without digging into it, this looks like a possible cause:
>> 
>>  
>> https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585
>> 
>>  atkbd: Disable periodic polling by default.
>>  It is one of the few remaining Giant-locked callouts.  It would be
>>  good to remove it, not mentioning that polling itself is not good.
>> 
>>  If this cause keyboard/mouse freezes on some hardware, please set
>>  loader tunable hw.atkbd.hz=1 as workaround and report the issue.
>> 
>> So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
>> /boot/loader.conf, then reboot and see if it helps.
>> 
>> Best
>> Michael
>> 
>> -- 
>> Michael Gmelin
>> 
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

On Mon, 4 Sep 2023 18:43:11 +0200
Matthias Apitz  wrote:

> I have a 14.0-CURRENT compiled from sources of head from August 4,
> which boots fine from a produced USB key, but the keyboard does not
> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
> 
> The keyboard works during the boot menu (for example to enable verbose
> boot messages) but not on the login: prompt of the booted system.
> 
> I've enabled SSH access into the C720 (if someone need more
> information) and I'm attaching /var/log/messages of the booted system.

Hi Matthias,

The C720 required special patches for the keyboard to work, which I
originally added here:
https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b

I assume that something in that area changed recently.

Without digging into it, this looks like a possible cause:

  
https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585

  atkbd: Disable periodic polling by default.
  It is one of the few remaining Giant-locked callouts.  It would be
  good to remove it, not mentioning that polling itself is not good.

  If this cause keyboard/mouse freezes on some hardware, please set
  loader tunable hw.atkbd.hz=1 as workaround and report the issue.

So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
/boot/loader.conf, then reboot and see if it helps.

Best
Michael

-- 
Michael Gmelin

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

[Michael Gmelin]

On Sat, 2 Sep 2023 09:53:38 +0100
Graham Perrin  wrote:

> Some inspections are extraordinarily time-consuming. Others complete 
> very quickly, as they should.
> 
> One recent inspection took more than half an hour.
> 
> Anyone else?
> 

Does `git clone https://git.freebsd.org/ports.git` work for you?
(currently it's not working from where I am). Maybe related.

Best
Michael


-- 
Michael Gmelin

Re: periodic daily produces ridiculously huge report files

[Michael Grimm]

Michael Grimm  wrote

> Ever since either upgrading to MAIN or WITHOUT_INET6=yes [1] I noticed that 
> periodic daily still runs in the morning failing to mail ridiculously huge 
> report files (>= 90 *GB*).
> 
> [1] Can't remember when this started.

FTR: It started with WITHOUT_INET6=yes. Recompiling world and kernel including 
IPv6 support brings "netstat -i -d -W -n" back to normal behavior. No more of 
netstat producing producing huge amounts of garbage. 

> But I would like to know, if this has to do with WITHOUT_INET6=yes or FreeBSD 
> 14?
> Or something different ...
> 
> Did someone of you experiences equal behaviour of "netstat -i -d -W"?
> Anyone with WITHOUT_INET6=yes willing to test this?

Anyone?

Regards,
Michael

periodic daily produces ridiculously huge report files

[Michael Grimm]

Hi,

I recently upgraded from 13-STABLE to MAIN, now at FreeBSD 14.0-ALPHA1 amd64 
1400094 #12 main-n264689-580cadd6a5f0, a custom kernel compiled *without* IPv6 
(WITHOUT_INET6=yes).

Ever since either upgrading to MAIN or WITHOUT_INET6=yes [1] I noticed that 
periodic daily still runs in the morning failing to mail ridiculously huge 
report files (>= 90 *GB*).

[1] Can't remember when this started.

I believe to have found the step in periodic daily causing these huge files, 
but I do not know why:

1) I used to run default daily_status_network_netstat_flags="-d -W" in 
/etc/periodic.conf

This normally produces an output like:

MWN> netstat -i -d -W -n 
NameMtu NetworkAddress  Ipkts Ierrs 
IdropOpkts Oerrs  Coll  Drop
vtnet0 1490fa:16:3e:37:a7:35   963666 0 
0  1145053 0 0 0
vtnet0- 1.2.3.4/32 1.2.3.4 859598 - 
-  1068898 - - -
vtnet0- 10.20.30.40/32 10.20.30.40  12176 - 
-0 - - -
vtnet0- 50.60.70.80/32 50.60.70.80  0 - 
-0 - - -
vtnet0- 100.100.100.10/32  100.100.100.105200 - 
-0 - - -
vtnet1*1500fa:16:3e:58:c8:c90 0 
00 0 0 0
lo0   16384lo0 20 0 
0   20 0 0 0
lo0   -- - -- - - -
lo0   -- - -- - - -
lo0   - 127.0.0.0/8127.0.0.1   20 - 
-   20 - - -
bridge0149058:9c:fc:00:61:18   186483 0 
0   173172 0 0 0
bridge0   - 10.2.2.0/2410.2.2.2546625 - 
- 6698 - - -
bridge0   - 10.2.2.199/32  10.2.2.1995198 - 
-0 - - -
bridge0   - 10.2.2.220/32  10.2.2.220  363021 - 
-0 - - -
ipsec0 1400ipsec0  852284 0 
0  1035859 0 0 0
ipsec0- 10.2.2.0/2410.2.2.250  391221 - 
-   941898 - - -
pflog033152pflog0   0 0 
049185 0 0 0
epair201a  149002:0a:28:51:b5:0a33154 0 
032531 0 0 0
epair203a  1490   02:0b:44:a0:f4:0a 2807 0 
0 2567 0 0 0
epair2a1490   02:22:d3:ae:82:0a 7635 0 
0 5435 0 0 0
epair1a1490   02:61:a8:aa:89:0a   142474 0 
0   132256 0 0 0
epair6a1490   02:b4:4a:c7:dd:0a  228 0 
0  213 0 0 0
epair5a1490   02:ba:52:8a:6d:0a  185 0 
0  170 0 0 0

But pretty often "netstat -i -d -W -n" produces garbage like spaces or "0". 
This fills /tmp pretty fast (luckily a compressed zfs filesystem) and my mta 
still tries to mail in the morning.


2) I modified /etc/periodic.conf to daily_status_network_netstat_flags="-d -W 
-4"

This produces an output like:

MWN> netstat -i -d -W -n -4 
Name  Mtu NetworkAddress   Ipkts Ierrs Idrop
Opkts Oerrs  Coll  Drop
vtnet0  - 1.2.3.4/32 1.2.3.4  859590 - -  
1068102 - - -  
vtnet0  - 10.20.30.40/32 10.20.30.40   11592 - -
0 - - -
vtnet0  - 50.60.70.80/32 50.60.70.80   0 - -
0 - - -
vtnet0  - 100.100.100.10/32  100.100.100.10 5192 - -
0 - - -  
lo0 - 127.0.0.0/8127.0.0.120 - -
   20 - - -
bridge0 - 10.2.2.0/2410.2.2.254 6623 - -
 6696 - - -
bridge0 - 10.2.2.199/32  10.2.2.199 5196 - -
0 - - -
bridge0 - 10.2.2.220/32  10.2.2.220   363021 - -
0 - - -
ipsec0  - 10.2.2.0/2410.2.2.250   391221 - -   
941898 - - -

This fixed my issue with periodic daily.

But I would like to know, if this has to do with WITHOUT_INET6=yes or FreeBSD 
14?
Or something different ...

Did someone of you experiences equal behaviour of "netstat -i -d -W"?
Anyone with WITHOUT_INET6=yes willing to test this?

Regards,
Michael

Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core

[Michael Butler]

On 8/8/23 10:56, Tomoaki AOKI wrote:

On Tue, 8 Aug 2023 17:02:32 +0300
Konstantin Belousov  wrote:


 [ .. snip .. ]


The workaround is switched on automatically, when kernel detects 'small cores'
reported by CPUID.


If I read the code correctly, vm.pmap.pcid_invlpg_workaround
(precicely, the corresponding variable) is set to non-zero when the
workaround is enabled. Not sure it was detected correctly at the
original reporter's environment, but forcibly setting the tunable to 1
didn't reported to help sufficiently.
Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help.


I'm seeing similar stability problems on an N95-based device. This too 
is an Alderlake-N device with only E-cores although I'm running it with 
a compilation with CPUTYPE=tremont .. from an older, verbose start-up ..


PPIM 0: PA=0x40, VA=0x8271, size=0x1d5000, mode=0x1
pmap: large map 8 PML4 slots (4096 GB)
VT(efifb): resolution 800x600
Preloaded elf kernel "/boot/kernel.new/kernel" at 0x8234e000.
Preloaded boot_entropy_cache "/boot/entropy" at 0x82357d08.
Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at 
0x82357d60.

Preloaded hostuuid "/etc/hostid" at 0x82357dc0.
Preloaded TSLOG data "TSLOG" at 0x82357e10.
CPU: Intel(R) N95 (1689.60-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xb06e0  Family=0x6  Model=0xbe  Stepping=0

Features=0xbfebfbff

Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended 
Features=0x239ca7eb
  Structured Extended 
Features2=0x98c007bc
  Structured Extended 
Features3=0xfc184410

  XSAVE Features=0xf
  IA32_ARCH_CAPS=0x180fd6b
  VT-x: Basic Features=0x3da0500
Pin-Based Controls=0xff
Primary Processor 
Controls=0xfffbfffe
Secondary Processor 
Controls=0x75d7fff

Exit Controls=0x3da0500
Entry Controls=0x3da0500
EPT Features=0x6f34141
VPID Features=0xf01
  TSC: P-state invariant, performance statistics
64-Byte prefetching
L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line
real memory  = 17179869184 (16384 MB)
Physical memory chunk(s):
0x0001 - 0x0009dfff, 581632 bytes (142 pages)
0x0009f000 - 0x0009, 4096 bytes (1 pages)
0x0010 - 0x5fff, 1609564160 bytes (392960 pages)
0x62401000 - 0x7264dfff, 270848000 bytes (66125 pages)
0x75fff000 - 0x75ff, 4096 bytes (1 pages)
0x00011000 - 0x000462497fff, 14533881856 bytes (3548311 pages)
0x00047fa0 - 0x00047fb68fff, 1478656 bytes (361 pages)
avail memory = 16363008000 (15604 MB)
CPU microcode: updated from 0xc to 0x10
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
SMP: Added CPU 6 (AP)

On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random 
faults still occurred under load, for example, 'make buildworld'. 
Apparent misreads of source-files resulting in syntax errors were the 
most common symptom. Compilation reattempts (mostly) succeed.


Initially, I put this down to an inadequate power-supply but setting 
vm.pmap.pcid_enabled=0 seems to have stabilised it.


I guess there's another dragon in there .. :-(

Michael

[SOLVED] 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

[Michael Grimm]

Dag-Erling Smørgrav  wrote:
> Michael Grimm  writes:

>> I'm currently in the process to prepare for upcoming 14-STABLE. Thus,
>> I upgraded one of my sytems from 13-STABLE to 14-CURRENT.
> 
> Did you run etcupdate?

I was just about to report that I somehow managed to "solve" this issue with 
pam_opie, but not knowing how.

Yep, I did run etcupdate, but not before reporting my issue. This morning I did 
reinstall world, kernel and all my ports and ran etcupdate on host and in all 
my ports. Removing security/opie afterwards and everything is fine now.

Sorry for the noise, I should have known better!

Regards and thanks to all,
Michael

14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

[Michael Grimm]

Hi,

I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I 
upgraded one of my sytems from 13-STABLE to 14-CURRENT.

Everything went fine, except for programs that need /usr/lib/pam_opie.so which 
are:

1) jexec  /usr/bin/login -u 
2) redis-server
3) mariadb1011-server

Error messages:

su[6371]: in openpam_load_module(): no pam_opie.so found
su[6371]: pam_start: System error

Well, although it has been reported some time ago that pam_opie and 
pam_opieaccess.so will become removed in Freebsd 14, there is a port 
security/opie providing both libraries. Quick workaround.

But I want to understand why the above mentioned programs do fail although not 
dynamically linked against /usr/lib/pam_opie.so

MWN> ldd /usr/bin/login
/usr/bin/login:
libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000)
libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000)
libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000)
libc.so.7 => /lib/libc.so.7 (0xd408f99d000)
[vdso] (0xd408e18f630)

MWN> ldd /usr/local/bin/redis-server
/usr/local/bin/redis-server:
libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000)
libm.so.5 => /lib/libm.so.5 (0x89a87beb000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000)
libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000)
libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000)
[vdso] (0x89a87323630)

MWN> ldd /usr/local/libexec/mariadbd
/usr/local/libexec/mariadbd:
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000)
libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000)
libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000)
libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000)
libthr.so.3 => /lib/libthr.so.3 (0x145aebf1)
libc.so.7 => /lib/libc.so.7 (0x145aec7fa000)
libelf.so.2 => /lib/libelf.so.2 (0x145aee867000)
[vdso] (0x145ae5010630)

Which alternatives to pam_opie should I investigate?
Reason: I want to get rid of security/opie

Thanks and regards,
Michael

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Michael Gmelin]

On 6. Aug 2023, at 18:12, Warner Losh  wrote:On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz  wrote:El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió:

> On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:
> 
> >
> > I did, based of a git clone of head, a clean compile of world and kernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I wanted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildworld' puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> > lrwxr-xr-x  1 root wheel      54 Aug  5 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> > -r-xr-xr-x  1 root wheel    9576 Nov 30  2020 basename
> > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020) and
> > of course are missing shared libs when they get called in the actual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >         libdialog.so.8 => not found (0)
> >         ^^
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> >         libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> >         [vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >         libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >         libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> >         libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> >         [vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> > Or what I have done wrong or overlooked?
> >
> 
> So, the build process builds tools that are used to make and install
> FreeBSD.
> That's what legacy is about: providing a compatible way to do all this. We
> setup env vars, etc, so that these tools pull their libraries from legacy
> as well
> so that we have a consistent set of binaries to run on while the rest of
> the world
> is being replaced. I'm surprised to see this failing, since it's what
> nanobsd does
> all the time, and I build new systems with nanobsd every week based on
> recent
> current trees.
> 
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ # 

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note:
I started with an empty new /usr/obj.So what's the vintage of the host you are building with? And what sources areyou building...Also of note: we switched to no-clean builds by default which is way faster, butalso exposes issues like this...
Thanks, this is valuable information (starts adapting idempotent playbooks).-m

Re: poudriere && git

[Michael Grimm]

Matthias Apitz  wrote

> poudriere jail -c -j head -m null -S /usr/src
> 
> which gives an error:
> 
> [00:00:00] Error: Must set -M to path of jail to use
> 
> I don't know what to set for the path to -M. The host system is in
> /usr/src and /usr/obj.  My old existing jail is:
> 
> poudriere jail -l
> JAILNAMEVERSION  ARCH  METHOD   TIMESTAMP 
>   PATH
> freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 
> 12:43:46 /usr/local/poudriere/jails/freebsd-r368166

Creation:
poudriere jail -c -j stable -m src=/usr/src

poudriere jail -l
JAILNAME VERSION ARCH  METHOD   TIMESTAMP   PATH
stable   13.2-STABLE 1302507 amd64 src=/usr/src 2023-08-05 15:01:13 
/usr/home/poudriere/jails/stable

Updating:
poudriere jail -u -j stable

Regards,
Michael

Re: poudriere && git

[Michael Grimm]

Matthias Apitz  wrote:

> In the past I created the jails based on svn, for example with
> 
> # poudriere jail  -c -j freebsd-r368166 -m svn+http -v head@r368166

Use "-m src=/usr/src" instead.

It is documented in man poudriere-jail:

 -m methodSpecify which method to use to create the jail.  The
  default is http.

  Pre-built distribution options:

[…]

  src=path Install from the given directory at path.
   This directory will not be built unless -b
   is given.  It is expected that it is
   already built and maps to a corresponding
   /usr/obj directory.

HTH and regards,
Michael

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 11:32:19 -0600
Warner Losh  wrote:

> On Thu, Jun 8, 2023, 11:18 AM Michael Gmelin 
> wrote:
> 
> > >
> > > Tried today's snaphot, same problem.
> > >
> > >   # reboot
> > >   Waiting (max 60 seconds) for system process `vnlru' to stop...
> > > done Waiting (max 60 seconds) for system process `syncer' to
> > > stop... Syncing disks, vnodes remaining... 0 0 0 0 done
> > >   All buffers synced.
> > >   Uptime: 4m14s
> > >   Consoles: userboot
> > >
> > >   FreeBSD/amd64 User boot lua, Revision 1.2
> > >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > >   ERROR: cannot open /boot/lua/loader.lua: no such file or
> > > directory.
> > >
> > >
> > >   Type '?' for a list of commands, 'help' for more detailed help.
> > >   OK
> > >
> > >
> > > That's after installing CURRENT in a fresh vm managed by vm-bhyve
> > > using bsdinstall's automatic ZFS option.
> > >  
> >
> > Thinking about this, it's possible that vm-bhyve is using the zfs
> > boot loader from the host machine.
> >
> > Please consider this noise, unless you hear from me again.
> >  
> 
> Yes. It does. This can be an unfortunate design choice at times.
> 

For completeness sake, this is how I boot 14.0 on 13.2 using
sysutils/vm-bhyve:

  ISO=FreeBSD-14.0-CURRENT-amd64-20230608-653738e895ba-263444-bootonly.iso
  export ISO

  cd /mountpoint/for/pool/vm

  vm iso https://download.freebsd.org/snapshots/ISO-IMAGES/14.0/$ISO
  mkdir .loaders
  tar --strip-components 1 -C .loaders -xf .iso/$ISO boot/userboot.so
  mv .loaders/userboot.so .loaders/userboot14.so

  vm create test14
  sysrc -f test14/test14.conf memory=1G
  sysrc -f test14/test14.conf \
    bhyveload_loader="$(realpath .loaders/userboot14.so)"

OS installation is done the usual way (using tmux instead of cu in this
example):

  pkg install -y tmux
  sysrc -f .config/system.conf console=tmux
  vm install test14 $ISO
  tmux attach -t test14


Best
Michael

-- 
Michael Gmelin

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 19:06:23 +0200
Michael Gmelin  wrote:

> On Thu, 8 Jun 2023 16:20:12 +
> Glen Barber  wrote:
> 
> > On Thu, Jun 08, 2023 at 06:11:15PM +0200, Michael Gmelin wrote:  
> > > Hi,
> > > 
> > > I didn't dig into this yet.
> > > 
> > > After installing the current 14-snapshot (June 1st) in a
> > > bhyve-vm, I get this on boot:
> > > 
> > >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > > 
> > > (booting stops at this point)
> > > 
> > > Seems like the boot loader is missing this recently added feature.
> > > 
> > 
> > Can you try today's snapshot?  They are propagated to most mirrors
> > now.
> >   
> 
> Tried today's snaphot, same problem.
> 
>   # reboot
>   Waiting (max 60 seconds) for system process `vnlru' to stop... done
>   Waiting (max 60 seconds) for system process `syncer' to stop... 
>   Syncing disks, vnodes remaining... 0 0 0 0 done
>   All buffers synced.
>   Uptime: 4m14s
>   Consoles: userboot  
> 
>   FreeBSD/amd64 User boot lua, Revision 1.2
>   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
>   ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> 
> 
>   Type '?' for a list of commands, 'help' for more detailed help.
>   OK 
> 
> 
> That's after installing CURRENT in a fresh vm managed by vm-bhyve
> using bsdinstall's automatic ZFS option.
> 

Thinking about this, it's possible that vm-bhyve is using the zfs boot
loader from the host machine.

Please consider this noise, unless you hear from me again.

Best
Michael

-- 
Michael Gmelin

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 16:20:12 +
Glen Barber  wrote:

> On Thu, Jun 08, 2023 at 06:11:15PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > I didn't dig into this yet.
> > 
> > After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
> > get this on boot:
> > 
> >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > 
> > (booting stops at this point)
> > 
> > Seems like the boot loader is missing this recently added feature.
> >   
> 
> Can you try today's snapshot?  They are propagated to most mirrors
> now.
> 

Tried today's snaphot, same problem.

  # reboot
  Waiting (max 60 seconds) for system process `vnlru' to stop... done
  Waiting (max 60 seconds) for system process `syncer' to stop... 
  Syncing disks, vnodes remaining... 0 0 0 0 done
  All buffers synced.
  Uptime: 4m14s
  Consoles: userboot  

  FreeBSD/amd64 User boot lua, Revision 1.2
  ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
  ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


  Type '?' for a list of commands, 'help' for more detailed help.
  OK 


That's after installing CURRENT in a fresh vm managed by vm-bhyve using
bsdinstall's automatic ZFS option.

Best
Michael

-- 
Michael Gmelin

CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

Hi,

I didn't dig into this yet.

After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
get this on boot:

  ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2

(booting stops at this point)

Seems like the boot loader is missing this recently added feature.

Best
Michael

-- 
Michael Gmelin

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 22:36 schrieb Yuri:

Yuri wrote:

Michael Osipov wrote:

Am 2023-05-15 um 22:19 schrieb Yuri:

Michael Osipov wrote:

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.


I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar


Not in /etc/login.conf:

$ grep NO /etc/login.conf
     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
-R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO
NO_PROXY='localhost


Weird, works for me running main-n262913-bee3d4bf8ed5:

$ grep NO_PROXY /etc/login.conf
 :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO_PROXY
NO_PROXY=localhost,*.siemens.net


Oh, the fix is in there:

commit f32db406504ece1b28f43dc816736e081fe22826
Author: Sean Eric Fagan 
Date:   Sat Jan 14 10:37:31 2023 -0800

 Allow a comma-separated list in login class capabilities,
 by adding a version of strcspn that allows quoting.

So what exactly are we talking about here? :-)


I am on 12-STABLE, and reported on that. Tried back than on 13, it was 
broken as well. You might want to try 14 with double quotes and see if 
it works. If at least one works, docs need to be updated for sure, and 
also make sure that in single quotes escapes like \c for colon still work.


I'll try a VM with a main snapshot as well tomorrow.

M

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 22:19 schrieb Yuri:

Michael Osipov wrote:

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.


I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar


Not in /etc/login.conf:

$ grep NO /etc/login.conf
:setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 
-R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO
NO_PROXY='localhost

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.

Michael

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.

Michael

Boot failure on a ThinkPad T14/Ryzen 7 Pro 6850U

[Michael Dexter]

Hello all!

I confess that this issue exists on 13.1 and 13.2 in addition to the 
14-CURRENT snapshot from last week but hopefully there is more to try.


This Pr covers the fundamental issue and I have been updating it a I try 
suggestions:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707

In short, stock kernels, non-verbose stop at:

...
psm0: model Generic PS/2 mouse, device ID 0
battery0:  on acpi0
acpi_acad0:  on acpi0


A verbose boot stops at:

...
pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0
uart0 failed to probe at port 0x3f8 irq 4 on isa0
pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1


A kernel built with options ACPI_DEBUG with these boot parameters:

set debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
set debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"

Stops at:

...
 exregion-059 ExSystemMemorySpaceHan: System-Memory (width 8) R/W 0 
Address=70F3

...
 nsxfeval-0386 EvaluateObject : Null handle with relative pathname 
[_PRW] nsxfeval-0386 EvaluateObject...


Related suggestion: Should 'options	ACPI_DEBUG' be built into the 
snapshot kernels along with WITNESS etc?


Any additional suggestions?

Thank you!

Michael

Re: ntpd fails on recent -current/arm64

[Michael Butler]

On 4/23/23 07:47, Peter Jeremy wrote:

Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed,
some change in the kernel has made ntpd stop working on my arm64 test
box.  (My amd64 test box is a couple of days behind so I'm not sure if
it's arm-specific).


 [ .. snip .. ]

While I can't suggest a fix, I discovered this workaround until one is 
found; edit /etc/ntp.conf to include ..


interface ignore wildcard
interface listen lo0
interface listen em0

 .. or whichever interfaces are required on the host,

Michael

Re: Reducing SIGINFO verbosity

[Michael Gmelin]

On Thu, 23 Jun 2022 11:15:55 -0600
Warner Losh  wrote:

> On Sun, Jun 19, 2022 at 6:06 AM Michael Gmelin 
> wrote:
> 
> >
> >
> > On Fri, 21 May 2021 08:36:49 -0600
> > Warner Losh  wrote:
> >  
> > > On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> > > wrote:
> > >  
> > > > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:  
> > > > > No, I don’t think there’s any reason to default it
> > > > > differently on stable  
> > > > vs  
> > > > > current. I think it’s useful (and I prefer the more verbose
> > > > > form, which isn’t the default).  
> > > >
> > > > I agree that there's no reason for the default to be different,
> > > > but I would say that it is much easier for someone who knows
> > > > that there is a default to be changed to change it, than it is
> > > > for someone who does not. Therefore, if the information is not
> > > > useful to someone who does not know how to get rid of it, then
> > > > it should default to not being displayed, IMHO.
> > > >  
> > >
> > > I plan on changing the default for non-INVARIANT kernels back to
> > > the old behavior.
> > >
> > > INVARIANT kernels will keep this behavior because it's a debugging
> > > kernel and this is one more thing to help debugging problems.
> > >  
> >
> > Did this ever happen? I just installed a fresh 13.1-RELEASE
> > production system (non-INVARIANT kernel) and it seems like SIGINFO
> > still outputs kernel stack information.
> >  
> 
> https://reviews.freebsd.org/D35576 for those who wish to weigh in.
> 
> Warner
> 
> 

Hi Warner,

I just installed 13.2-RELEASE, seems like this was never MFCd (it is in
main, but not in stable/13 or releng/13.2). TBH, I could've checked
myself back then (it's so easy to forget to MFC).

Cheers
Michael

p.s. Learned about it by hitting ctrl-t to check if freebsd-update on my
slow test machine is actually alive :D

-- 
Michael Gmelin

FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55

[Michael Jung]

After upgrading from

FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 
stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64


TO

FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 
stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


I had a kernel crash which can be found here.

http://mail.mikej.com/core.txt.0

It has not happened again, but I'm putting it though it's normal paces.

The only thing that was occurring which is not a normal thing for me to
is I was moving TB's worth of data between directly attached two zpools.

Regards,

Michael Jung

Re: Tooling Integration and Developer Experience

[Michael Gmelin]

> On 31. Jan 2023, at 22:44, Kurt Jaeger  wrote:
> 
> Hi!
> 
 This can be as easy as moving everything into Phabricator.
>>> There's the issue that Phabricator itself is no longer supported
>>> upstream:
> [...]
>>> https://we.phorge.it/
> 
>> Should be no harder than regular update. They even have a HOWTO
>> https://we.phorge.it/w/installation_and_setup/update_from_phabricator/
> 
> So, as a step 0 we would need a phorge port...
>> 1. Upgrade to Phorge
>> 2. Setup Maniphest for bugs and tasks
>> 3. Migrate bugs into Maniphest
>> 4. Enable Harbormaster (Build/CI) - this requires coordination with
>> whoever is working on pre-commit CI.
> [...]
>> Infra operations are hard, and I have experience with it. I'd be happy to
>> help.
> 
> Do you think you can provide a phorge port ?
> 

I created the phabricator port in 2014 and have been maintaining it since then. 
I’m also subscribed to phorge, so technically I could also maintain a phorge 
port (I also have many years of experience in maintaining and using phabricator 
instances, also fixing bugs and adding some local features).

So far I haven’t created a port for phorge, as progress on it seemed very slow 
(and many of the changes were also merged into phab) and therefore there was 
little incentive to migrate any of the instances I maintain.

AFAIK FreeBSD’s phabricator instance is not based on the port and uses custom 
patches anyway (I can’t remember having a single communication with 
phabricator-admin regarding the port), therefore having a phorge port most 
likely isn’t a pre-condition for the project to use it.

Best 

> -- 
> p...@opsec.eu+49 171 3101372Now what ?
> 

witness_lock_list_get: witness exhausted

[Michael Jung]

First shame on me as I obviously missed the reply to my former report and did 
not
report back on a proposed patch.

https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068136.html

I am still running current – the guest has 160GB Ram and 64 vCPU’s assigned 
under ESXi
which mainly runs poudriere for amd64+arm builds and I again noticed
"witness_lock_list_get: witness exhausted" on the console (which I don't pay 
much attention to).

UNAME: FreeBSD poudriere.gopai.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n259872-f948cb717f50: Wed Dec 28 13:13:43 EST 2022 
mi...@poudriere.gopai.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

It seems that LOCK_NCHILDREN and LOCK_CHILDCOUNT never got incremented due to 
my lack of reporting in
/usr/src/sys/kern/subr_witness.c

If it's just a matter of incrementing LOCK_CHIDCOUNT 4096 and LOCK_NCHILDREN 20 
without adding the
sysctl knobs I do that also - I am not kernel savvy.

I will make sure and test an updated patch should one be made available or 
advise whether to increment these values
or ignore the warnings.

Regards,

Michael Jung





CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

smartpqi0 "panic: Segment size is not aligned" Related panic on savecore?

[Michael Dexter]

The HPE P408i-a SR Gen10 3.00/smartpqi(4) on an HP DL325 EYPC system 
worked well under 13.* and a SATA SSD but is providing odd behavior 
under the 14-CURRENT 2022-11-23 RE snapshot.


The dmesg is blown with this incrementing error:

...
(probe0:smartpqi0:0:582:0): Down reving Protocol Version from 6 to 2?
(probe1:smartpqi0:0:583:0): Down reving Protocol Version from 6 to 2?
(probe0:smartpqi0:0:584:0): Down reving Protocol Version from 6 to 2?
...
(probe0:smartpqi0:0:1088:2): Down reving Protocol Version from 6 to 5?
pass0 at smartpqi0 bus 0 scbus0 target 64 lun 0
pass0:  Fixed Enclosure Services SPC-3 SCSI device
(quiets down)

dd'ing the 2022-11-23 Release Engineering VM raw snapshot to a device 
boots fine via USB and performs a growfs but booting to the HBA results 
in a panic when savecore it run, reporting:


panic: Segment size is not aligned


Workaround:

Set savecore_enable="NO" in rc.conf before booting.


Reproduction:

service savecore onestart


Cleanup: fsck / in single user mode and disable savecore as needed.


Possibly related?

Open (note savecore):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240145

Resolved with the same "Segment size is not aligned" panic:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259541
https://reviews.freebsd.org/D30182

Should I update that second PR? Have any suggestions for verifying the 
issue?


All the best,

Michael

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

On Sun, 28 Aug 2022 03:21:24 -0700
Cy Schubert  wrote:

> In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>,
> Michael Gmelin w
> rites:
> > 
> >
> >  
> > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote:
> > >=20
> > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > (CEST):  
> > >> As stated before in this thread, replacing /var/run with tmpfs
> > >> is not a supported configuration.  
> > >=20
> > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > creates a t=  
> > mpfs backed /var, populates it through mtree, and makes a proper
> > /var/run av= ailable.  
> > >=20
> > > However it doesn't (yet) create /var/run/clamav of course.
> > >=20
> > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > walks thro=  
> > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > found as need= ed. All that the security/clamav port would need to
> > do then is to drop an ap= propriate small mtree file as
> > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > the same logic as dropping service scripts as /usr/local/=
> > etc/rc.d/clamav-*.
> >
> > =46rom a user's perspective, it would be preferable to have this
> > happen at s= ervice start though, as (unlike in the setup
> > described) reboots don't happen= that frequently, but files in
> > /var/run might get deleted manually. Maybe so= me rc framework
> > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > which, if set, is applied in the default start_precmd. Besides
> > being mo= re resilient, this would also have the advantage that all
> > required file syst= ems should be available at that point and the
> > separation between system and p = orts would be more clear. Another
> > advantage would be that directories are on= ly created for services
> > that are actually enabled/started.  
> 
> Unfortunately this requires all ports to include an mtree file.
> Relying on port maintainers who are human to ensure that these files
> are created and updated when ports are created and maintained will
> result in more human error. I've learned over my long career to rely
> more on automation than human beings. Automation [should] never fail
> and when it does it does temporarily until the bug is found and
> fixed. Human beings inconsistently fail.
> 
> If it were an auto-discovery script that created an mtree file as
> part of the packaging process, it would be another matter. But this
> optional solution path should be discussed on ports@, not here.
> 
> 

I don't have much skin in the game, but I created a little proof of
concept to allow further discussion (which is not ports-specific, as it
works for all service scripts):

https://reviews.freebsd.org/D36385

This basically allows both system admins and port maintainers to
create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
always relative to the service script called) which are automatically
applied on service start. It's non-intrusive and doesn't require any
sweeping changes to existing ports/services.

In this specific case, the requester could create
/usr/local/etc/mtree/clamav-clamd with the required content (or
persuade the port maintainer to include that file).

You could of course add some construct to the ports framework that
picks up certain directories from the package list automatically and
places them into an mtree file as part of the build or installation
process. But that would be an additional feature on top of this change.

This is meant to inspire more discussions, I'm not trying to force
anything in. ;)

Cheers
Michael

-- 
Michael Gmelin

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 28. Aug 2022, at 10:42, free...@oldach.net wrote:
> 
> Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
>> As stated before in this thread, replacing /var/run with tmpfs is not a
>> supported configuration.
> 
> Not supported? What is the purpose of /etc/rc.d/var then? That creates a 
> tmpfs backed /var, populates it through mtree, and makes a proper /var/run 
> available.
> 
> However it doesn't (yet) create /var/run/clamav of course.
> 
> It would be fairly easy to extend /etc/rc.d/var by a logic that walks through 
> /usr/local/etc/mtree/* and runs mtree on each of the files found as needed. 
> All that the security/clamav port would need to do then is to drop an 
> appropriate small mtree file as /usr/local/etc/mtree/clamav. From a port's 
> perspective that is the same logic as dropping service scripts as 
> /usr/local/etc/rc.d/clamav-*.

From a user's perspective, it would be preferable to have this happen at 
service start though, as (unlike in the setup described) reboots don't happen 
that frequently, but files in /var/run might get deleted manually. Maybe some 
rc framework based solution would make sense, e.g., a variable `mtree_files`, 
which, if set, is applied in the default start_precmd. Besides being more 
resilient, this would also have the advantage that all required file systems 
should be available at that point and the separation between system and ports 
would be more clear. Another advantage would be that directories are only 
created for services that are actually enabled/started.

Cheers
Michael

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 15:18, free...@oldach.net wrote:
> 
> Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST):
>> (you're removing /var/run, which shouldn't be removed
> 
> Not quite. It's actually not uncommon to boot with an empty /var. Please see 
> /etc/rc.d/var and related.

That’s a good point.

> The request that ports/packages should consider this case is not exactly 
> unreasonable IMO.
> 

If I was the maintainer, I would simply add the code to create the directory 
for robustness sake (I for one deleted subdirs in /var/run more than once and 
would expect a port to fix this on restart, also to make sure correct 
permissions are applied). But since it doesn’t seem like this is going to 
happen, adding a custom rc file would be a viable short term workaround for the 
requester.

I like the idea of having something like tmpfiles.d, it would also help port 
maintainers (could also be done as a port).

Cheers

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 12:54, FreeBSD User  wrote:
> 
> Am Sat, 27 Aug 2022 11:21:40 +0200
> Michael Gmelin  schrieb:
> 
>>>> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>>> 
>>> Port security/clamav is without doubt for many of FreeBSD users an 
>>> important piece of
>>> security software so I assume a widespread usage.
>>> 
>>> It is also a not uncommon use case to use NanoBSD or any kind of 
>>> low-memory-footprint
>>> installation schemes in which /var/run - amongst other system folders - are 
>>> created at boot
>>> time as TMPFS and highly volatile.
>>> 
>>> In our case, the boxes running a small security appliance based upon 
>>> FreeBSD is rebooted
>>> every 24 hours and so /var/run is vanishing.
>>> 
>>> To make the long story short:
>>> 
>>> The solution for this problem would be a check for existence and take 
>>> action addendum in
>>> precmd() routine of the rc-script as sketched in Bug 259699.
>>> The maintainer rejects such a workaround by arguing this would violate POLA 
>>> (see comment 4
>>> in PR 259699 [2]. The maintainer's argument regaring to mtree's files are 
>>> sound to me.
>>> 
>>> The question is: how can this issue be solved?
>>> 
>>> It is really hard to always chenge our local repository and patch whenever 
>>> clamav has been
>>> patched and modified for what reason ever.
>>> 
>>> Tahanks for reading,
>>> 
>> 
>> Why don’t you simply add an rc script to your appliance that creates the 
>> missing
>> directory/directories on boot before clamav is started?
>> 
>> Best
>> Michael
>> 
>> 
>> 
> 
> Why not fixing this on a more general basis?

It‘s a reasonable way forward, given the limitations you described (you’re 
removing /var/run, which shouldn’t be removed and the port maintainer not 
willing to add code to compensate for this). This would fix it for you for your 
specific needs in a reliable way, you would never have to patch the port again 
and also won’t use other people‘s time to find a general solution to your very 
specific problem. It’s a sustainable quick fix to your problem at hand. You can 
always come up with something grand later, but this would actually work right 
away.

Cheers

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
> 
> Hello,
> 
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> 
> Port security/clamav is without doubt for many of FreeBSD users an important 
> piece of security
> software so I assume a widespread usage.
> 
> It is also a not uncommon use case to use NanoBSD or any kind of 
> low-memory-footprint
> installation schemes in which /var/run - amongst other system folders - are 
> created at boot
> time as TMPFS and highly volatile.
> 
> In our case, the boxes running a small security appliance based upon FreeBSD 
> is rebooted every
> 24 hours and so /var/run is vanishing.
> 
> To make the long story short:
> 
> The solution for this problem would be a check for existence and take action 
> addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate POLA 
> (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound 
> to me.
> 
> The question is: how can this issue be solved?
> 
> It is really hard to always chenge our local repository and patch whenever 
> clamav has been
> patched and modified for what reason ever.
> 
> Tahanks for reading,
> 

Why don’t you simply add an rc script to your appliance that creates the 
missing directory/directories on boot before clamav is started?

Best
Michael

Re: main-n257625-587649902329-dirty?

[Michael Gmelin]

> On 26. Aug 2022, at 18:55, Nuno Teixeira  wrote:
> 
> 
> Hello to all,
> 
> Today I updated and uname -a shows main-n257625-587649902329-dirty.
> Why is showing -dirty?
> 

This means that the git workdir it was built on was dirty, see 
https://remarkablemark.org/blog/2017/10/12/check-git-dirty/

Cheers
Michael

Re: ZFS: cannot import zroot: I/O error

[Michael Gmelin]

> On 15. Aug 2022, at 18:22, Toomas Soome  wrote:
> 
> 
> 
>> On 15. Aug 2022, at 18:01, FreeBSD User  wrote:
>> 
>> Hello,
>> 
>> I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 
>> 4.1.24/26 (do not know
>> exactly). The host is a special system based on Linux und VirtualBox and I 
>> have no chances to
>> configure the VBox.
>> 
>> Somehow the VBox crashed and hung up the complete computer, so I had to cold 
>> start it after
>> approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS 
>> filesystem was
>> wrecked, shwing a stream of 
>> 
>> zio_read error: 5
>> ZFS: i/o error - all block copies unavailable
>> 
>> After a quick search I found some advices howto try fixing, last an longest 
>> one was 
>> 
>> zpool import -fFX -N -R /alternate/path zroot
>> 
>> which took approx 20 minutes - with no success.
>> 
>> There are some valuable data on the partition, which are all backed up, but 
>> it would take its
>> time to restore everything, so I'd like to ask whether there is any cance to 
>> "repair" the
>> mysterious damage.
>> 
>> I'm able to boot off from an USB flash drive …
>> 
> 
> This happens when vbox is telling zfs that data is written on disk, but is 
> actually still in caches… So yea, the standard answer could be “restore from 
> backup”, but it also may help to use ability to revert TXG (it does drop 
> data!).  See also 
> https://gist.github.com/mkhon/34d979c78077a20648456272d7f2cc15
> 

While it might not help the requester with the problem at hand, this situation 
can be prevented (or at least made less likely) by disabling "IgnoreFlush" - 
depending on the virtual device emulated this could be something like:

VBoxManage setextradata VM-name   
"VBoxInternal/Devices/ahci/0/LUN#[0]/Config/IgnoreFlush" 0

or

VBoxManage setextradata VM-name 
"VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/IgnoreFlush" 0

See also: https://www.virtualbox.org/manual/ch12.html#ts_ide-sata-flush

It’s highly recommended for ZFS in case your VM isn’t a throwaway CI thing.

Best
Michael

Re: bhyve core dump related to llvm 14

[Michael Dexter]

On 7/21/22 8:31 AM, Chuck Tuffli wrote:

I have a virtual machine used to test the NVMe emulation in bhyve. All
of the tests in the VM pass running under FreeBSD 13.1-R, but the same
VM running under -current causes bhyve(8) to dump core because of a
segmentation fault.

git bisect identified the last "good" commit on main as
 cb2ae6163174 sysvsem: Fix a typo
After this commit, there are a half-dozen commits related to merging
the llvm project release/14.x



Chuck and I put our heads together to find a way to reproduce this issue 
and came up with this:


Attache a 1gb disk image as emulation type "nvme" to a VM of any recent 
version, and run this command:


nvmecontrol io-passthru -o 0x2 -l 4096 -4 0x20 -r nvme0ns1

This fails gracefully on 13.0R and 13.1R, but panics the bhyve process 
with a 14-CURRENT host after the LLVM 14 import.


I have detailed reproduction steps and the debug output in this bug report:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265749

Michael

Re: pkg: Newer FreeBSD version for package... but why?

[Michael Gmelin]

On Wed, 13 Jul 2022 10:29:06 +0300
Andriy Gapon  wrote:

> # uname -U
> 1400063
> 
> # uname -K
> 1400063
> 
> # pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching packagesite.pkg: 100%5 MiB   4.8MB/s00:01
> Processing entries:   0%
> Newer FreeBSD version for package zyre:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400063
> - running kernel: 1400051
> Ignore the mismatch and continue? [y/N]:
> 
> Does anyone know why this would happen?
> Where does pkg get its notion of the running kernel version?
> 

If I'm reading the sources correctly, it's determining the OS version
by looking at the elf headers of various files in this order:

getenv("ABI_FILE")
/usr/bin/uname
/bin/sh

So I would assume that `file /usr/bin/uname` shows 1400051 on your
system.

You can point it to checking another file by setting ABI_FILE[0] in the
environment or ignore the check by setting IGNORE_OSVERSION (like
advised). The "running kernel:" label seems a bit misleading.

Cheers
Michael

-- 
Michael Gmelin

Re: Accessibility in the FreeBSD installer and console

[Michael Gmelin]

> On 9. Jul 2022, at 03:22, Klaus Küchemann  wrote:
> 
> 
>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>> 
>> Hi,
>> 
>> The only argument I've heard from some non-sighted friends about not using 
>> FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the 
>> start if I press this and this key. …….
> 
> Hi,
> 
> I would like to shortly introduce myself.
> I am indispensable  for all your friends and everybody else
> and yes, I can speak (and I can even hear)-
> I am the de facto standard for everything audio for Apple users and I even 
> can 
> make users of other OSes very very happy.
> 
>> 
>> Am 08.07.2022 um 12:53 schrieb Hans Petter Selasky :
>> Hi,
>> Here is the complete patch for Voice-Over in the FreeBSD console:
>> 
>> https://reviews.freebsd.org/D35754
>> 
>> You need to install espeak from pkg and then install the 
>> /etc/devd/accessibility.conf file and then run sysctl 
>> kern.vt.accessibility.enable=1 after booting the new kernel.
>> 
>> It is freaking awesome!
>> 
>> There might be some bugs, but it worked fine for me!
>> 
>> —HPS
> 
> Congratulations ! 
> 
> But while reading the docs of your system`s bluetooth drivers I became a bit 
> afraid 
> that I won’t be fully supported , I hope this is unfounded.
> 
> It’s not only that I’m a shiny white culty thing ..
> your friends can leave me in their ears and can simultaneously hear the 
> surroundings AND the Audio output.
> That’s why I’m indispensable…
> 
> Will you ensure that at least one bt-chip will support me in your system and 
> will you 
> care for the corresponding drivers?
> 
> If yes I would be happy to meet you in your VT-console ,
> 
> And when you later even support vice versa: 
> -SpeechToText- ,
> It’s possible that we become friends for life .
> 
> 
> Best Regards,
> yours 
> 
> AirPodsPro  :-) 

But why would you ever leave your family that was designed from the ground up 
to match you and any need you could potentially have? And why would you not 
share any word your "owner" (the person who spent money on you, so they could 
use you) says with your creator and all its connected systems and entities, so 
that they could be fully analyzed and monetized?

-m

p.s. seriously, if you want the full Apple experience, you really should stay 
within their ecosystem. Trying to compete with that (with all its questionable 
implications in terms of digital sovereignty) is pointless, especially if you 
are neither broke nor care too much about privacy. If these things mean nothing 
to you, just buy the off the shelf solution and save the time that tinkering 
with free alternatives (that will never be as smooth as "the real thing") would 
require and spend it on things that mean something to you (friends, family, 
charity).

Re: Accessibility in the FreeBSD installer and console

[Michael Gmelin]

> On 8. Jul 2022, at 14:48, Hans Petter Selasky  wrote:
> 
> On 7/8/22 14:34, David Chisnall wrote:
> Snipsnap
> Hi,
> 
> I've updated my patch a little bit, so please re-fetch it.
> 
> I tried:
> 
> action  "echo -- $text | rtprio 8 
> /usr/local/bin/flite_cmu_us_slt"
> 
> And it doesn't sound as good as espeak :-(
> 
> Do we have more of these in ports which are know to be good?
> 

A very long time ago I used festival, which seems to exist as a package (pkg 
install festival festvox-voiceyouneed).

It’s quite old though (I assume that "flite" is the light version of it), back 
then it sounded ok, but we were easy to impress ;)

Cheers

Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums

[Michael Gmelin]

On Mon, 27 Jun 2022 16:18:58 +
Ivan Quitschal  wrote:

> > Hi,
> >
> >Can you dump "kldstat" at the different times?  
> 
> >I guess it may be just be that the wrong module is loaded first, so
> >it grabs the device, because there are no other drivers loaded, even
> >though ums is a generic driver.  
> 
> >Try loading all relevant drivers in /boot/loader.conf . Then the
> >attach order shouldn't matter.  
> 
> >--HPS  
> 
> 
> Hi Michael 
> 
> Yes , hw.usb.usbhid.enable="1" is in loader.conf , not sysctl 
> 
> Hi Warner
> 
> When ums.ko is up, the second attach is always taken by "ums" first
> no matter what. First time you boot tho, it takes the correct one
> (hms)
> 
> Hi Hans
> 
> Looks like this below is the only order I could make it work even tho
>  uhid and usbhid get loaded regardless what I put on loader.conf
> 
> usbhid_load="NO" <-- still loaded anyway
> uhid_load="NO" <-- still loaded anyway
> ums_load="NO" <- this one is not loaded
> ic_load="YES"
> iichid_load="YES"
> hidbus_load="YES"
> hsctrl_load="YES"
> hidmap_load="YES"
> hcons_load="YES"
> hkbd_load="YES"
> hms_load="YES"
> hmt_load="YES"
> hconf_load="YES"
> 
> hw.usb.usbhid.enable="1"
> 
> with the order below , after 5 reboots and lots of kvm switches , it
> always ended up on the right iichid device. Seems to be working now
> 
> but like I said, its random, let see after some more reboots if this
> rule is still valid

I don't know if it makes any difference in your case, but I had best
results loading these drivers through rc.conf, e.g.:

  sysrc kld_list+="hidraw hkbd"

Cheers
Michael

-- 
Michael Gmelin

Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums

[Michael Gmelin]

On Mon, 27 Jun 2022 15:19:28 +
Ivan Quitschal  wrote:

> Hi all
> 
> Not sure if I found a problem here but here we go.
> 
> Since I have a KVM usb switch here for keyboard/mouse sometimes I
> toggle it between my windows and freebsd. I am using iichid here to
> have my multimedia keys working on keyboard and all
> 
> hw.usb.usbhid.enable="1"
> 
> Im also using Wulf's moused
> https://github.com/wulf7/moused
> so far so good. Problem is:
> 
> when I switch to windows , everything is detached correctly (hms,
> hkbd etc), but when I switch back, sometimes the keyboard and mouse
> are wrongly attached to "ums" device , not hms. (sometimes it goes to
> the correct one). Shouldn't ums/uhid modules be deactivated once
> hw.usb.usbhid.enable is set to 1 ?
> 
> The workaround I did here was to manually kldunload both uhid.ko and
> ums.ko within rc.local during boot. This way I can detache attach the
> kbd/mouse back as much as I want and it always end up in hms/hkbd
> devices
> 
> Is this how its supposed to function? Randomly choosing between ums
> or hms?

Did you set hw.usb.usbhid.enable="1" in /boot/loader.conf, or by using
the sysctl? If you don't do it yet, I'd recommend the former.

Cheers
Michael

> 
> Thanks
> 
> --tzk
> 



-- 
Michael Gmelin

Re: Posting netiquette: HTML, attachments etc.

[Michael Gmelin]

> On 26. Jun 2022, at 20:19, Walter Parker  wrote:
> 
> 
> So, utf-8 is good, posting to multiple lists is bad (but ok when you do it),

I didn’t insinuate that it’s good for me to post to three lists at a time 
either, but how would you decide which one to leave out when responding to a 
post you received on multiple lists? My original response reduced the number of 
lists involved, but I was quoted on all three lists again, so I also responded 
on all of them.

> what about the original post? He was asking about HTML. UTF-8 != HTML. UTF is 
> a character encoding format. It is supported by most email clients and does 
> not require HTML for support.
> 

At some point in this email exchange he was suggesting to remove any kind of 
special characters from email and documentation and my original response (he 
quoted) was partially about this.

If it’s just about HTML: I would love to eliminate HTML email, but most email 
clients create it without the user having a chance to intervene. An example is 
iOS Mail, which creates html as soon as you copy and paste almost anything into 
it. AFAIK it still manages to create a useful plain text alternative (unlike 
BBOS 10, if anyone remembers), which makes it better than other email clients - 
so filtering away html in this case would be fine. But there is no option that 
says “send plaintext email”.

I also agree that the original exchange that sparked this debate was quite 
terrible in terms of email formatting (it looked like outlook, no quoting, top 
posting like exchanging written letters, using various font types and sizes). 
So if we could eliminate these kind of emails, I would be happy.

Cheers
Michael 

p.s. I’m pretty sure top posting is also against netiquette - unless *you* do 
it of course ;)

> 
> Walter
> 
>> On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin  wrote:
>> 
>> 
>>>> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>>>> 
>>> 
>>>> 
>>>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>>>> 
>>>> FreeBSD Handbook: Appendix C: updates and corrections
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>>>> 
>>>> I'm glad that HTML is supported.
>>> 
>>> No, people should not be sending HTML emails to lists.
>>> Consult history of email netiquettes to discover the many why's.
>>> 
>>>> Also, I want support for things such as PNG.
>>> 
>>> Attachments are not necessarily against such netiquettes,
>>> but rightly tend to be administratively size limited.
>>> 
>>>> What is the possibility of getting the/a "netiquette" link in
>>>> the FreeBSD Mailinglist footer that is already appended to all
>>>> the messages?
>>> 
>>> There is no such footer appended to the lists, because they're bloat.
>>> Their aims usually better done at first via signup, in quarterly, and
>>> via the occaisional involuntary and accepted friendly cluebat.
>>> 
>>> 
>>>> we are dealing with real people working with the email
>>>> clients available to them in 2022
>>> 
>>> Same arguments was made in 1982 1992 2002 etc, and the netiquette
>>> won validity for good reasons and is still taught trained and disciplined.
>> 
>> Trying to stop people from using UTF-8 is futile. Also, quoting various 
>> arguments from different people without context is bad style - I gave very 
>> specific examples, including the fact that a lot of email is written on 
>> mobile devices where people don’t have control over many aspects of how 
>> things are sent and I argued which parts of netiquette could/should still be 
>> followed given the realities of today and where we need to relax if we want 
>> to have communication happen on our mailing lists.
>> 
>> My answer here is an example of that - there is no reasonable way to follow 
>> any line length limits on a phone and it also automatically chooses the 
>> typographically correct UTF-8 characters, even though I would prefer to use 
>> ASCII - but there is no way I’ll change every single "‘" to "'" manually or 
>> disable the features that make typing on such a device an acceptable 
>> experience. Just won’t happen.
>> 
>> If your email client and/or your desktop can’t handle UTF-8, it’s time to 
>> fix your setup.
>> 
>> -m
>> 
>> p.s. Is it really necessary to have this discussion on multiple lists?
>> 
> 
> 
> -- 
> The greatest dangers to liberty lurk in insidious encroachment by men of 
> zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: Posting netiquette: HTML, attachments etc.

[Michael Gmelin]

> On 26. Jun 2022, at 09:37, grarpamp  wrote:
> 
> 
>> 
>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>> 
>> FreeBSD Handbook: Appendix C: updates and corrections
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>> 
>> I'm glad that HTML is supported.
> 
> No, people should not be sending HTML emails to lists.
> Consult history of email netiquettes to discover the many why's.
> 
>> Also, I want support for things such as PNG.
> 
> Attachments are not necessarily against such netiquettes,
> but rightly tend to be administratively size limited.
> 
>> What is the possibility of getting the/a "netiquette" link in
>> the FreeBSD Mailinglist footer that is already appended to all
>> the messages?
> 
> There is no such footer appended to the lists, because they're bloat.
> Their aims usually better done at first via signup, in quarterly, and
> via the occaisional involuntary and accepted friendly cluebat.
> 
> 
>> we are dealing with real people working with the email
>> clients available to them in 2022
> 
> Same arguments was made in 1982 1992 2002 etc, and the netiquette
> won validity for good reasons and is still taught trained and disciplined.

Trying to stop people from using UTF-8 is futile. Also, quoting various 
arguments from different people without context is bad style - I gave very 
specific examples, including the fact that a lot of email is written on mobile 
devices where people don’t have control over many aspects of how things are 
sent and I argued which parts of netiquette could/should still be followed 
given the realities of today and where we need to relax if we want to have 
communication happen on our mailing lists.

My answer here is an example of that - there is no reasonable way to follow any 
line length limits on a phone and it also automatically chooses the 
typographically correct UTF-8 characters, even though I would prefer to use 
ASCII - but there is no way I’ll change every single "‘" to "'" manually or 
disable the features that make typing on such a device an acceptable 
experience. Just won’t happen.

If your email client and/or your desktop can’t handle UTF-8, it’s time to fix 
your setup.

-m

p.s. Is it really necessary to have this discussion on multiple lists?

Re: Reducing SIGINFO verbosity

[Michael Gmelin]

On Fri, 21 May 2021 08:36:49 -0600
Warner Losh  wrote:

> On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> wrote:
> 
> > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:  
> > > No, I don’t think there’s any reason to default it differently on
> > > stable  
> > vs  
> > > current. I think it’s useful (and I prefer the more verbose form,
> > > which isn’t the default).  
> >
> > I agree that there's no reason for the default to be different, but
> > I would say that it is much easier for someone who knows that there
> > is a default to be changed to change it, than it is for someone who
> > does not. Therefore, if the information is not useful to someone
> > who does not know how to get rid of it, then it should default to
> > not being displayed, IMHO.
> >  
> 
> I plan on changing the default for non-INVARIANT kernels back to
> the old behavior.
> 
> INVARIANT kernels will keep this behavior because it's a debugging
> kernel and this is one more thing to help debugging problems.
> 

Did this ever happen? I just installed a fresh 13.1-RELEASE production
system (non-INVARIANT kernel) and it seems like SIGINFO still outputs
kernel stack information.

Cheers
Michael

-- 
Michael Gmelin

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 15:10, Larry Rosenman  wrote:
> 
> 
> On 06/18/2022 3:54 am, Michael Gmelin wrote:
> 
> [SNIP]
> 
>  
> Subvendor is Fujitsu Siemens - so I guess this is integrated into a system by 
> them.
>  
> Seems like flashing the 2108 to an IT firmware isn't an option (based on what 
> I found online). You could check if there are firmware updates available 
> though. How did you configure the drives in the megaraid utility (ctrl-h 
> after boot)? Did you create a RAID-0 for each disk? And what capacity is 
> shown in there?
>  
> Based on [0], 2108 based controllers don't support 4kn. IT mode would help 
> (true passthrough), but as written above, I don't think it's an option for 
> this model.
>  
> -m
>  
> [0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list
> 
> 
> 
> as I said earlier in the thread, I've bought 2 of these:
> https://www.ebay.com/itm/194910024856
>  
> which if I'm reading that chart right should work with the 4Kn drives. 
>  

That certainly sounds promising.

Best
Michael
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 01:31, Larry Rosenman  wrote:
> On 06/17/2022 6:20 pm, Michael Gmelin wrote:
>>>> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
>>> On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>>>> 
>>>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>>>>>>>>> that will
>>>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>>>>>>> support 8TB drives.
>>>>>>>>> What's the communities recommendation?
>>>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>>>>>>>>> have 16 slots.
>>>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>>>>>>> is directly related to capacity.  According to my observations it may
>>>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>>>> Seagate HDDs in our products, so about that instability I only heard
>>>>>>>> from forums and TrueNAS community user reports.
>>>>>>> This is a mfi(4) set of controllers, and a ST8Nm0045 8TB (CMR) 
>>>>>>> drive.
>>>>>>> Is this a bad combo?
>>>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>>>> mfi0 Physical Drives:
>>>>>>> 0 (  932G) UNCONFIGURED GOOD  
>>>>>>> SATA E1:S3
>>>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due 
>>>>>> to problems with hot-plug, disk identification, etc. and so have limited 
>>>>>> experience with them.  But I know some of LSI RAIDs can be reflashed 
>>>>>> into equivalent HBAs, so if they share the hardware, I can speculate 
>>>>>> that they may share some issues.
>>>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
>>>>> problem than what we heard for HBAs.  It looks like a kind of problems 
>>>>> that should not happen to HBAs, since they should not care about disk 
>>>>> capacity.
>>>> What does `smartctl -a ` report (especially sector sizes)?
>>>> -m
>>>>> --
>>>>> Alexander Motin
>>> It's not even making a mfid* node (it is a 4Kn disk)
>> Ok, that’s sad (and explains the wrong size calculation as 4096/512=8).
>> Is this in HBA mode? (Like Alexander suggested, re-/crossflashing
>> using an IT firmware might be an option). What controller / firmware
>> image version is it?
>> -m
>>> --
>>> Larry Rosenman http://www.lerctr.org/~ler
>>> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
>>> US Mail: 570

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
> On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>> 
>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>>>>>>> that will
>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>>>>> support 8TB drives.
>>>>>>> What's the communities recommendation?
>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>>>>>>> have 16 slots.
>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>>>>> is directly related to capacity.  According to my observations it may
>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>> Seagate HDDs in our products, so about that instability I only heard
>>>>>> from forums and TrueNAS community user reports.
>>>>> This is a mfi(4) set of controllers, and a ST8Nm0045 8TB (CMR) drive.
>>>>> Is this a bad combo?
>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>> mfi0 Physical Drives:
>>>>>  0 (  932G) UNCONFIGURED GOOD  
>>>>> SATA E1:S3
>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due to 
>>>> problems with hot-plug, disk identification, etc. and so have limited 
>>>> experience with them.  But I know some of LSI RAIDs can be reflashed into 
>>>> equivalent HBAs, so if they share the hardware, I can speculate that they 
>>>> may share some issues.
>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
>>> problem than what we heard for HBAs.  It looks like a kind of problems that 
>>> should not happen to HBAs, since they should not care about disk capacity.
>> What does `smartctl -a ` report (especially sector sizes)?
>> -m
>>> --
>>> Alexander Motin
> It's not even making a mfid* node (it is a 4Kn disk)

Ok, that’s sad (and explains the wrong size calculation as 4096/512=8).

Is this in HBA mode? (Like Alexander suggested, re-/crossflashing using an IT 
firmware might be an option). What controller / firmware image version is it?

-m


> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: How to supress prompt on bc 5.3.1,Re: How to supress prompt on bc 5.3.1

[Michael Butler]

On 6/15/22 18:47, Masachika ISHIZUKA wrote:

   I updated to master-n256084-5dd1f6f1441 (1400061) and this
leads to bc to 5.3.1.
   Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
doesn't work on 5.3.1.  Is there any way to supress prompt ?


This is fixed in 5.3.2:


This version is already available as a port, but it cannot be
built in the base system at the default WARNS level.

I had suggested a different patch that was tested in base and
have re-submitted that patch after noticing the issue with the
current code.


   Thank you for commit.

   'bc' 5.3.3 works fine on master-n256152-ce00b11940a.


There's still some remaining buildworld left-overs in /tmp from this 
series of updates ..


imb@toshi:/home/imb> ll /tmp/*tmp
-rw-r--r--  1 root  wheel  6768 Jun 15 12:18 /tmp/bc_help.txt.XBwzl9An2r.tmp
-rw-r--r--  1 root  wheel  6768 Jun 15 11:26 /tmp/bc_help.txt.zLR884lFpG.tmp
-rw-r--r--  1 root  wheel  5797 Jun 15 12:18 /tmp/dc_help.txt.RGfFwWi2Yh.tmp
-rw-r--r--  1 root  wheel  5797 Jun 15 11:26 /tmp/dc_help.txt.oltK8Dc7mR.tmp
-rw-r--r--  1 root  wheel  3416 Jun 15 12:18 /tmp/lib.bc.NuspIZHi5s.tmp
-rw-r--r--  1 root  wheel  3416 Jun 15 11:26 /tmp/lib.bc.wwZJr98NlN.tmp
-rw-r--r--  1 root  wheel  9069 Jun 15 11:26 /tmp/lib2.bc.5ywBAhZgwg.tmp
-rw-r--r--  1 root  wheel  9069 Jun 15 12:18 /tmp/lib2.bc.D4PYZlxfWk.tmp

commit 695052e is incomplete

[Michael Butler]

After 695052e, the directories compat, dtrace, engines, flua, i18n and 
libxo now get created under /usr. This is one level higher than they 
should be.


The fix appears to be something like ..

diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist
index 9f934976b77..95a711a4418 100644
--- a/etc/mtree/BSD.usr.dist
+++ b/etc/mtree/BSD.usr.dist
@@ -59,7 +59,6 @@
 ..
 ..
 share
-..
 ..
 ..
 ..

Re: git question: How do I push a cherry-pick of someone else's commit?

[Michael Gmelin]

What is the error message?

Did you try “git push -f”

> On 9. Jun 2022, at 21:33, Rick Macklem  wrote:
> 
> I just tried to MFC a commit done to fix my commit by imp@
> and it won't let be push the cherry-pick.
> 
> What's the trick to doing this?
> Or do I need to get Warner to do it?
> If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
> 
> rick
> ps: The stable/13 build will be broken until this gets resolved.
>  I'll revert the MFC if it isn't fixed soon.
> 

Re: commit 99902b1 causes kernel panics

[Michael Butler]

On 6/5/22 02:09, Hans Petter Selasky wrote:

On 6/4/22 23:21, Michael Butler wrote:
On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional 
video adapter, this commit causes a panic when i915kms is loaded :-( 
This adapter does not use any additional firmware.




Does the attached patch fix this problem?


It does - thanks!

Michael

commit 99902b1 causes kernel panics

[Michael Butler]

On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional 
video adapter, this commit causes a panic when i915kms is loaded :-( 
This adapter does not use any additional firmware.


Reverting only this change allows me to run way past it - up to commit 
00b0158d2ca, so far.


All modules were recompiled to match.

/var/crash/core.txt contains ..

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x19
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808abe54
stack pointer   = 0x0:0xfe011920e9b0
frame pointer   = 0x0:0xfe011920e9b0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 1274 (Xorg)
trap number = 12
panic: page fault
cpuid = 3
time = 1654274788
Uptime: 57s
Dumping 749 out of 16251 
MB:..3%..11%..22%..33%..41%..52%..62%..71%..82%..92%


__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  0x808b0e88 in dumpsys (di=0x0)
at /usr/src/sys/x86/include/dump.h:87
#3  doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:430
#4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537
#5  0x808b12fc in vpanic (fmt=,
ap=ap@entry=0xfe011920e810) at 
/usr/src/sys/kern/kern_shutdown.c:975

#6  0x808b1183 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:899
#7  0x80c8712c in trap_fatal (frame=frame@entry=0xfe011920e8f0,
eva=25) at /usr/src/sys/amd64/amd64/trap.c:942
#8  0x80c874d6 in trap_pfault (frame=0xfe011920e8f0,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/include/cpufunc.h:411
#9  
#10 _rw_wowned (c=0x19) at /usr/src/sys/kern/kern_rwlock.c:270
#11 0x80bf1a0a in vm_page_busy_acquire (m=0xfe0005affec8,
allocflags=allocflags@entry=16) at /usr/src/sys/vm/vm_page.c:888
#12 0x8271b9a1 in lkpi_vmf_insert_pfn_prot_locked (
vma=0xf8015c3bc300, addr=, pfn=,
prot=24) at /usr/src/sys/compat/linuxkpi/common/src/linux_page.c:297
#13 0x8252d390 in remap_io_mapping () from /boot/modules/i915kms.ko
#14 0x826449c6 in vm_fault_gtt () from /boot/modules/i915kms.ko
#15 0x82714e56 in linux_cdev_pager_populate (
vm_obj=0xf80154cd1b58, pidx=,
fault_type=, max_prot=,
first=0xfe011920ec20, last=0xfe011920ec38)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:692
#16 0x80bdb732 in vm_pager_populate (object=0x19,
object@entry=0xfe011920ebb0, pidx=16, fault_type=1024,
first=0xfe011920ec20, last=0xfe011920ec38,
max_prot=) at /usr/src/sys/vm/vm_pager.h:182
#17 vm_fault_populate (fs=0xfe011920ecc0)
at /usr/src/sys/vm/vm_fault.c:469
#18 vm_fault_allocate (fs=fs@entry=0xfe011920ecc0)
at /usr/src/sys/vm/vm_fault.c:1162
#19 0x80bda47f in vm_fault_object (fs=0xfe011920ecc0,
behindp=0xfe011920ecb4, aheadp=0xfe011920ecbc)
at /usr/src/sys/vm/vm_fault.c:1414
#20 vm_fault (map=map@entry=0xfe012b5233f0,
vaddr=vaddr@entry=35550920704, fault_type=fault_type@entry=2 '\002',
fault_flags=fault_flags@entry=0, m_hold=m_hold@entry=0x0)
at /usr/src/sys/vm/vm_fault.c:1549
#21 0x80bda07d in vm_fault_trap (map=0xfe012b5233f0,
vaddr=, fault_type=,
fault_flags=fault_flags@entry=0, signo=0xfe011920ef00,
ucode=0xfe011920ef04) at /usr/src/sys/vm/vm_fault.c:667
#22 0x80c87345 in trap_pfault 
(frame=frame@entry=0xfe011920ef40,
usermode=true, signo=0xfe011a70b318, 
signo@entry=0xfe011920ef00,

ucode=0x3004, ucode@entry=0xfe011920ef04)
at /usr/src/sys/amd64/amd64/trap.c:846
#23 0x80c86a75 in trap (frame=0xfe011920ef40)
at /usr/src/sys/amd64/amd64/trap.c:385
#24 
#25 0x000839618c9f in ?? ()
Backtrace stopped: Cannot access memory at address 0x820718370
(kgdb)

Re: Bulld failure of editors/libreoffoce only on main (aka -current)

[Michael Butler]

On 5/23/22 12:49, Dima Panov wrote:

My recent -current jail is also have LLVM_DEFAULT=14 and not hit any 
serious issue yet:)


tcberner was initiated exp-run to make llvm13 as default some time ago

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456


I'd caution against adopting llvm14 for the moment.

One apparently architecturally-specific problem with llvm14 on 
rocketlake (Intel Xeon E-2334 here) is a never-ending compilation in 
devel/boost-libs if CPUTYPE is set.


The file libs/atomic/src/find_address_sse41.cpp causes c++ to run 
forever :-( It also seems to spin forever with CPUTYPE set to "native".


I just found this last night but setting CPUTYPE to "ivybridge" or 
leaving it unset allows it to run to completion,


Michael

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Sat, May 14, 2022, 21:40 Michael Schuster  wrote:
>
> On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber  wrote:
> >
> > On Thu, 12 May 2022, at 07:12, Michael Schuster wrote:
> > > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber  
> > > wrote:
> > >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> > >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> > >> > regular files and empty directories). Booting into that BE didn't work
> > >> > either, I got errors about missing "/dev/" files (can't recall the
> > >> > exact names).
> > >> >
> > >> > What do you guys (plural ;-)) think?
> > >
> > > Hi Dave,
> > > thx for your perseverance :-)
> > >
> > > I have (at least) one question for you before I attempt this:
> > > where do I get these .txz files?
> >
> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/
> > https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/
> >
> > > should devfs be in /etc/fstab? in my current BE, it isn't ...
> >
> > this is the bare minimum I used. NB my partitions have artisanal
> > GPT labels, yours will probably be different.
> >
> > # DeviceMountpoint  FStype  Options 
> > DumpPass#
> > #/dev/gpt/swap0 noneswapsw  
> > 0   0
> > /dev/gpt/efiboot/boot/efi   msdosfs 
> > rw,late,longnames   0   0
> > tmpfs   /tmptmpfs   
> > rw,mode=01777,size=120g 0   0
> >
> > thats all I needed to boot to userland & login. I'm reasonably sure that,
> > assuming you have a default zfs install, you'd not need anything in 
> > /etc/fstab
> > to boot.
> >
> > > if so: do you have an example of such a line? In the instances I looked
> > > up, I wasn't quite able to make it work (but perhaps that's a dead end
> > > anyway).
> > >
> > >> # bectl activate -t vanilla
> > >
> > > does that ("activate -t") work on UEFI systems? The last time I used it
> > > (at least a year ago), it wasn't.
> >
> > Yes it does here. failing that just use `bectl activate`. The -t is
> > a very nice addition.
> >
> > Well, we're definitely on the FreeBSD-current email list here, so it's
> > definitely in CURRENT, and 13.1 RC.
>
> Dave, all:
>
> findings:
> 1) temporary activation doesn't work for me: bectl accepts the option
> but there's no effect I noticed(*), beadm refuses the option.


update (answered in a different thread, but to keep this here too):
temporary activation does in fact work, it's not reflected in the list
of BEs presented at the boot menu

I'm still working on a "full" installation of what I have on the
running BE into the new one ("vanilla") - if you have any ideas, I
welcome them :-)

thx
Michael
>
> 2) booting into 'vanilla' worked - I got into a root shell on the console.
>
> Since I copied the files you mention (/etc/fstab /etc/rc.conf
> /boot/loader.conf) unchanged, that looks good.
>
> so ... this is probably a good starting point (again ;-)).
>
> I rebooted into the last "good" BE, mounted vanilla a clone of vanilla
> on /mnt (with vanilla a point to start again if anything goes wrong)
> and started with "pkg -r /mnt install pkg" ...
>
> but I admit it's getting late today, so I'll be lazy and ask if you
> have any further recommendations - I've come to expect them to work
> nicely :-) (and yes, I am grateful!)
>
> *) unless the first BE to be shown when I select 'boot environments'
> at boot isn't in fact the active one
>

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Sat, May 14, 2022 at 10:30 PM Mark Millard  wrote:
>
> Michael Schuster  wrote on
> Date: Sat, 14 May 2022 21:40:56 +0200 :
>
> > findings:
> > 1) temporary activation doesn't work for me: bectl accepts the option
> > but there's no effect I noticed(*), beadm refuses the option.
> > . . .
> > *) unless the first BE to be shown when I select 'boot environments'
> > at boot isn't in fact the active one
[...]
>
> I expect that you will find the temporary activation worked just
> fine, as it always has for me:

you are right - it did!
thanks for the advice (a bit surprising, but who am I to judge ;-))

cheers
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber  wrote:
>
> On Thu, 12 May 2022, at 07:12, Michael Schuster wrote:
> > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber  
> > wrote:
> >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> >> > regular files and empty directories). Booting into that BE didn't work
> >> > either, I got errors about missing "/dev/" files (can't recall the
> >> > exact names).
> >> >
> >> > What do you guys (plural ;-)) think?
> >
> > Hi Dave,
> > thx for your perseverance :-)
> >
> > I have (at least) one question for you before I attempt this:
> > where do I get these .txz files?
>
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/
> https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/
>
> > should devfs be in /etc/fstab? in my current BE, it isn't ...
>
> this is the bare minimum I used. NB my partitions have artisanal
> GPT labels, yours will probably be different.
>
> # DeviceMountpoint  FStype  Options   
>   DumpPass#
> #/dev/gpt/swap0 noneswapsw
>   0   0
> /dev/gpt/efiboot/boot/efi   msdosfs 
> rw,late,longnames   0   0
> tmpfs   /tmptmpfs   
> rw,mode=01777,size=120g 0   0
>
> thats all I needed to boot to userland & login. I'm reasonably sure that,
> assuming you have a default zfs install, you'd not need anything in /etc/fstab
> to boot.
>
> > if so: do you have an example of such a line? In the instances I looked
> > up, I wasn't quite able to make it work (but perhaps that's a dead end
> > anyway).
> >
> >> # bectl activate -t vanilla
> >
> > does that ("activate -t") work on UEFI systems? The last time I used it
> > (at least a year ago), it wasn't.
>
> Yes it does here. failing that just use `bectl activate`. The -t is
> a very nice addition.
>
> Well, we're definitely on the FreeBSD-current email list here, so it's
> definitely in CURRENT, and 13.1 RC.

Dave, all:

findings:
1) temporary activation doesn't work for me: bectl accepts the option
but there's no effect I noticed(*), beadm refuses the option.
2) booting into 'vanilla' worked - I got into a root shell on the console.

Since I copied the files you mention (/etc/fstab /etc/rc.conf
/boot/loader.conf) unchanged, that looks good.

so ... this is probably a good starting point (again ;-)).

I rebooted into the last "good" BE, mounted vanilla a clone of vanilla
on /mnt (with vanilla a point to start again if anything goes wrong)
and started with "pkg -r /mnt install pkg" ...

but I admit it's getting late today, so I'll be lazy and ask if you
have any further recommendations - I've come to expect them to work
nicely :-) (and yes, I am grateful!)

*) unless the first BE to be shown when I select 'boot environments'
at boot isn't in fact the active one

cheers
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber  wrote:

> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> > regular files and empty directories). Booting into that BE didn't work
> > either, I got errors about missing "/dev/" files (can't recall the
> > exact names).
> >
> > What do you guys (plural ;-)) think?
>

Hi Dave,
thx for your perseverance :-)

I have (at least) one question for you before I attempt this:

> this works for me:
>
> # zfs create -o canmount=noauto -o mountpoint=/ zroot/ROOT/vanilla
> # bectl mount vanilla /mnt
> # cd /some/path/to/sets/
> # tar xzpf ./kernel.txz -C /mnt/
> # tar xzpf ./base.txz -C /mnt/
>

showing my ignorance here: where do I get these .txz files?

# tzsetup -C /mnt UTC
> # pwd_mkdb -p -d /mnt/etc /mnt/etc/master.passwd
> # ln -s /usr/home /mnt/home
> ### copy in & amend /etc/fstab /etc/rc.conf /boot/loader.conf as required
>

should devfs be in /etc/fstab? in my current BE, it isn't ...
if so: do you have an example of such a line? In the instances I looked up,
I wasn't quite able to make it work (but perhaps that's a dead end anyway).

# bectl activate -t vanilla
>

does that ("activate -t") work on UEFI systems? The last time I used it (at
least a year ago), it wasn't.

Thx
Michael

# reboot
>
> try that and let us know what, if any, errors you get?
>
> A+
> Dave
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Mon, May 9, 2022 at 10:04 AM Dave Cottlehuber  wrote:
>
> On Mon, 9 May 2022, at 06:25, Michael Schuster wrote:
> > On Fri, May 6, 2022 at 12:15 AM Wes Maag  wrote:
> >>
> >>
> >> On Thu, May 5, 2022 at 4:10 PM Michael Schuster 
> >>  wrote:
> >>> Hi all,
> >>>
> >>> while still working (slowly) on an answer to my own question on the
> >>> right workflow to keep current up to date reliably with boot
> >>> environments, I noticed that after creating and mounting a new BE,
> >>> that new BE's /dev (eg /mnt/dev) is very sparsely populated:
>
> This is expected; /dev would usually be empty until devfs is mounted.

You're right - I have a few "historical" BEs lying around, and for
most of them, /dev/ is empty. As you guess (below), for the others,
they're most likely remnants of the first time I tried to do "pkg -c
/mnt" without /mnt/dev being mounted. (as an aside: when was that
changed? I know for sure that this hasn't always been necessary)

I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
regular files and empty directories). Booting into that BE didn't work
either, I got errors about missing "/dev/" files (can't recall the
exact names).

What do you guys (plural ;-)) think?

Thx
Michael

>
> Looking into the unmounted /dev via the last zfs snapshot of your
> / filesystem should also be empty:
>
> $ ls -AFGhl /.zfs/snapshot/$(ls -rt /.zfs/snapshot/ | tail -1)/dev
> total 0
>
> If it's not I'd guess these are stray garbage from BE experiments
> where /dev wasn't mounted and various scripts & tools tried to pipe
> via /dev/{fd,zero,null,...}.
>
> If you created a hypothetical "empty" BE from scratch, unpacked
> src tarballs into it, it would also be empty.
>
> A+
> Dave



-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

On Fri, May 6, 2022 at 12:15 AM Wes Maag  wrote:

>
>
> On Thu, May 5, 2022 at 4:10 PM Michael Schuster 
> wrote:
>
>> Hi all,
>>
>> while still working (slowly) on an answer to my own question on the
>> right workflow to keep current up to date reliably with boot
>> environments, I noticed that after creating and mounting a new BE,
>> that new BE's /dev (eg /mnt/dev) is very sparsely populated:
>>
>> [22:44:45: ~ 0] $ ll /mnt/dev
>> total 20
>> 9 dr-xr-xr-x   4 root  wheel   7 Apr 18 00:35 .
>> 9 drwxr-xr-x  23 root  wheel  30 May  5 22:44 ..
>> 1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 fd
>> 1 lrwxr-xr-x   1 root  wheel  12 Apr 17 20:41 log -> /var/run/log
>> 1 -rw-r--r--   1 root  wheel  63 May  3 22:19 null
>> 1 -rw-r--r--   1 root  wheel   1 May  3 22:18 null.bak
>> 1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 shm
>> [22:44:48: ~ 0] $
>>
>> (no matter whether I use "beadm create" or "bectl create -r")
>>
>> I can then mount devfs:
>> # mount -t devfs devfs /mnt/dev
>>
>> and it will look (and work) as expected (eg for "pkg -c /mnt update"
>> (*)) ... as long as the BE is mounted.
>> When I try to boot from (into?) that BE though, it fails, and on the
>> console I can see messages about missing /dev/... entries. I sneaked a
>> peek into beinstall.sh, found no inspiration there, I'm afraid.
>>
>> I believe I noticed this apparent requirement to mount devfs
>> separately not so long ago ... definitely this year, while I've been
>> experimenting with boot environments for quite a bit longer. Was I
>> just lucky all along, or did something change ... and, more
>> importantly, how do I make my boot environments bootable again?
>>
>> TIA for hints, pointers, advice
>> Michael
>>
>> *) I first noticed something was amiss when "pkg -c /mnt ... "
>> complained about /dev/null missing, IIRC ...
>>
>>
> getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev
> to contain anything after a create.
>
> Why it is not populated on boot seems odd to me though... It's possible,
> if you created a deep boot environment, you created a pool/ROOT/dev dataset
> and it is overwriting the initial /dev from boot (I have not tested this
> theory). Tough to say without more information about the BE layout, and
> maybe a look at fstab.
>
> FWIW I typically run "pkg -r /tmp/be_mount." after mounting with
> "bectl mount" which should give you the same effect as -c without the
> rooted devfs requirement
>

thx Wes and others for feedback, on or off list.
For now I'd like to keep the simplest setting in focus:

When I do:
# beadm create new_BE
# beadm activate new_BE
# reboot

I would expect new_BE to boot and also otherwise to all intents and
purposes behave just like the previous BE I just "left"; similarly, if I
skip the 'activate' step and select new_BE from the FreeBSD boot menu.

thx
Michael
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: FreeBSD, boot environments and /dev

[Michael Schuster]

Hi Wes,

finally I get round to responding (below) ...

On Fri, May 6, 2022 at 12:15 AM Wes Maag  wrote:
>
>
>
> On Thu, May 5, 2022 at 4:10 PM Michael Schuster  
> wrote:
>>
>> Hi all,
>>
>> while still working (slowly) on an answer to my own question on the
>> right workflow to keep current up to date reliably with boot
>> environments, I noticed that after creating and mounting a new BE,
>> that new BE's /dev (eg /mnt/dev) is very sparsely populated:
>>
>> [22:44:45: ~ 0] $ ll /mnt/dev
>> total 20
>> 9 dr-xr-xr-x   4 root  wheel   7 Apr 18 00:35 .
>> 9 drwxr-xr-x  23 root  wheel  30 May  5 22:44 ..
>> 1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 fd
>> 1 lrwxr-xr-x   1 root  wheel  12 Apr 17 20:41 log -> /var/run/log
>> 1 -rw-r--r--   1 root  wheel  63 May  3 22:19 null
>> 1 -rw-r--r--   1 root  wheel   1 May  3 22:18 null.bak
>> 1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 shm
>> [22:44:48: ~ 0] $
>>
>> (no matter whether I use "beadm create" or "bectl create -r")
>>
>> I can then mount devfs:
>> # mount -t devfs devfs /mnt/dev
>>
>> and it will look (and work) as expected (eg for "pkg -c /mnt update"
>> (*)) ... as long as the BE is mounted.
>> When I try to boot from (into?) that BE though, it fails, and on the
>> console I can see messages about missing /dev/... entries. I sneaked a
>> peek into beinstall.sh, found no inspiration there, I'm afraid.
>>
>> I believe I noticed this apparent requirement to mount devfs
>> separately not so long ago ... definitely this year, while I've been
>> experimenting with boot environments for quite a bit longer. Was I
>> just lucky all along, or did something change ... and, more
>> importantly, how do I make my boot environments bootable again?
>>
>> TIA for hints, pointers, advice
>> Michael
>>
>> *) I first noticed something was amiss when "pkg -c /mnt ... "
>> complained about /dev/null missing, IIRC ...
>> --
>> Michael Schuster
>> http://recursiveramblings.wordpress.com/
>> recursion, n: see 'recursion'
>>
>
> getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev to 
> contain anything after a create.

as I wrote, I *thought* that worked automatically ... apparently not.

> Why it is not populated on boot seems odd to me though... It's possible, if 
> you created a deep boot environment, you created a pool/ROOT/dev dataset
> and it is overwriting the initial /dev from boot (I have not tested this 
> theory). Tough to say without more information about the BE layout, and maybe 
> a look at fstab.

(after beadm create and beadm mount):
$ zfs list -tall
[...]
tank/ROOT/BE_20220507_171901_adm
184K   397G  17.9G  /
tank/ROOT/BE_20220507_171901_adm/ports
  8K   397G  1.92G  /usr/ports
tank/ROOT/BE_20220507_171901_adm/src
  8K   397G  2.57G  /usr/src

$ mount | grep dev
devfs on /dev (devfs)
/dev/nvd0p1 on /boot/efi (msdosfs, local)
devfs on /compat/linux/dev (devfs)
fdescfs on /compat/linux/dev/fd (fdescfs)
tmpfs on /compat/linux/dev/shm (tmpfs, local)

$ cat /etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/nvd0p1 /boot/efi   msdosfs rw  2   2
/dev/nvd0p3 noneswapsw  0   0
proc/proc   procfs  rw  0   0

> FWIW I typically run "pkg -r /tmp/be_mount." after mounting with "bectl 
> mount" which should give you the same effect as -c without the rooted devfs 
> requirement

good point ... until now, "pkg -c" worked as expected, I never looked
further ;-) I'll keep it in mind!

I expected (perhaps naively) that with -c, pkg would be using the
"new" stuff I'd installed in the previous step (see below), not the
currently running bits ... Any thoughts on that?

One more data point, perhaps that's relevant:
I've been updating these BEs using a sequence of installing freshly
built current into /mnt (using "DESTDIR=/mnt"), following by a few
ports (drm-devel, primarily), and then doing pkg update/upgrade.

thx
Michael

-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

FreeBSD, boot environments and /dev

[Michael Schuster]

Hi all,

while still working (slowly) on an answer to my own question on the
right workflow to keep current up to date reliably with boot
environments, I noticed that after creating and mounting a new BE,
that new BE's /dev (eg /mnt/dev) is very sparsely populated:

[22:44:45: ~ 0] $ ll /mnt/dev
total 20
9 dr-xr-xr-x   4 root  wheel   7 Apr 18 00:35 .
9 drwxr-xr-x  23 root  wheel  30 May  5 22:44 ..
1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 fd
1 lrwxr-xr-x   1 root  wheel  12 Apr 17 20:41 log -> /var/run/log
1 -rw-r--r--   1 root  wheel  63 May  3 22:19 null
1 -rw-r--r--   1 root  wheel   1 May  3 22:18 null.bak
1 drwxr-xr-x   2 root  wheel   2 Apr 18 00:35 shm
[22:44:48: ~ 0] $

(no matter whether I use "beadm create" or "bectl create -r")

I can then mount devfs:
# mount -t devfs devfs /mnt/dev

and it will look (and work) as expected (eg for "pkg -c /mnt update"
(*)) ... as long as the BE is mounted.
When I try to boot from (into?) that BE though, it fails, and on the
console I can see messages about missing /dev/... entries. I sneaked a
peek into beinstall.sh, found no inspiration there, I'm afraid.

I believe I noticed this apparent requirement to mount devfs
separately not so long ago ... definitely this year, while I've been
experimenting with boot environments for quite a bit longer. Was I
just lucky all along, or did something change ... and, more
importantly, how do I make my boot environments bootable again?

TIA for hints, pointers, advice
Michael

*) I first noticed something was amiss when "pkg -c /mnt ... "
complained about /dev/null missing, IIRC ...
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Michael Schuster]

On Thu, Apr 28, 2022 at 10:43 AM Christoph Moench-Tegeder
 wrote:
>
> ## Michael Schuster (michaelspriv...@gmail.com):
>
> > $subject happened to me just now on current. I researched it on the
> > internet,
>
> Don't look that far, the answer is in UPDATING:
>  20220426:
>   AFFECTS: users of deskutils/grantleetheme

thx all - that was the relevant hint here.

regards
Michael
>
> Regards,
> Christoph
>
> --
> Spare Space



-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Michael Gmelin]

On Thu, 28 Apr 2022 12:31:06 +0200
Stefan Esser  wrote:

> Am 28.04.22 um 09:11 schrieb Baptiste Daroussin> It is 2 things, it
> is a port problem of maintainers who do not check for
> > upgradability of their packages, and it can also been seen as
> > something pkg can deal with, but a complicated case, so I don't
> > know yet how.
> > 
> > The main issue is a file in vX which becomes a directory in vX+1
> > which goes in the way pkg does extract files to be as atomic as
> > possible.  
> 
> This case could be caught and dealt with by removing the file or by
> moving it out of the way (to a temporary name to allow it to be
> recovered if the subsequent steps fail or to be deleted if they
> succeed).
> 
> Further special conditions may apply - but since there is no way a
> file and directory can exist under the same name (on FreeBSD, at
> least), it is safe to assume that the file will not be kept when the
> package is installed.

The opposite case seems more interesting/problematic.

-m

-- 
Michael Gmelin

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Michael Schuster]

Chris,

thx for your response. However 

On Thu, Apr 28, 2022 at 4:19 AM Chris  wrote:
>
> On 2022-04-27 12:59, Michael Schuster wrote:
> > Hi,
> >
> > $subject happened to me just now on current. I researched it on the
> > internet, the answer to this issue seems to be a universal "uninstall
> > and install the package" which seems to have worked in all cases I saw
> > it suggested.
> >
> > I'm trying to embed this command into a script and would like to avoid
> > manual intervention (I have to admit, this is the first time I've
> > encountered this error in the two years I've been doodling with
> > FreeBSD again) ...
> > Is anything more known about this error behaviour, and what I can do
> > to avoid it?
> >
> > TIA
> > Michael
> >
> > PS: in case it matters: the full path shown in the error message is
> > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG,
> > the package being extracted is grantleetheme-22.04.0
> This looks more a case for the Maintainer of the GrantleeTheme than for
> current@

 ... maybe. OTOH, the instances I found mentioned on the 'net are all
about different packages:

eg:
https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767

I feel there's something different at work here than just one
maintainer's oversight.

Thx
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

"pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Michael Schuster]

Hi,

$subject happened to me just now on current. I researched it on the
internet, the answer to this issue seems to be a universal "uninstall
and install the package" which seems to have worked in all cases I saw
it suggested.

I'm trying to embed this command into a script and would like to avoid
manual intervention (I have to admit, this is the first time I've
encountered this error in the two years I've been doodling with
FreeBSD again) ...
Is anything more known about this error behaviour, and what I can do
to avoid it?

TIA
Michael

PS: in case it matters: the full path shown in the error message is
/usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG,
the package being extracted is grantleetheme-22.04.0
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

RE: Chasing OOM Issues - good sysctl metrics to use?

[Michael Jung]

Hi:

I guess I'm kind of high jacking this thread but I think what I'm
going to ask is close enough to the topic at hand to ask instead
of starting a new thread and referencing this one.

I use sysutils/monit to what running processes and then restart them
I as I want.

I use  protect(1) to make sure that monit would not dies.

In /etc/rc.local "protect -i monit"

protect seems in the end simply call

 PROC_SPROTECT with the INHERIT flag and as documented in procctl(2)

So I followed a bit of code I guess that cools if I got it right but I know
about .0001% about system internals.

Can anyone speak to how protect(1) works and is it in itself is prone to what 
has been discussed?

For my use case is protect "good enough" or do I really need to tuning like has 
been talked about?

If protect is the right answer and someone could explain how it does
Its thing at a slighter higher technical barrier I would love to hear
more about why I'm either doing it wrong, that that what I'm doing it ok, or
why I should really be doing something completely different and the why I
should be doing it differently.

I suspect there are many that would like to know this but would never ask,
at least not on list.

Always the seeker of new knowledge.

Thanks in advance.

--mikej





CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Mark Millard
Sent: Saturday, April 23, 2022 3:32 PM
To: Pete Wright 
Cc: freebsd-current 
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?

On 2022-Apr-23, at 10:26, Pete Wright 
mailto:p...@nomadlogic.org>> wrote:

> On 4/22/22 18:46, Mark Millard wrote:
>> On 2022-Apr-22, at 16:42, Pete Wright 
>> mailto:p...@nomadlogic.org>> wrote:
>>
>>> On 4/21/22 21:18, Mark Millard wrote:
 Messages in the console out would be appropriate
 to report. Messages might also be available via
 the following at appropriate times:
>>> that is what is frustrating. i will get notification that the processes are 
>>> killed:
>>> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>> Those messages are not reporting being out of swap
>> as such. They are reporting sustained low free RAM
>> despite a number of less drastic attempts to gain
>> back free RAM (to above some threshold).
>>
>> FreeBSD does not swap out the kernel stacks for
>> processes that stay in a runnable state: it just
>> continues to page. Thus just one large process
>> that has a huge working set of active pages can
>> lead to OOM kills in a context were no other set
>> of processes would be enough to gain the free
>> RAM required. Such contexts are not really a
>> swap issue.
>
> Thank you for this clarification/explanation - that totally makes sense!
>
>>
>> Based on there being only 1 "killed:" reason,
>> I have a suggestion that should allow delaying
>> such kills for a long time. That in turn may
>> help with investigating without actually
>> suffering the kills during the activity: more
>> time with low free RAM to observe.
>
> Great idea thank-you! and thanks for the example settings and descriptions as 
> well.
>> But those are large but finite activities. If
>> you want to leave something running for days,
>> weeks, months, or whatever that produces the
>> sustained low free RAM conditions, the problem
>> will eventually happen. Ultimately one may have
>> to exit and restart such processes once and a
>> while, exiting enough of them to give a little
>> time with sufficient free RAM.
> perfect - since this is a workstation my run-time for these processes is 
> probably a week as i update my system and pkgs over the weekend, then dog 
> food current 

Re: 'set but unused' breaks drm-*-kmod

[Michael Butler]

On 4/21/22 03:42, Emmanuel Vadot wrote:


  Hello Michael,

On Wed, 20 Apr 2022 23:39:12 -0400
Michael Butler  wrote:


Seems this new requirement breaks kmod builds too ..

The first of many errors was (I stopped chasing them all for lack of
time) ..

--- amdgpu_cs.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26:
error: variable 'priority' set but not used
[-Werror,-Wunused-but-set-variable]
  enum drm_sched_priority priority;
  ^
1 error generated.
*** [amdgpu_cs.o] Error code 1



  How are you building the port, directly or with PORTS_MODULES ?
  I do make passes on the warning for drm and I did for set-but-not-used
case but unfortunately this option doesn't exists in 13.0 so I couldn't
apply those in every branch.


I build this directly on -current. I'm guessing that these are what 
triggered this behaviour:


commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1
Author: John Baldwin 
Date:   Mon Apr 18 16:06:27 2022 -0700

Make -Wunused-but-set-variable a fatal error for clang 13+ for 
kernel builds.


Reviewed by:imp, emaste
Differential Revision:  https://reviews.freebsd.org/D34949

commit 615d289ffefe2b175f80caa9b1e113c975576472
Author: John Baldwin 
Date:   Mon Apr 18 16:06:14 2022 -0700

Re-enable set but not used warnings for kernel builds.

make tinderbox now passes with this warning enabled as a fatal error,
so revert the change to hide it in preparation for making it fatal.

This reverts commit e8e691983bb75e80153b802f47733f1531615fa2.

Reviewed by:imp, emaste
Differential Revision:  https://reviews.freebsd.org/D34948

'set but unused' breaks drm-*-kmod

[Michael Butler]

Seems this new requirement breaks kmod builds too ..

The first of many errors was (I stopped chasing them all for lack of 
time) ..


--- amdgpu_cs.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: 
error: variable 'priority' set but not used 
[-Werror,-Wunused-but-set-variable]

enum drm_sched_priority priority;
^
1 error generated.
*** [amdgpu_cs.o] Error code 1

advice sought: workflow with -CURRENT and amd GPU [Re: -CURRENT hangs since at least 2022-04-04]

[Michael Schuster]

Hi,

I'm highjacking and re-purposing the previous thread, I hope that's OK
(I did change the subject ;-)) - I'm keeping some of the previous
contents for reference.

I have similar HW to OP (Ryzen 7 4700 w. Renoir Graphics), and have
been using a similar approach to keep the machine up to date - or so I
suspect. Still, after a while (several months), I end up with one or
more of these:
- I get some sort of panic in DRM (at startup or, currently, at shutdown)
- when I boot into to a previous BE to attempt a fix and then again
reboot into the current one, I get tons of messages like this
 "... kernel: KLD iic.ko: depends on kernel - not available or
version mismatch
  ... kernel: linker_load_file: /boot/kernel/iic.ko - unsupported file type"
   and computer refuses to accept input (let alone start X)

and some others I don't recall right now.

Before I ask for advice (see below), let me explain the approaches
I've taken so far. I install with ZFS from the beginning, current boot
env is "N". These are outlines, not exact commands:

I) never touch the current BE, always update a new one:
  1) given current BE N, I create a new BE N+1 and mount it on /mnt,
  2) 'cd /usr/src; git pull; sudo make DESTDIR=/mnt ... (build, install, etc)'
  3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make DESTDIR=/mnt install'
  4) beadm activate BE N+1; reboot

II) keep a "new" BE as backup/fallback, update current BE:
  1) given current BE N, I create a new BE N+1 (mounting not required)
(this is the intended 'fallback')
  2) 'cd /usr/src; git pull"; then "make" as described in the Handbook
"24.6. Updating FreeBSD from Source"
  3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make install'
  4) reboot

in both scenarios(sp?), I do "pkg update; pkg upgrade" from time to
time (also following the resp. approach shown above).

I suspect that I'm missing something fundamental in my approaches -
does anyone have a (for them) foolproof approach along these lines, or
can someone show me what I'm missing in either of mine (in private, if
you prefer)?

TIA for all and any advice
Michael

On Mon, Apr 18, 2022 at 9:33 PM Pete Wright  wrote:
>
>
>
> On 4/18/22 12:23, filis+fbsdcurr...@filis.org wrote:
> > Hi,
> >
> > I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U
> > with Radeon Graphics", since it didn't work on 13R.
> > I use Boot environments and on 2022-04-04 I updated it and it started
> > to completely freeze under X (I haven't tried letting it run without
> > X) after a few dozen minutes.
> [...]
>
>
> After updating your CURRENT environment did you rebuild the drm-kmod
> package?  that's usually required as the LKPI is much more of a moving
> target on that branch compared to STABLE or RELEASE.  i have a pretty
> much identical setup and building/installing drm-devel-kmod has been
> working flawlessly for quite a while.
>
> after building/installing my latest world i do following (this is from a
> local script i use when rebuilding):
>
> cd $PORTS/graphics/drm-devel-kmod
> sudo pkg unlock -y drm-devel-kmod
> sudo make package
> sudo pkg upgrade -y work/pkg/*.pkg
> sudo pkg lock -y drm-devel-kmod
>
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: recover deleted file

[Michael Gmelin]

> On 17. Apr 2022, at 06:20, Peter Jeremy  wrote:
> 
> On 2022-Apr-17 01:13:02 +0300, Sami Halabi  wrote:
>> I understand its hard to undelete since no one designed UFS/ZFS to do so..
>> that why I asked in later replies to see if someone would step in and
>> implement such a "feature" and I suggested some directions/thoughts.
> 
> As you point out, neither UFS nor ZFS were designed to support an
> "undelete" function: Once an inode has no references (open files
> or directory entries), the inode and all associated data blocks are
> returned to the free list and could be used by a subsequent allocation.
> 
> What semantics would you like UFS or ZFS to implement instead?  Is it
> just that the inode and associated data blocks should stay in limbo
> for some period?  If, what controls the period?  What if a file is
> truncated to 0 or overwritten before being unlinked?  How much would
> you be willing to pay for "undelete" functionality?
> 
>> As soren@ suggested in later reply it maybe would be easier to implement
>> custom rm script that moves files to "Recycle bin" directory (and empty it
>> after some period)
> 
> Alternatively, you could alias "rm" to "rm -i".
> 
>> but as a programmer I know that perfection is needed :)
>> so It might start as a simple task and end in many what-if's
>> (unfortunattly I did my last C programming in late 2003!).
> 
> This doesn't need to be C.  You could do this in your scripting
> language of choice.  Or you could offer to pay someone to do this
> for you.
> 
>> What amzes me is that this "feature" was asked too much in the last decade
>> or two and no one ever implemented it, maybe it's not needed in daily
>> usage, but in disasters it would be super userful, save admins many time
>> and nerves..
> 
> I went rummaging back through my mail archives and it actually doesn't
> seem to come up that often.  You seem to be about the 3rd person this
> century on the lists I read.  I did find a discussion in zfs-discuss
> from May/June 2006 about supporting undelete but it seems that no
> agreement on the desired behaviour was achieved.
> 
>> For now I did some backup tools locally and used chflags to mark them
>> undeletable so I wouldn't do that mistake again,
> 
> You could also consider snapshots - both UFS and ZFS support snapshots.
> 
> If the information is very critical (you mentioned legal consequences)
> then you might like to consider real-time replication of the MySQL redo
> logs to another systems - though that won't necessarily protect you
> from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;

It will, if you keep the binary logs/replication logs around. Combined with 
regular zfs snapshots (on the replicant‘s side) you can do a robust and 
relatively speedy point in time recovery that prevents data loss (ideally, 
access to the main db and the replicant is segregated). Saved me more than once.

Best
Michael

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[Michael Butler]

On 4/16/22 01:22, Gleb Smirnoff wrote:

   Hi Florian, Hi Michael,

On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote:
M> >> I can reproduce this locally, will try to figure out what is going on.
M> >> If you can bisect it, it would be great.
M> >
M> > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed
M> > toggling net.inet6.ip6.source_address_validation makes the issue go away
M> > on latest main.
M>
M> I found this commit and the ipv4 analog also cause packets between
M> non-VNET jails on the same host and to the host itself to be dropped :-(

I see your mails and will look into the problem ASAP.

Meanwhile...

Florian, can you please confirm you are using jails too?

Michael, can you please confirm or decline that you see the packets
that are dropped when you tcpdump on lo0?


All the jails are aliased to share a single bridge interface. That 
results in the route to each jail being on lo0 so .. probably :-)


Michael

Re: recover deleted file

[Michael Gmelin]

> On 16. Apr 2022, at 14:32, Sami Halabi  wrote:
> 
> 
> how to do step 3 /?

E.g., grep for something you know (like a phrase, unique name etc) from the 
file, then dump N times the expected file size from that position into another 
file, open the result in a “robust” text editor and stitch things together.

If your lost file is something binary (or even worse, encrypted), things get a 
lot more complicated of course. There might be tooling for this I’m not aware 
of, the few times this happened to me, lost files where C++ sources that were 
relatively easy to extract manually.

Best
Michael

> 
>> On Sat, Apr 16, 2022 at 2:59 PM Michael Gmelin  wrote:
>> Depends on the kind of file.
>> 
>> You can always:
>> 1. reboot the system into single user mode, mount the fs readonly (important 
>> to not overwrite data you want to recover)
>> 2. dd the partition and into a file
>> 3. find the content of the deleted file in the dump
>> 
>> I was able to recover a complete codebase i deleted accidentally that way a 
>> long time ago.
>> 
>> Good luck
>> Michael
>> 
>>>> On 16. Apr 2022, at 13:52, Sami Halabi  wrote:
>>>> 
>>> 
>>> well.. thats the trivial answer.. the problem is backups is a day before... 
>>> if i can undelete it would save me loss of 1 day offset..
>>> 
>>> anyone?
>>> 
>>>> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz  wrote:
>>>> El día sábado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribió:
>>>> 
>>>> > Hi,
>>>> > is there anyway easy to restore deleted file by accident in UFS
>>>> 
>>>> Yes, restore it from a backup media.
>>>> 
>>>> matthias
>>>> 
>>>> 
>>>> -- 
>>>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ 
>>>> +49-176-38902045
>>>> Public GnuPG key: http://www.unixarea.de/key.pub
>>>> 
>>>> Peace instead of NATO!  Мир вместо НАТО!  Frieden statt NATO! ¡Paz en vez 
>>>> de OTAN!
>>>> 
>>> 
>>> 
>>> -- 
>>> Sami Halabi
>>> Information Systems Engineer
>>> NMS Projects Expert, FreeBSD SysAdmin Expert
>>> Asterisk Expert
> 
> 
> -- 
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert

Re: recover deleted file

[Michael Gmelin]

Depends on the kind of file.

You can always:
1. reboot the system into single user mode, mount the fs readonly (important to 
not overwrite data you want to recover)
2. dd the partition and into a file
3. find the content of the deleted file in the dump

I was able to recover a complete codebase i deleted accidentally that way a 
long time ago.

Good luck
Michael

> On 16. Apr 2022, at 13:52, Sami Halabi  wrote:
> 
> 
> well.. thats the trivial answer.. the problem is backups is a day before... 
> if i can undelete it would save me loss of 1 day offset..
> 
> anyone?
> 
>> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz  wrote:
>> El día sábado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribió:
>> 
>> > Hi,
>> > is there anyway easy to restore deleted file by accident in UFS
>> 
>> Yes, restore it from a backup media.
>> 
>> matthias
>> 
>> 
>> -- 
>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
>> Public GnuPG key: http://www.unixarea.de/key.pub
>> 
>> Peace instead of NATO!  Мир вместо НАТО!  Frieden statt NATO! ¡Paz en vez de 
>> OTAN!
>> 
> 
> 
> -- 
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert

Re: recover deleted file

[Michael Schuster]

On Sat, Apr 16, 2022, 13:24 Sami Halabi  wrote:

> Hi,
> is there anyway easy to restore deleted file by accident in UFS
>

If you used "rm" and didn't take the media offline immediately after, then
no, not only not easy but probably impossible (depending on how active the
FS is)


> Sami
>
> --
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert
>

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[Michael Butler]

On 4/15/22 17:39, Florian Smeets wrote:

On 15.04.22 21:24, tue...@freebsd.org wrote:

On 15. Apr 2022, at 20:20, Florian Smeets  wrote:


Hi,

there seems to be an issue with local IPv6 TCP connections on main. I 
have been seeing this for a couple of months at least. pkg upgr on my 
webserver hosting the pkg repo is very slow, all other hosts can 
connect to the pkg repo just fine. So IPv6 connections from external 
hosts are not affected.


I thought I must have misconfigured something, as my setup is a bit 
weird. Yesterday I noticed the same issue on a different host, turns 
out all my 14.0 hosts seem to be affected, cognet@ could also 
reproduce it on one of his systems.


The service/software used does not seem to matter, I tried with port 
22, 25, 80 and 443.


ICMP and UDP don't seem to be affected. ping6 gets replies 
immediately. And UDP connections with nc -l -u / nc -u don't have any 
delay, sent data is received immediately.


Testing local TCP connections show this:

flo@rp64:~ $ ifconfig dwc0|grep 2003
inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf
flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22
[3 second delay here]
Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] 
succeeded!

SSH-2.0-OpenSSH_8.9 FreeBSD-20220413





I need help debugging this, I don't know how to analyze this further. 
I will start bisecting this, but I thought maybe someone has an idea.

Hi Florian,

I can reproduce this locally, will try to figure out what is going on. 
If you can bisect it, it would be great.


Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed 
toggling net.inet6.ip6.source_address_validation makes the issue go away 
on latest main.


I found this commit and the ipv4 analog also cause packets between 
non-VNET jails on the same host and to the host itself to be dropped :-(


Michael

Re: Deprecating ISA sound cards

[Michael Gmelin]

> On 20. Mar 2022, at 15:45, David Chisnall  wrote:
> 
> On 19 Mar 2022, at 21:24, Chris  wrote:
>> 
>>> On 2022-03-18 09:08, Ed Maste wrote:
>>> ISA sound cards have been obsolete for more than a decade, and it is
>>> (past) time to retire their drivers. This includes the following
>>> drivers/devices:
>>> snd_ad1816  Analog Devices AD1816 SoundPort
>>> snd_ess Ensoniq ESS
>>> snd_guscGravis UltraSound
>>> snd_mss Microsoft Sound System
>>> snd_sbc Creative Sound Blaster
>>> I have a review open to add deprecation notices:
>>> https://reviews.freebsd.org/D34604
>>> I expect to commit this in the near future, then MFC to stable
>>> branches and remove these drivers from main. Please follow up if
>>> there's a reason we should postpone the removal of any of these
>>> drivers.
>> This only hurts from a nostalgic perspective. Those GUS cards were 
>> incredible!
>> I have a board running freebsd that has 2 GUS cards in it running
> 
> Exactly my reaction.  You can tell you’re old when drivers are removed from 
> the tree for mainstream hardware that you never owned but wished that you 
> could afford.
> 

I’ll never give away my GUS classic/GF1 with full 1MB onboard RAM(!). It was 
too much fun to program and tracker/demo support was superb. Plus, red PCBs 
felt really 1337 back then.

That said (and assuming it still works), it's unlikely I would use it with 
anything else but DOS these days.

Cheers
Michael

solved: [Re: CURRENT doesn't recognise synaptics touchpad]

[Michael Schuster]

Hi all,

sometimes, reading documentation does help :-)
I followed the instructions at https://github.com/wulf7/iichid and added
this:

ig4_load="YES"
iicbus_load="YES"

to the already present

iichid_load="YES"

in /boot/loader.conf, and now touchpad works.

cheers!
Michael

On Thu, Mar 3, 2022 at 9:06 PM Michael Schuster 
wrote:

> Hi all,
>
> I have another issue with my recent re-installation to Current: touchpad
> support seems to have vanished. I know it works because the keyboard lights
> up when I touch it, it also works under linux (dual-boot), and it worked
> with the previous installation of FreeBSD, where I installed iichid (and
> others, I guess) from the sources.
>
> I've been searching high and low for things to test or set, with no
> visible success:
> - create an /etc/X11/xorg.conf
> - add or remove various settings from /boot/loader.conf
>
> I have libinput and xf86-input-libinput installed.
>
> TIA for all and any advice/pointers/RTFMs.
>
> cheers
> Michael
> --
> Michael Schuster
> http://recursiveramblings.wordpress.com/
> recursion, n: see 'recursion'
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

CURRENT doesn't recognise synaptics touchpad

[Michael Schuster]

Hi all,

I have another issue with my recent re-installation to Current: touchpad
support seems to have vanished. I know it works because the keyboard lights
up when I touch it, it also works under linux (dual-boot), and it worked
with the previous installation of FreeBSD, where I installed iichid (and
others, I guess) from the sources.

I've been searching high and low for things to test or set, with no visible
success:
- create an /etc/X11/xorg.conf
- add or remove various settings from /boot/loader.conf

I have libinput and xf86-input-libinput installed.

TIA for all and any advice/pointers/RTFMs.

cheers
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[Michael Gmelin]

On Mon, 28 Feb 2022 16:15:45 +0100
FreeBSD User  wrote:

> Hello folks,
> 
> we run at least two poudriere build systems on recent CURRENT boxes
> and one of these poudriere build systems is working within a jail -
> setup via FreeBSD's /etc/jail.conf and by misusing the port ezjail
> for copying/deploying our self-compiled jail binary. The poudriere
> jail uses ZFS and is, to make it short, working like a charme.
> 
> Now we try to setup another poudriere, but this time the base is
> XigmaNAS 12.3.0.4/9009, which is based upon 12.X-RELENG, utilizing
> "bastille". Bastille is up to date (in terms od the XigmaNAS plugin).
> 
> Following the setup we used on the native CURRENT "jailed poudriere"
> builder and also following this reference (for those who want to
> check on this)
> 
> https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
> 
> which seems quite recent and with the exception, that we use "vnet"
> on all of our systems for jails and so does XigmaNAS.
> 
> Starting a building process via poudriere ends up with
> 
> 
> # poudriere bulk -p head -z default -j 123-amd64 -f
> /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating
> the reference jail... done [00:00:01] Mounting system devices for
> 123-amd64-head-default [00:00:01] Warning: Using packages from
> previously failed, or uncommitted, build:
> /mnt/poudriere/data/packages/123-amd64-head-default/.building
> [00:00:01] Mounting ports from: /mnt/poudriere/ports/head [00:00:01]
> Mounting packages from:
> /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01]
> Mounting distfiles from: /mnt/poudriere/ports/distfiles [00:00:01]
> Copying /var/db/ports from:
> /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02]
> Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> /etc/resolv.conf ->
> /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf
> [00:00:02] Starting jail 123-amd64-head-default jail: jail_set:
> Operation not permitted [00:00:02] Cleaning up [00:00:02] Unmounting
> file systems
> 
> poudriere jail -l:
> 
> # poudriere jail -l
> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> 123-amd64 12.3-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> 14:11:32 /mnt/poudriere/jails/130-amd64
> 
> The jail.conf for this specific jail is as follows:
> 
> [...]
> pulverfass-001 {
> devfs_ruleset = 13;
> enforce_statfs = 1;
> exec.clean;
> exec.consolelog =
> /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> host.hostname = X;
> mount.devfs;
> mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> securelevel = 0;
> 
> vnet;
> vnet.interface = e0b_bastille4;
> exec.prestart += "jib addm bastille4 igb0";
> exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> destroy bastille4";
> 
> allow.mount;
> allow.mount.fdescfs;
> allow.mount.devfs;
> allow.mount.tmpfs;
> allow.mount.nullfs;
> allow.mount.procfs;
> allow.mount.linsysfs;
> allow.mount.linprocfs;
> allow.mount.zfs;
> 
> allow.chflags;
> allow.raw_sockets;
> allow.socket_af;
> allow.sysvipc;
> 
> linux = new;
> 
> exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> exec.start += "/sbin/zfs mount -a";
> exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> 
> }
> [...]
> 
> Tracking the execution of the build process by issuing
> 
> poudriere -x bulk ...
> 
> and examin the resulting trace doesn' tgive me any hint, the error
> reported above immediately occurs when the jail is about to be
> started:
> 
> + set -u +x
> + jail -c persist 'name=123-amd64-head-default'
> 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> not permitted
> + exit_handler
> [...]
> 
> Searching the net revealed some issues with setting IP4 and IP6 in
> poudriere, but those findings are dated back to 2017 and 2014 and I
> guess this is solved right now.
> 
> The difference between our manually jail.conf driven setup and the
> XigmaNAS/bastille based one is, bastille uses jib/netgraph 

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop  wrote:

> Hi,
>
> Where would this sysctl needed to be documented  for the OP to find it?
>

IMO vt(4) would have been a good place.

>
> Regards,
> Ronald
>
>
> *Van:* Toomas Soome 
> *Datum:* 28 februari 2022 08:29
> *Aan:* Michael Schuster 
> *CC:* FreeBSD CURRENT 
> *Onderwerp:* Re: "vidcontrol -i mode" shows no output except header (in
> search of smaller console font)
>
>
>
> On 28. Feb 2022, at 08:23, Michael Schuster 
> wrote:
>
> Hi Toomas,
>
>
> On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:
>
>>
>>
>> On 27. Feb 2022, at 23:36, Michael Schuster 
>> wrote:
>>
>> Hi all,
>>
>> I'm trying to get a smaller font in my text-consoles (using vt) on my
>> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
>> CURRENT from last week.
>>
>> [...]
>
>
>> UEFI or BIOS setup?
>>
>
> UEFI
>
>
>> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or
>> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will
>> cause the values list to be printed), or use loadfont command with your
>> custom font file (created with vtfontcvt).
>>
>
> I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm
> first time.
>
> Many thanks!
> Michael
>
>
> You are welcome.
>
> rgds,
> toomas
>
>
>
>
>
>

-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

Hi Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:

>
>
> On 27. Feb 2022, at 23:36, Michael Schuster 
> wrote:
>
> Hi all,
>
> I'm trying to get a smaller font in my text-consoles (using vt) on my
> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
> CURRENT from last week.
>
> [...]


> UEFI or BIOS setup?
>

UEFI


> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or
> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will
> cause the values list to be printed), or use loadfont command with your
> custom font file (created with vtfontcvt).
>

I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm
first time.

Many thanks!
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

"vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

Hi all,

I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen
4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
CURRENT from last week.

My research led me to believe that using vidcontrol would help me here, but
however I do try, "vidcontrol -i mode" prints nothing except the header
line, and other "vidcontrol" subcommands give me "Inappropriate ioctl for
device".

I tried a few things
- switched to sc via setting "kern.vty=sc" in /boot/loader.conf, this
caused a hang on reboot
- setting "hw.vga.textmode" to 1
- "kldload vesa"
... and probably a few other things I now forget, all to no effect - I
still get nothing.

I then performed an update from a freshly 'git pulled' source today
(kernel, world, drm-devel-kmod), a simple "vidcontrol" test still shows the
same.

I know it can work because I had a smaller font before I re-installed over
the previous installation (which originally came from ghostbsd in Aug
2020), so - I assume - it can't be rocket science :-)
I'd appreciate further hints/pointers/RTFMs (though I've tried quite a few
of those).

TIA
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'