[Bug 280028] S3 suspend of Thinkpad x270 stopped working after freebsd-update to 14.1-RELEASE-p1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280028 cos changed: What|Removed |Added Status|Open|Closed Resolution|--- |FIXED --- Comment #21 from cos --- I never did manage to reverse engineer the seemingly undocumented FreeBSD release process. Thus without knowing which branch/commits to build, the bisecting never commenced. (I also tried obvious ideas such as `rgrep '14.1-RELEASE-p1' /usr/src`, but that returns empty.) However suspend-resume works reliably again after an upgrade to 14.1-RELEASE-p5. So I guess someone did solve this. Great! Closing as FIXED. Please feel free to re-categorize as DUPLICATE or whatever if more appropriate. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282279] The rc(8) scripts 'netif' or 'routing' man pages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279 Bug ID: 282279 Summary: The rc(8) scripts 'netif' or 'routing' man pages Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: verma...@interia.pl The rc(8) 'netif' and 'routing' scripts could/should have at least some basic man(1) page. Even people that are quite long into FreeBSD does not really get all the stuff they do: - https://mastodon.bsd.cafe/@mms/113353330603293053 Regards, vermaden -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281218] Quectel LTE MODEM not working anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218 --- Comment #18 from cyberponk --- Same problem here and I have an external LTE modem so I will use it until the problem is fixed. If you need any testing i´m available. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282279] The rc(8) scripts 'netif' or 'routing' should have man pages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=1089 ||80 Summary|The rc(8) scripts 'netif' |The rc(8) scripts 'netif' |or 'routing' man pages |or 'routing' should have ||man pages -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #54 from Mark Millard --- I've finally tested the RPi5 with video. I've installed official builds of: xorg-minimal-7.5.2_3 X.Org minimal distribution metaport xf86-video-scfb-0.0.7_2X.Org syscons display driver lxqt-2.0.0_1 Meta-port for the LXQt Desktop firefox-131.0_1,2 Web browser based on the browser portion of Mozilla gimp-2.10.38,2 Meta-port for the Gimp (Of course, lots more was also installed.) Because there is a known crash-issue for firefox vs. aslr on aarch64, I'm using: # proccontrol -m aslr -s disable firefox to run firefox. The RPi5 has 8 GiBytes of RAM. I'm not activating swap. My context does not have the accounting patches, so I'm ignoring laundry but monitoring free via top. (My top build is a personally patched variation.) The context is UFS based, zfs.ko not loaded. main [so: 15]. Firefox with some https://www.homedepot.com tabs and a gimp are running. A simple ssh session from another computer is in use for monitoring from another room. After everything was set up I saw the likes of 3571Mi Free. But I'm leaving it idle, not using it. In your context, is there a known way to get the OOM problem with some programs running but with on interactive use of the system once set up? Is there a known time frame for such for seeing notable Free decreases in your context? After about 60 min: 3452Mi Free, so about 119 MiByte drop in an hour but I've no clue if such a rate will be sustained. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #8 from Mark Johnston --- (In reply to Christos Margiolis from comment #7) Those messages are the result of basically the same bug, but this time in devmatch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #9 from Mark Johnston --- https://reviews.freebsd.org/D47243 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #52 from Mark Millard --- (In reply to Henrich Hartzer from comment #50) Were Active, Inact, Laundry, Wired, and Free such that Laundry was huge in each case (and the others were not)? Did the lead up to the failures have Laundry increasing at a notable sustained rate vs. did it more suddenly jump? If you had spare USB media and a USB port, for example, having a swap space that is say, something like 3.6*RAM (so RAM+SWAP == 4.6*RAM) and seeing if the RAM+SWAP use stabilized before running out of RAM+SWAP could be interesting. If it stabilized, you might be able to see how much RAM+SWAP your example-being-tested needs. That can help for future planning. (The 3.6 factor should avoid warnings when the swap is added about potentially being mistuned.) (This USB or analogous test need not be biased for the performance you would like in normal operation.) Now that you get reasonable/useful Active, Inact, Laundry, Wired, and Free figures while monitoring in top, such explorations should now be possible via use of top. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #50 from Henrich Hartzer --- Thank you! That is interesting. So the memory can be reclaimed if pushed out to swap, but I wonder if swap would fill up fairly quickly. Running with all of the patches I had some more OOM behavior. I had a fairly light Firefox (a dozen tabs, nothing very heavy), some other processes, and ran Gimp. I couldn't get very far with Gimp. pid 1614 (firefox), jid 0, uid 1003, was killed: a thread waited too long to allocate a page iwn0: RF switch: radio disabled wlan0: link state changed to DOWN pid 11298 (firefox), jid 0, uid 1002, was killed: a thread waited too long to allocate a page pid 1532 (firefox), jid 0, uid 1002, was killed: failed to reclaim memory pid 68014 (gimp-2.10), jid 0, uid 0, was killed: failed to reclaim memory When the system starts to lock up, I kill the RF switch which usually helps it become more responsive. You can see the "a thread waited too long to allocate a page" error again. With my main Firefox process dead I tried Gimp again. I could barely use it before it died again. pid 69150 (gimp-2.10), jid 0, uid 0, was killed: failed to reclaim memory pid 98331 (keepassxc), jid 0, uid 0, was killed: failed to reclaim memory pid 1729 (telegram-desktop), jid 0, uid 1002, was killed: failed to reclaim memory Is "failed to reclaim memory" from not being able to swap out the dirty pages? I'm surprised by how much memory Firefox and Gimp use. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #51 from Mark Millard --- (In reply to Mark Millard from comment #49) Hmm. Making explicit that unswappable is laundry would be more like (adding "laundry" to each of the pair): vm.domain.0.stats.unswappable: Unswappable laundry pages vm.domain.0.stats.unswppdpgs: Unswappable laundry pages scanned by the page daemon And, avoiding capitalizing "laundry" after "Swappable": vm.domain.0.stats.laundpdpgs: Swappable laundry pages scanned by the page daemon -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #6 from Christos Margiolis --- (In reply to Mark Johnston from comment #5) Right, this makes since the panics would occur after recompiling the module I work working on. I'm now compiling the kernel with the patch applied to test if it fixes the problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #53 from Mark Millard --- (In reply to Henrich Hartzer from comment #50) "failed to reclaim memory" is from multiple attempts to increase the free RAM to not be below a target threshold. There is a parameter for controlling the number of attempts before the related OOM kills start. For example in /boot/loader.conf I have: # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 (You might well want bigger than 120. The default is 12 --last I knew anyway. You might want 1200 or 12000 for experimenting. I expect too large a number might end up with overflow problems but have not checked the details.) The setting does not ever disable the "failed to reclaim memory" OOM activity. It just makes it take longer to happen. It is more useful for spanning temporary heavy RAM use, such as can happen during buildworld, for example. It is not a fix for permanent heavy RAM use. But it can help allow exploring a context by giving more time before the OOM activity happens. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #5 from Mark Johnston --- (In reply to Christos Margiolis from comment #4) Yes, one of the consequences of the UFS soft updates implementation is that crashes can result in truncated files if those files had been written shortly before the panic. So if you do something like "make installkernel; ", the linker.hints file created by kldxref during installkernel might end up truncated. The kernel linker reads that file, and doesn't properly handle the case where it's truncated. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #10 from Christos Margiolis --- The devmatch patch catches the truncated linker files fine. Now I do not get any panic, but I do need to recompile the module in order to be able to load it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 --- Comment #17 from Mark Johnston --- (In reply to Andriy Gapon from comment #16) Yes, I've observed this too when measuring TCP ping-pong latency over loopback - latency is higher if the core was recently idle, I guess because autonomous CPPC gradually ramps up the awoken core's performance level. Running a background loop on the core results in lower latency. Unfortunately we don't have any driver (yet) to control CPPC on modern AMD systems. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #7 from Christos Margiolis --- The crash is fixed, thanks. It turns that linker.hints was indeed getting truncated (see below). Should these messages be concerning by any chance? Loading kernel modules: linker.hints file truncated devmatch: Linker hints version -1515870811 doesn't match expected 1. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg 32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32 Setting hostname: freebsd. Setting up harvesting: PURE_VMGENID,PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . lo0: link state changed to UP vtnet0: link state changed to UP Starting Network: lo0 vtnet0. lo0: flags=1008049 metric 0 mtu 16384 options=680003 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 groups: lo nd6 options=21 vtnet0: flags=1008843 metric 0 mtu 1500 options=80028 ether 00:a0:98:0e:02:93 inet 169.254.0.2 netmask 0x broadcast 169.254.255.255 media: Ethernet autoselect (10Gbase-T ) status: active nd6 options=29 Starting devd. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. devmatch: Linker hints version -1515870811 doesn't match expected 1. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282267] boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267 --- Comment #4 from Trond Endrestøl --- To clarify, this was experienced yesterday on a VM running on Xen, XCP-ng 8.2.1. It might apply to any system, physical or virtual, exposing a serial port. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #49 from Mark Millard --- (In reply to commit-hook from comment #48) Previous(/current) descriptions : vm.domain.0.stats.laundpdpgs: Laundry pages scanned by the page daemon vm.domain.0.stats.laundry: laundry pages vm.domain.0.stats.unswappable: Unswappable pages vm.domain.0.stats.unswppdpgs: Unswappable pages scanned by the page daemon More accurate ones for comparison/contrast (if I've understood right)? : vm.domain.0.stats.laundpdpgs: Swappable Laundry pages scanned by the page daemon vm.domain.0.stats.laundry: Swappable+Unswappable laundry pages vm.domain.0.stats.unswappable: Unswappable pages vm.domain.0.stats.unswppdpgs: Unswappable pages scanned by the page daemon vm.domain.0.stats.laundpdpgs is actually unchanged but in the new context the original description is highly ambiguous via it not matching vm.domain.0.stats.laundry . To estimate the old vm.domain.0.stats.laundry value (just Swappable) requires subtraction in the new context. Also: vm.domain.0.stats.laundry+vm.domain.0.stats.unswappable should not be used in the new context (avoiding double counting of unswappable). The proposed wording suggests those points. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282279] The rc(8) scripts 'netif' or 'routing' should have man pages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279 Alexander Ziaee changed: What|Removed |Added CC||zi...@runbox.com --- Comment #1 from Alexander Ziaee --- I have a draft dated June 16th but gave up because 1. (Afaict) no rc.d scripts have manpages and 2. I'm not even close to qualified to write this. I would like to mention a caveat that local internet operations like attaching graphical console to a bhyve on the same machine, or using musicpd, will fail if netif is stopped. Service routing restart isn't necessary at least on dhcp wifi. I don't fully understand what's going on there, but I did have to remove it from wifi(7) because it does break things on some setups. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282281] zfs: panic: VERIFY(avl_is_empty(&sk->sk_dsl_keys)) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282281 Bug ID: 282281 Summary: zfs: panic: VERIFY(avl_is_empty(&sk->sk_dsl_keys)) failed Product: Base System Version: 15.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: lexi.free...@le-fay.org observed while shutting down. host: FreeBSD 15.0-CURRENT #3 lf/main-n269068-2cff93ced1d: Wed Oct 23 02:48:20 BST 2024 srcma...@hemlock.eden.le-fay.org:/data/build/obj/freebsd/data/build/src/freebsd/lf/main/amd64.amd64/sys/GENERIC root@hemlock:~ # shutdown -r now Shutdown NOW! shutdown: [pid 74216] root@hemlStopping jails:. Stopping bird. Waiting for PIDS: 26888Oct 23 06:44:39 hemlock bird[26888]: Shutdown completed . Stopping cron. Waiting for PIDS: 19791. Stopping inetd. Waiting for PIDS: 28413. Stopping smartctl_exporter. Waiting for PIDS: 40315. Stopping rsyncd. Waiting for PIDS: 35838. Stopping node_exporter. Waiting for PIDS: 34016. Stopping nginx. Waiting for PIDS: 30716. Stopping nfsd. Waiting for PIDS: 19020 19719. Stopping smbd. Waiting for PIDS: 16334. Stopping mountd. Waiting for PIDS: 7148. Stopping nscd. Waiting for PIDS: 89764. /etc/rc.shutdown: WARNING: $buildbot_enable is not set properly - see rc.conf(5). Stopping openssh. Waiting for PIDS: 2821, 2821. eval: utx: not found Stopping powerd. Waiting for PIDS: 99443. Stopping ntpd. Waiting for PIDS: 98249. Stopping unbound. Waiting for PIDS: 42838. Beginning shutdown process * parallel shutdown of non-ordered guests: system.grp system.grp system.pwd system.pwd * stopping lab3 * waiting 2 second(s) * stopping lab2 * waiting 2 second(s) * stopping lab1 * waiting 2 second(s) * stopping ivy * waiting 2 second(s) * stopping lily * waiting 2 second(s) * stopping iris * waiting 2 second(s) * stopping media Waiting for PIDS: 29703 97832 1242 4323 90 second watchdOct 23 06:46:10 hemlock init[1]: /etc/rc.shutdown terminated abnormally, going to single user mode Oct 23 06:46:10 hemlock syslogd: exiting on signal 15 vmnet8: link state changed to DOWN vmnet7: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 0 0 done All buffers synced. Uptime: 19m16s panic: VERIFY(avl_is_empty(&sk->sk_dsl_keys)) failed cpuid = 0 time = 1729662389 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0104810ac0 vpanic() at vpanic+0x13f/frame 0xfe0104810bf0 spl_panic() at spl_panic+0x3a/frame 0xfe0104810c50 spa_keystore_fini() at spa_keystore_fini+0xe4/frame 0xfe0104810c90 spa_deactivate() at spa_deactivate+0x388/frame 0xfe0104810ce0 spa_evict_all() at spa_evict_all+0xc8/frame 0xfe0104810d00 spa_fini() at spa_fini+0x18/frame 0xfe0104810d40 zfs_kmod_fini() at zfs_kmod_fini+0x7e/frame 0xfe0104810d60 zfs_shutdown() at zfs_shutdown+0x2b/frame 0xfe0104810d70 kern_reboot() at kern_reboot+0x4f3/frame 0xfe0104810db0 sys_reboot() at sys_reboot+0x396/frame 0xfe0104810e00 amd64_syscall() at amd64_syscall+0x158/frame 0xfe0104810f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0104810f30 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x2884ba, rsp = 0x820811528, rbp = 0x820811610 --- KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at kdb_enter+0x33: movq$0,0x1054b02(%rip) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282279] The rc(8) scripts 'netif' or 'routing' should have man pages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279 --- Comment #2 from Slawomir Wojciech Wojtczak --- IMHO it does not have to be 'separate' man pages - it may be something like 'rc-roles' or rc-scripts' or 'rc-services' ... that would be probably good way to start - and more and more service names could be added to it later. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282269] /etc/rc.d/kld: print the kernel modules being loaded
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282269 Bug ID: 282269 Summary: /etc/rc.d/kld: print the kernel modules being loaded Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: f...@freebsd.org Created attachment 254445 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254445&action=edit kld patch the kld rc script currently just prints Loading kernel modules: and nothing else. It really should tell us what it's doing. This patch will change it to print out like: Loading kernel modules: if_epair if_ovpn accf_http accf_data -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282269] /etc/rc.d/kld: print the kernel modules being loaded
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282269 Mark Felder changed: What|Removed |Added Component|misc|conf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #47 from Mark Johnston --- (In reply to Mark Millard from comment #46) My wording wasn't very good. I was speculating about the contents of the laundry queue on Henrich's system specifically. You're right that process exit can also reclaim pages (from the laundry queue), but here I'm assuming that many of the laundry queue pages there are owned by firefox. The inactive queue contains a mix of clean and dirty pages. The queue is scanned only when there is memory pressure. "Recently referenced" pages are moved back to the active queue or requeued to the tail of the inactive queue. Unreferenced pages found to be dirty during a scan are moved to the laundry queue, while clean pages are reclaimed on the spot. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #48 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6a07e67fb7a8b5687a492d9d70a10651d5933ff5 commit 6a07e67fb7a8b5687a492d9d70a10651d5933ff5 Author: Mark Johnston AuthorDate: 2024-10-22 12:48:43 + Commit: Mark Johnston CommitDate: 2024-10-22 12:48:43 + vm_meter: Fix laundry accounting Pages in PQ_UNSWAPPABLE should be considered part of the laundry. Otherwise, on systems with no swap, the total amount of memory visible to tools like top(1) decreases. It doesn't seem very useful to have a dedicated counter for unswappable pages, and updating applications accordingly would be painful, so just lump them in with laundry for now. PR: 280846 Reviewed by:bnovkov, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D47216 sys/vm/vm_meter.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #2 from Christos Margiolis --- Not sure if this theory is correct, but I am noticing that the issue is more frequent when the panic was caused by a manual call to panic(9), as opposed to, say, a memory issue. I sent you the dump file on Slack because it's too big to attach here. Seems like it's crashing when loading filemon(4): (kgdb) bt #0 __curthread () at /mnt/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=textdump@entry=0) at /mnt/src/sys/kern/kern_shutdown.c:404 #2 0x805a33b6 in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /mnt/src/sys/ddb/db_command.c:595 #3 0x805a31eb in db_command (last_cmdp=, cmd_table=, dopager=true) at /mnt/src/sys/ddb/db_command.c:508 #4 0x805a2bfd in db_command_loop () at /mnt/src/sys/ddb/db_command.c:555 #5 0x805a8979 in db_trap (type=, code=) at /mnt/src/sys/ddb/db_main.c:267 #6 0x81189485 in kdb_trap (type=3, code=code@entry=0, tf=tf@entry=0xfe0046ce0110) at /mnt/src/sys/kern/subr_kdb.c:790 #7 0x81a201a8 in trap (frame=0xfe0046ce0110) at /mnt/src/sys/amd64/amd64/trap.c:606 #8 #9 kdb_enter (why=, msg=) at /mnt/src/sys/kern/subr_kdb.c:556 #10 0x810dde37 in vpanic ( fmt=fmt@entry=0x81c8f46f "ASan: Invalid access, %zu-byte %s at %#lx, %s(%x)", ap=ap@entry=0xfe0046ce03e0) at /mnt/src/sys/kern/kern_shutdown.c:967 #11 0x810ddbd5 in panic (fmt=0x81c8f46f "ASan: Invalid access, %zu-byte %s at %#lx, %s(%x)") at /mnt/src/sys/kern/kern_shutdown.c:892 #12 0x81160970 in kasan_report (addr=18446741875887136624, size=4, write=false, pc=, code=) at /mnt/src/sys/kern/subr_asan.c:202 #13 0x8107f1f3 in linker_hints_lookup ( path=0x829c65e0 "/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays", modname=0xfe004a17ec00 "filemon", modnamelen=7, verinfo=0x0, pathlen=) at /mnt/src/sys/kern/kern_linker.c:2046 #14 linker_search_module (modname=0xfe004a17ec00 "filemon", modnamelen=7, verinfo=0x0) at /mnt/src/sys/kern/kern_linker.c:2134 #15 linker_load_module (kldname=kldname@entry=0x0, modname=0xfe004a17ec00 "filemon", parent=parent@entry=0x0, verinfo=verinfo@entry=0x0, lfpp=lfpp@entry=0xfe0046ce0c00) at /mnt/src/sys/kern/kern_linker.c:2272 #16 0x81082e23 in kern_kldload (td=, file=file@entry=0xfe004a17ec00 "filemon", fileid=fileid@entry=0xfe0046ce0ca0) at /mnt/src/sys/kern/kern_linker.c:1236 #17 0x81083052 in sys_kldload (td=0x826074b0 , uap=) at /mnt/src/sys/kern/kern_linker.c:1259 #18 0x81a223ae in syscallenter (td=0xfe005bc4c000) at /mnt/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #19 amd64_syscall (td=0xfe005bc4c000, traced=0) at /mnt/src/sys/amd64/amd64/trap.c:1192 #20 #21 0x12614498a7da in ?? () Backtrace stopped: Cannot access memory at address 0x126142f959a8 (kgdb) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 243548] mlx4en shows DAC cable media type as '10Gbase-SR'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243548 Eric Sproul changed: What|Removed |Added CC||e...@thesprouls.net --- Comment #1 from Eric Sproul --- The same situation happens for sfxge (Solarflare) when using DAC cabling. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN after post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 Bug ID: 282268 Summary: linker_load_module() panics with KASAN after post-panic reboot Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: chris...@freebsd.org Created attachment 25 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=25&action=edit linker_load_module() disassembly This is a relatively consistent bug, although it does not have a 100% reproduction rate. What I usually do is the following: 1. Boot into a KASAN kernel. 2. Panic the kernel somehow and reboot. 3. During the reboot, it is likely that linker_load_module() will panic when rc(8) is trying to load the modules. I have also attached the linker_load_module() disassembly. Sample panic message: Loading kernel modules: panic: ASan: Invalid access, 4-byte read at 0xfe0047935020, MallocRedZone(fb) cpuid = 1 time = 1729606284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfe0046c3f070 kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfe0046c3f1d0 vpanic() at vpanic+0x226/frame 0xfe0046c3f370 panic() at panic+0xb5/frame 0xfe0046c3f440 kasan_code_name() at kasan_code_name/frame 0xfe0046c3f510 linker_load_module() at linker_load_module+0xe03/frame 0xfe0046c3fbb0 kern_kldload() at kern_kldload+0x233/frame 0xfe0046c3fc70 sys_kldload() at sys_kldload+0xd2/frame 0xfe0046c3fd10 amd64_syscall() at amd64_syscall+0x39e/frame 0xfe0046c3ff30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0046c3ff30 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x311d0dce37da, rsp = 0x311d0c9d2428, rbp = 0x311d0c9d29a0 --- KDB: enter: panic [ thread pid 92 tid 100096 ] Stopped at kdb_enter+0x34: movq$0,0x1f09b11(%rip) db> -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN after post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 Mark Johnston changed: What|Removed |Added Status|New |Open CC||ma...@freebsd.org --- Comment #1 from Mark Johnston --- Can you get a kernel dump? Which module is it trying to load? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 Christos Margiolis changed: What|Removed |Added Summary|linker_load_module() panics |linker_load_module() panics |with KASAN after post-panic |with KASAN during |reboot |post-panic reboot -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282267] boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267 Bug ID: 282267 Summary: boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: trond.endres...@ximalas.info Both of boot_multicons and boot_serial are set to NO, and console is set to efi, yet the boot loader gives the impression that I want a dual console with serial as the primary. The later boot loader logic seems to be correct. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282267] boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267 --- Comment #1 from Trond Endrestøl --- Created attachment 254441 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254441&action=edit The last six lines of /boot/loader.conf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282267] boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267 --- Comment #2 from Trond Endrestøl --- Created attachment 254442 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254442&action=edit Excerpt from the show command, notice the values for boot_multicons, boot_serial, and console -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282267] boot_multicons="NO", boot_serial="NO", and console="efi" in /boot/loader.conf isn't respected by the boot loader's menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267 --- Comment #3 from Trond Endrestøl --- Created attachment 254443 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254443&action=edit The boot loader's menu thinks I want a dual console with serial as the primary -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282143] grep -v does nothing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282143 Mark Johnston changed: What|Removed |Added Resolution|--- |Works As Intended CC||ma...@freebsd.org Status|New |Closed --- Comment #5 from Mark Johnston --- I believe there is no bug here, at least not in grep. Please re-open if I'm missing something. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282271] praudit -n still resolves uids/gids
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282271 Bug ID: 282271 Summary: praudit -n still resolves uids/gids Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: knan-...@modirum.com man praudit(1) says -n Do not convert user and group IDs to their names but leave in their numeric forms. yet this doesn't seem to work. uids are still resolved to names. This is unhelpful when audit files are shipped to other machines. example: cat | praudit -n header_ex,131,11,execve(2),0,10.4.15.10,Tue Oct 22 06:00:14 2024, + 43 msec exec arg,wc,-l path,/usr/bin/wc attribute,555,root,wheel,3566801450,67953,0 subject,-1,root,wheel,root,wheel,48335,0,0,0.0.0.0 return,success,0 trailer,131 # freebsd-version -ukr 14.1-RELEASE 14.1-RELEASE 14.1-RELEASE-p2 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 Mark Linimon changed: What|Removed |Added Keywords||crash, loader -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 --- Comment #16 from Andriy Gapon --- Just in case, I want to share an old discovery of mine: https://forums.FreeBSD.org/threads/variable-ping-latency-on-ryzen-setup.82791/post-547552 The point is that not all "micro-stutter" can be attributed to FreeBSD. The hardware itself may introduce it during very low utilization for power saving reasons. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #3 from Mark Johnston --- Are you using UFS? I bet your linker.hints is getting truncated during the panic, which triggers a small bug in the kernel linker: https://reviews.freebsd.org/D47240 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282268] linker_load_module() panics with KASAN during post-panic reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268 --- Comment #4 from Christos Margiolis --- (In reply to Mark Johnston from comment #3) Yes, the VM is using UFS. Why is this a problem on UFS specifically, by the way? -- You are receiving this mail because: You are the assignee for the bug.
