14.0 ’arp -a’ creates a crash

This was helpful Sergio- as you confirmed it's on GENERIC and you provided what you did. I generated static list, loaded it and triggered the crash. The stack trace (938 is arp command):
Code: 
Sleeping thread (tid 100689, pid 938) owns a non-sleepable lock
KDB: stack backtrace of thread 100689:
#0 0xffffffff80b5028b at mi_switch+0xbb
#1 0xffffffff80ba044b at sleepq_catch_signals+0x2ab
#2 0xffffffff80ba0189 at sleepq_wait_sig+0x9
#3 0xffffffff80b4f9f3 at _sleep+0x1e3
#4 0xffffffff80be26ca at sbwait+0x6a
#5 0xffffffff80be85ec at soreceive_generic+0x2cc
#6 0xffffffff80bea45f at soreceive+0x2f
#7 0xffffffff80beef80 at kern_recvit+0x190
#8 0xffffffff80bef51f at sys_recvmsg+0x6f
#9 0xffffffff8100d119 at amd64_syscall+0x109
#10 0xffffffff80fe43db at fast_syscall_common+0xf8
panic: sleeping thread
cpuid = 7
time = 1716317361
KDB: stack backtrace:
#0 0xffffffff80b9009d at kdb_backtrace+0x5d
#1 0xffffffff80b431a2 at vpanic+0x132
#2 0xffffffff80b43063 at panic+0x43
#3 0xffffffff80ba8e9e at propagate_priority+0x29e
#4 0xffffffff80ba99e4 at turnstile_wait+0x314
#5 0xffffffff80b3e9c9 at __rw_rlock_hard+0x279
#6 0xffffffff80d8c2af at dump_lle+0x1f
#7 0xffffffff80c6c38c at htable_foreach_lle+0x5c
#8 0xffffffff80d8c234 at dump_llts_iface+0x54
#9 0xffffffff80d8bfcd at rtnl_handle_getneigh+0x20d
#10 0xffffffff80d882d2 at rtnl_handle_message+0x132
#11 0xffffffff80d85c0b at nl_taskqueue_handler+0x79b
#12 0xffffffff80ba5992 at taskqueue_run_locked+0x182
#13 0xffffffff80ba6c22 at taskqueue_thread_loop+0xc2
#14 0xffffffff80afdb7f at fork_exit+0x7f
#15 0xffffffff80fe4b2e at fork_trampoline+0xe
With this information PR can be opened.

I've opened a PR 279208 for it.
 
It depends on how urgent this issue is? Work around it (by not using static ARP for example), continue with 14.0 and wait for the actual 14.1 release. Or take the plunge and go with the BETA3 now and test the crap out of it.

www.freebsd.org

FreeBSD 14.1 Release Process

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
Sergio- said:
Good news) And what should someone who works on version release 14.0 on the main gateway do?)
Click to expand...
If it's urgent, you could try cherry-pick the commit on releng/14.0 as it was cherry-picked from main on releng/14.1 (14.1-BETA3), actually on stable/14, or simply replace original file with committed.

Rename original /usr/sbin/arp before: /usr/src/usr.sbin/arp # make install
 
T-Daemon said:
/usr/src/usr.sbin/arp # make install
Click to expand...

Does not work (
I applied a patch, rebuilt, loaded a table of static addresses from a file and.... The system did NOT crash immediately))) ... It crashed a little later))) After the command arp -a or re-loading the data from the file .
At the same time, not all addresses were read from the file and the system filled up the logs with entries about part of the network that it did not have time to enter into the arp table.
 
Sergio- said:
Does not work ( [...]
Click to expand...
If the need is (very) high, you could also consider switching to 14-STABLE (however, IIRC a switch "back" to 14.1-RELEASE isn't possible). As I see, the commit in question was merged to 14-STABLE some time ago: commit arp: fix arp -s/-S, but that would mean extra work, build from source and leaving the easy binary update path. Switching to the releng/14.1 branch, even at this moment before the official release, seems like a more obvious path forward. The planning is 24 may (=tomorrow) Release Candidate 14.1-RC1 build begins. (To me that seems worth waiting for but I don't have the knowledge of your circumstances).
 
Code: 
# freebsd-update upgrade -r 14.1-RC1
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.0-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic kernel/generic-dbg src/src world/base world/base-dbg
world/lib32 world/lib32-dbg

The following components of FreeBSD do not seem to be installed:

Does this look reasonable (y/n)? y

Fetching metadata signature for 14.1-RC1 from update1.freebsd.org... failed.
Fetching metadata signature for 14.1-RC1 from update2.freebsd.org... failed.
Fetching metadata signature for 14.1-RC1 from dualstack.aws.update.freebsd.org... failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (14.1-RC1) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See [URL]https://www.freebsd.org/platforms/[/URL] for more info.

If unsupported, FreeBSD must be upgraded by source.

What does this mean?
Too early? 14.1-RC1 not ready yet?
Looks like I need to update to 14.1- BETA3 first (
 
You can upgrade to RC1, then RC2, RC3 and eventually 14.1-RELEASE of course. But unless you run into any of the bugs specific to BETA3 I'd just wait for the full release, or else you'll have to upgrade nearly every week. Nothing wrong with upgrading every week, just a lot of work.

www.freebsd.org

FreeBSD 14.1 Release Process

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
You must log in or register to reply here.
Back
Top