[Bug 279208] filling up arp table with static entries leads to a crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279208] filling up arp table with static entries leads to a crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 martin changed: What|Removed |Added Summary|filling up arp table with |filling up arp table with |static entries can lead to |static entries leads to a |crash |crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279208] filling up arp table with static entries can lead to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 Bug ID: 279208 Summary: filling up arp table with static entries can lead to crash Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: mar...@bxlr.sk Loading arp table with the arp -f command leads to a panic. Sometimes panic occurs immediately, sometimes after loading more entries (more subnets or wider subnet). Executing few arp -a processes and waiting few minutes does lead to panic too. To reproduce I've created an alias on interface and a list of dummy entries: # ifconfig em0 alias 172.17.1.1/24 # cat 1list 172.17.1.2 13:01:00:00:00:02 172.17.1.3 13:01:00:00:00:03 .. 172.17.1.255 13:01:00:00:00:ff # arp -f 1list # ps axl |grep arp 0 842 820 1 20 0 12956 2688 sbwait I+0 0:00.02 arp -a Those entries that arp command did show have obvious overflow: # arp -an ? (172.17.3.254) at 13:03:00:00:00:fe on em0 expires in -1716331940 seconds [ethernet] ? (172.17.3.222) at 13:03:00:00:00:de on em0 expires in -1716331940 seconds [ethernet] Sleeping thread (tid 100853, pid 0) owns a non-sleepable lock KDB: stack backtrace of thread 100853: #0 0x80b5028b at mi_switch+0xbb #1 0x80b4fa00 at _sleep+0x1f0 #2 0x80ba6c11 at taskqueue_thread_loop+0xb1 #3 0x80afdb7f at fork_exit+0x7f #4 0x80fe4b2e at fork_trampoline+0xe panic: sleeping thread cpuid = 1 time = 1716332236 KDB: stack backtrace: #0 0x80b9009d at kdb_backtrace+0x5d #1 0x80b431a2 at vpanic+0x132 #2 0x80b43063 at panic+0x43 #3 0x80ba8e9e at propagate_priority+0x29e #4 0x80ba99e4 at turnstile_wait+0x314 #5 0x80b3e9c9 at __rw_rlock_hard+0x279 #6 0x80d8c2af at dump_lle+0x1f #7 0x80c6c38c at htable_foreach_lle+0x5c #8 0x80d8c234 at dump_llts_iface+0x54 #9 0x80d8bfcd at rtnl_handle_getneigh+0x20d #10 0x80d882d2 at rtnl_handle_message+0x132 #11 0x80d85c0b at nl_taskqueue_handler+0x79b #12 0x80ba5992 at taskqueue_run_locked+0x182 #13 0x80ba6c22 at taskqueue_thread_loop+0xc2 #14 0x80afdb7f at fork_exit+0x7f #15 0x80fe4b2e at fork_trampoline+0xe Uptime: 4m49s -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Bug ID: 279203 Summary: logger: Forking many logger executables at once renders machine unresponsive Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: gre...@freebsd.org CC: r...@freebsd.org Forking logger many times like this: #!/bin/sh for id in $(jot 100); do logger -p local2.info -t pot "wledkjweldjwldjkwedj" & done sends the machine into some race condition, causing loads of 300-500. I can reproduce it on multicore machines (including within bhyve), not on single core. Load is mostly caused by system calls. When knowing pids, it's sometimes possible to recover the host by killing all logger processes (killall won't work though, as the machine is too loaded for that). I could not reproduce this on 13.2 (at least not as easily). When building logger without capsicum, this doesn't happen, but that could be a red herring. Happens on 13.3 as well as 13.3p2. This is causing quite some headache. We put logger under a lock to reduce concurrency, which made things better, but we still see the general situation (either other things call logger or, more likely, this is just a symptom of a bigger underlying issue). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276724] 'man 8 glabel': add extra content
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276724 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c80c104cbd52db994c0f2757bd1c6d014744022c commit c80c104cbd52db994c0f2757bd1c6d014744022c Author: Chris Moerz AuthorDate: 2024-05-21 18:10:11 + Commit: Joseph Mingrone CommitDate: 2024-05-21 18:49:17 + glabel.8: Describe cases related to permissions / existing mounts Specially, note some requirements for label changes: - glabel requires write permission on device - filesystems first need to be unmounted for new labels to persist across reboots - if the affected device node holds the filesystem root, single-user mode with r/o mount will be required. Also, while here, apply some formatting tweaks. PR: 276724 Reported by:Alex Matei Reviewed by:gbe, jrm, Alexander Ziaee Differential Revision: https://reviews.freebsd.org/D44394 lib/geom/label/glabel.8 | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 --- Comment #1 from Wolfram Schneider --- There is a similar problem with the PnetCDF manual pages: $ mandoc FreeBSD-ports-14.0-RELEASE/misc/man1/cdfdiff.1.gz | tail -n1 Printed: 1900-0-0 PnetCDF 1.12.3 cdfdiff(1) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266142] SNDSTIOC_ADD_USER_DEVS ioctl on /dev/sndstat passes unchecked size from user to malloc() -> potential crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266142 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5830a00c2c5485ec17900558e4f29c459c6a1f3e commit 5830a00c2c5485ec17900558e4f29c459c6a1f3e Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:28 + Commit: Christos Margiolis CommitDate: 2024-05-21 17:45:49 + sound: Check user-supplied size passed to SNDSTIOC_ADD_USER_DEVS* SNDSTIOC_ADD_USER_DEVS* expects a user-supplied sndstioc_nv_arg->nbytes, however we currently do not check whether this size is actually valid, which results in a panic when SNDSTIOC_ADD_USER_DEVS* is called with an invalid size. sndstat_add_user_devs() calls sndstat_unpack_user_nvlbuf(), which then calls malloc() with that size. PR: 266142 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:brooks Differential Revision: https://reviews.freebsd.org/D45236 (cherry picked from commit 074d337ad618f9cc2a1d5ab18b484928e57bd72b) sys/dev/sound/pcm/sndstat.c | 5 + sys/sys/sndstat.h | 5 + 2 files changed, 10 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266144] bug in sndstat_unpack_user_nvlbuf()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266144 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=45feaa73c68011bbba647d1eb6f86a166a0453e9 commit 45feaa73c68011bbba647d1eb6f86a166a0453e9 Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:33 + Commit: Christos Margiolis CommitDate: 2024-05-21 17:45:55 + sound: Correctly check nvlist_unpack() error The current check is never false and if nvlist_unpack() fails, we might panic later down the road. PR: 266144 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch, emaste Differential Revision: https://reviews.freebsd.org/D45237 (cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a) sys/dev/sound/pcm/sndstat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 Brooks Davis changed: What|Removed |Added Resolution|--- |Works As Intended Status|New |Closed --- Comment #3 from Brooks Davis --- It's a little unfortunate that we can't cross build release/13.0 on 14.0 without patches, but ultimately there isn't much we can do. I don't think it would generally make sense to merge the changes back to old release branches. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 --- Comment #2 from Mark Shank --- (In reply to Brooks Davis from comment #1) I had checked out releng/13.0 in order to track down an issue for bug #271826 comment#20 Thank you for the quick response and the patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274423] A place to record all issues with the upgrade to mandoc 1.14.6 - metabug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274423 Wolfram Schneider changed: What|Removed |Added Depends on||279202 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 [Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 Wolfram Schneider changed: What|Removed |Added Blocks||274423 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274423 [Bug 274423] A place to record all issues with the upgrade to mandoc 1.14.6 - metabug -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 Bug ID: 279202 Summary: mandoc: displays wrong date for GNU Radius manual pages: "0, 1900" Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: wo...@freebsd.org mandoc(1) displays a wrong date for the GNU Radius manual pages: $ mandoc FreeBSD-ports-14.0-RELEASE/misc/man1/radgrep.1.gz | tail -n1 GNU Radius 0, 1900 radgrep(1) GNU troff (groff) version 1.23.0 works fine: $ zcat FreeBSD-ports-14.0-RELEASE/misc/man1/radgrep.1.gz |nroff -man | tail -n1 GNU Radius May 21, 2024 radgrep(1) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279201] mptutil(8) use date from the future: May 24, 2024
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279201 Bug ID: 279201 Summary: mptutil(8) use date from the future: May 24, 2024 Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: wo...@freebsd.org CC: d...@freebsd.org Today is May 21th, but the manual page for mptutil(8) reports itself as from May 24, 2024 $ man mptutil | tail -n1 FreeBSD 15.0-CURRENT May 24, 2024 FreeBSD 15.0-CURRENT -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199
Brooks Davis changed:
What|Removed |Added
CC||bro...@freebsd.org
--- Comment #1 from Brooks Davis ---
What source version are you building? This should have been fixed long ago
(the fixes were in the stable/14 when it was branched and MFC'd to stable/13).
If you need to merge them to a local branch, here are the changes:
commit b3b462229f972e2ed24d450d7d2f8855cdd58a87
Author: Ed Maste
Date: Fri Apr 1 09:58:47 2022 -0400
installworld: handle ldd including preloaded objects
The installworld target makes a temporary copy of binaries to be used
during the install. Libraries that they depend on are also included,
found by using `ldd`.
After commit 0913953c9ed0 ldd started listing preloaded objects,
including [vdso], under a [preloaded] header. Skip ldd output that is
enclosed in square brackets.
Reviewed by:cy, kib [earlier version]
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34734
and then I rewrote it to be zsh friendly with:
commit bda5d2a45c8dcc9bbeb71cddeef930ffa6a47f23
Author: Brooks Davis
Date: Fri Jul 1 08:33:16 2022 +0100
installworld: improve portability of ldd use
b3b462229f97 added a case statement to ignore lines containing strings
in square brackets such as "[vdso]" and "[preloaded]". On MacOS
Monterey where /bin/sh may be zsh, this fails with:
/bin/sh: -c: line 0: syntax error near unexpected token `;;'
Invoke grep in the pipeline to remove such lines instead.
Reviewed by:emaste
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D35618
diff --git a/Makefile.inc1 b/Makefile.inc1
index 20c537512273..12bb892dfd58 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1368,12 +1368,8 @@ distributeworld installworld stageworld:
_installcheck_world .PHONY
fi; \
done); \
if [ -z "${CROSSBUILD_HOST}" ] ; then \
- libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null |
sort -u | \
+ libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null |
sort -u | grep -Ev '\[.*]' | \
while read line; do \
- case $$line in \
- "["*"]") \
- continue;; \
- esac; \
set -- $$line; \
if [ "$$2 $$3" != "not found" ]; then \
echo $$2; \
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279174] POLA violation: Graphical Installer for a natively text UI OS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279174 Pierre Pronchery changed: What|Removed |Added CC||khor...@defora.org --- Comment #3 from Pierre Pronchery --- Hi Alexander, (all) [I understand that this is not the place for a discussion - we can take it privately from there - but I think some aspects deserve more clarity] First, thank you for your interest, and for the praise; much appreciated. While I totally agree with your evaluation of FreeBSD, I also believe that it can grow to be more than a text-based Operating System, and that graphical interfaces can be useful to many less tech-savvy users even while setting up a server. I have witnessed this myself, and this is also the reason behind projects like TrueNAS, PC-BSD, GhostBSD, or MidnightBSD for instance. With this in mind, this new graphical version of the installer does not replace the existing one. It adds a new possibility, by means of an additional installation image. It is only available there, and even then it still starts the text-based installer on the first VT as usual. This actually works as a failover mechanism if the graphical installer fails to start. In fact the current design of the graphical installer re-uses the code of the traditional text-based installer. This is an intentional decision on my part, which allows both implementations to improve each other in most situations: a fix in the graphical installer automatically applies to the other one, and vice versa. Win win :) Ed wrote a bit too fast, as by now almost every part is ready and pending review in Phabricator. However overall it is not an easy thing to just approve and push, as it adds weight to releases (currently 8 GB on amd64), flirts with what is acceptable in base (e.g., downloading ports to generate an image) and will probably require documentation updates as well. So this will still take time and broader approval before making it to a future release. Knowing this, I took it upon myself to travel to AsiaBSDCon and communicate about this project at the DevSummit and at the conference, and I also intend to present it to a broader group of FreeBSD developers next week during BSDCan. I would like to conclude by mentioning two related initiatives: Alfonso Siciliano, the author of bsddialog, is working on an additional installation step which would drop a graphical interface after installation if so desired - thus fixing the POLA violation - while a GSoC student, Leaf Yen, is working on extending the installation media for upgrading or repairing existing installations. I am very much looking forward to the first official release of such commercial-grade installation media for FreeBSD :) Anyhow hoping this clarifies, -- Pierre Pronchery -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279200] sysrc(8) fails to perform set operations for += and -= in -c (check only) mode.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279200 Bug ID: 279200 Summary: sysrc(8) fails to perform set operations for += and -= in -c (check only) mode. Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: cr...@rlwinm.de The sysrc command does not perform required set union/difference operations when asked to check if a variable contains certain values (or not) e.g. the following sequences of commands returns failure when it shouldn't: sysrc jail_list="jail1 jail2 jail3" && sysrc -c jail_list+=" jail2" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 Bug ID: 279199 Summary: cross-compile installworld fails attempting to copy vdso library Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: marksh...@aol.com Attachment #250855 text/plain mime type: Created attachment 250855 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250855=edit console output from make installworld Cross compiling on amd64 for powerpc64. buildworld and buildkernel run fine. installworld fails attempting to copy non-existent vdso library. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279195] kernel panic while re-configuring if_vlan(4) vlan id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279195 Kristof Provost changed: What|Removed |Added Assignee|b...@freebsd.org|k...@freebsd.org Status|New |In Progress --- Comment #3 from Kristof Provost --- Patch in https://reviews.freebsd.org/D45285 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279198] devd_enable="NO" do not set hw.bus.devctl_queue to 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279198 Eugene Grosbein changed: What|Removed |Added Assignee|b...@freebsd.org|eu...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279198] devd_enable="NO" do not set hw.bus.devctl_queue to 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279198 Eugene Grosbein changed: What|Removed |Added CC||eu...@freebsd.org --- Comment #1 from Eugene Grosbein --- Created attachment 250852 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250852=edit proposed fix Please apply proposed patch to /etc/rc.d/devd and report back. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279198] devd_enable="NO" do not set hw.bus.devctl_queue to 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279198 Bug ID: 279198 Summary: devd_enable="NO" do not set hw.bus.devctl_queue to 0 Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: dmitryluhtio...@gmail.com devd_enable="NO" do not set hw.bus.devctl_queue to 0 FreeBSD vpn 14.0-STABLE FreeBSD 14.0-STABLE #0 stable/14-n267376-ca8e2e4c91cc: Thu Apr 18 05:55:35 UTC 2024 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279195] kernel panic while re-configuring if_vlan(4) vlan id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279195
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #2 from Kristof Provost ---
Yeah, that seems to need this:
diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c
index b69d8107e30d..b936d4673404 100644
--- a/sys/net/if_vlan.c
+++ b/sys/net/if_vlan.c
@@ -1715,10 +1715,17 @@ vlan_config(struct ifvlan *ifv, struct ifnet *p,
uint16_t vid,
ifv->ifv_proto = proto;
if (ifv->ifv_vid != vid) {
+ int oldvid = ifv->ifv_vid;
+
/* Re-hash */
vlan_remhash(trunk, ifv);
ifv->ifv_vid = vid;
error = vlan_inshash(trunk, ifv);
+ if (error) {
+ ifv->ifv_vid = oldvid;
+ /* Re-insert back where we found it. */
+ vlan_inshash(trunk, ifv);
+ }
}
/* Will unlock */
goto done;
After # ifconfig vlan0 vlan 110 you'll see that vlan0 thinks it's on 111, so
when it tries to vlan_remhash() it's not where it expects to find it.
There may be a similar problem in the case where we don't yet have a vlandev.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279195] kernel panic while re-configuring if_vlan(4) vlan id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279195 --- Comment #1 from Zhenlei Huang --- Backtrace: ``` Unread portion of the kernel message buffer: panic: vlan_remhash: vlan not found cpuid = 1 time = 1716278185 KDB: stack backtrace: #0 0x80b9009d at kdb_backtrace+0x5d #1 0x80b431a2 at vpanic+0x132 #2 0x80b43063 at panic+0x43 #3 0x80c72553 at vlan_remhash+0x63 #4 0x80c7414d at vlan_config+0xdd #5 0x80c73bea at vlan_ioctl+0x41a #6 0x80c60723 at ifhwioctl+0x883 #7 0x80c62843 at ifioctl+0x913 #8 0x80bb15a5 at kern_ioctl+0x255 #9 0x80bb12e3 at sys_ioctl+0x123 #10 0x8100d119 at amd64_syscall+0x109 #11 0x80fe43db at fast_syscall_common+0xf8 Uptime: 47s Dumping 696 out of 16207 MB:..3%..12%..21%..33%..42%..51%..63%..72%..81%..92% (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdownc:405 #2 0x80b42d37 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:526 #3 0x80b4320f in vpanic (fmt=0x81150b30 "%s: vlan not found\n", ap=ap@entry=0xfe00f9bcd9c0) at /usr/src/sys/kern/kern_shutdown.c:970 #4 0x80b43063 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:894 #5 0x80c72553 in vlan_remhash (trunk=, ifv=ifv@entry=0xf8032f2c9d80) at /usr/src/sys/net/if_vlan.c:480 #6 0x80c7414d in vlan_config (ifv=ifv@entry=0xf8032f2c9d80, p=p@entry=0xf80003ba7800, vid=111, proto=) at /usr/src/sys/net/if_vlan.c:1719 #7 0x80c73bea in vlan_ioctl (ifp=0xf8036582e000, ifp@entry=, cmd=, cmd@entry=, data=, data@entry=) at /usr/src/sys/net/if_vlan.c:2264 #8 0x80c60723 in ifhwioctl (cmd=cmd@entry=2149607737, ifp=0xf8036582e000, data=data@entry=0xfe00f9bcdd50 "vlan0", td=td@entry=0xfe00fae223a0) at /usr/src/sys/net/if.c:2757 #9 0x80c62843 in ifioctl (so=0xf8000ae773c0, so@entry=, cmd=2149607737, cmd@entry=, data=0xfe00f9bcdd50 "vlan0", data@entry=, td=0xfe00fae223a0, td@entry=) at /usr/src/sys/net/if.c:3070 #10 0x80bb15a5 in fo_ioctl (fp=0xf800039b5640, com=2149607737, data=, active_cred=, td=0xfe00fae223a0) at /usr/src/sys/sys/file.h:366 #11 kern_ioctl (td=td@entry=0xfe00fae223a0, fd=, com=com@entry=2149607737, data=, data@entry=0xfe00f9bcdd50 "vlan0") at /usr/src/sys/kern/sys_generic.c:805 #12 0x80bb12e3 in sys_ioctl (td=0xfe00fae223a0, uap=0xfe00fae227a0) at /usr/src/sys/kern/sys_generic.c:713 #13 0x8100d119 in syscallenter (td=0xfe00fae223a0) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 #14 amd64_syscall (td=0xfe00fae223a0, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1197 #15 #16 0x178be8b75e0a in ?? () Backtrace stopped: Cannot access memory at address 0x178be401c0a8 (kgdb) ``` -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279195] kernel panic while re-configuring if_vlan(4) vlan id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279195 Bug ID: 279195 Summary: kernel panic while re-configuring if_vlan(4) vlan id Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: z...@freebsd.org Spot this while repeating https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279181 . Steps to repeat: ``` # ifconfig vlan0 create vlan 100 vlandev cxl0 # ifconfig vlan1 create vlan 110 vlandev cxl0 # ifconfig vlan0 vlan 110 ifconfig: SIOCSETVLAN: File exists # ifconfig vlan0 vlan 110 # ifconfig vlan0 vlan 111 .. panic ... ``` -- You are receiving this mail because: You are the assignee for the bug.
