pkg scripts need updating

[Michael Butler]

After commit aa48259f337100e79933d660fec8856371f761ed to src which 
removed security_daily_compat_var, I get these warnings daily..


aaron.protected-networks.net login failures:

aaron.protected-networks.net refused connections:
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found


Checking for security vulnerabilities in base (userland & kernel):
Database fetched: 2024-05-12T14:16-04:00
0 problem(s) in 0 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found


Checking for packages with security vulnerabilities:
Database fetched: 2024-05-12T14:16-04:00
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found


Checking for packages with mismatched checksums:

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: 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(&tp->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>
rman_reserve_resour

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

freebsd-current@freebsd.org

[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

freebsd-current@freebsd.org

[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

freebsd-current@freebsd.org

[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

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: 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: 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: '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

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: 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: ZFS PANIC: HELP.

[Michael Butler]

On 2/27/22 16:09, Larry Rosenman wrote:

On 02/27/2022 3:03 pm, Michael Butler wrote:

[ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 
14-CURRENT from a recent snapshot, and restore the datasets I care 
about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and
mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended
up setting the debug flag for mrsas in /etc/sysctl.conf ..

dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael


I don't see it:
✖1 ❯ sysctl dev.mfi
dev.mfi.0.keep_deleted_volumes: 0
dev.mfi.0.delete_busy_volumes: 0
dev.mfi.0.%parent: pci3
dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 
subdevice=0x1f17 class=0x010400

dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0
dev.mfi.0.%driver: mfi
dev.mfi.0.%desc: Dell PERC H700 Integrated
dev.mfi.%parent:


 my brain-fade - you're right; it is only there and tunable in the 
mrsas driver.


My apologies :-(

Michael

Re: ZFS PANIC: HELP.

[Michael Butler]

 [ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 14-CURRENT 
from a recent snapshot, and restore the datasets I care about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and mrsas 
drivers to be 'chatty' in this way - IOCTL complaints. I ended up 
setting the debug flag for mrsas in /etc/sysctl.conf ..


dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

[Michael Butler via freebsd-current]

Confirmed. The kernel at ..

FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021

 .. boots successfully.

The kernel at ..

FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021

 .. fails immediately after printing something like ..

Timecounters tick every 1.000 msec
Timecounter "TSC" frequency 701570048 Hz quality 800

 .. but before initializing ipfw as it used to,

Michael

On 12/21/21 12:01, Michael Butler via freebsd-current wrote:

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

     x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

     x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


 Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt🔒 on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
&

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

[Michael Butler via freebsd-current]

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt🔒 on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
> Hi Larry,
>
> This looks like some use-after-free or otherwise corrupted callout
> structure.  Unfortunately the backtrace does not tell what was the
> callout.  When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry Rosenman wrote:
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
>> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021
>> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> amd64
>>
>> VMCORE *IS* available.
>>
>>
>>
>>
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 20
>> fault virtual address   = 0x0
>> fault code 

Re: cross-compiling for i386 on amd64 fails

[Michael Butler via freebsd-current]

I should have been more specific ..

I'm observing that "/usr/src/release/release.sh -c release-i386.conf" 
fails when targeting a i386 build on an amd64 host :-(



On 11/16/21 02:33, Warner Losh wrote:

A meta-build worked for me just now...

Warner

On Mon, Nov 15, 2021 at 9:35 PM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:


Haven't had time to identify which change caused this yet but I now get ..

===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is
incompatible with elf_i386_fbsd
===> cddl/lib/libspl (obj,all,install)
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
--- libavl.so.2 ---
*** [libavl.so.2] Error code 1

make[4]: stopped in /usr/src/cddl/lib/libavl

 imb

cross-compiling for i386 on amd64 fails

[Michael Butler via freebsd-current]

Haven't had time to identify which change caused this yet but I now get ..

===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is 
incompatible with elf_i386_fbsd

===> cddl/lib/libspl (obj,all,install)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- libavl.so.2 ---
*** [libavl.so.2] Error code 1

make[4]: stopped in /usr/src/cddl/lib/libavl

imb

Re: current now panics when starting VBox VM

[Michael Butler via freebsd-emulation]

On 11/3/21 11:13, Konstantin Belousov wrote:

On Wed, Nov 03, 2021 at 11:05:11AM -0400, Michael Butler via freebsd-emulation 
wrote:

On 11/3/21 10:36, Ed Maste wrote:
The kgdb back-trace isn't any more enlightening to me :-(

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) bt
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=) at
/usr/src/sys/kern/kern_shutdown.c:399
#2  0x808cbac5 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:487
#3  0x808cbedb in vpanic (fmt=,
ap=0xfe0129a6a8d0) at /usr/src/sys/kern/kern_shutdown.c:920
#4  0x808cbd33 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:844
#5  0x80ca920c in trap_fatal (frame=frame@entry=0xfe0129a6aac0,
eva=0) at /usr/src/sys/amd64/amd64/trap.c:946
#6  0x80ca95af in trap_pfault (frame=frame@entry=0xfe0129a6aac0,
usermode=false, signo=, signo@entry=0x0, ucode=, ucode@entry=0x0)
 at /usr/src/sys/amd64/include/cpufunc.h:417
#7  0x80ca89bc in trap (frame=0xfe0129a6aac0) at
/usr/src/sys/amd64/amd64/trap.c:443
#8  
#9  strlen () at /usr/src/sys/amd64/amd64/support.S:751
#10 0x808b4d79 in sysctl_kern_proc_pathname (oidp=,
arg1=0xfe0129a6ad8c, arg2=, req=0xfe0129a6acc0) at
/usr/src/sys/kern/kern_proc.c:2330
#11 0x808dc331 in sysctl_root_handler_locked
(oid=oid@entry=0x810cf0e0 ,
arg1=arg1@entry=0xfe0129a6ad8c, arg2=arg2@entry=1,
 req=0xfe0129a6acc0, tracker=tracker@entry=0xfe0129a6ac38) at
/usr/src/sys/kern/kern_sysctl.c:185
#12 0x808db88b in sysctl_root (oidp=,
arg1=0xfe0129a6ad8c, arg1@entry=0xfe0129a6ad80, arg2=1,
arg2@entry=4, req=req@entry=0xfe0129a6acc0)
 at /usr/src/sys/kern/kern_sysctl.c:2305
#13 0x808dbdf3 in userland_sysctl (td=td@entry=0xfe012991a000,
name=name@entry=0xfe0129a6ad80, namelen=4, old=,
oldlenp=,
 inkernel=, inkernel@entry=0, new=0x0, newlen=0,
retval=0xfe0129a6ade8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2462
#14 0x808dbc3c in sys___sysctl (td=0xfe012991a000,
uap=0xfe012991a3f0) at /usr/src/sys/kern/kern_sysctl.c:2335
#15 0x80ca9b5c in syscallenter (td=0xfe012991a000) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#16 amd64_syscall (td=0xfe012991a000, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1191
#17 
#18 0x00080315a71a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffc778
(kgdb)



Try this

commit 2d3f95bd1fd4f71769f60b8037c1ff27c75d8258
Author: Konstantin Belousov 
Date:   Wed Nov 3 17:11:33 2021 +0200

 proc_get_binpath(): return empty string instead of NULL
 
 for strange case where process does not have text.
 
 Sponsored by:   The FreeBSD Foundation

 MFC after:  3 days

diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 2156c5c465ba..d11f651960c0 100644
--- a/sys/kern/kern_proc.c
+++ b/sys/kern/kern_proc.c
@@ -2252,7 +2252,7 @@ proc_get_binpath(struct proc *p, char *binname, char 
**retbuf,
vp = p->p_textvp;
if (vp == NULL) {
PROC_UNLOCK(p);
-   *retbuf = NULL;
+   *retbuf = "";
*freebuf = NULL;
return (0);
}



Interestingly, when I went to log out of KDE afer applying this patch 
and rebuilding the kernel, it also paniced without VBox ruuning. The log 
looks similar but the back-trace points to this possibility .. see 
frames 8 through 10 .


__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" 
(offsetof(struct pcpu,

(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x808cbac5 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3  0x808cbedb in vpanic (fmt=, 
ap=0xfe011c1858d0)

at /usr/src/sys/kern/kern_shutdown.c:920
#4  0x808cbd33 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5  0x80ca920c in trap_fatal (frame=frame@entry=0xfe011c185ac0,
eva=0) at /usr/src/sys/amd64/amd64/trap.c:946
#6  0x80ca95af in trap_pfault 
(frame=frame@entry=0xfe011c185ac0,

usermode=false, signo=, signo@entry=0x0,
ucode=, ucode@entry=0x0)
at /usr/src/sys/amd64/include/cpufunc.h:417
#7  0x80ca89bc in trap (frame=0xfe011c185ac0)
at /usr/src/sys/amd64/amd64/trap.c:443
#8  
#9  strlen () at /usr/src/sys/amd64/amd64/support.S:751
#10 0x808b4d79 in sysctl_kern_proc_pathname (oidp=,
arg1=0xfe011c185d8c, arg2=, req=0xfe011c185cc0)
at /usr/src/sys/kern/kern_proc.c:2330
#11 0x808dc331 in sysctl_root_handler_locked (
oid=oid@entry=0xfff

Re: current now panics when starting VBox VM

[Michael Butler via freebsd-emulation]

On 11/3/21 10:36, Ed Maste wrote:

On Tue, 2 Nov 2021 at 18:32, Michael Butler via freebsd-emulation
 wrote:


Before reporting this, I rebuilt world including kernel, all kmods and
virtualbox itself to no avail :-(


Thanks for confirming.

Now that the WARN_ON noise is disabled by default would you mind
rebuilding a new kernel and obtaining a less-noisy log?


Dump header from device: /dev/ada1s3b
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 853581824
  Blocksize: 512
  Compression: none
  Dumptime: 2021-11-03 10:57:00 -0400
  Hostname: toshi.auburn.protected-networks.net
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 14.0-CURRENT #50 main-dbfe5dd3f9: Wed Nov  3 
10:26:58 EDT 2021


r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
  Panic String: page fault
  Dump Parity: 351593830
  Bounds: 0
  Dump Status: good

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ca54e4
stack pointer   = 0x28:0xfe0129a6ab80
frame pointer   = 0x28:0xfe0129a6ab80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1384 (plasmashell)
trap number = 12
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) 
failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871

WARN_ON(!mutex_is_locked(&dev->struct_mutex))

WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))
panic: page fault
cpuid = 0
time = 1635951420
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621
WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) 
failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&plane->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871
WARNING !drm_modeset_is_locked(&

Re: current now panics when starting VBox VM

[Michael Butler via freebsd-emulation]

On 11/2/21 17:48, Cy Schubert wrote:

In message <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology>,
Greg
V via freebsd-current writes:



On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current
 wrote:

On current as of this morning (I haven't tried to bisect yet) ..

  .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod,
trying to start a VirtualBox VM triggers this panic ..




#16 0x80c81fc8 at calltrap+0x8
#17 0x808b4d69 at sysctl_kern_proc_pathname+0xc9


something something https://reviews.freebsd.org/D32738 ? sysctl_kern_proc_pat
hname was touched recently there.

(Also can someone commit https://reviews.freebsd.org/D30174 ? These warning-f
illed reports are unreadable >_<)


Usually the first thing to do with virtualbox is rebuild it. That usually
fixes any panics I experience here. Of course, make sure your virtualbox
ports subdirs are fully patched, as it's an opportune time to update it too.


Before reporting this, I rebuilt world including kernel, all kmods and 
virtualbox itself to no avail :-(


I agree; most issues I've had in the past have been resolvable using 
this approach. Not this time,


Michael

current now panics when starting VBox VM

[Michael Butler via freebsd-current]

On current as of this morning (I haven't tried to bisect yet) ..

FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
14.0-CURRENT #42 main-a670e1c13a: Tue Nov  2 09:29:28 EDT 2021 
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI 
 amd64


 .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, 
trying to start a VirtualBox VM triggers this panic ..


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ca5564
stack pointer   = 0x28:0xfe011c036b80
frame pointer   = 0x28:0xfe011c036b80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1378 (plasmashell)
trap number = 12
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) 
failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e40542 at drm_atomic_helper_check_modeset+0x242
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at pani

Re: what does "failed to read progbits" mean?

[Michael Butler via freebsd-current]

This seems to have gone away after 
https://freshbsd.org/freebsd/src/commit/70f51f0e474ffe1fb74cb427423a2fba3637544d


Not sure if the bug that commit fixes was the underlying cause,

Michael


On 10/25/21 11:40, Nuno Teixeira wrote:

Same here:
kldxref /boot/kernel
failed to read progbits

But kernel failed to install. I will include log tomorrow, I'm doing a 
clean build with /usr/obj/.. deleted.


Michael Butler via freebsd-current <mailto:freebsd-current@freebsd.org>> escreveu no dia quinta, 21/10/2021 
à(s) 20:14:


Well this is different .. I did a full rebuild (after "rm -rf
/usr/obj/*") this morning and now see ..

===> linux_common (install)
install -T release -o root -g wheel -m 555   linux_common.ko
/boot/kernel/
install -T dbg -o root -g wheel -m 555   linux_common.ko.debug
/usr/lib/debug/boot/kernel/
===> linuxkpi (install)
install -T release -o root -g wheel -m 555   linuxkpi.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linuxkpi.ko.debug
/usr/lib/debug/boot/kernel/
kldxref /boot/kernel
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
kldxref: /boot/kernel/kernel: cannot load DT_RELA section
--
  >>> Installing kernel TOSHI completed on Thu Oct 21 15:05:00 EDT 2021
--

Is something broken or just cosmetic noise?

         imb

what does "failed to read progbits" mean?

[Michael Butler via freebsd-current]

Well this is different .. I did a full rebuild (after "rm -rf 
/usr/obj/*") this morning and now see ..


===> linux_common (install)
install -T release -o root -g wheel -m 555   linux_common.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linux_common.ko.debug 
/usr/lib/debug/boot/kernel/

===> linuxkpi (install)
install -T release -o root -g wheel -m 555   linuxkpi.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linuxkpi.ko.debug 
/usr/lib/debug/boot/kernel/

kldxref /boot/kernel
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
kldxref: /boot/kernel/kernel: cannot load DT_RELA section
--
>>> Installing kernel TOSHI completed on Thu Oct 21 15:05:00 EDT 2021
--

Is something broken or just cosmetic noise?

imb

Re: drm-devel-kmod build failures

[Michael Butler via freebsd-current]

Thanks - that works :-)

On 10/11/21 13:31, Mateusz Guzik wrote:

This should do it (untested):

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 37b268afa..f05de73fa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -117,9 +117,15 @@ dma_buf_close(struct file *fp, struct thread *td)
 return (0);
  }

+#if __FreeBSD_version >= 1400037
+static int
+dma_buf_stat(struct file *fp, struct stat *sb,
+struct ucred *active_cred __unused)
+#else
  static int
  dma_buf_stat(struct file *fp, struct stat *sb,
  struct ucred *active_cred __unused, struct thread *td __unused)
+#endif
  {

 /* XXX need to define flags for st_mode */


On 10/11/21, Michael Butler via freebsd-current
 wrote:

After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..

--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1:

error: conflicting types for 'dma_buf_stat'
dma_buf_stat(struct file *fp, struct stat *sb,
^
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18:

note: previous declaration is here
static fo_stat_t dma_buf_stat;
   ^
1 error generated.
*** [dma-buf.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi
1 error

make[3]: stopped in
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi

I get a similar error with drm-current-kmod. What changed?

imb

drm-devel-kmod build failures

[Michael Butler via freebsd-current]

After the latest freebsd version bump in param.h, I tried to rebuild the 
DRM modules. It failed with ..


--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1: 
error: conflicting types for 'dma_buf_stat'

dma_buf_stat(struct file *fp, struct stat *sb,
^
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18: 
note: previous declaration is here

static fo_stat_t dma_buf_stat;
 ^
1 error generated.
*** [dma-buf.o] Error code 1

make[3]: stopped in 
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi

1 error

make[3]: stopped in 
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi


I get a similar error with drm-current-kmod. What changed?

imb

Re: intermittent bsdtar/jemalloc failures

[Michael Butler via freebsd-current]

On 10/7/21 20:19, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:

On 10/7/21 16:52, Mark Johnston wrote:

On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current 
wrote:

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so
badly as to require stepping almost hourly :-(


If you return to TSC, does the problem go away?
Same question if you leave HPET on, but set fast_gettime to 0.


While I've only done one build (still) with HPET with 
kern.timecounter.fast_gettime=0, I didn't see a core-dump.

I'll test more over the weekend,

imb

Re: intermittent bsdtar/jemalloc failures

[Michael Butler via freebsd-current]

On 10/7/21 16:52, Mark Johnston wrote:

On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current 
wrote:

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so
badly as to require stepping almost hourly :-(


Could you show output from

# kldload cpuctl
# cpucontrol -i 0x15 /dev/cpuctl0
# cpucontrol -i 0x16 /dev/cpuctl0

as well as a copy of the dmesg after a boot?  I am looking at a similar
problem currently.


root@vm01:/usr/home/imb # cpucontrol -i 0x15 /dev/cpuctl0
cpuid level 0x15: 0x07280202 0x 0x 0x0503
root@vm01:/usr/home/imb # cpucontrol -i 0x16 /dev/cpuctl0
cpuid level 0x16: 0x07280202 0x 0x 0x0503

This is a Dell-1950 1-U box with a SAS drive-box attached ..

root@vm01:/usr/home/imb # less /var/log/dmesg.today
---<>---
VERBOSE_SYSINIT: DDB not enabled, symbol lookups disabled.
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #256 main-42dfad2ef1: Sat Oct  2 09:41:36 EDT 2021

r...@vm01.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/VM01 
amd64
FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-12.0.1-0-gfed41342a82f)

VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.31-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6

Features=0xbfebfbff

Features2=0xce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65811677184 (62762 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
Security policy loaded: MAC/ntpd (mac_ntpd)
ioapic0: MADT APIC ID 8 != hw id 0
ioapic0  irqs 0-23
Launching APs: 3 4 1 6 2 5 7
Timecounter "TSC-low" frequency 1413155409 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
vtvga0: 
smbios0:  at iomem 0xfcdf0-0xfce0e
smbios0: Version: 2.5, BCD Revision: 2.5
acpi0: 
acpi0: Power Button (fixed)
Firmware Error (ACPI): Could not resolve symbol [\134_SB._OSC.CDW1], 
AE_NOT_FOUND (20210930/psargs-503)
ACPI Error: Aborting method \134_SB._OSC due to previous error 
(AE_NOT_FOUND) (20210930/psparse-689)

apei0:  on acpi0
ipmi0:  port 0xca8,0xcac on acpi0
ipmi0: KCS mode found at io 0xca8 on acpi
cpu0:  on acpi0
atrtc0:  port 0x70-0x7f irq 8 on acpi0
atrtc0: registered as a time-

Re: intermittent bsdtar/jemalloc failures

[Michael Butler via freebsd-current]

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) 
dummy(-100)

kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so 
badly as to require stepping almost hourly :-(


So .. I have this in /etc/sysctl.conf ..

kern.timecounter.hardware=HPET

While I hope it wouldn't make a difference, I also have powerd enabled 
in /etc/rc.conf to (marginally) reduce the power-consumption when the 
machine is near-idle. sysctl -a | grep ^dev.cpu | grep freq shows ..


dev.cpu.7.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.7.freq: 2834
dev.cpu.3.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.3.freq: 2834
dev.cpu.5.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.5.freq: 2834
dev.cpu.1.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.1.freq: 2834
dev.cpu.6.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.6.freq: 2834
dev.cpu.2.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.2.freq: 2834
dev.cpu.4.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.4.freq: 2834
dev.cpu.0.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.0.freq: 2834

imb


OpenPGP_signature
Description: OpenPGP digital signature

intermittent bsdtar/jemalloc failures

[Michael Butler via freebsd-current]

While building a local release bundle, I sometimes get bsdtar failing 
(and dumping core) as follows below. Worse, as can be seen below, it 
doesn't stop the build unless I happen to notice and it yields an 
incomplete package.


a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion: 
"nstime_compare(&decay->epoch, &time) <= 0"

Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS 
file-systems all around. I tried stopping NTPD temporarily but the 
failures persist .. sometimes :-(


I've seen this at different points in the archiving process so it 
doesn't seem specific to building kernel.txz.


Any thoughts?

imb


OpenPGP_signature
Description: OpenPGP digital signature

git commit for WITH_DETECT_TZ_CHANGES breaks date, et al

[Michael Butler via freebsd-current]

After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to 
recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set.


For example ..

imb@vm01:/home/imb> date
Tue Sep 14 01:25:57  2021

Every other daemon also thinks it's running in UTC+0 :-(

When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in 
/etc/src.conf, the output is (for me) ..


imb@vm01:/usr/src/lib/libc> date
Mon Sep 13 21:28:29 EDT 2021

imb

Re: awk behaviour?

[Michael Butler via freebsd-current]

On 7/29/21 6:09 AM, Michael Gmelin wrote:



On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste  wrote:


On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
 wrote:


What prompted the question was my (obviously poor) attempt to debug
and resolve this failure when attempting to build a release for
i386 on an amd64 ..


This will be due to my 4e224e4be7c3. I'm not sure exactly what's
happening yet, but I can provoke this behaviour if `${PKG_CMD}
--version` outputs something other than a single line with the version
number.



Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
(whatever LOCALBASE is at that point)? This would make pkg --version
shows its bootstrap message:

   The package management tool is not yet installed on your system.
   Do you want to fetch and install it now? [y/N]:

which could explain the behavior.

Just speculating...


This is consistent with the behaviour I'm now seeing after the most 
recent patch.


In the chroot environment used by a cross-compilation, there is no 
installed pkg port. When pkg is invoked in the target environment, it 
now waits on the yes/no response,


imb

Re: awk behaviour?

[Michael Butler via freebsd-current]

On 7/28/21 1:36 PM, Warner Losh wrote:

On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:


I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?



Why $$ instead of $? $ isn't expanded in '' expressions, so doubling isn't
necessary
unlike in make... With single quotes it works for me:

% pkg --version | awk -F. '{print $1 * 1 + $2 * 100 + $3}'
11603
% pkg --version
1.16.3

In awk $$n is $($n), so $$ in this context would evaluate $1 to 1 and then
$1 to be 1. And then $2 to be 16
and then $17 to be 0 and then $3 to be 1 and then $1 to be 1 which leads to
10001.


What prompted the question was my (obviously poor) attempt to debug and 
resolve this failure when attempting to build a release for i386 on an 
amd64 ..


make -C /usr/src/release  obj
make -C /usr/src/release  ftp cdrom memstick.img mini-memstick.img
mkdir -p dist
cd /usr/src/release/.. && make TARGET_ARCH=i386 TARGET=i386 
distributeworld DISTDIR=/usr/obj/usr/src/i386.i386/release/dist
make[3]: "/usr/obj/usr/src/i386.i386/toolchain-metadata.mk" line 1: 
Using cached toolchain metadata from build at 
vm01.auburn.protected-networks.net on Wed Jul 28 18:01:01 UTC 2021


make[3]: "/usr/src/Makefile.inc1" line 1864: String comparison operator 
must be either == or !=
make[3]: "/usr/src/Makefile.inc1" line 2073: String comparison operator 
must be either == or !=

make[3]: Fatal errors encountered -- cannot continue
make[3]: stopped in /usr/src
*** Error code 1

Stop.

imb

Re: awk behaviour?

[Michael Butler via freebsd-current]

NVM .. it's the escaping of '$' .. 

On 7/28/21 1:29 PM, Michael Butler via freebsd-current wrote:

I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 * 
100 + $$3}'

10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?

 imb

awk behaviour?

[Michael Butler via freebsd-current]

I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 * 
100 + $$3}'

10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?

imb

Re: 14-CURRENT/aarch64 build problem

[Michael Butler via freebsd-arm]

On 6/8/21 3:42 PM, Juraj Lutter wrote:




On 8 Jun 2021, at 21:38, bob prohaska  wrote:

FWIW, same problem seen here. In an added twist, git pull (hoping for
a fix) fails also:

root@www:/usr/src # git pull
error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': 
'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 
'refs/remotes/freebsd/vendor/openzfs/legacy'
 From https://git.freebsd.org/src
! [new branch]  vendor/openzfs/legacy -> 
freebsd/vendor/openzfs/legacy  (unable to update local ref)
error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': 
'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 
'refs/remotes/freebsd/vendor/openzfs/master'
! [new branch]  vendor/openzfs/master -> 
freebsd/vendor/openzfs/master  (unable to update local ref)
error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': 
'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 
'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release'
! [new branch]  vendor/openzfs/zfs-2.1-release -> 
freebsd/vendor/openzfs/zfs-2.1-release  (unable to update local ref)

Is this a problem at my end, or the server's end?


This already has been documented, as the old openzfs branch has been 
renamed/moved.

$ git remote prune freebsd
$ git pull

See: https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html


Having pulled a completely new tree (rm -rf /usr/src/*; git clone), I 
get the following failure .. did I miss something?


===> cddl/lib/libicp_rescue (obj,all,install)
Building 
/usr/obj/usr/src/amd64.amd64/cddl/lib/libicp_rescue/libicp_rescue.so.3

building shared library libicp_rescue.so.3
Building /usr/obj/usr/src/amd64.amd64/cddl/lib/libicp_rescue/_libinstall
===> cddl/lib/libspl (obj,all,install)
make[4]: make[4]: don't know how to make atomic.S. Stop
`assert.c' is up to date.
`list.c' is up to date.
`mkdirp.c' is up to date.
`page.c' is up to date.
`timestamp.c' is up to date.
`zone.c' is up to date.
`include/sys/list.h' is up to date.
`include/sys/list_impl.h' is up to date.
`getexecname.c' is up to date.
`gethostid.c' is up to date.
`getmntany.c' is up to date.
`mnttab.c' is up to date.
`atomic.S' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags 
REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)!
`afterdepend' was not built (deferred, type 
OP_DEPENDS|OP_NOTMAIN|OP_PHONY|OP_DEPS_FOUND|OP_MARK, flags 
REMAKE|DONE_WAIT|DONECYCLE)!
`afterdepend' has .ORDER dependency against .depend (deferred, type 
OP_DEPENDS|OP_NOPATH|OP_DEPS_FOUND|OP_MARK, flags 
REMAKE|DONE_WAIT|CYCLE|DONECYCLE)
`assert.o' was not built (unmade, type 
OP_DEPENDS|OP_NOPATH|OP_HAS_COMMANDS|OP_DEPS_FOUND|OP_MARK, flags 
REMAKE|DONE_WAIT|DONECYCLE)!
`list.o' was not built (unmade, type 
OP_DEPENDS|OP_NOPATH|OP_HAS_COMMANDS|OP_DEPS_FOUND|OP_MARK, flags 
REMAKE|DONE_WAIT|DONECYCLE)!

`
 [ .. etc. .. ]

imb

Re: Build of some ports hang up on recent 14-CURRENT amd64

[Michael Butler via freebsd-current]

This is likely fixed as of ~30 mins ago on commit 
e8b9c508b7ae5be618ada089103468c400e465cd


The cause appears to have been commit d36d6816151705907393889

imb

On 4/9/21 4:55 PM, Yasuhiro Kimura wrote:

yasu@rolling-vm-freebsd1[1044]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT 
#0 main-n245912-f2400e6e832: Sat Apr 10 01:42:33 JST 2021 
ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  amd64

After the update from 36d6e65722e to f2400e6e832 I noticed build of
some ports hang up in the middle of it on my 14-CURRENT amd64 host.

One of such examples is security/py-cryptography.

--
root@rolling-vm-freebsd1[1008]# make
===>  License APACHE20 BSD3CLAUSE accepted by the user
===>   py39-cryptography-3.3.2 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py39-cryptography-3.3.2 for building
===>  Extracting for py39-cryptography-3.3.2
=> SHA256 Checksum OK for cryptography-3.3.2.tar.gz.
===>  Patching for py39-cryptography-3.3.2
===>   py39-cryptography-3.3.2 depends on package: py39-cffi>=1.8 - found
===>   py39-cryptography-3.3.2 depends on package: py39-setuptools>0 - found
===>   py39-cryptography-3.3.2 depends on file: /usr/local/bin/python3.9 - found
===>  Configuring for py39-cryptography-3.3.2
running config
--

And another one is devel/arcanist-lib.

--
root@rolling-vm-freebsd1[1023]# make
===>  License APACHE20 accepted by the user
===>   arcanist-lib-php74-20210113 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by arcanist-lib-php74-20210113 for building
===>  Extracting for arcanist-lib-php74-20210113
=> SHA256 Checksum OK for phacility-arcanist-20210113-b2e715f_GH0.tar.gz.
===>  Patching for arcanist-lib-php74-20210113
===>  Applying FreeBSD patches for arcanist-lib-php74-20210113 from 
/usr/ports/devel/arcanist-lib/files
===>  Configuring for arcanist-lib-php74-20210113
===>  Staging for arcanist-lib-php74-20210113
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/include/php/main/php.h - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/curl.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/dom.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/json.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/simplexml.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/zlib.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/mbstring.so - found
===>   Generating temporary packing list
cd /usr/ports/devel/arcanist-lib/work-php74/arcanist-b2e715f ; /bin/pax -rw * 
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist
install -l rs 
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/support/shell/hooks/bash-completion.sh
  
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/share/bash-completion/completions/arc
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/bin/arc
 shell-complete --generate
  GENERATE  Generating shell completion rules...
  RULES  Wrote updated completion rules for "bash" to: 
work-php74/stage/usr/local/lib/php/arcanist/support/shell/rules/bash-rules.sh.
  NOTE  You may need to open a new terminal window or launch a new shell before 
the changes take effect.
--

The problem also happens with poudriere.

I tried boot with old 36d6e65722e kernel but the problem still
happens. So the cause may be older than it.

Does anyone else have the same problem?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: On 14-CURRENT: no ports options anymore?

[Michael Butler via freebsd-current]

On 3/13/21 3:00 PM, Hartmann, O. wrote:

On Sat, 13 Mar 2021 19:52:47 + (UTC)
Filippo Moretti via freebsd-current  wrote:

  
I had the same problem in console modeFiippo

 On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser 
 wrote:

  Am 13.03.21 um 20:17 schrieb Hartmann, O.:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


Hi Oliver,

please check your TERM setting and test with a trivial setting
if it is not one of xterm, vt100 or vt320 (for example).

I had this problem when my TERM variable was xterm-color, which
used to be supported but apparently no longer is.

Regards, STefan


[...]

on one of the hosts (non-X11), loged in via ssh, the settings are:

# echo $TERM
xterm
cd /usr/ports/www/apache24
make config
===> Options unchanged (no menu popping up)



I ran into something similar where dialog4ports would dump core after an 
upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,


imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kern_jail.c w/o INVARIANTS

[Michael Butler via freebsd-current]

Seems there's a typo in this when INVARIANTS is not turned on ..

diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index 48c91a95bf..342af50462 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2671,7 +2671,7 @@ prison_free_not_last(struct prison *pr)
("prison_free_not_last freed last ref on prison %p (jid=%d).",
 pr, pr->pr_id));
 #else
-   refcount_release(&pr>pr_ref);
+   refcount_release(&pr->pr_ref);
 #endif
 }


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

make release broken?

[Michael Butler via freebsd-current]

Any ideas what broke this?


--
>>> Kernel build for GENERIC completed on Tue Feb  9 20:48:05 UTC 2021
--
>>> Kernel(s)  GENERIC built in 465 seconds, ncpu: 8, make -j8
--
make -C /usr/src/release  obj
make -C /usr/src/release  ftp cdrom dvdrom memstick.img mini-memstick.img
`ftp' is up to date.
sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_CD 
disc1.iso disc1
makefs: cd9660_add_boot_disk: lstat("disc1/boot/cdboot"): No such file 
or directory

*** Error code 1

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

    imb




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ZFS feature compatibility?

[Michael Butler via freebsd-current]

I have a few machines on which I've been hesitant to run 'zpool upgrade' 
as I'm not sure of the (boot?) implications. They report like this ..


imb@toshi:/home/imb> uname -a
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI 
 amd64


imb@toshi:/home/imb> zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support

the features. See zpool-features(5) for details.

Is it safe to upgrade the root pool?

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg.c revision 367687 breaks pkg

[Michael Butler]

Not for me, it's not ..

imb@toshi:/usr/src/usr.sbin/pkg> pkg info -a
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: n

And yet ..

imb@toshi:/home/imb> ll /usr/local/sbin/pkg
-rwxr-xr-x  1 root  wheel  2890304 Oct 11 09:54 /usr/local/sbin/pkg*

Reverting to SVN r367686 works correctly. mailwrapper is similarly broekn,

imb


On 11/15/20 1:55 PM, Scott Long wrote:

This is fixed in revision 367701

Scott



On Nov 15, 2020, at 11:52 AM, Manfred Antar  wrote:

pkg.c revision 367687 breaks pkg :

(pkg)5052}pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]:

This is after upgrading to the latest pkg and libutil.
pkg.c version 367075 works:

(pkg)5057}pkg
pkg: not enough arguments
Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C 
] [-R ] [-o var=value] [-4|-6]  []

For more information on available commands and options see 'pkg help’.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: objcopy "text file busy" build failure with populated /usr/obj

[Michael Butler]

On 9/20/20 10:58 AM, Mark Murray wrote:

Hi *

I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin 
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then 
the build works, but takes a few hours. If I do a no-clean build with /obj/obj populated with he 
contents of a previous build, and /usr/src with updated ("svn update") sources, then the 
below nearly always happens early in the rebuild. It is in "stage 4.4: building 
everything" that this happens. The build is parallel (-j8), and I have manually de-threaded 
the output.

The generated command-line from the logfile is:

cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm 
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/

legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  
SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all


Anyone else seeing this?

objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1

make[4]: stopped in /usr/src/usr.bin/objcopy


Yes, although simply restarting the build seems to avoid the problem on 
the second attempt.


However, I'm building on a dual quad-core amd64 platform (8 cores total) 
so it's not just ARM being affected,


imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildworld: "cp: /dev/null: Invalid argument"

[Michael Butler]

On 9/10/20 12:17 PM, Ryan Stone wrote:
> I'm curious: does this give a similar issue?
>
> touch /tmp/foo
> cp /tmp/foo /tmo/foo2
>
> I'm wondering if the issue is that copy_file_range isn't handling
> empty files, or if it's a devfs issue.


An empty file doesn't generate the error ..

imb@vm01:/home/imb> touch xx
imb@vm01:/home/imb> cp xx yy
imb@vm01:/home/imb>
imb@vm01:/home/imb> cp /dev/null yy
cp: /dev/null: Invalid argument
imb@vm01:/home/imb>


>
> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
>  wrote:
>> It seems that SVN r365549 broke "cp /dev/null ..."
>>
>> imb
>>
>> On 9/10/20 10:35 AM, Michael Butler wrote:
>>> Is anyone else seeing failures like this in building world and, in my
>>> case, cron jobs as well?
>>>
>>>
>>> Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
>>> --- all_subdir_sbin ---
>>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
>>> --- all_subdir_stand ---
>>> --- zfsboot.ldr ---
>>> cp: /dev/null: Invalid argument
>>> *** [zfsboot.ldr] Error code 1
>>> make[5]: *** zfsboot.ldr removed
>>> --- all_subdir_kerberos5 ---
>>> Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
>>> --- all_subdir_stand ---
>>>
>>> make[5]: stopped in /usr/src/stand/i386/zfsboot
>>> .ERROR_TARGET='zfsboot.ldr'
>>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
>>> .MAKE.LEVEL='5'
>>> MAKEFILE=''
>>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
>>> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
>>> .CURDIR='/usr/src/stand/i386/zfsboot'
>>> .MAKE='make'
>>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
>>> .TARGETS='all'
>>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
>>> LD_LIBRARY_PATH=''
>>> MACHINE='amd64'
>>> MACHINE_ARCH='amd64'
>>> MAKEOBJDIRPREFIX=''
>>> MAKESYSPATH='/usr/src/share/mk'
>>> MAKE_VERSION='20200902'
>>>
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildworld: "cp: /dev/null: Invalid argument"

[Michael Butler]

It seems that SVN r365549 broke "cp /dev/null ..."

    imb

On 9/10/20 10:35 AM, Michael Butler wrote:
> Is anyone else seeing failures like this in building world and, in my
> case, cron jobs as well?
>
>
> Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
> --- all_subdir_sbin ---
> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
> --- all_subdir_stand ---
> --- zfsboot.ldr ---
> cp: /dev/null: Invalid argument
> *** [zfsboot.ldr] Error code 1
> make[5]: *** zfsboot.ldr removed
> --- all_subdir_kerberos5 ---
> Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
> --- all_subdir_stand ---
>
> make[5]: stopped in /usr/src/stand/i386/zfsboot
> .ERROR_TARGET='zfsboot.ldr'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
> .CURDIR='/usr/src/stand/i386/zfsboot'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
> .TARGETS='all'
> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20200902'
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

buildworld: "cp: /dev/null: Invalid argument"

[Michael Butler]

Is anyone else seeing failures like this in building world and, in my
case, cron jobs as well?


Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
--- all_subdir_sbin ---
Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
--- all_subdir_stand ---
--- zfsboot.ldr ---
cp: /dev/null: Invalid argument
*** [zfsboot.ldr] Error code 1
make[5]: *** zfsboot.ldr removed
--- all_subdir_kerberos5 ---
Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
--- all_subdir_stand ---

make[5]: stopped in /usr/src/stand/i386/zfsboot
.ERROR_TARGET='zfsboot.ldr'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cp /dev/null zfsboot.ldr;'
.CURDIR='/usr/src/stand/i386/zfsboot'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20200902'

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: documentation on release build process change (svn -> git)?

[Michael Butler]

On 8/29/20 5:48 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote:
>> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote:

 [ .. ]

>>> Nevermind, I see the problem.  Standby.
>>>
>>
>> r364966 should fix it.  Thank you again for your help here.
>>
> 
> Sigh.  r364968 should *really* fix it..

It does and without pulling ~1.2GB of GIT pack down :-)

> Is it Friday yet?

LOL :-)

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: documentation on release build process change (svn -> git)?

[Michael Butler]

On 8/29/20 5:17 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
>> The build-from-existing mode fails with ..
>>
>> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
>> fatal: not a git repository (or any parent up to mount point /usr)
>> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>> umount: /usr/local/release-builds/i386/dev: not a file system root directory
>>
> 
> Here's the fun part - Which revision was this?

The host system is check-out from SVN r364964,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: documentation on release build process change (svn -> git)?

[Michael Butler]

On 8/29/20 12:04 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote:
>> I added a way to update an existing tree in r364959.  I have only done
>> very trivial testing on this change, however, so please let me know if
>> it does not work as expected.
>>
> r364960 further refines how this works; that would be a better revision
> to use to test.

The build-from-scratch mode now works to produce tar-balls and ISOs :-)
However, I noticed that after building a clean amd64 tool-chain, it does
fetch the amd64 GIT packages and dependencies (~76MB in all) before
building 'all' for the target. No big deal but I usually prefer to build
everything locally.

The build-from-existing mode fails with ..

imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
fatal: not a git repository (or any parent up to mount point /usr)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
umount: /usr/local/release-builds/i386/dev: not a file system root directory

Many thanks for your efforts!

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: documentation on release build process change (svn -> git)?

[Michael Butler]

On 8/29/20 11:14 AM, Glen Barber wrote:
> NOPORTS=yes is the problem, and I forgot to address it before merging
> the project branch back.  Please try with r364956.

Trying now but, in the interim, I noted ..

With SVN, I could re-use a previously existing build directory and it
would simply apply the relevant diffs to bring the tree up to date.

In the move to GIT, now it seems I have to pull the whole tree down or
it complains ..

imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
fatal: destination path '/usr/local/release-builds/i386/usr/src' already
exists and is not an empty directory.

I'm not that familiar with GIT but .. Is there an incremental update
option I can use? If so, should this be the default? As is, it seems
like a colossal waste of bandwidth and unwanted load on the parent GIT repo,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: documentation on release build process change (svn -> git)?

[Michael Butler]

On 8/28/20 1:44 PM, Glen Barber wrote:

> Note, not entirely tested, however, since future snapshots and 13.0 will
> be exclusively built from the git sources.

When building with ..

## Set miscellaneous 'make release' settings.
NODOC=yes
NOPORTS=yes
WITH_DVD=yes

The build fails after building the target kernel but before building
either the tar-balls or ISOs with ..

>>> Kernel(s)  GENERIC-NODEBUG built in 765 seconds, ncpu: 8, make -j4
--
make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found.
Set GIT_CMD appropriately."

It seems to want GIT in the chroot environment, because it's there on
the host,

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

documentation on release build process change (svn -> git)?

[Michael Butler]

Is there any documentation around the changes to the release build
system from SVN to GIT?

I currently keep a mirrored SVN repo and the revised release scripts
seem not to have that as a build option. Can I still use this or do I
need to throw it all out and start over?

With one target machine being a 700MHz Pentium-3, building locally is
not a practical option,

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kldref: too many segments on kernel build

[Michael Butler]

Any thoughts as to why this is happening when I build a (custom) kernel?

kldxref: /boot/kernel/kernel: too many segments

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

cross-build failure on objcopy

[Michael Butler]

When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get
the error below after a previously successful build.

Running the build again (a 3rd time) completes successfully :-(

This is the output from

cd /usr/src/release; ./release.sh -c release-i386.conf

 [ .. ]

===> usr.bin/cxxfilt (all)
===> usr.bin/objcopy (all)
===> usr.sbin/bsnmpd/tools/bsnmptools (all)
===> usr.bin/file2c (all)
===> usr.bin/gprof (all)
===> usr.bin/indent (all)
===> usr.bin/lex (all)
===> usr.bin/mkstr (all)
===> usr.bin/nm (all)
objcopy: open objcopy failed: Text file busy
--- objcopy ---
*** [objcopy] Error code 1
make[4]: *** objcopy removed

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

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r363032 - portmaster|portupgrade now fails

[Michael Butler]

Reverting SVN r363031 works around it,

imb

On 7/8/20 8:42 PM, Manfred Antar wrote:
> Same error here, Even trying to build a port fails:
> (src)5023}cd /usr/ports/shells/bash
> (bash)5024}make
> make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison 
> operator should be either == or !=
> make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional 
> (defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} < 
> ${_MAKE_JOBS_NUMBER} ))
> make: Fatal errors encountered -- cannot continue
> make: stopped in /usr/ports/shells/bash
> (bash)5025}
> 
>> On Jul 8, 2020, at 5:33 PM, Michael Butler  
>> wrote:
>>
>> Did the bmake update break the updating of ports or something else?
>>
>> # sudo -E portmaster -a
>> ===>>> Gathering distinfo list for installed ports
>>
>> ===>>> Starting check of installed ports for available updates
>> make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
>> comparison operator should be either == or !=
>> make: "/usr/ports/Mk/Uses/python.mk" line 384: Malformed conditional
>> (!(!empty(_PYTHON_VERSION_MINIMUM) && (  ${__VER} <
>> ${_PYTHON_VERSION_MINIMUM})) &&  !(!empty(_PYTHON_VERSION_MAXIMUM) && (
>> ${__VER} > ${_PYTHON_VERSION_MAXIMUM})))
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r363032 - portmaster|portupgrade now fails

[Michael Butler]

Did the bmake update break the updating of ports or something else?

# sudo -E portmaster -a
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates
make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should be either == or !=
make: "/usr/ports/Mk/Uses/python.mk" line 384: Malformed conditional
(!(!empty(_PYTHON_VERSION_MINIMUM) && (  ${__VER} <
${_PYTHON_VERSION_MINIMUM})) &&  !(!empty(_PYTHON_VERSION_MAXIMUM) && (
${__VER} > ${_PYTHON_VERSION_MAXIMUM})))

 [ snip ]

make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should be either == or !=
make: "/usr/ports/Mk/Uses/python.mk" line 384: Malformed conditional
(!(!empty(_PYTHON_VERSION_MINIMUM) && (  ${__VER} <
${_PYTHON_VERSION_MINIMUM})) &&  !(!empty(_PYTHON_VERSION_MAXIMUM) && (
${__VER} > ${_PYTHON_VERSION_MAXIMUM})))
make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should be either == or !=
make: "/usr/ports/Mk/Uses/python.mk" line 384: Malformed conditional
(!(!empty(_PYTHON_VERSION_MINIMUM) && (  ${__VER} <
${_PYTHON_VERSION_MINIMUM})) &&  !(!empty(_PYTHON_VERSION_MAXIMUM) && (
${__VER} > ${_PYTHON_VERSION_MAXIMUM})))
make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should be either == or !=
make: "/usr/ports/Mk/Uses/python.mk" line 384: Malformed conditional
(!(!empty(_PYTHON_VERSION_MINIMUM) && (  ${__VER} <
${_PYTHON_VERSION_MINIMUM})) &&  !(!empty(_PYTHON_VERSION_MAXIMUM) && (
${__VER} > ${_PYTHON_VERSION_MAXIMUM})))

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

magic file update?

[Michael Butler]

I'm seeing this message repeatedly during port builds. Should I be
concerned?

file: File 5.39 supports only version 16 magic files.
`/usr/share/misc/magic.mgc' is version 14

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: anyone else seeing bind fail on recent -current?

[Michael Butler]

On 4/15/20 7:19 PM, Michael Butler wrote:
> This instance is/was running in a jail but now fails sometime after SVN
> r359823 .. I'm trying to bisect but any hints appreciated ..
> 
> named[98746]: 
> named[98746]: BIND 9 is maintained by Internet Systems Consortium,
> named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
> named[98746]: corporation.  Support and training for BIND 9 are
> named[98746]: available at https://www.isc.org/support
> named[98746]: 
> named[98746]: command channel listening on 127.0.0.1#953
> named[98746]: command channel listening on ::1#953
> named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back
> trace
> named[98746]: #0 0x2cbb35 in ??
> named[98746]: #1 0x4a7b4a in ??
> named[98746]: #2 0x4bd297 in ??
> named[98746]: #3 0x4c12a1 in ??
> named[98746]: #4 0x8009f67f4 in ??
> named[98746]: #5 0x8009f87b8 in ??
> named[98746]: #6 0x8009e7e81 in ??
> named[98746]: #7 0x4bb6e9 in ??
> named[98746]: #8 0x800a15f39 in ??
> named[98746]: exiting (due to assertion failure)
> root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named

As it turns out, the update to devel/libuv on SVN r531786 causes this
failure .. :-(

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

anyone else seeing bind fail on recent -current?

[Michael Butler]

This instance is/was running in a jail but now fails sometime after SVN
r359823 .. I'm trying to bisect but any hints appreciated ..

named[98746]: 
named[98746]: BIND 9 is maintained by Internet Systems Consortium,
named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
named[98746]: corporation.  Support and training for BIND 9 are
named[98746]: available at https://www.isc.org/support
named[98746]: 
named[98746]: command channel listening on 127.0.0.1#953
named[98746]: command channel listening on ::1#953
named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back
trace
named[98746]: #0 0x2cbb35 in ??
named[98746]: #1 0x4a7b4a in ??
named[98746]: #2 0x4bd297 in ??
named[98746]: #3 0x4c12a1 in ??
named[98746]: #4 0x8009f67f4 in ??
named[98746]: #5 0x8009f87b8 in ??
named[98746]: #6 0x8009e7e81 in ??
named[98746]: #7 0x4bb6e9 in ??
named[98746]: #8 0x800a15f39 in ??
named[98746]: exiting (due to assertion failure)
root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: SVN r358655 breaks i386 buildworld :-(

[Michael Butler]

In case anyone else is seeing this ..

 Forwarded Message 
Subject: Re: SVN r358655 breaks i386 buildworld :-(
Date: Thu, 5 Mar 2020 09:49:01 -0500
From: Michael Butler 
To: Gleb Smirnoff 

On 3/4/20 10:00 PM, Michael Butler wrote:
> On i386, I get this ..
> 
> Building
> /usr/obj/usr/src/i386.i386/rescue/rescue/usr/src/sbin/mount_nfs/mount_nfs.o
> /usr/src/sbin/mount_nfs/mount_nfs.c:549:10: error: cast from 'char *' to
> 'struct if_msghdr *' increases required alignment from 1 to 4
> [-Werror,-Wcast-align]
> ifm = (struct if_msghdr *)buf;
>   ^~~
> 1 error generated.

Not sure if it's the correct solution but I noted sbin/dhclient has a
Makefile fix which disables this warning. Applying this works around the
problem ..

Index: sbin/mount_nfs/Makefile
===
--- sbin/mount_nfs/Makefile (revision 358670)
+++ sbin/mount_nfs/Makefile (working copy)
@@ -11,6 +11,8 @@
 UMNTALL= ${SRCTOP}/usr.sbin/rpc.umntall
 CFLAGS+= -DNFS -I${MOUNT} -I${UMNTALL}

+NO_WCAST_ALIGN= yes
+
 .PATH: ${MOUNT} ${UMNTALL}

 .include 


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Michael Butler]

On 2/21/20 11:49 AM, Ed Maste wrote:
> It seems starting sshd from inetd via tcpd is a reasonable approach
> for folks who want to use it; also, have folks using libwrap looked at
> sshd's Match blocks to see if they provide the desired functionality?

While match blocks can disallow a login from anything other than an
approved source address, they apparently permit the configured number of
failed attempts before throwing the prospective intruder out. With the
wrappers, it's an immediate disconnect.

They also have no mechanism to recognize a DNS mismatch (forward versus
reverse map).

imb



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

lame reverse DNS?

[Michael Butler]

Seems there's an issue with freebsd.org's reverse DNS resulting in
refused email, e.g.

Feb 17 08:58:54 mail postfix/smtpd[41811]: NOQUEUE: reject: RCPT from
unknown[2610:1c1:1:606c::19:2]: 550 5.7.25 Client host rejected: cannot
find your hostname, [2610:1c1:1:606c::19:2];
from= to=
proto=ESMTP helo=
Feb 17 10:55:52 mail postfix/smtpd[82117]: NOQUEUE: reject: RCPT from
unknown[96.47.72.81]: 550 5.7.25 Client host rejected: cannot find your
hostname, [96.47.72.81]; from=
to= proto=ESMTP helo=
Feb 17 11:11:15 mail postfix/smtpd[83299]: NOQUEUE: reject: RCPT from
unknown[96.47.72.81]: 550 5.7.25 Client host rejected: cannot find your
hostname, [96.47.72.81]; from=
to= proto=ESMTP helo=

Looking more closely ..

/home/imb> host 2610:1c1:1:606c::19:2
Host
2.0.0.0.9.1.0.0.0.0.0.0.0.0.0.0.c.6.0.6.1.0.0.0.1.c.1.0.0.1.6.2.ip6.arpa
not found: 2(SERVFAIL)
/home/imb> host 96.47.72.81
Host 81.72.47.96.in-addr.arpa not found: 2(SERVFAIL)

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Michael Butler]

On 2/14/20 6:37 PM, Ben Woods wrote:
> On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly  wrote:
>
>> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
>>> Upstream OpenSSH-portable removed libwrap support in version 6.7,
>>> released in October 2014. We've maintained a patch in our tree to
>>> restore it, but it causes friction on each OpenSSH update and may
>>> introduce security vulnerabilities not present upstream. It's (past)
>>> time to remove it.
>>
>> So color me ignorant, but how does this affect things like DenyHosts? Or
>> is
>> there an in-application way to block dictionary attacks? I can't go back
>> to
>> having my servers pounded on day and night (and yes, I listed on an
>> alternative port).
>
>
> DenyHosts can be configured to use PF firewall tables directly, rather than
> using TCP wrappers:
> https://github.com/denyhosts/denyhosts/blob/master/denyhosts.conf#L261
>
Requiring the addition of a firewall where there was none before is a
significant and potentially error-prone change. I am not about to add
this degree of complexity to every machine which only has a single port
exposed via NAT.


To maintain equivalent functionality, the port version
(security/openssh-portable) has the requisite patch as an option or,
perhaps better, the base SSHD can be run from INETD and, consequently,
TCP-wrapped as it was before,


    imb



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r355732 breaks DRM

[Michael Butler]

-current now fails to build the DRM drivers :-(

Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/drm/drm_os_freebsd.o
--- drm_os_freebsd.o ---
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_os_freebsd.c:47:3:
error: implicit declaration of function 'untimeout' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
untimeout(clear_debug_func, NULL, reset_debug_log_handle);
^
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_os_freebsd.c:57:28:
error: implicit declaration of function 'timeout' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
reset_debug_log_handle = timeout(clear_debug_func, NULL,
 ^
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_os_freebsd.c:57:26:
error: assigning to 'struct callout_handle' from incompatible type 'int'
reset_debug_log_handle = timeout(clear_debug_func, NULL,
   ^ ~~~
3 errors generated.

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r355491 breaks libprocstat

[Michael Butler]

This member removal has other consequences. As follows ..

--- lib/libprocstat__L ---
Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
'next' in 'struct vm_map_entry'
for (entryp = map->header.next;
  ~~~ ^
/usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
'next' in 'struct vm_map_entry'
entryp = vmentry.next) {
 ~~~ ^
2 errors generated.

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r355148/9 breaks build

[Michael Butler]

Something missing from a header here?

Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o
--- uma_core.o ---
/usr/src/sys/vm/uma_core.c:1864:39: error: use of undeclared identifier
'sysctl___vm_uma'
zone->uz_oid = SYSCTL_ADD_NODE(NULL,
SYSCTL_STATIC_CHILDREN(_vm_uma),
 ^
/usr/src/sys/sys/sysctl.h:245:44: note: expanded from macro
'SYSCTL_STATIC_CHILDREN'
#define SYSCTL_STATIC_CHILDREN(oid_name)
(&sysctl__##oid_name.oid_children)
  ^
:154:1: note: expanded from here
sysctl___vm_uma
^
/usr/src/sys/vm/uma_core.c:1864:15: error: assigning to 'struct
sysctl_oid *' from incompatible type 'void'
zone->uz_oid = SYSCTL_ADD_NODE(NULL,
SYSCTL_STATIC_CHILDREN(_vm_uma),
 ^
~~
2 errors generated.
*** [uma_core.o] Error code 1

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r354896 breaks build

[Michael Butler]

The no-relax flag can't be used on all architectures ..

Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail
--- jail ---
ld: error: unknown argument '--no-relax'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_usr.sbin/portsnap ---
--- all_subdir_usr.sbin/portsnap/make_index ---
===> usr.sbin/portsnap/make_index (all)
--- all_subdir_usr.sbin/jail ---
*** [jail] Error code 1

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

make release with i386 target now fails

[Michael Butler]

I'm sure I did this yesterday without a failure; any hints as to what
broke/how to fix it?

imb

===> tests/sys/cddl/zfs/tests/threadsappend (all)
===> tests/sys/cddl/zfs/tests/truncate (all)
===> usr.sbin/amd/libamu (all)
===> usr.sbin/audit (all)
===> tests/sys/cddl/zfs/tests/txg_integrity (all)
===> tests/sys/cddl/zfs/tests/userquota (all)
--- xdr_func_%undef.c ---
*** [xdr_func_%undef.c] Error code 1
make[5]: *** xdr_func_%undef.c removed

make[5]: stopped in
/usr/local/release-builds/i386/usr/src/usr.sbin/amd/libamu
.ERROR_TARGET='xdr_func_%undef.c'
.ERROR_META_FILE='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.sbin/amd/libamu/xdr_func_%undef.c.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes'
_ERROR_CMD='unifdef -x1 -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS
-DHAVE_XDR_DIRLIST -DHAVE_XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES
-DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH -DHAVE_XDR_ENTRY
-DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR
-DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME
-DHAVE_XDR_FTYPE -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS
-DHAVE_XDR_LINKARGS -DHAVE_XDR_MOUNTBODY -DHAVE_XDR_MOUNTLIST
-DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NFSCOOKIE
-DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME
-DHAVE_XDR_POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS
-DHAVE_XDR_READDIRRES -DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES
-DHAVE_XDR_READRES -DHAVE_XDR_RENAMEARGS -DHAVE_XDR_SATTR
-DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAVE_XDR_STATFSRES
-DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS -DHAVE_XDR_U_INT64_T -o
xdr_func_%undef.c
/usr/local/release-builds/i386/usr/src/contrib/amd/libamu/xdr_func.c;'
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r354253 breaks buildworld

[Michael Butler]

On 11/2/19 5:15 PM, Toomas Soome wrote:
> Should be fixed by r354265.

The problem has moved .. now the kernel won't build ..

Building /usr/obj/usr/src/amd64.amd64/sys/VM01/avl.o
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/lz4.o
--- lz4.o ---
cc: error: no such file or directory:
'/usr/src/sys/cddl/contrib/opensolaris/lz4/lz4.c'
cc: error: no input files
*** [lz4.o] Error code 1

That's brought in by sys/conf/files as follows ..

imb@vm01:/sys/conf> grep lz4 *
files:cddl/contrib/opensolaris/lz4/lz4.c
optional zfs compile-with "${ZFS_C}"
kern.pre.mk:ZFS_CFLAGS+=-I$S/cddl/contrib/opensolaris/common/lz4

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r354253 breaks buildworld

[Michael Butler]

Something missing from SVN r354253?

Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue
ld: error: undefined symbol: lz4_init
>>> referenced by spa_misc.c:2066
(/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
>>>   spa_misc.o:(spa_init) in archive
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a

ld: error: undefined symbol: lz4_fini
>>> referenced by spa_misc.c:2096
(/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096)
>>>   spa_misc.o:(spa_fini) in archive
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
cpp: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [rescue] Error code 1

make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
.ERROR_TARGET='rescue'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
curdirOk=yes'
_ERROR_CMD='cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -march=ivybridge
-std=gnu99 -Wno-format-zero-length-Qunused-arguments -static
-static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo
date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo
kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo
rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo csh.lo
camcontrol.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo
fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo
ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo
ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo
mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo
reboot.lo restore.lo rcorder.lo route.lo savecore.lo shutdown.lo
spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ccdconfig.lo
ping6.lo rtsol.lo ipf.lo routed.lo rtquery.lo bectl.lo zfs.lo zpool.lo
bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo
gzip.lo bzip2.lo less.lo xz.lo zstd.lo tar.lo nc.lo vi.lo id.lo
iscsictl.lo zdb.lo chroot.lo chown.lo iscsid.lo
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/exec.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/getusershell.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/login_class.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/popen.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/rcmdsh.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/sysctl.o
/usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/system.o -lcrypt
-ledit -ljail -lkvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias
-lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
-lnvpair -lpthread -luutil -lumem -lbe -lgeom -lbsdxml -lkiconv -lmt
-lsbuf -lufs -lz -lbz2 -lprivatezstd -larchive -lcrypto -lmd -lm;'
.CURDIR='/usr/obj/usr/src/amd64.amd64/rescue/rescue'

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r353868 breaks net/intel-em-kmod

[Michael Butler]

On 10/24/19 1:56 PM, Gleb Smirnoff wrote:
> On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
> M> The removal of these KPIs yields:
> M> 
> M> link_elf_obj: symbol if_multiaddr_array undefined
> M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
> 
> What's the reason to keep these outside of the tree drivers? AFAIU, they
> are maintained by the same team that maintains in-tree drivers. Cced them.

For some reason, the default in-kernel driver doesn't play nicely with
VirtualBox especially when attempting to bridge the host and client.

I have not explored why it works with NAT but not bridge,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r353868 breaks net/intel-em-kmod

[Michael Butler]

The removal of these KPIs yields:

link_elf_obj: symbol if_multiaddr_array undefined
linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r353480 now mandates kernel option VIMAGE

[Michael Butler]

sys/net/route.c will no longer compile when VIMAGE is removed from the
kernel,

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

rc.d/linux runs unconditionally

[Michael Butler]

In rc.d/sysvipc we see ..

name="sysvipc"
desc="Load SysV IPC modules"
rcvar="sysvipc_enable"
start_cmd="${name}_start"

 .. so it won't try to run without explicitly setting sysvipc_enable in
/etc/rc.conf.

However in rc.d/linux, we have only ..

name="linux"
desc="Enable Linux ABI"
start_cmd="${name}_start"

 .. which causes it to try to load the linux modules unconditionally
even when I don't want them,

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fusefs & ntfs-3g

[Michael Butler]

On 9/8/19 7:09 PM, Alan Somers wrote:
> On Sun, Sep 8, 2019 at 5:00 PM Clay Daniels Jr. 
> wrote:
> 
>> I want to view my Windows C: drive on ata0p4.
>> This is what I have:
>> FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351901 GENERIC  amd64
>> clay@bsd13:~ % pkg info -r fusefs-libs
>> fusefs-libs-2.9.9:
>> clay@bsd13:~ % pkg info -r fusefs-libs3
>> fusefs-libs3-3.6.2:
>> clay@bsd13:~ % cat /boot/loader.conf
>> hw.syscons.disable=1
>> fusefs_load="YES"
>> clay@bsd13:~ % kldstat
>> Id Refs AddressSize Name
>>  1   72 0x8020  2336f80 kernel
>>  21 0x8253800027990 fusefs.ko
>>  31 0x8272   2519c4 amdgpu.ko
>>  42 0x8297200077bd0 drm.ko
>>  55 0x829ea00012470 linuxkpi.ko
>>  63 0x829fd00012f30 linuxkpi_gplv2.ko
>>  72 0x82a1  8e0 lindebugfs.ko
>>  81 0x82a11000 f281 ttm.ko
>>  91 0x82a21000 23f7 radeon_kabini_pfp_bin.ko
>> 101 0x82a24000 23f5 radeon_kabini_me_bin.ko
>> 111 0x82a27000 23f5 radeon_kabini_ce_bin.ko
>> 121 0x82a2a000 43f7 radeon_kabini_mec_bin.ko
>> 131 0x82a2f000 2a77 radeon_kabini_rlc_bin.ko
>> 141 0x82a32000 12e9 radeon_kabini_sdma_bin.ko
>> 151 0x82a34000 12eb radeon_kabini_sdma1_bin.ko
>> 161 0x82a3600038ea7 radeon_kabini_uvd_bin.ko
>> 171 0x82a6f00018c47 radeon_kabini_vce_bin.ko
>> 181 0x82a88000 2538 intpm.ko
>> 191 0x82a8b000  a50 smbus.ko
>> 201 0x82a8c000 1820 uhid.ko
>> 211 0x82a8e000 2928 ums.ko
>> 221 0x82a91000 1b00 wmt.ko
>> 231 0x82a93000  acf mac_ntpd.ko
>> 241 0x82a94000 a9f8 tmpfs.ko
>>
>> clay@bsd13:~ % pkg info fusefs-ntfs-2017.3.23
>> fusefs-ntfs-2017.3.23
>> Name   : fusefs-ntfs
>> Version: 2017.3.23
>> Installed on   : Sun Sep  8 17:24:36 2019 CDT
>> Origin : sysutils/fusefs-ntfs
>> Architecture   : FreeBSD:13:amd64
>> Prefix : /usr/local
>> Categories : sysutils
>> Licenses   : GPLv2+
>> Maintainer : free...@dussan.org
>> WWW: https://www.tuxera.com/community/open-source-ntfs-3g/
>> Comment: Mount NTFS partitions (read/write) and disk images
>> Options:
>> DOCS   : on
>> LOCK   : on
>> UBLIO  : on
>> Shared Libs required:
>> libfuse.so.2
>> libuuid.so.1
>> libublio.so.1
>> Shared Libs provided:
>> libntfs-3g.so.88
>> Annotations:
>> FreeBSD_version: 1300044
>> repo_type  : binary
>> repository : FreeBSD
>> Flat size  : 1.93MiB
>> Description:
>> The ntfs-3g driver is an open source, freely available read/write NTFS
>> driver, which provides safe and fast handling of the Windows XP, Windows
>> Server 2003, Windows 2000, Windows Vista, Windows Server 2008, Windows 7
>> and Windows 8 NTFS file systems. Almost the full POSIX filesystem
>> functionality is supported, the major exceptions are changing the file
>> ownerships and the access rights.
>>
>> root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt
>> * Windows is hibernated, refused to mount.
>> The disk contains an unclean file system (0, 0).
>> Metadata kept in Windows cache, refused to mount.
>> Falling back to read-only mount because the NTFS partition is in an unsafe
>> state. Please resume and shutdown Windows fully (no hibernation
>> or fast restarting.
>>
>> I'm having a roadblock here. Maybe someone knows the answer.
>>
> 
> I'm assuming that you already ascertained that the Windows file system was
> in fact clean?  If so, then this sounds like a problem with fusefs-ntfs,
> not with fuse in general.  I've CC'd its maintainer.  He may be able to
> help you.
> -Alan

Windows-10 has a changed default; it does the equivalent of hibernation
to facilitate "fast start". ntfs-3g won't touch a partition for writing
in that mode :-(

If I recall correctly, there is a setting you must change from in
Windows under control panel -> system -> power and sleep. From there you
should be able to disable the "fast start" option and, after shutting
down, ntfs-3g will allow a read/write mount,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ses no longer attaches

[Michael Butler]

On 2019-08-27 19:41, Michael Butler wrote:
> On 2019-08-27 19:15, Niclas Zeising wrote:
>> On 2019-08-28 00:38, Alexander Motin wrote:
>>> Hi.
>>>
>>> On 27.08.2019 18:03, Niclas Zeising wrote:
>>>> I have an issue where the ses driver no longer attaches.  Last known
>>>> good version was r351188, r351544 is broken.  In that interval,
>>>> something happened.  I haven't had time to bisect yet.
>>>
>>> I would appreciate some details, like dmesg, error messages, etc.  On my
>>> test systems I see no problems.
>>>
>>
>> Hi!
>> I did some more digging. r351355 is ok, while r351356 is bad.  This is
>> Warner's (CC:d) commit to add RST support to nvme, however, I'm using a
>> ssd drive connected to ahci.
>>
>> What happens is that the ses driver doesn't attach to the AHCI SGPIO
>> enclosure.  This is on a laptop with an ssd (not an nvme) drive.  I have
>> the same issue on another computer as well.  On the broken kernel,
>> sesutil status complains about "No SES devices found", on the working
>> kernel it reports "ok".
> 
> I can confirm this behaviour (haven't checked versioning) .. working
> kernel yields ..
> 
> Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
> Aug 20 17:40:06 toshi kernel: ses0: 
> SEMB S-E-S 2.00 device
> Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
> Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
> scbus0 target 0
> Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
> scbus1 target 0

Should have been ..

Aug 20 17:40:06 toshi kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port
Multiplier not supported
Aug 20 17:40:06 toshi kernel: ahcich0:  at channel 0 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich1:  at channel 1 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich4:  at channel 4 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich5:  at channel 5 on ahci0
Aug 20 17:40:06 toshi kernel: ahciem0:  on ahci0

> 
>  [ .. other stuff .. ]
> 
> Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
> Aug 20 17:40:06 toshi kernel: ses0: 
> SEMB S-E-S 2.00 device
> Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
> Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
> scbus0 target 0
> Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
> scbus1 target 0
> 
>  .. non working reports ..
> 
> Aug 27 11:06:28 toshi kernel: ahciem0:  bridge> at channel 2147483647 on ahci0
> Aug 27 11:06:28 toshi kernel: device_attach: ahciem0 attach returned 6
> 
>   imb
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ses no longer attaches

[Michael Butler]

On 2019-08-27 19:15, Niclas Zeising wrote:
> On 2019-08-28 00:38, Alexander Motin wrote:
>> Hi.
>>
>> On 27.08.2019 18:03, Niclas Zeising wrote:
>>> I have an issue where the ses driver no longer attaches.  Last known
>>> good version was r351188, r351544 is broken.  In that interval,
>>> something happened.  I haven't had time to bisect yet.
>>
>> I would appreciate some details, like dmesg, error messages, etc.  On my
>> test systems I see no problems.
>>
> 
> Hi!
> I did some more digging. r351355 is ok, while r351356 is bad.  This is
> Warner's (CC:d) commit to add RST support to nvme, however, I'm using a
> ssd drive connected to ahci.
> 
> What happens is that the ses driver doesn't attach to the AHCI SGPIO
> enclosure.  This is on a laptop with an ssd (not an nvme) drive.  I have
> the same issue on another computer as well.  On the broken kernel,
> sesutil status complains about "No SES devices found", on the working
> kernel it reports "ok".

I can confirm this behaviour (haven't checked versioning) .. working
kernel yields ..

Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
Aug 20 17:40:06 toshi kernel: ses0: 
SEMB S-E-S 2.00 device
Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
scbus0 target 0
Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
scbus1 target 0

 [ .. other stuff .. ]

Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
Aug 20 17:40:06 toshi kernel: ses0: 
SEMB S-E-S 2.00 device
Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
scbus0 target 0
Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
scbus1 target 0

 .. non working reports ..

Aug 27 11:06:28 toshi kernel: ahciem0:  at channel 2147483647 on ahci0
Aug 27 11:06:28 toshi kernel: device_attach: ahciem0 attach returned 6

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r351457 breaks drm-current

[Michael Butler]

On 2019-08-24 19:09, Michael Butler wrote:
> On 2019-08-24 14:04, Konstantin Belousov wrote:
>> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>>> that's the right fix.
>> More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
>> same as all in-tree consumers of the header do, apparently.
>>
>> But another question is why the driver needs md_var.h, there are no
>> externally usable definitions there.
> 
> There are uses of other variables from machine/md_var.h, notably
> cpu_feature, in linux_compat.c.
> 
> Including sys/pcpu.h allows the build to continue .. as in ..
> 
> *** linuxkpi/gplv2/src/linux_compat.c~  Wed Aug  7 14:36:56 2019
> --- linuxkpi/gplv2/src/linux_compat.c   Sat Aug 24 18:58:08 2019
> ***
> *** 2,7 
> --- 2,8 
>   #include 
>   #if defined(__i386__) || defined(__amd64__)
>   #include 
> + #include 
>   #include 
>   #endif
>   #include 
> 
> Locally, I've put this patch into graphics/drm-current-kmod/files so I
> don't trip over it on subsequent builds,

This is now resolved in-tree by ports SVN r510009 - thanks to all,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r351457 breaks drm-current

[Michael Butler]

On 2019-08-24 14:04, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>> that's the right fix.
> More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
> same as all in-tree consumers of the header do, apparently.
> 
> But another question is why the driver needs md_var.h, there are no
> externally usable definitions there.

There are uses of other variables from machine/md_var.h, notably
cpu_feature, in linux_compat.c.

Including sys/pcpu.h allows the build to continue .. as in ..

*** linuxkpi/gplv2/src/linux_compat.c~  Wed Aug  7 14:36:56 2019
--- linuxkpi/gplv2/src/linux_compat.c   Sat Aug 24 18:58:08 2019
***
*** 2,7 
--- 2,8 
  #include 
  #if defined(__i386__) || defined(__amd64__)
  #include 
+ #include 
  #include 
  #endif
  #include 

Locally, I've put this patch into graphics/drm-current-kmod/files so I
don't trip over it on subsequent builds,

Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r351457 breaks drm-current

[Michael Butler]

As follows ..

Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_compat.o
--- linux_compat.o ---
In file included from
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_compat.c:5:
./machine/md_var.h:61:34: error: declaration of 'struct pcpu' will not
be visible outside of this function [-Werror,-Wvisibility]
voidamd64_bsp_pcpu_init1(struct pcpu *pc);
^
./machine/md_var.h:63:32: error: declaration of 'struct pcpu' will not
be visible outside of this function [-Werror,-Wvisibility]
voidamd64_bsp_ist_init(struct pcpu *pc);
  ^

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r350713 breaks non-debug kernel builds

[Michael Butler]

As follows ..

--- kern_sysctl.o ---
/usr/src/sys/kern/kern_sysctl.c:1623:19: error: use of undeclared
identifier 'kdb_active'
if (arg2 == 0 || kdb_active) {
 ^
1 error generated.
*** [kern_sysctl.o] Error code 1

imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Heads up for breaking drm update.

[Michael Butler]

On 2019-05-19 23:21, Johannes Lundberg wrote:
> 
> On 5/19/19 7:36 PM, Steve Kargl wrote:
>> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote:
>>> LinuxKPI in base have received a lot of updates recently for Linux 5.0,
>>> a couple of them will break drm-current-kmod. So, as of r347973 you will
>>> need drm-current-kmod 4.16.g20190519. Ports have been updated and new
>>> packages should be available shortly.
>>>
>> If drm-current-kmod is broken, should I venture to ask
>> about drm-stable-kmod and drm-legacy-kmod?
> 
> That's a very good question. Maybe I should have included more
> information regarding what's not affected. The last series of commits
> have been to LinuxKPI in -CURRENT. As such:
> 
> drm-kmod: Meta port, not relevant
> drm-current-kmod: See original message
> drm-fbsd11.2-kmod: Not affected by changes in -CURRENT
> drm-fbsd12.0-kmod: Not affected by changes in -CURRENT
> drm-legacy-kmod: Not affected by changes in LinuxKPI
> 
> drm-stable-kmod does not exist anymore. Stable drm kmod ports for other
> than -CURRENT are more or less frozen in separate branches where they
> only receive bug fixes (drm-fbsdxxx-kmod).
> 
> Hope that answers your questions.

It should also be noted that drm-current now has a new dependency on
lindebugfs. It won't load without it :-(

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

[Michael Butler]

On 2019-05-09 14:38, Gleb Smirnoff wrote:
> On Thu, May 09, 2019 at 02:32:44PM -0400, Michael Butler wrote:
> M> (kgdb) frame 8
> M> #8  0x80a15377 in ip_output (m=, opt= M> optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
> M> /usr/src/sys/netinet/ip_output.c:362
> M> 362 IFP_TO_IA(ifp, ia, &in_ifa_tracker);
> M> (kgdb) print imo
> M> $1 = (struct ip_moptions *) 0xfe0072b14780
> M> (kgdb) print ifp
> M> $2 = (struct ifnet *) 0xf8000411
> M> (kgdb) print ia
> M> $3 = 
> ...
> 
> This all looks good.
> 
> Can you please traverse the 'in_ifaddrhead' linked list?

To close the loop on this - it's now fixed by SVN r347466,

Thanks!

imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

[Michael Butler]

On 2019-05-09 14:22, Gleb Smirnoff wrote:
>   Michael,
> 
> On Thu, May 09, 2019 at 10:25:37AM -0500, Kyle Evans wrote:
> K> > #0  doadump () at src/sys/amd64/include/pcpu.h:241
> K> > #1  0x808393c8 in kern_reboot (howto=260) at
> K> > /usr/src/sys/kern/kern_shutdown.c:470
> K> > #2  0x80839826 in vpanic (fmt=, ap= K> > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896
> K> > #3  0x80839663 in panic (fmt=) at
> K> > /usr/src/sys/kern/kern_shutdown.c:823
> K> > #4  0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156)
> K> > at /usr/src/sys/amd64/amd64/trap.c:946
> K> > #5  0x80c31c59 in trap_pfault (frame=0xfe0072b14510,
> K> > usermode=0) at src/sys/amd64/include/cpufunc.h:423
> K> > #6  0x80c30fde in trap (frame=0xfe0072b14510) at
> K> > /usr/src/sys/amd64/amd64/trap.c:441
> K> > #7  0x80c0d4b5 in calltrap () at
> K> > /usr/src/sys/amd64/amd64/exception.S:232
> K> > #8  0x80a15377 in ip_output (m=, opt= K> > optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
> K> > /usr/src/sys/netinet/ip_output.c:362
> K> > #9  0x809ffea4 in igmp_intr (m=) at
> K> > /usr/src/sys/netinet/igmp.c:3455
> K> > #10 0x80975a0f in netisr_dispatch_src (proto=2, source= K> > optimized out>, m=) at 
> /usr/src/sys/net/netisr.c:1122
> K> > #11 0x809fe07a in igmp_fasttimo () at
> K> > /usr/src/sys/netinet/igmp.c:496
> K> > #12 0x808c5854 in pffasttimo (arg=) at
> K> > /usr/src/sys/kern/uipc_domain.c:521
> K> > #13 0x80853df3 in softclock_call_cc (c=0x813f7f48,
> K> > cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
> K> > #14 0x808542b9 in softclock (arg=0x814c9ac0) at
> K> > /usr/src/sys/kern/kern_timeout.c:869
> K> > #15 0x807fd0c4 in ithread_loop (arg=) at
> K> > /usr/src/sys/kern/kern_intr.c:1129
> K> > #16 0x807f9f33 in fork_exit (callout=0x807fcef0
> K> > , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at
> K> > /usr/src/sys/kern/kern_fork.c:1058
> K> > #17 0x80c0e4ae in fork_trampoline () at
> K> > /usr/src/sys/amd64/amd64/exception.S:995
> K> > #18 0x in ?? ()
> K> >
> K> 
> K> Ah, I misread your backtrace (and forgot the proper tap detachment
> K> from my previous patch, so that's fixed/committed anyways). CC'ing
> K> Gleb for further triage as committer of r347375 that touched things in
> K> this path.
> 
> Michael, can you please dump a core and look at it in kgdb? Line 362 in
> ip_output() really belongs to part that had minimal change with r347375.
> So I need more details. Can you please print out in kgdb the following
> variables: imo, ifp, ia?
> 

This was a backtrace from kgdb. From frame 8, I see ..

(kgdb) frame 8
#8  0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
/usr/src/sys/netinet/ip_output.c:362
362 IFP_TO_IA(ifp, ia, &in_ifa_tracker);
(kgdb) print imo
$1 = (struct ip_moptions *) 0xfe0072b14780
(kgdb) print ifp
$2 = (struct ifnet *) 0xf8000411
(kgdb) print ia
$3 = 

(kgdb) print *imo
$4 = {imo_multicast_ifp = 0xf8000411, imo_multicast_addr =
{s_addr = 1924220944}, imo_multicast_vif = 18446744073709551615,
imo_multicast_ttl = 1 '\001', imo_multicast_loop = 0 '\0',
  imo_num_memberships = 15350, imo_max_memberships = 63489,
imo_membership = 0xf80002c10d00, imo_mfilters = 0xf80002c10d00,
imo_epoch_ctx = {data = 0xfe0072b147b0}}
(kgdb) print *ifp
$5 = {if_link = {cstqe_next = 0x0}, if_clones = {le_next = 0x0, le_prev
= 0xf800040f9728}, if_groups = {cstqh_first = 0xf80002878d60,
cstqh_last = 0xf80002878d38},
  if_alloctype = 6 '\006', if_numa_domain = 255 '�', if_softc =
0xf80004197300, if_llsoftc = 0x0, if_l2com = 0xf800040fe800,
if_dname = 0x80e0bd14 "tap", if_dunit = 0,
  if_index = 4, if_index_reserved = 0, if_xname = 0xf80004110058
"tap0", if_description = 0x0, if_flags = 34818, if_drv_flags = 0,
if_capabilities = 524288, if_capenable = 524288,
  if_linkmib = 0x0, if_linkmiblen = 0, if_refcount = 1, if_type = 6
'\006', if_addrlen = 6 '\006', if_hdrlen = 14 '\016', if_link_state = 1
'\001', if_mtu = 1500, if_metric = 0,
  if_baudrate = 1000, if_hwassist = 0, if_epoch = 10, if_lastchange
= {tv_sec = 1557408022, tv_usec = 929504}, if_snd = {ifq_head = 0x0,
ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50,
ifq_mtx = {lock_object = {lo_name = 0xf80004110058 "tap0",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0},
ifq_drv_head = 0x0, ifq_drv_tail = 0x0,
ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = 0, altq_flags = 0,
altq_disc = 0x0, altq_ifp = 0xf8000411, altq_enqueue = 0,
altq_dequeue = 0, altq_request = 0,
altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr =
0x0}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0,
ta_priority = 0,
ta_func = 0x809494e0 , ta_contex

Re: Danish FreeBSD Developer hates jews collectively

[Michael Butler]

On 2019-05-09 14:03, ossobser...@redchan.it wrote:
> Background: Apparently a FreeBSD developer, a viking looking fellow, 

Further miscellaneous dribble elided ..

This has no place on this mailing list. Take your hate someplace else,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

[Michael Butler]

On 2019-05-09 09:07, Kyle Evans wrote:
> On Thu, May 9, 2019 at 7:24 AM Michael Butler
>  wrote:
>>
>> Seems there's a lock or tuntap issue after recent changes. Restarting
>> openvpn (configured to use /dev/tap) yields a panic as follows:
>>
> 
> Ah, I knew I was forgetting something. =( Give this a shot:
> https://people.freebsd.org/~kevans/etherdetach.diff

Sorry - same result,

(kgdb) bt
#0  doadump () at src/sys/amd64/include/pcpu.h:241
#1  0x808393c8 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:470
#2  0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896
#3  0x80839663 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:823
#4  0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156)
at /usr/src/sys/amd64/amd64/trap.c:946
#5  0x80c31c59 in trap_pfault (frame=0xfe0072b14510,
usermode=0) at src/sys/amd64/include/cpufunc.h:423
#6  0x80c30fde in trap (frame=0xfe0072b14510) at
/usr/src/sys/amd64/amd64/trap.c:441
#7  0x80c0d4b5 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:232
#8  0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
/usr/src/sys/netinet/ip_output.c:362
#9  0x809ffea4 in igmp_intr (m=) at
/usr/src/sys/netinet/igmp.c:3455
#10 0x80975a0f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122
#11 0x809fe07a in igmp_fasttimo () at
/usr/src/sys/netinet/igmp.c:496
#12 0x808c5854 in pffasttimo (arg=) at
/usr/src/sys/kern/uipc_domain.c:521
#13 0x80853df3 in softclock_call_cc (c=0x813f7f48,
cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
#14 0x808542b9 in softclock (arg=0x814c9ac0) at
/usr/src/sys/kern/kern_timeout.c:869
#15 0x807fd0c4 in ithread_loop (arg=) at
/usr/src/sys/kern/kern_intr.c:1129
#16 0x807f9f33 in fork_exit (callout=0x807fcef0
, arg=0xf800025f10a0, frame=0xfe0072b14ac0) at
/usr/src/sys/kern/kern_fork.c:1058
#17 0x80c0e4ae in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:995
#18 0x in ?? ()

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

at SVN r347375, terminating/restarting openvpn on tap causes panic

[Michael Butler]

Seems there's a lock or tuntap issue after recent changes. Restarting
openvpn (configured to use /dev/tap) yields a panic as follows:

(kgdb) bt
#0  doadump () at src/sys/amd64/include/pcpu.h:241
#1  0x808393c8 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:470
#2  0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896
#3  0x80839663 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:823
#4  0x80c31686 in trap_fatal (frame=0xfe0072b14510, eva=156)
at /usr/src/sys/amd64/amd64/trap.c:946
#5  0x80c31a39 in trap_pfault (frame=0xfe0072b14510,
usermode=0) at src/sys/amd64/include/cpufunc.h:423
#6  0x80c30dbe in trap (frame=0xfe0072b14510) at
/usr/src/sys/amd64/amd64/trap.c:441
#7  0x80c0d295 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:232
#8  0x80a15387 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
/usr/src/sys/netinet/ip_output.c:362
#9  0x809ffeb4 in igmp_intr (m=) at
/usr/src/sys/netinet/igmp.c:3455
#10 0x80975a1f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122
#11 0x809fe08a in igmp_fasttimo () at
/usr/src/sys/netinet/igmp.c:496
#12 0x808c5854 in pffasttimo (arg=) at
/usr/src/sys/kern/uipc_domain.c:521
#13 0x80853df3 in softclock_call_cc (c=0x813f7f48,
cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
#14 0x808542b9 in softclock (arg=0x814c9ac0) at
/usr/src/sys/kern/kern_timeout.c:869
#15 0x807fd0c4 in ithread_loop (arg=) at
/usr/src/sys/kern/kern_intr.c:1129
#16 0x807f9f33 in fork_exit (callout=0x807fcef0
, arg=0xf80002620100, frame=0xfe0072b14ac0) at
/usr/src/sys/kern/kern_fork.c:1058
#17 0x80c0e28e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:995
#18 0x in ?? ()

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r346700 breaks build

[Michael Butler]

Seems that the lib32 piece (on amd64) is now broken; as follows:

--- realinstall_subdir_lib/libbe ---
--- _libinstall ---
install: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/: No such file
or directory
*** [_libinstall] Error code 71

make[5]: stopped in /usr/src/lib/libbe
.ERROR_TARGET='_libinstall'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libbe/_libinstall.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='sh /usr/src/tools/install.sh  -C -o root -g wheel -m 444
libbe.a /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/; sh
/usr/src/tools/install.sh  -C -o root -g wheel -m 444   libbe_p.a
/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/; sh
/usr/src/tools/install.sh  -s -o root -g wheel -m 444   -S  libbe.so.1
/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/; sh
/usr/src/tools/install.sh -l rs -o root -g wheel -m 755
/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/libbe.so.1
/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so; -chflags
noschg /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so.1;
rm -f /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so.1;'
.CURDIR='/usr/src/lib/libbe'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libbe'
.TARGETS='install'
DESTDIR='/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp'
LD_LIBRARY_PATH=''
MACHINE='i386'
MACHINE_ARCH='i386'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64/obj-lib32'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk
/usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk
/etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk
/usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk
/usr/src/share/mk/bsd.suffixes.mk /etc/make.conf
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk
/etc/src.conf /usr/src/lib/libbe/Makefile /usr/src/share/mk/src.opts.mk
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk
/usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.lib.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/src.init.mk /usr/src/lib/libbe/../Makefile.inc
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk
/usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/lib/libbe'
1 error

Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r346645 breaks build of DRM drivers

[Michael Butler]

The removal of dma_mask (around line 105) in
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h breaks the
DRM loadable modules :-(

As follows ..

--- amdgpu_amdkfd.o ---
/usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:37:
error: no member named 'dma_mask' in 'struct device'
uint64_t address_mask = adev->dev->dma_mask ?
~*adev->dev->dma_mask :
~  ^
/usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:61:
error: no member named 'dma_mask' in 'struct device'
uint64_t address_mask = adev->dev->dma_mask ?
~*adev->dev->dma_mask :
~  ^
2 errors generated.

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r346316 breaks build

[Michael Butler]

On 2019-04-17 20:45, Ed Maste wrote:
> On Wed, 17 Apr 2019 at 17:31, Michael Butler  
> wrote:
>>
>> There seems to be a missing include here?
>>
>> ===> usr.bin/strings (obj,all,install)
>> Building
>> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/strings/strings.o
>> /usr/src/contrib/elftoolchain/strings/strings.c:198:55: error: use of
>> undeclared identifier 'FA_OPEN'
>> fa = fileargs_init(argc, argv, O_RDONLY, 0, &rights, FA_OPEN);
> 
> I can't reproduce this and the CI builds
> (https://ci.freebsd.org/tinderbox) are all passing, although this was
> reported privately to me by others so something's up. What is the
> FreeBSD version on your build host?
> 

This is a native build on current. It fails with or without removing
/usr/obj/*.

Sean Eric Fagan (sef) pointed me to the fact that cap_fileargs.h is not
updated as part of the bootstrap-tools target. As I don't understand how
that target is built or configured, I successfully worked around it by
doing (on my amd64 host) ..

cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \
/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/casper/
cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/casper/
cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \
/usr/include/casper/

imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"