[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #11 from Tomasz "CeDeROM" CEDRO --- In another bug report I have tried to create fallback xorg.conf configuration that would allow working on a machine even with no 3D acceleration but there are several problems: 1. scfb only works on a single monitor. no multi-monitor work is possible (xinerama?). 2. two monitor work is possible only when amdgpu module is loaded. 3. when one screen is rotated (pivot) this requires xranrd and this does not work when "accel" option is disabled. 4. as described above in #c10 setting "dri" "2" helps a bit but workstation also remains unreliable. Does anyone know how to create xorg.conf that would allow working with two monitor (one rotated) setup without drm kmod linuxkpi? Such fallback would be really good to have :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278283] /usr/bin/calendar: 11 bugs fixed, major improvements [tarball]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278283
w...@psr.com changed:
What|Removed |Added
Product|Base System |Ports & Packages
Version|Unspecified |Latest
Component|bin |Individual Port(s)
--- Comment #2 from w...@psr.com ---
Over a month and no reply at all even though all the code was provided? I'm a
bit surprised. Maybe the relevant people have been busy...
I changed "Product" for this bug report from "base system" to "ports and
packages". calendar is both and can be released either way. If it's not going
to make it into 14.1, then it most likely would first appear via port/package.
In line 291 of my new calendar.c, I'd like to replace "to" with "and":
- printf ("%d days between %d/%02d/%02d to %d/%02d/02d\n",
+ printf ("%d days between %d/%02d/%02d and %d/%02d/02d\n",
[END]
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277389] Reproduceable low memory freeze on 14.0-RELEASE-p5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389 --- Comment #39 from Henrich Hartzer --- Ok, I finally had an OOM again. Here's the dmesg excerpt: pid 95407 (firefox), jid 0, uid 1003, was killed: a thread waited too long to allocate a page Not sure if related to ZFS or not. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 231768] [request] Disable COMPAT_FREEBSD4/5/6/7/9 as default kernel option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #7 from Warner Losh --- I think this is a good idea... But it's scope is larger than just a bug request... Maybe post it to arch@ as a discussion point? I suspect people will be like "sure, no problem." One question you should have answered up front is "how will this affect rust since it uses that old FreeBSD 10 binary stuff" or did at one point. That's the only possible reason to keep old stuff... and I think that it's fine to do this, and there's no lurking 'killer ap' that would need it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 231768] [request] Disable COMPAT_FREEBSD4/5/6/7/9 as default kernel option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 --- Comment #8 from Henrich Hartzer --- I think Rust will be okay as this doesn't touch version 10 and supposedly it's being bumped along: https://github.com/rust-lang/rust/issues/89058 I'll send an email to arch@. That seems like a good idea. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277389] Reproduceable low memory freeze on 14.0-RELEASE-p5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389 --- Comment #40 from Mark Millard --- (In reply to Henrich Hartzer from comment #39) "was killed: a thread waited too long to allocate a page" and how you produce it is likely not a good match to the context for the panics or for the "failed to reclaim memory" notices reported by Pascal or others trying to replicate Pascal's failures via steps similar to Pascal's steps. You likely need your own Bugzilla submittal with its own steps-to-reproduce (in/for your context, anyway). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278888] [regression] login.conf setenv silently drops " inside string values
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27 --- Comment #2 from Sean Eric Fagan --- Hm, I think that was in fact a deliberate choice on my part, to treat quotes the way one would in sh. I'd have to go try a test with it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 Bug ID: 278908 Summary: Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen Product: Base System Version: Unspecified Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ni...@protonmail.com Do we have that fix in llvm for the upcoming release of 14.1? https://github.com/llvm/llvm-project/issues/90985 https://www.phoronix.com/news/LLVM-Slower-With-AMD-Opts -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278063] Add znver4 to 14-STABLE examples
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278063 --- Comment #3 from ni...@protonmail.com --- (In reply to Joel Bodenmann from comment #2) Same here compiling base with znver4 works here too (14.0) so i think it should be back-ported for 14.0/14.1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278888] [regression] login.conf setenv silently drops " inside string values
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27 --- Comment #3 from Benjamin Takacs --- (In reply to Sean Eric Fagan from comment #2) sh has one of the worst ways to handle strings (there are reasons like word splitting for that, but that still doesn't make it good and those reasons don't apply to login.conf and similar). I think bug 236204 should have been fixed, by not treating '\054' as if it were ','. As that would give you propper terminators for strings. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277677] /bin/rmdir should exit with status code 2 for invalid arguments
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277677 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9bcc1b18c119148e4455e548c90b2bc9cef16d1b commit 9bcc1b18c119148e4455e548c90b2bc9cef16d1b Author: Henrich Hartzer AuthorDate: 2024-05-10 17:53:49 + Commit: Warner Losh CommitDate: 2024-05-11 19:13:28 + /bin/rmdir: Exit with status 2 for invalid arguments PR: 277677 Signed-off-by: Henrich Hartzer Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1161 bin/rmdir/rmdir.1 | 15 --- bin/rmdir/rmdir.c | 2 +- bin/rmdir/tests/rmdir_test.sh | 6 +++--- 3 files changed, 12 insertions(+), 11 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 231768] [request] Disable COMPAT_FREEBSD4/5/6/7/9 as default kernel option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 Dag-Erling Smørgrav changed: What|Removed |Added CC||d...@freebsd.org --- Comment #9 from Dag-Erling Smørgrav --- Hard no. This is change for change's sake, with no justification beyond a handwavy “muh security”. If you have concrete issues with any of these options, feel free to raise them in separate PRs. Otherwise, let FreeBSD be FreeBSD. If you prefer HardenedBSD, you know where to find it. -- 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 Mark Linimon changed: What|Removed |Added Summary|'man 8 glabel' |'man 8 glabel': add extra ||content -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277340] X710-DA4 TX Queue ring_state STALLED without resetting to IDLE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277340 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278826] [hpet] cdev->si_refcount leakage when enable hpet as timecounter hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278826 --- Comment #8 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e93404065177d6c909cd64bf7d74fe0d8df35edf commit e93404065177d6c909cd64bf7d74fe0d8df35edf Author: Konstantin Belousov AuthorDate: 2024-05-07 13:23:28 + Commit: Konstantin Belousov CommitDate: 2024-05-12 01:13:00 + cdev_pager_allocate(): ensure that the cdev_pager_ops ctr is called only once per allocated vm_object. Otherwise, since constructors are not idempotent, we e.g. leak device reference in case of non-managed pager. PR: 278826 Reported by:Austin Zhang Reviewed by:alc, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D45113 sys/vm/device_pager.c | 70 +-- 1 file changed, 51 insertions(+), 19 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256722] [PATCH] EFI boot: Fix boot freeze on some systems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256722 --- Comment #20 from Vinícius Zavam --- (In reply to Vinícius Zavam from comment #19) funny fact here is that booting the installed OS only moves further when 140-R is used (install media: 'FreeBSD-14.0-RELEASE-amd64-disc1.iso') - still using a KVM guest [amd64]. though, we noticed that this installation media do not even offer the option to enable/disable 'ACPI' via "boot options" on the beastie menu - this symptom also shows up after the installation. * SCREENSHOT: https://share.riseup.net/#DwMljC5mQUweZ3XOzPHmJg once we identified that, we tried to disable ACPI before booting a fresh installed system after installing from 'FreeBSD-15.0-CURRENT-amd64-20240509-ce7756fdca1f-270021-disc1.iso'... but that did not work either. 14.1-BETA1 and newer medias do have ACPI enable/disable option again, on the boot options menu. RECAP: the following installation medias were tested (as KVM guest): * FreeBSD-14.0-RELEASE-amd64-disc1.iso * FreeBSD-14.1-BETA1-amd64-disc1.iso * FreeBSD-14.1-BETA2-amd64-disc1.iso * FreeBSD-14.1-PRERELEASE-amd64-20240425-9857f824ec77-267512-disc1.iso * FreeBSD-14.1-PRERELEASE-amd64-20240503-19e335596658-267586-disc1.iso * FreeBSD-14.1-STABLE-amd64-20240509-7b65987885da-267634-disc1.iso * FreeBSD-15.0-CURRENT-amd64-20240425-78101d437a92-269695-disc1.iso * FreeBSD-15.0-CURRENT-amd64-20240502-b07689d1f2a2-269827-disc1.iso * FreeBSD-15.0-CURRENT-amd64-20240509-ce7756fdca1f-270021-disc1.iso -- You are receiving this mail because: You are the assignee for the bug.
[Bug 243380] atrun(8) man page does not reflect cron.d change
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243380 Gordon Bergling changed: What|Removed |Added Status|New |In Progress --- Comment #4 from Gordon Bergling --- committed to HEAD, MFC is waiting. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277345] [nanoBSD] fix parameter expansion for ${NANO_OBJ} to also unbreak ${PATH}
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277345 Luc Hondareyte changed: What|Removed |Added CC||hondareyte@laposte.net --- Comment #1 from Luc Hondareyte --- Hello, This has been fixed with this commit https://cgit.freebsd.org/src/commit/?id=98bac6fb064ca7536ddb67b845c653b926b699a5 and pushed in stable/14 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278936] mqueuefs: Crashes when removing queue as user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278936 Bug ID: 278936 Summary: mqueuefs: Crashes when removing queue as user Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rbra...@suse.com A mounted mqueuefs crashes when removing queue as user. To reproduce: $ sudo mount -t mqueuefs none /mnt $ sudo touch /mnt/queue1 $ sudo rm -f /mnt/queue1 This only seems to crash on -CURRENT as I couldn't reproduce on -RELEASE or -STABLE. You can use the QEMU VM at https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-ufs.qcow2.xz dmesg log: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0x80ba8aae stack pointer = 0x28:0xfe0068c12e50 frame pointer = 0x28:0xfe0068c12ec0 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 = 0 (thread taskq) rdi: deadc0dedeadc0de rsi: c0de rdx: rcx: 0001 r8: 0001 r9: rax: 0001 rbx: f800034f6400 rbp: fe0068c12ec0 r10: 0001 r11: 0001 r12: 0001 r13: c0de r14: f800034f6458 r15: f80104001020 trap number = 9 panic: general protection fault cpuid = 1 time = 1715530856 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0068c12b90 vpanic() at vpanic+0x13f/frame 0xfe0068c12cc0 panic() at panic+0x43/frame 0xfe0068c12d20 trap_fatal() at trap_fatal+0x40b/frame 0xfe0068c12d80 calltrap() at calltrap+0x8/frame 0xfe0068c12d80 --- trap 0x9, rip = 0x80ba8aae, rsp = 0xfe0068c12e50, rbp = 0xfe0068c12ec0 --- taskqueue_run_locked() at taskqueue_run_locked+0x1be/frame 0xfe0068c12ec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfe0068c12ef0 fork_exit() at fork_exit+0x82/frame 0xfe0068c12f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0068c12f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278937] mqueuefs: Crashes when removing queue as user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278937 Bug ID: 278937 Summary: mqueuefs: Crashes when removing queue as user Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rbra...@suse.com A mounted mqueuefs crashes when removing queue as user. To reproduce: $ sudo mount -t mqueuefs none /mnt $ sudo touch /mnt/queue1 $ sudo rm -f /mnt/queue1 This only seems to crash on -CURRENT as I couldn't reproduce on -RELEASE or -STABLE. You can use the QEMU VM at https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-ufs.qcow2.xz dmesg log: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0x80ba8aae stack pointer = 0x28:0xfe0068c12e50 frame pointer = 0x28:0xfe0068c12ec0 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 = 0 (thread taskq) rdi: deadc0dedeadc0de rsi: c0de rdx: rcx: 0001 r8: 0001 r9: rax: 0001 rbx: f800034f6400 rbp: fe0068c12ec0 r10: 0001 r11: 0001 r12: 0001 r13: c0de r14: f800034f6458 r15: f80104001020 trap number = 9 panic: general protection fault cpuid = 1 time = 1715530856 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0068c12b90 vpanic() at vpanic+0x13f/frame 0xfe0068c12cc0 panic() at panic+0x43/frame 0xfe0068c12d20 trap_fatal() at trap_fatal+0x40b/frame 0xfe0068c12d80 calltrap() at calltrap+0x8/frame 0xfe0068c12d80 --- trap 0x9, rip = 0x80ba8aae, rsp = 0xfe0068c12e50, rbp = 0xfe0068c12ec0 --- taskqueue_run_locked() at taskqueue_run_locked+0x1be/frame 0xfe0068c12ec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfe0068c12ef0 fork_exit() at fork_exit+0x82/frame 0xfe0068c12f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0068c12f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278936] mqueuefs: Crashes when removing queue as user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278936 --- Comment #1 from Ricardo Branco --- *** Bug 278937 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278937] mqueuefs: Crashes when removing queue as user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278937 Ricardo Branco changed: What|Removed |Added Status|New |Closed Resolution|--- |DUPLICATE --- Comment #1 from Ricardo Branco --- *** This bug has been marked as a duplicate of bug 278936 *** -- You are receiving this mail because: You are the assignee for the bug.
Problem reports for b...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- New |252123 | fetch(3): Fix wrong usage of proxy when request i New |262764 | After DVD1 13.0-R install with ports tree, portsn New |262989 | sys/conf/files, sys/conf/options, sys/conf/NOTES: New |269994 | build options have different kernel and userland New |276571 | makefs(8) creates broken UFS images with sectorsi Open| 46441 | sh(1): Does not support PS1, PS2, PS4 parameter e Open|165059 | vtnet(4): Networking breaks with a router using v Open|177821 | sysctl: Some security.jail nodes are funky, dupli Open|220246 | syslogd does not send RFC3164-conformant messages Open|250309 | devmatch: panic: general protection fault: sysctl Open|255130 | Issue with rtsx driver Open|256952 | kqueue(2): Improve epoll Linux compatibility (com Open|257149 | CFLAGS not passed to whole build Open|257646 | opensm: rc service is installed by default, but o Open|258665 | lib/libfetch: Add Happy Eyeballs (RFC8305) suppor Open|259292 | vmware/pvscsi: UNMAP fails on VMWare 6.7 thinly p Open|259636 | multiple components: Change "Take Affect" to "Tak Open|259655 | periodic: security/security.functions does not re Open|259703 | In sys/dev/pci/pci.c, error in do_power_nodriver Open|259808 | etc/periodic/daily/100.clean-disks: Fix error (Di Open|260214 | acpi_battery: Should provide current/max battery Open|260245 | swap/vm: Apparent memory leak: 100% swap usage Open|261640 | sysctl: Add -F option to display sysctl format st Open|261641 | drm-kmod: Launch message is written into (possibl Open|261771 | nvme(4): Reports errors every 5 minutes: PRP OFFS Open|261971 | kernel crash launching bhyve guest on ZFS: #15 bu Open|262157 | su+j: Crashes during mmc(4) fsck after timeout: E Open|262192 | Crashes at boot with kern.random.initial_seeding. Open|264028 | loader: Incorrect (32gb) memory reported by BTX l Open|264075 | freebsd-update in 13.1-RELEASE detects an install Open|264188 | kinit(1): Ignores KRB5CCNAME environment variable Open|264226 | setting kern.vty=sc causes hang during UEFI boot Open|264833 | 12.3-STABLE panic on sync and reboot: panic: slee Open|266419 | mrsas: Corrupts memory (crashes) when reading dat 34 problems total for which you should take action.
[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 Tijl Coosemans changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 Bug ID: 278949 Summary: sysv IPC sysctl's behave differently for 32-bit on 64bits hosts Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rbra...@suse.com To reproduce: I created only one object of each type with the ipcmk command shipped by util-linux like this: $ ipcmk -M 1k -S 1 -Q Then ran ipcs in Ubuntu Jammy 64-bits & 32-bits created with `debootstrap [--arch i386] /compat/ubuntu[32]` $ sudo chroot /compat/ubuntu ipcs -a -- Message Queues keymsqid owner perms used-bytes messages 0x0fb549ed 65536 1000 64400 -- Shared Memory Segments keyshmid owner perms bytes nattch status 0x25caab18 65536 1000 6444096 0 -- Semaphore Arrays keysemid owner perms nsems 0xbf526696 65536 1000 6441 $ sudo chroot /compat/ubuntu32 ipcs -a -- Message Queues keymsqid owner perms used-bytes messages 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 0xdeadc0de 2147483647 3735929054 33616045693110842147038 16045693110842147038 -- Shared Memory Segments keyshmid owner perms bytes nattch status 0x1000 65536 1000 64471807 1715595399 -- Semaphore Arrays keysemid owner perms nsems 0x 65536 1000 6440 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278721] ldns uses nameserver commented out in resolv.conf (host, drill)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278721 Dag-Erling Smørgrav changed: What|Removed |Added Severity|Affects Some People |Affects Many People Status|New |In Progress Flags||mfc-stable14?, ||mfc-stable13?, ||needs_errata? Assignee|b...@freebsd.org|d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Konstantin Belousov --- https://reviews.freebsd.org/D45175 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277473] Virtio memory ballooning does not return unused memory to host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473 Laurent Chardon changed: What|Removed |Added Resolution|--- |Works As Intended Status|New |Closed --- Comment #3 from Laurent Chardon --- The memory ballooning works fine if I'm not using a PCI block device passthrough. I suspect that the problem might be with libvirt rather than freebsd. My workaround is to use a regular block device in my qemu config (no host PCI passthrough). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278958] zfs panic: page fault in sync_dnodes_task
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278958 Bug ID: 278958 Summary: zfs panic: page fault in sync_dnodes_task Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: nunziotocci2...@gmail.com Created attachment 250626 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250626&action=edit core.txt Fatal trap 12: page fault while in kernel mode cpuid = 29; apic id = 1d fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x820975a1 stack pointer = 0x28:0xfe022b901de0 frame pointer = 0x28:0xfe022b901de0 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 = 6 (dp_sync_taskq_17) rdi: f8000234cf60 rsi: f800022f8328 rdx: rcx: r8: r9: fe027bbf1a00 rax: 00e8 rbx: 0270 rbp: fe022b901de0 r10: r11: 98ff24fe r12: f800022f8328 r13: r14: f8000234cf40 r15: f80aa5726c00 trap number = 12 panic: page fault cpuid = 29 time = 1715524597 KDB: stack backtrace: #0 0x80b9009d at kdb_backtrace+0x5d #1 0x80b431a2 at vpanic+0x132 #2 0x80b43063 at panic+0x43 #3 0x8100c85c at trap_fatal+0x40c #4 0x8100c8af at trap_pfault+0x4f #5 0x80fe3ac8 at calltrap+0x8 #6 0x82105083 at sync_dnodes_task+0x63 #7 0x8209addf at taskq_run+0x1f #8 0x80ba5992 at taskqueue_run_locked+0x182 #9 0x80ba6c22 at taskqueue_thread_loop+0xc2 #10 0x80afdb7f at fork_exit+0x7f #11 0x80fe4b2e at fork_trampoline+0xe Uptime: 4d20h39m45s kgdb backtrace: #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=0x81136b3b "%s", ap=ap@entry=0xfe022b901c30) at /usr/src/sys/kern/kern_shutdown.c:970 #4 0x80b43063 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:894 #5 0x8100c85c in trap_fatal (frame=0xfe022b901d20, eva=0) at /usr/src/sys/amd64/amd64/trap.c:952 #6 0x8100c8af in trap_pfault (frame=0xfe022b901d20, usermode=false, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:760 #7 #8 0x820975a1 in list_remove (list=0xf8000234cf60, object=object@entry=0xf800022f8328) at /usr/src/sys/contrib/openzfs/module/os/freebsd/spl/list.c:127 #9 0x8216158e in multilist_sublist_remove ( mls=mls@entry=0xf8000234cf40, obj=obj@entry=0xf800022f8328) at /usr/src/sys/contrib/openzfs/module/zfs/multilist.c:363 #10 0x82105083 in dmu_objset_sync_dnodes (list=0xf8000234cf40, tx=0xf80aa5726c00) at /usr/src/sys/contrib/openzfs/module/zfs/dmu_objset.c:1557 #11 sync_dnodes_task (arg=0xf8083ac22e60) at /usr/src/sys/contrib/openzfs/module/zfs/dmu_objset.c:1638 #12 0x8209addf in taskq_run (arg=0xf8005728f900, pending=) at /usr/src/sys/contrib/openzfs/module/os/freebsd/spl/spl_taskq.c:320 #13 0x80ba5992 in taskqueue_run_locked ( queue=queue@entry=0xf80002356300) at /usr/src/sys/kern/subr_taskqueue.c:512 #14 0x80ba6c22 in taskqueue_thread_loop ( arg=arg@entry=0xf80003a91620) at /usr/src/sys/kern/subr_taskqueue.c:824 #15 0x80afdb7f in fork_exit ( callout=0x80ba6b60 , arg=0xf80003a91620, frame=0xfe022b901f40) at /usr/src/sys/kern/kern_fork.c:1160 #16 See attached for core.txt This seems to happen intermittently while running a backup, which is performed by a remote computer running `zfs send` through SSH. If there's anything else you'd like to see please let me know. I have a full vmcore as well if needed (11GB). I am also able to run kgdb to inspect said vmcore. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278958] zfs panic: page fault in sync_dnodes_task
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278958 Mark Linimon changed: What|Removed |Added Keywords||crash Assignee|b...@freebsd.org|f...@freebsd.org -- 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 #1 from Christos Margiolis --- Thanks for the report Robert, I will take this. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278979] CARP not working on 14.0-RELEASE on VMware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278979 Bug ID: 278979 Summary: CARP not working on 14.0-RELEASE on VMware Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: tbu...@hrsd.com After upgrading from from 13.2 to 14.0, CARP stopped working as expected. For one, no matter what I do with manually setting the state or adjusting the advskew, it doesn't work as expected. The same with the preempt kernel parameter. I have tried both unicast and multicast peer settings. Here are the configs: host1 $ ifconfig | grep 'vhid 10' inet 172.21.4.170 netmask 0x broadcast 172.21.4.170 vhid 10 carp: MASTER vhid 10 advbase 1 advskew 50 host1 $ grep 'vhid 10' /etc/rc.conf ifconfig_vmx0_alias10="inet vhid 10 advskew 50 pass redacted alias 172.21.4.170/32" host1 $ $ export PS1='host2 $ ' host2 $ export PS1='host2 $ '^C host2 $ ifconfig | grep 'vhid 10' inet 172.21.4.170 netmask 0x broadcast 172.21.4.170 vhid 10 carp: MASTER vhid 10 advbase 1 advskew 100 host2 $ grep 'vhid 10' /etc/rc.conf ifconfig_vmx0_alias10="inet vhid 10 advskew 100 pass redacted alias 172.21.4.170/32" host2 $ host1 $ cat /etc/sysctl.conf net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=1 Nothing has changed other than the OS version. I verified the hypervisor environment by making sure two 13.2 hosts with identical configs except their IPs work on the same vSwitch and the same ESXi hosts. I also tried changing the NIC type from VMXNET3 (vmx driver) to intel (em driver) with the same results. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278979] CARP not working on 14.0-RELEASE on VMware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278979 Vladimir Druzenko changed: What|Removed |Added CC||v...@freebsd.org Assignee|b...@freebsd.org|networker-b...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278988] diff -B -q: unintuitive or incorrect?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278988 Bug ID: 278988 Summary: diff -B -q: unintuitive or incorrect? Product: Base System Version: 14.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: dhe...@gmail.com I stumbled upon a very unintuitive behavior of diff: when option -q is used, -B is ignored, unless it is also accompanied by -b, as in the following examples # create test files: one containing a single newline, another containing 2 newlines $ echo "" > a $ echo -e "\n" > b $ diff a b -B # ok: no diff reported $ diff a b -B -q # weird: -B seems ignored, diff reported (GNU diff does not report it) $ diff a b -b # ok: -b only ignores spaces, not entire lines $ diff a b -b -q # ok: the diff remains, -q does not affect it $ diff a b -B -b -q # ok: this time, -B was taken into account So, we have: 1. -B works on its own; 2. when -B -q is used, -B seems ignored; 3. -b on its own does not suffice to remove the diff in these files 4. -B -b -q works (no diff), but since -b is irrelevant without -q, this seems like a bug. In GNU diff, `diff a b -B -q` behaves as what I consider "expected": the files are considered equal. If this is intended behavior, the documentation needs to mention it. Bug #252515 is similar to this one (it mentioned `-w`, while this one mentions `-B`). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2789 ||90 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2625 ||00, ||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2622 ||82, ||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2762 ||98 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262500] Framework laptop (Intel i5-1135G7): No cursor movement or buttons on console; no right button in Xorg
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262500 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2621 ||52 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276298] Framework Laptop: Recording audio not working for both built in mic and headphones
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276298 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2621 ||52 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262282] Framework laptop touchpad latency
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262282 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2621 ||52 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 192562] zfs(5): missing manpage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192562 Alexander Ziaee changed: What|Removed |Added CC||concussious.bugzilla@runbox ||.com --- Comment #5 from Alexander Ziaee --- Update: We are moving all the filesystem manuals to section four in https://github.com/freebsd/freebsd-src/pull/1077 feedback and suggestions are desired in that thread :) Filesystem pages in section five don't describe file formats, they describe the kernel interface of the filesystem driver. ZFS is actually demonstrating what we're trying to do: there's zfs(4) for that, and then z$whatever(8) for the tooling and z$whatever(7) for concept overviews. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278993] fsck not checking disk if sysctl kern.boottrace.enabled=1 is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278993 Bug ID: 278993 Summary: fsck not checking disk if sysctl kern.boottrace.enabled=1 is set Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: s...@freebsd.org Recently I found that some of my VPS-s fsck is not running (what is causing failed mount root in case of hard reset). After troubleshooting, I was able to find a root cause - it was kern.boottrace.enabled=1 in the /boot/loader.conf. This is caused by missing "$autoboot" variable in the /etc/rc.d/fsck when that script is running, so it does not run correctly. To reproduce on the clean system: 1. Add kern.boottrace.enabled=1 to the /boot/loader.conf 2. Add background_fsck="NO" to the /etc/rc.conf 3. Reset system and check logs. Fsck will not be started. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278993] fsck not checking disk if sysctl kern.boottrace.enabled=1 is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278993 --- Comment #1 from Oleksii Samorukov --- Okay, so the problem is that "$autoboot" is used by the fsck script but not exported, so when the boot trace is running, the script does not work. Without a backtrace, export is not needed as the script is sourced. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278993] fsck not checking disk if sysctl kern.boottrace.enabled=1 is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278993 --- Comment #2 from Oleksii Samorukov --- P.S. Looks like fsck is only rc.d script depending on $autoboot. Not sure if its better to export it or change fsck to no use it... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278988] diff -B -q: unintuitive or incorrect?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278988 --- Comment #1 from dhe...@gmail.com --- I wonder if it would suffice to add D_SKIPBLANKLINES to the flags in https://reviews.freebsd.org/D28064. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277959] Refactor of usr.sbin/daemon caused regression in restart parameter
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277959 Ray Bellis changed: What|Removed |Added CC||r...@bellis.me.uk --- Comment #1 from Ray Bellis --- Possibly related, but since upgrading to 13.3 we've seen repeated instances of `daemon` exiting but leaving the child process (a Perl script) running. It's feasible that this is associated with a perl libwww POST that is timing out, perhaps raising a signal that is propagating to `daemon`? I'm running truss on some of my systems to try to determine root cause, and will raise a separate ticket if it turns out to be unrelated. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279005] Cannot build 14-STABLE kernel due to ld: error: undefined symbol: ktrcapfail (ktrace)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279005 Bug ID: 279005 Summary: Cannot build 14-STABLE kernel due to ld: error: undefined symbol: ktrcapfail (ktrace) Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: jakub_l...@mailplus.pl Hello, I'm on FreeBSD 14.1-STABLE #0 stable/14-91df7d335 with custom kernel with KTRACE removed, after updating git I wanted to rebuild the same kernel and world, kernel failed with: --- kernel --- linking kernel ld: error: undefined symbol: ktrcapfail >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(namei) >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(namei_setup) >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(vfs_lookup) >>> referenced 3 more times *** [kernel] Error code 1 I suspect recent ktrace changes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279005] Cannot build 14-STABLE kernel due to ld: error: undefined symbol: ktrcapfail (ktrace)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279005 --- Comment #1 from jakub_l...@mailplus.pl --- Adding options KTRACE # ktrace(1) support allowed kernel to build/link/install. FreeBSD 14.1-STABLE #1 stable/14-0418d7a09 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279005] Cannot build 14-STABLE kernel due to ld: error: undefined symbol: ktrcapfail (ktrace)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279005 --- Comment #2 from jakub_l...@mailplus.pl --- Fixed by kib@ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279012] Linuxulator: Glibc getaddrinfo(3) Breakage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279012 Bug ID: 279012 Summary: Linuxulator: Glibc getaddrinfo(3) Breakage Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: gn...@duck.com In commit https://cgit.freebsd.org/src/commit?id=b977dd1ea5fbc2df3f1279330be4d089322eb2cf , the check if (hdr->nlmsg_len < sizeof(struct nlmsghdr) + sizeof(struct ifaddrmsg)) return (EBADMSG); in `sys/compat/linux/linux_netlink.c:97` was added and caused glibc's getaddrinfo(3) to break. This, as one might think, causes quite a few programs in the linuxulator to stop working. After looking into it, glibc is indeed not sending what we're expecting. Not only are they not including the space of the header, but they're also using the seemingly depreciated (i.e no documentation [i could find] speaking of it) `rtgenmsg` format. [1] While indeed we also have this in our source tree `sys/netlink/route/route.h:363`, it's used nowhere except in `crypto/heimdal/lib/roken/getifaddrs.c:275`; however, even in that code, they make sure to include the space of the header with the `NLMSG_LENGTH` macro. Obliviously, please take this with a large grain of salt as I'm quite inexperienced. That being said, I believe our best bet would be to contact upstream, and in the meantime, implement this functionality. On the latter half, I would be more than happy to do said implementing, all I would need are some pointers to relevant documentation. Cheers! [1] https://elixir.bootlin.com/glibc/latest/source/sysdeps/unix/sysv/linux/check_pf.c#L92 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279012] Linuxulator: Glibc getaddrinfo(3) Breakage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279012 seafork changed: What|Removed |Added Severity|Affects Some People |Affects Only Me -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279012] Linuxulator: Glibc getaddrinfo(3) Breakage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279012 Mark Linimon changed: What|Removed |Added CC||gleb...@freebsd.org Assignee|b...@freebsd.org|emulat...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #12 from Tomasz "CeDeROM" CEDRO --- I have rolled back to 13.2-RELEASE-p11. 14.0 is unreliable :-( Long live the zfs snap and zfs rollback! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265311] silly mount() arguments with MNT_UPDATE and MNT_UNION can cause kernel page-fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265311 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=21ccdb4119afdfdfeaa80e9c8514171c65b35862 commit 21ccdb4119afdfdfeaa80e9c8514171c65b35862 Author: Konstantin Belousov AuthorDate: 2024-05-15 09:54:49 + Commit: Konstantin Belousov CommitDate: 2024-05-16 01:00:26 + vfs_domount_update(): postpone setting MNT_UNION until VFS_MOUNT() is done The file system that handles updating the mount point might do lookups during the update, in which case it could find the flag MNT_UNION set on the mp while mount point is still not updated. In particular, the rootvp->v_mount->mnt_vnodecovered is not yet set. Delay setting MNT_UNION until the mount is performed. PR: 265311 Reported by:Robert Morris Reviewed by:mckusick, olce Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D45208 sys/kern/vfs_mount.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277963] Increase MAXLOGNAME from 33 to 65
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277963 --- Comment #1 from Baptiste Daroussin --- sorry for late reply. The main issue to switch MAXLOGNAME to 65 would be utmpx because it hard codes 32 which means the name will truncate the name. If nothing has changed since I grew it to 33, the upgrade to 65 would be safe as all consumers of MAXLOGNAME (in base at least) are properly checking boundaries when manipulating strings, so worst case scenario is truncation, but no overflow. So the right approach is imho to first upgrade utmpx (if this is possible at all) and only after that upgrade MAXLOGNAME. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279021] Random phantom files by g_new_bio() failure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279021 Bug ID: 279021 Summary: Random phantom files by g_new_bio() failure Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: seigo.tanim...@gmail.com A bug in g_new_bio() is suspected to cause the random phantom files often silently; expoited during the poudriere-bulk(8) test on bug #275594, comment #147. * Test Environment: Hypervisor - CPU: Intel Core i7-13700KF 3.4GHz (24 threads) - RAM: 128 GB - OS: Windows 10 - Storage: NVMe and SATA HDDs - Hypervisor: VMWare Workstation 17.5 * Test Environment: VM & OS - vCPUs: 16 - RAM: 16 GB - Swap: 128 GB on NVMe - OS: FreeBSD 14.1-BETA2 - All of the releng/14.1 fixes in bug #275594, comment #147 applied. - Storage & Filesystems: ZFS mainly - Main pool: 1.5G on SATA HDD - ZIL: 16 GB on NVMe - L2ARC: 64 GB on NVMe * Application - poudriere - Number of ports to build: 2325 (including dependencies) - Major configurations for port building - poudriere.conf - #NO_ZFS=yes (ZFS enabled) - USE_PORTLINT=no - USE_TMPFS="wrkdir data localbase" - TMPFS_LIMIT=32 - DISTFILES_CACHE=(configured in ZFS) - CCACHE_DIR=(configured in ZFS) - The cache is cleared in advance. - CCACHE_STATIC_PREFIX=/usr/local - PARALLEL_JOBS=16 (actually givin via "poudriere bulk -J") - make.conf - MAKE_JOBS_NUMBER=4 * Steps 1. Remove the package output directory, so that all packages are built. 2. Clear the ccache contents by "ccache -C". 3. Run 'poudriere bulk' to start the parallel build. 4. Observe the system and build progress by top(1), poudriere web UI, cmdwatch(1) + sysctl(8), etc. * Expected results - All of the ports are built successfully. * Observed behaviors during building - In about 2 hours, the RAM went out and the kernel started swapping out the pages. - The bulk port build failed at random. + A header file or a library provided via the dependency was often missing. - The kernel occasionally logged "swap_pager: cannot allocate bio". - vm.uma.g_bio.stats.fails increased up to ~5000. * Analysis g_new_bio(), the kernel function that allocates a new bio in the non-blocking manner, returns NULL if the g_bio uma(9) zone has no free items. While such the case is regarded as a rare error with an ordinary HDD, an nvme(4) storage is likely to trigger that issue because of its high capacity for the parallel I/O operations. Although not confirmed precisely, the effect of this issue seems to include the phantom files, ie the files created newly do not become visible immediately Under poudriere-bulk(8), it is suspected that the files installed during build-depends and lib-depends are not detected as expected. The problem happens at random; it is up to the state of the g_bio zone. No logs are emitted by g_new_bio() in case of an allocation failure. An exception is the swap pager, which logs "swap_pager: cannot allocate bio". The increase of vm.uma.g_bio.stats.fails is the sole record of the errors. * Proposed Fix and Test Results Reserve some bios for the non-blocking allocation. Uma(9) supports the item reservation, which can be used to implement the fix. NB the item reservation of uma(9) can be configured at the boot time only, in practice. The proposed fix has been committed to the submitter's GitHub repository and made public. New Loader Tunable: - kern.geom.reserved_new_bios The number of the bios reserved for the non-blocking allocation. (Default: 65536) Zero means no bios are reserved. Due to the limitation on the uma(9) zone, this configuration cannot be altered upon a running host. All of the sources are under https://github.com/altimeter-130ft/freebsd-freebsd-src. | | Git Commit Hash Base Branch | Fix Branch| Base| Fix +===+=+ main| topic-bio-reservation | c1ebd76c3f | c784b64b8a +---+-+ stable/14 | stable/14-topic-bio-reservation | 3c414a8c2f | aeaac96a7a +---+-+ releng/14.1 | releng/14.1-topic-bio-reservation | e3e57ae30c | 8f0281d20d +---+-+ releng/14.0 | releng/14.0-topic-bio-reservation | d338712beb | 6f8fed52ee +---+-+ stable/13 | stable/13-topic-bio-reservation | 85e63d952d | 64b9962cec +---+-+ releng/13.3 | releng/13.
[Bug 279021] Random phantom files by g_new_bio() failure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279021 --- Comment #1 from Seigo Tanimura --- Diff review: https://reviews.freebsd.org/D45215 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264030] [tracking] 13.1-RELEASE issue reports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264030 Bug 264030 depends on bug 264528, which changed state. Bug 264528 Summary: net/freerdp: NLA fails to connect through gateway after 13.1 upgrade: rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264528 What|Removed |Added Status|Open|Closed Resolution|--- |Feedback Timeout -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279005] Cannot build 14-STABLE kernel due to ld: error: undefined symbol: ktrcapfail (ktrace)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279005 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Resolution|--- |FIXED Status|New |Closed --- Comment #3 from Ed Maste --- commit 00cf2f3092e462b8840b8cb9c3d86c471da065e5 Author: Konstantin Belousov Date: Wed Apr 24 22:06:14 2024 +0300 vfs_lookup.c: only call ktrcapfail() if KTRACE is enabled (cherry picked from commit 6b0cf2a2379b86b67269ed4549057cd6d69490e5) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278988] diff -B -q: unintuitive or incorrect?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278988 Ed Maste changed: What|Removed |Added Status|New |In Progress CC||ema...@freebsd.org Assignee|b...@freebsd.org|ema...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279038] zfs panic: VERIFY3(dev->l2ad_hand + distance < dev->l2ad_end) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279038 Bug ID: 279038 Summary: zfs panic: VERIFY3(dev->l2ad_hand + distance < dev->l2ad_end) failed Product: Base System Version: 13.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: j...@mit.edu While receiving incremental rsync data over the network my server crashed with message panic: VERIFY3(dev->l2ad_hand + distance < dev->l2ad_end) failed (161060749312 < 161060749312) Looking at arc.c, end of function l2arc_evict, I wonder if < should be <=. The relevant variables are l2ad_hand = 161051246592 l2ad_start = 4198400 l2ad_end = 161060749312 l2ad_first = 0 l2ad_writing = 0 distance = 9502720 # zfs version zfs-2.1.15-FreeBSD_gfb6d53206 zfs-kmod-2.1.15-FreeBSD_gd99134be8 The server has a raidz2 pool on 3.5 inch hard drives with a cache on SSD. RAM is 24 GB and there is no other pressure on memory or CPU. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279038] zfs panic: VERIFY3(dev->l2ad_hand + distance < dev->l2ad_end) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279038 John F. Carr changed: What|Removed |Added See Also||https://github.com/openzfs/ ||zfs/issues/16202 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87a156527563d0728bff355093e26943da3d7fad commit 87a156527563d0728bff355093e26943da3d7fad Author: Konstantin Belousov AuthorDate: 2024-05-13 17:17:47 + Commit: Konstantin Belousov CommitDate: 2024-05-16 17:53:31 + SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information PR: 278949 Reviewed by:markj Tested by: Ricardo Branco Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D45175 sys/kern/sysv_msg.c | 34 ++ sys/kern/sysv_sem.c | 33 + sys/kern/sysv_shm.c | 36 sys/sys/msg.h | 3 +++ sys/sys/sem.h | 3 +++ sys/sys/shm.h | 2 ++ 6 files changed, 111 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277967] The loader should fail gracefully when /boot/loader.conf attempts to load a module that is too large
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277967 Yuri Victorovich changed: What|Removed |Added Blocks||277364 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277364 [Bug 277364] x11/nvidia-driver: kernel panic: "NVRM: rm_init_rm() failed" after update to 550.54.14 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278828] panic when writing to geli device after running attach twice
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278828 Mariusz Zaborski changed: What|Removed |Added CC||osho...@freebsd.org --- Comment #1 from Mariusz Zaborski --- Hello Andre, Thank you for the report. I have created a patch for it: https://reviews.freebsd.org/D45225 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278828] panic when writing to geli device after running attach twice
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278828 Mariusz Zaborski changed: What|Removed |Added Version|14.0-STABLE |CURRENT Assignee|b...@freebsd.org|osho...@freebsd.org Severity|Affects Some People |Affects Many People -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279038] zfs panic: VERIFY3(dev->l2ad_hand + distance < dev->l2ad_end) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279038 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|f...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279054] Compile failure when #include in C++ code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279054
Bug ID: 279054
Summary: Compile failure when #include
in C++ code
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: cnba...@gmail.com
Both FreeBSD 14 and 15 generated the same errors.
C++ Codes:
```
#include
int main()
{
snl_state st{};
return 0;
}
```
Errors:
In file included from main.cpp:1:
/usr/include/netlink/netlink_snl.h:83:24: error: cannot initialize a variable
of type 'struct linear_buffer *' with an rvalue of type 'void *'
83 | struct linear_buffer *lb = calloc(1, size);
| ^~~~
/usr/include/netlink/netlink_snl.h:107:9: error: cannot initialize return
object of type 'char *' with an lvalue of type 'void *'
107 | return (data);
|^~
/usr/include/netlink/netlink_snl.h:278:12: error: assigning to 'char *' from
incompatible type 'void *'
278 | ss->buf = malloc(ss->bufsize);
| ^~~
/usr/include/netlink/netlink_snl.h:498:2: error: no matching function for call
to 'snl_parse_fields'
498 | snl_parse_fields(ss, hdr, parser->in_hdr_size, parser->fp,
parser->fp_size, target);
| ^~~~
/usr/include/netlink/netlink_snl.h:479:1: note: candidate function not viable:
cannot convert argument of incomplete type 'void *' to 'struct nlmsghdr *' for
2nd argument
479 | snl_parse_fields(struct snl_state *ss, struct nlmsghdr *hdr, int hdrlen
__unused,
| ^
/usr/include/netlink/netlink_snl.h:619:8: error: cannot initialize a variable
of type 'char *' with an rvalue of type 'void *'
619 | char *buf = snl_allocz(ss, maxlen + 1);
| ^ ~~
/usr/include/netlink/netlink_snl.h:636:3: error: no matching function for call
to 'strlcpy'
636 | strlcpy(target, tmp, (size_t)arg);
| ^~~
/usr/include/string.h:98:9: note: candidate function not viable: cannot convert
argument of incomplete type 'void *' to 'char *__restrict' for 1st argument
98 | size_t strlcpy(char * __restrict, const char * __restrict, size_t);
| ^ ~~
In file included from main.cpp:1:
/usr/include/netlink/netlink_snl.h:649:9: error: cannot initialize a variable
of type 'char *' with an rvalue of type 'void *'
649 | char *buf = snl_allocz(ss, maxlen);
| ^ ~~
/usr/include/netlink/netlink_snl.h:678:21: error: cannot initialize a variable
of type 'struct snl_parray *' with an lvalue of type 'void *'
678 | struct snl_parray *array = target;
|^ ~~
/usr/include/netlink/netlink_snl.h:685:17: error: assigning to 'void **' from
incompatible type 'void *'
685 | array->items = snl_allocz(ss, size * sizeof(void *));
|^
/usr/include/netlink/netlink_snl.h:701:2: error: assigning to 'struct nlattr *'
from incompatible type 'void *'
701 | NLA_FOREACH(nla, NLA_DATA(container_nla),
NLA_DATA_LEN(container_nla)) {
|
^~
/usr/include/netlink/netlink_snl.h:66:22: note: expanded from macro
'NLA_FOREACH'
66 | for (_attr = (_start); \
| ^~~~
/usr/include/netlink/netlink_snl.h:715:11: error: cannot initialize a variable
of type 'void **' with an rvalue of type 'void *'
715 | void **new_array = snl_allocz(ss, new_size
*sizeof(void *));
|^
/usr/include/netlink/netlink_snl.h:828:26: error: cannot initialize a variable
of type 'struct snl_attr_bitset *' with an lvalue of type 'void *'
828 | struct snl_attr_bitset *target = _target;
| ^~~~
/usr/include/netlink/netlink_snl.h:864:26: error: cannot initialize a variable
of type 'struct snl_attr_bitset *' with an lvalue of type 'void *'
864 | struct snl_attr_bitset *target = _target;
| ^~~~
/usr/include/netlink/netlink_snl.h:984:11: error: no matching function for call
to 'snl_parse_attrs_raw'
984 | return (snl_parse_attrs_raw(ss, data, len, ps->np,
ps->np_size, attrs));
| ^~~
/usr/include/netlink/netlink_snl.h:448:1: note: candidate function not viable:
cannot convert argument of incomplete type 'void *' to 'struct
[Bug 279069] linux: Add support for POSIX message queues PR:1248
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279069 Bug ID: 279069 Summary: linux: Add support for POSIX message queues PR:1248 Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rbra...@suse.com The current implementation of mqueuefs in the Linuxulator is a skeleton that is enabled only for i386 when P1003_1B_MQUEUE is defined. This is wrong. Either this must be disabled or fixed. This is an attempt of a fix for amd64 which works so far with some limitations. I need some comments on whether this is an exercise in futility (who really uses mqueue?) or worth trying: https://github.com/freebsd/freebsd-src/pull/1248 PR:1248 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279069] linux: Add support for POSIX message queues: git pull request 1248
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279069 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org Summary|linux: Add support for |linux: Add support for |POSIX message queues|POSIX message queues: git |PR:1248 |pull request 1248 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279071] loader build error with EFI_DEBUG
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279071
Bug ID: 279071
Summary: loader build error with EFI_DEBUG
Product: Base System
Version: 15.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: j...@mit.edu
Created attachment 250737
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250737&action=edit
Use -Wno-format for zfs_module.c
When compiling with -DEFI_DEBUG, stand/efi/boot1/zfs_module.c needs the same
-Wno-format flag as ufs_module.c. Otherwise,
/usr/src/stand/efi/boot1/zfs_module.c:155:22: error: format specifies type
'wchar_t *' (aka 'int *') but the argument has type 'CHAR16 *' (aka 'unsigned
short *') [-Werror,-Wformat]
154 | DPRINTF("load: '%s' spa: '%s', devpath: %S\n",
filepath,
| ~~
155 | spa->spa_name, text);
|^~~~
/usr/home/15/src/stand/efi/boot1/boot_module.h:37:45: note: expanded from macro
'DPRINTF'
37 | #define DPRINTF(fmt, args...) printf(fmt, ##args)
| ~~~^~~~
1 error generated.
*** [zfs_module.o] Error code 1
Fix attached.
The comment in stand/efi/boot1/Makefile says this is platform-dependent. I was
cross-compiling aarch64 to riscv64.
--
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 #2 from Christos Margiolis --- Submitted a fix: https://reviews.freebsd.org/D45236 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279097] /usr/share/zfs/compatibility.d version in files does not correspond to the version in file names
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279097 Bug ID: 279097 Summary: /usr/share/zfs/compatibility.d version in files does not correspond to the version in file names Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: 000.f...@quip.cz There are files with ZFS features for backward compatibility. Each file has a first line with a comment with OS version but many files have "Features supported by FreeBSD 11.3" even if the OS version in file name is different: # head -n1 /usr/share/zfs/compatibility.d/free* ==> /usr/share/zfs/compatibility.d/freebsd-11.0 <== # Features supported by FreeBSD 11.0 ==> /usr/share/zfs/compatibility.d/freebsd-11.1 <== # Features supported by FreeBSD 11.0 ==> /usr/share/zfs/compatibility.d/freebsd-11.2 <== # Features supported by FreeBSD 11.2 ==> /usr/share/zfs/compatibility.d/freebsd-11.3 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freebsd-11.4 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freebsd-12.0 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freebsd-12.1 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freebsd-12.2 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freenas-11.0 <== # Features supported by FreeBSD 11.0 ==> /usr/share/zfs/compatibility.d/freenas-11.1 <== # Features supported by FreeBSD 11.0 ==> /usr/share/zfs/compatibility.d/freenas-11.2 <== # Features supported by FreeBSD 11.2 ==> /usr/share/zfs/compatibility.d/freenas-11.3 <== # Features supported by FreeBSD 11.3 ==> /usr/share/zfs/compatibility.d/freenas-9.10.2 <== # Features supported by FreeNAS 9.10.2 Shouldn't the comment matches the file name? -- 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 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org --- Comment #1 from Christos Margiolis --- Hello Robert. I hit this bug a few minutes ago and I just stumbled upon your bug report. The fix is indeed what you proposed: https://reviews.freebsd.org/D45237 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 186369] [suspend/resume] snd_hda(4) does not work after suspend-to-ram
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186369 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org --- Comment #3 from Christos Margiolis --- Is this bug reproducible on the latest FreeBSD release? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 158979] [snd_uadio] snd_uaudio fails to initialize built-in microphone in Logitech Webcam C160
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158979 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org Status|Open|Closed Resolution|--- |FIXED --- Comment #11 from Christos Margiolis --- Closing as the user seems to have found a workaround. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 156198] [snd_hda] [hang] loading snd_hda kernel module hangs system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156198 Christos Margiolis changed: What|Removed |Added Resolution|--- |Overcome By Events CC||chris...@freebsd.org Status|Open|Closed --- Comment #3 from Christos Margiolis --- Closing as this bug is no longer present in current FreeBSD versions. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 150284] [snd_hda] No gain with Audio
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150284 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org Resolution|--- |Overcome By Events Status|Open|Closed --- Comment #3 from Christos Margiolis --- Closing as this is no longer an issue with current FreeBSD versions. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 146031] [snd_hda] race condition when kldunload snd_hda sound called
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146031 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org --- Comment #8 from Christos Margiolis --- Is this bug still reproducible with recent FreeBSD versions? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 137589] [snd_uaudio] snd_uaudio.ko (USB audio driver) doesn't work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137589 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org Status|Open|Closed Resolution|--- |Not Enough Information -- You are receiving this mail because: You are the assignee for the bug.
[Bug 134767] [sound] [snd_hda] [regression] Sigmatel STAC9205X no sound under RELENG_7_2_0_RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=134767 Christos Margiolis changed: What|Removed |Added CC||chris...@freebsd.org --- Comment #10 from Christos Margiolis --- Is this bug still reproducible with recent FreeBSD versions? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279122] /boot/kernel/kernel: "not stripped"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279122 Bug ID: 279122 Summary: /boot/kernel/kernel: "not stripped" Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: egyp...@freebsd.org I'm running stripped 'kernel' for quite a few years without ANY sort of issue. I use them on physical and virtual machines - also, on "normal" deployments of FreeBSD or serving mfs images (compressed, or not). So, is there a very good reason why we (officially) do not strip the FreeBSD kernel? - at least on STABLE or RELEASE versions. Once I am pretty much far from being an expert on that level, I would love to get more input about it from anyone that would be keen to explain that to me (and others here). - shall this kind of topic be added to our Handbook (or developers documentation) as well? >From a FreeBSD live system, here we have some fair outputs of what is meant by this PR: root@:~ # mkdir /tmp/base root@:~ # mount /dev/gpt/base0 /tmp/base/ root@:~ # tar xf /usr/freebsd-dist/base.txz -C /tmp/ usr/bin/strip root@:~ # cp -a /boot/kernel/kernel /tmp/base/kernel root@:~ # /tmp/usr/bin/strip /tmp/base/kernel *** 14.0-RELEASE root@:~ # uname -abiUK FreeBSD 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 GENERIC 1400097 1400097 de04db27d4d136c96cba9e384c8bc9e7b337a2c5 root@:~ # file /boot/kernel/kernel /tmp/base/kernel /boot/kernel/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, BuildID[sha1]=de04db27d4d136c96cba9e384c8bc9e7b337a2c5, not stripped /tmp/base/kernel:ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, BuildID[sha1]=de04db27d4d136c96cba9e384c8bc9e7b337a2c5, stripped root@:~ # ls -lais /boot/kernel/kernel /tmp/base/kernel 10156980 26371 -r-xr-xr-x 1 root wheel 27003712 Nov 10 2023 /boot/kernel/kernel 6 23144 -r-xr-xr-x 1 root wheel 23643432 May 18 08:07 /tmp/base/kernel *** 14.1-STABLE root@:~ # uname -abiUK FreeBSD 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n267634-7b65987885da GENERIC amd64 GENERIC 1401500 1401500 03870066df47c918b5678f89b12252aae1c3e94f root@:~ # file /boot/kernel/kernel /tmp/base/kernel /boot/kernel/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, BuildID[sha1]=03870066df47c918b5678f89b12252aae1c3e94f, not stripped /tmp/base/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /red/herring, BuildID[sha1]=03870066df47c918b5678f89b12252aae1c3e94f, stripped root@:~ # ls -laish /boot/kernel/kernel /tmp/base/kernel 10163936 28434 -r--r--r-- 1 root wheel 28M May 9 06:11 /boot/kernel/kernel 7 25200 -r--r--r-- 1 root wheel 25M May 18 07:49 /tmp/base/kernel -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279134] The 'mb' macro in /usr/include/machine/atomic.h conflicts with variables of same name
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279134 Bug ID: 279134 Summary: The 'mb' macro in /usr/include/machine/atomic.h conflicts with variables of same name Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: y...@freebsd.org Log: https://pkg-status.freebsd.org/ampere3/data/140releng-armv7-default/9476d3e04f44/logs/cardinal-24.04.log Shouldn't the variables mb, wmb, rmb be renamed to have the atomic_ prefix? This would reduce the chance of conflicts like this. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136
Bug ID: 279136
Summary: clang-16 frontend command fails with exit code 138
w/out any assertion message on the port
security/botan3
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: y...@freebsd.org
0. Program arguments: c++ -fstack-protector -m64 -pthread -std=c++20
-D_REENTRANT -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall
-Wextra -Wpedantic -Wshadow -Wstrict-aliasing -Wstrict-overflow=5 -Wcast-align
-Wmissing-declarations -Wpointer-arith -Wcast-qual -Wshorten-64-to-32 -Wcomma
-Wdocumentation -DBOTAN_IS_BEING_BUILT -I build/include/public -I
build/include/internal -isystem build/include/external -isystem
/usr/local/include -c src/tests/test_rng_behavior.cpp -o
build/obj/test/test_rng_behavior.o
1. src/tests/test_rng_behavior.cpp:782:70: current parser token ';'
2. src/tests/test_rng_behavior.cpp:44:1: parsing namespace 'Botan_Tests'
3. src/tests/test_rng_behavior.cpp:46:1: parsing namespace
'Botan_Tests::(anonymous)'
4. src/tests/test_rng_behavior.cpp:757:1: parsing struct/union/class body
'Botan_Tests::(anonymous namespace)::System_RNG_Tests'
5. src/tests/test_rng_behavior.cpp:759:48: parsing function body
'Botan_Tests::(anonymous namespace)::System_RNG_Tests::run'
6. src/tests/test_rng_behavior.cpp:759:48: in compound statement ('{}')
7. src/tests/test_rng_behavior.cpp:778:99: in compound statement ('{}')
#0 0x04f90e31 (/usr/bin/c+++0x4f90e31)
#1 0x04f8f245 (/usr/bin/c+++0x4f8f245)
#2 0x04f375c5 (/usr/bin/c+++0x4f375c5)
#3 0x00082c2aa53f (/lib/libthr.so.3+0x1a53f)
#4 0x00082c2a9afb (/lib/libthr.so.3+0x19afb)
#5 0x000827b782d3 ([vdso]+0x2d3)
#6 0x026a7318 (/usr/bin/c+++0x26a7318)
#7 0x026a71ea (/usr/bin/c+++0x26a71ea)
..
#87 0x02475f91 (/usr/bin/c+++0x2475f91)
#88 0x00082e355afa __libc_start1 (/lib/libc.so.7+0x84afa)
c++: error: clang frontend command failed with exit code 138 (use -v to see
invocation)
FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git
llvmorg-16.0.6-0-g7cbf1a259152)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/test_rng_behavior-4c2d34.cpp
c++: note: diagnostic msg: /tmp/test_rng_behavior-4c2d34.sh
c++: note: diagnostic msg:
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Yuri Victorovich changed: What|Removed |Added URL||http://beefy12.nyi.freebsd. ||org/data/140amd64-default/0 ||7badf98bbd0/logs/errors/bot ||an3-3.3.0.log -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Yuri Victorovich changed: What|Removed |Added CC||d...@freebsd.org Assignee|b...@freebsd.org|toolch...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 Bug ID: 279138 Summary: NFS and NFSUPG and BUFWAIT Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: dgilb...@eicat.ca Setup: host: 14.0p2, 1900 threadripper (16 threads), 128G ram, 120T zfs vm: 15.0-CURRENT #5 main-n270190-75529910f77a: Thu May 16 19:08:46 EDT 2024 64G ram, 15 processors, 200G ZFS (zvol on host). Host runs poudreiere for <=14. VM runs 15 poudriere (not at same time). VM mounts /usr/local/poudriere via NFS. Multiple times, with at least one make-world on a new pull inbetween, the whole things stopps (it didn't used to, 2 to 3 months ago code). Seems to happen when this triple reversal happens: May 17 12:16:24 curpoud kernel: lock order reversal: May 17 12:16:24 curpoud kernel: 1st 0xf802dcae0230 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:3298 May 17 12:16:24 curpoud kernel: 2nd 0xfe006a1633c8 bufwait (bufwait, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:2442 May 17 12:16:24 curpoud kernel: lock order bufwait -> nfs established at: May 17 12:16:24 curpoud kernel: #0 0x80bb5ca5 at witness_checkorder+0x315 May 17 12:16:24 curpoud kernel: #1 0x80b0e962 at lockmgr_lock_flags+0x172 May 17 12:16:24 curpoud kernel: #2 0x80a1990c at nfs_lock+0x2c May 17 12:16:24 curpoud kernel: #3 0x80c25f50 at vop_sigdefer+0x30 May 17 12:16:24 curpoud kernel: #4 0x80c52783 at _vn_lock+0x53 May 17 12:16:24 curpoud kernel: #5 0x80c3a22d at vget_finish+0x4d May 17 12:16:24 curpoud kernel: #6 0x80c28b91 at vfs_hash_get+0xd1 May 17 12:16:24 curpoud kernel: #7 0x80a2293b at nfscl_nget+0x13b May 17 12:16:24 curpoud kernel: #8 0x80a0a2d8 at nfsrpc_readdirplus+0xa98 May 17 12:16:24 curpoud kernel: #9 0x80a150a0 at ncl_readdirplusrpc+0xf0 May 17 12:16:24 curpoud kernel: #10 0x80a26cbc at ncl_doio+0x47c May 17 12:16:24 curpoud kernel: #11 0x80a25e5f at ncl_bioread+0x5ef May 17 12:16:24 curpoud kernel: #12 0x80a19858 at nfs_readdir+0x1d8 May 17 12:16:24 curpoud kernel: #13 0x80c25f50 at vop_sigdefer+0x30 May 17 12:16:24 curpoud kernel: #14 0x811274a2 at VOP_READDIR_APV+0x32 May 17 12:16:24 curpoud kernel: #15 0x80c4f05e at kern_getdirentries+0x1ce May 17 12:16:24 curpoud kernel: #16 0x80c4f459 at sys_getdirentries+0x29 May 17 12:16:24 curpoud kernel: #17 0x8105f638 at amd64_syscall+0x158 May 17 12:16:24 curpoud kernel: lock order nfs -> bufwait attempted at: May 17 12:16:24 curpoud kernel: #0 0x80bb650b at witness_checkorder+0xb7b May 17 12:16:24 curpoud kernel: #1 0x80b0f06e at lockmgr_xlock_hard+0x6e May 17 12:16:24 curpoud kernel: #2 0x80b0f910 at __lockmgr_args+0x1e0 May 17 12:16:24 curpoud kernel: #3 0x80c388e0 at flushbuflist+0x110 May 17 12:16:24 curpoud kernel: #4 0x80c3859a at bufobj_invalbuf+0x8a May 17 12:16:24 curpoud kernel: #5 0x80a26f20 at ncl_vinvalbuf+0xf0 May 17 12:16:24 curpoud kernel: #6 0x80a17125 at nfs_open+0x1d5 May 17 12:16:24 curpoud kernel: #7 0x80c25f50 at vop_sigdefer+0x30 May 17 12:16:24 curpoud kernel: #8 0x811253cf at VOP_OPEN_APV+0x2f May 17 12:16:24 curpoud kernel: #9 0x80c52579 at vn_open_vnode+0x1b9 May 17 12:16:24 curpoud kernel: #10 0x80c51f78 at vn_open_cred+0x598 May 17 12:16:24 curpoud kernel: #11 0x80c48267 at openatfp+0x287 May 17 12:16:24 curpoud kernel: #12 0x80c47fbd at sys_openat+0x3d May 17 12:16:24 curpoud kernel: #13 0x8105f638 at amd64_syscall+0x158 May 17 12:16:24 curpoud kernel: #14 0x81030cdb at fast_syscall_common+0xf8 May 17 12:16:24 curpoud kernel: lock order reversal: May 17 12:16:24 curpoud kernel: 1st 0xfe01c4ec9e60 nfsupg (nfsupg, lockmgr) @ /usr/src/sys/fs/nfsclient/nfs_clsubs.c:151 May 17 12:16:24 curpoud kernel: 2nd 0xfe006a174e88 bufwait (bufwait, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:2442 May 17 12:16:24 curpoud kernel: lock order nfsupg -> bufwait attempted at: May 17 12:16:24 curpoud kernel: #0 0x80bb650b at witness_checkorder+0xb7b May 17 12:16:24 curpoud kernel: #1 0x80b0f06e at lockmgr_xlock_hard+0x6e May 17 12:16:24 curpoud kernel: #2 0x80b0f910 at __lockmgr_args+0x1e0 May 17 12:16:24 curpoud kernel: #3 0x80c388e0 at flushbuflist+0x110 May 17 12:16:24 curpoud kernel: #4 0x80c3859a at bufobj_invalbuf+0x8a May 17 12:16:24 curpoud kernel: #5 0x80a26f20 at ncl_vinvalbuf+0xf0 May 17 12:16:24 curpoud kernel: #6 0x80a25bc8 at ncl_bioread+0x358 May 17 12:16:24 curpoud kernel: #7 0x80a19858 at nfs_readdir+0x1d8 May 17 12:16:24 curpoud kernel: #8 0x80c25f50 at vop_sigdefer+0x30 May 17 12:16
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 --- Comment #1 from dgilb...@eicat.ca --- To add configuration details, the NFS mounts are as follows: vr:/usr/local/poudriere 5.2T 188K5.2T 0%/d/vr/poudriere vr:/usr/local/poudriere/data 5.2T 205K5.2T 0%/d/vr/poudriere/data vr:/usr/local/poudriere/data/.m 5.2T 427K5.2T 0%/d/vr/poudriere/data/.m vr:/usr/local/poudriere/data/cache 5.2T 14G5.2T 0%/d/vr/poudriere/data/cache vr:/usr/local/poudriere/data/images 5.2T 188K5.2T 0%/d/vr/poudriere/data/images vr:/usr/local/poudriere/data/logs5.2T 49G5.2T 1%/d/vr/poudriere/data/logs vr:/usr/local/poudriere/data/packages7.7T 2.5T5.2T33%/d/vr/poudriere/data/packages vr:/usr/local/poudriere/data/wrkdirs 5.2T 188K5.2T 0%/d/vr/poudriere/data/wrkdirs vr:/var/cache/ccache 5.7T 568G5.2T10%/d/vr/ccache and are put to work thusly: [2:3:303]root@curpoud:~> ll /usr/local/poudriere/data/ total 3 lrwxr-xr-x 1 root wheel 23 Mar 16 2022 .m -> /d/vr/poudriere/data/.m lrwxr-xr-x 1 root wheel 26 Mar 16 2022 cache -> /d/vr/poudriere/data/cache drwxr-xr-x 2 root wheel 2 Mar 16 2022 images lrwxr-xr-x 1 root wheel 25 Mar 16 2022 logs -> /d/vr/poudriere/data/logs lrwxr-xr-x 1 root wheel 29 Mar 16 2022 packages -> /d/vr/poudriere/data/packages drwxr-xr-x 2 root wheel 2 Mar 16 2022 wrkdirs -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 --- Comment #2 from dgilb...@eicat.ca --- I suppose I _might_ be burying the lead: after the LORs, I get a bunch of "fileid changed" nfs errors on the VM and then the NFS mounts are basically invalidated. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 --- Comment #3 from Konstantin Belousov --- The first LoR looks as a false positive, mostly. It is readdirplus doing scan of the directory, and then querying the attributes of each found entry' node, except dotdot. So the lock order is parent vnode -> (it's buffers) -> child vnode, as expected by VFS. I said "mostly" because server can do the directory move like from A->B to B->A while client is not aware, and I am not completely sure that our client- side invalidations would avoid tricking in this situation. But this is very unlikely. For the second LoR, nfsupg->bufwait, the reported order is right. I wonder where the reversed order was recorded. That said, to diagnose the problem, you need to gather the information listed in the developer's handbook, debugging kernels, debugging deadlocks: https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 --- Comment #4 from Rick Macklem --- (In reply to dgilbert from comment #2) "fileid changed" normally occurs when multiple NFS clients have the same /etc/hostid (due to cloning of system images or ???). This will confuse the server, since it will think the clients are the same client. If you have multiple clients doing NFSv4 mounts, make sure each one of them has a unique /etc/hostid. (If your NFS mounts are NFSv3, I do not have an explanation for "fileid changed". Long ago it was caused by a weird broken NFS cache device, but I doubt any of those still exists.) If your clients all have unique /etc/hostid's (and had them at mount time), and you still see problems, you could try reverting this commit: fbe965591f8a I don't see how it could cause a hang, but it is the only recent change related to directory reading. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278826] [hpet] cdev->si_refcount leakage when enable hpet as timecounter hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278826 --- Comment #9 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4018bcdea8e1934eedba4b800e6feb2099b1091d commit 4018bcdea8e1934eedba4b800e6feb2099b1091d Author: Konstantin Belousov AuthorDate: 2024-05-07 13:23:28 + Commit: Konstantin Belousov CommitDate: 2024-05-19 00:57:54 + cdev_pager_allocate(): ensure that the cdev_pager_ops ctr is called only once PR: 278826 (cherry picked from commit e93404065177d6c909cd64bf7d74fe0d8df35edf) sys/vm/device_pager.c | 70 +-- 1 file changed, 51 insertions(+), 19 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278826] [hpet] cdev->si_refcount leakage when enable hpet as timecounter hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278826 --- Comment #10 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2eeb0e9fc1306f40ec684af1ea56a8871a9a3684 commit 2eeb0e9fc1306f40ec684af1ea56a8871a9a3684 Author: Konstantin Belousov AuthorDate: 2024-05-07 13:23:28 + Commit: Konstantin Belousov CommitDate: 2024-05-19 00:59:13 + cdev_pager_allocate(): ensure that the cdev_pager_ops ctr is called only once PR: 278826 (cherry picked from commit e93404065177d6c909cd64bf7d74fe0d8df35edf) sys/vm/device_pager.c | 70 +-- 1 file changed, 51 insertions(+), 19 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278826] [hpet] cdev->si_refcount leakage when enable hpet as timecounter hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278826 Konstantin Belousov changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279138] NFS and NFSUPG and BUFWAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279138 Mark Linimon changed: What|Removed |Added Keywords||regression Assignee|b...@freebsd.org|f...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279152] panic: VERIFY3(NULL == dmu_buf_set_user(l->l_dbuf, &l->l_dbu)) failed (0x == 0xfffff808149f9800x)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279152 Bug ID: 279152 Summary: panic: VERIFY3(NULL == dmu_buf_set_user(l->l_dbuf, &l->l_dbu)) failed (0x == 0xf808149f9800x) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: p...@freebsd.org cpuid = 1 time = 1716101420 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0170b555f0 vpanic() at vpanic+0x13f/frame 0xfe0170b55720 spl_panic() at spl_panic+0x3a/frame 0xfe0170b55780 zap_expand_leaf() at zap_expand_leaf+0x8b7/frame 0xfe0170b55810 fzap_add_cd() at fzap_add_cd+0x1a3/frame 0xfe0170b558b0 fzap_add() at fzap_add+0x88/frame 0xfe0170b558d0 zap_add_impl() at zap_add_impl+0x291/frame 0xfe0170b55950 zap_add() at zap_add+0x70/frame 0xfe0170b559a0 zfs_link_create() at zfs_link_create+0x153/frame 0xfe0170b55af0 zfs_link() at zfs_link+0x37f/frame 0xfe0170b55b60 VOP_LINK_APV() at VOP_LINK_APV+0x86/frame 0xfe0170b55b90 kern_linkat_vp() at kern_linkat_vp+0x33c/frame 0xfe0170b55cc0 kern_linkat() at kern_linkat+0x17b/frame 0xfe0170b55de0 sys_link() at sys_link+0x28/frame 0xfe0170b55e00 amd64_syscall() at amd64_syscall+0x158/frame 0xfe0170b55f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0170b55f30 --- syscall (9, FreeBSD ELF64, link), rip = 0x19021dc7251a, rsp = 0x19021ac60538, rbp = 0x19021ac60670 --- How to reproduce: root@mercat1:~ # cd /usr/src/tools/test/stress2/misc root@mercat1:/usr/src/tools/test/stress2/misc # ./all.sh -al5 zfs3.sh Console log: https://people.freebsd.org/~pho/stress/log/log0525.txt -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279152] panic: VERIFY3(NULL == dmu_buf_set_user(l->l_dbuf, &l->l_dbu)) failed (0x == 0xfffff808149f9800x)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279152 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279154] loader.efi shows wrong kernel name, but boots correct kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279154 Bug ID: 279154 Summary: loader.efi shows wrong kernel name, but boots correct kernel Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: free...@kumba.dev NOTE: This is with FreeBSD 14.1-BETA2 I am not 100% on this yet, but I think I am seeing a bit of a visual bug in loader.efi. On an Intel NUC8i5BEH, I build and use a custom kernel that is installed to /boot/kernel.custom. In /boot, I create two symlinks: - "GENERIC" which points at /boot/kernel - "CUSTOM" which points at /boot/kernel.custom In /boot/loader.conf, I set these three variables: > kernels="CUSTOM GENERIC" > kernel="CUSTOM" > bootfile="/boot/kernel.custom/kernel" Under 14.0-RELEASE, the boot menu would show for Item #6, this text: > 6. Kernel: default/CUSTOM (X of Y) But under 14.1-BETA2, I see this: > 6. Kernel: default/GENERIC (X of Y) Which shouldn't happen, because the default kernel is the first element in the 'kernels' variable. However, despite what the menu shows, the correct kernel, pointed at by "CUSTOM", is what is booted (likely because of the setting of the 'kernel' variable or the bootfile variable). So I think this could be just a visual bug, but I am not 100% certain at the moment. I haven't updated a system using the classic BIOS loader yet to see if it's got the same bug. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279170] /etc/termcap.db -> /usr/share/misc/termcap.db missing?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279170 Bug ID: 279170 Summary: /etc/termcap.db -> /usr/share/misc/termcap.db missing? Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: ja...@catflap.org I was looking at a ktrace dump file recently (/bin/ls) and noticed that during initialisation, it attempted to read /etc/termcap.db - as that failed, it then read the text version pointed to by /etc/termcap Adding a link: /etc/termcap.db -> /usr/share/misc/termcap.db caused subsequent runs to use the termcap.db version. Is there any reason why /etc/termcap is linked, whilst /etc/termcap.db isn't? And if so, what's the purpose of /usr/share/misc/termcap.db ? Cheers, Jamie -- You are receiving this mail because: You are the assignee for the bug.
[Bug 134767] [sound] [snd_hda] [regression] Sigmatel STAC9205X no sound under RELENG_7_2_0_RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=134767 --- Comment #11 from Lars Hecking --- It is definitely no longer relevant to me. I don't have that machine anymore. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 134767] [sound] [snd_hda] [regression] Sigmatel STAC9205X no sound under RELENG_7_2_0_RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=134767 Christos Margiolis changed: What|Removed |Added Resolution|--- |Unable to Reproduce Status|Open|Closed -- You are receiving this mail because: You are the assignee for the bug.
