[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #7 from Oleh Vinichenko --- i will try most recent changes first. and then start reverting back. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279182] man(1) needs to check for .so files not only in the first line
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279182 Wolfram Schneider changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279182] man(1) needs to check for .so files not only in the first line
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279182 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=73eb53813fe3a2245edbeb670902e4bb9d41e288 commit 73eb53813fe3a2245edbeb670902e4bb9d41e288 Author: Wolfram Schneider AuthorDate: 2024-05-26 05:48:40 + Commit: Wolfram Schneider CommitDate: 2024-05-26 05:48:40 + man(1) needs to check for .so files not only in the first line PR: 279182 Some manual pages have a copyright notice or commit id before including other files with the .so macro. We need to skip comments and empty lines at the beginning of the manpage while checking for the first .so macro. MFC after: 1 week usr.bin/man/man.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279308] mdmfs does not work as documented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279308 Bug ID: 279308 Summary: mdmfs does not work as documented Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rozhuk...@gmail.com https://man.freebsd.org/cgi/man.cgi?query=mdmfs=8=0=FreeBSD+14.0-RELEASE+and+Ports Say: > Create and mount a 16 megabyte malloc-backed file system on /tmp using > the /dev/md1 device; furthermore, donot use soft-updates on > it and > mount itasync: > >mdmfs -M -S -o async -s 16m md1 /tmp But soft updates enabled and no "async". # mdmfs -M -S -o async -s 16m md1 /media # mount /dev/md1 on /media (ufs, local, soft-updates) # tunefs -p /dev/md1 tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k)40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) # mount -v /dev/md1 on /media (ufs, local, soft-updates, writes: sync 2 async 0, reads: sync 3 async 0, fsid 1572526616e23f74, vnodes: count 2 ) # uname -a FreeBSD rimwksv 14.1-STABLE FreeBSD 14.1-STABLE RIM_WKS amd64 Also, IMHO, -t should be forced for all memory backend mount points. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303 --- Comment #1 from Joshua Kinard --- Created attachment 250961 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250961=edit Patch to fix the case of the 'P' flag in newsyslog.conf's manpage -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303 Bug ID: 279303 Summary: usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: free...@kumba.dev Proposed patch fixes a very small typo in the newsyslog.conf(5) manpage that has the 'P' flag lowercased. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279302] kern: Remove leftover saf1761otg bits
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279302 --- Comment #1 from Joshua Kinard --- Created attachment 250960 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250960=edit Patch to cleanup remaining saf1761 driver references -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279302] kern: Remove leftover saf1761otg bits
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279302 Bug ID: 279302 Summary: kern: Remove leftover saf1761otg bits Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: free...@kumba.dev Almost all code related to the saf1761 driver was removed in commit 44796b7e822e, except for two small bits related to saf1761otg support in sys/conf/files and sys/dev/usb/controller/usb_controller.c. The proposed patch completes the removal of this driver. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275741] sys/modules: Fix processing of WITHOUT_MODULES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275741 Joshua Kinard changed: What|Removed |Added Attachment #247035|0 |1 is obsolete|| --- Comment #3 from Joshua Kinard --- Created attachment 250958 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250958=edit Fix processing of WITHOUT_MODULES v3 Updating the proposed patch to recent -CURRENT. Other fixes: - Fixed a spot where I was applying the include for the new 'kmod.withoutmk' logic on sys/modules/otus/Makefile, which doesn't have a SUBDIR variable defined; this needed to actually be applied to sys/modules/otusfw/Makefile. - Added the include to sys/modules/cxgbe/Makefile, which was missed in the last version of the patch. - Added the include to sys/modules/nvmf/Makefile (which looks like a recently-added module) - Added the include to sys/modules/pms/Makefile, which has a SUBDIR variable in it, but it is currently commented out, so this is for the future should that variable ever be uncommented. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #6 from Christos Margiolis --- Hello Oleh, In the description you are mentioning things working fine after reverting back to 8771127d75a1295dd32abd0022ff3750bc56470. It would be more helpful if you could start applying the commits after it one by one and let me know at which commit exactly things start breaking. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cd254b9243d3d0f4d86b388f919dc744086fb002 commit cd254b9243d3d0f4d86b388f919dc744086fb002 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:25 + Commit: Christos Margiolis CommitDate: 2024-05-25 19:30:49 + mixer(8): Ignore mixer_open() failures for the -a option The most likely reason mixer_open() will fail is because either the device doesn't exist, or because it is disabled, so there is not reason to kill the application. Instead, continue and print the rest of the enabled mixers. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45151 (cherry picked from commit 0e80798518be673bdad7245b627cb5bd7ec0) usr.sbin/mixer/mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ab7c89415462567665c36628137375847fbff590 commit ab7c89415462567665c36628137375847fbff590 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:17 + Commit: Christos Margiolis CommitDate: 2024-05-25 19:30:40 + sound: Handle unavailable devices in various OSS IOCTLs mixer(8)'s -a option is used to print information about all mixer devices in the system. To do this, it loops from 0 to mixer_get_nmixers(), and tries to open "/dev/mixer%d". However, this approach doesn't work when there are disabled/unregistered mixers in the system, or when an audio device simply doesn't have a mixer. mixer_get_nmixers() calls SNDCTL_SYSINFO and returns oss_sysinfo->nummixers, whose value is the number of currently _enabled_ mixers only. Taking the bug report mentioned below (277615) as an example, suppose a system with 8 mixer devices total, but 3 of them are either disabled or non-existent, which means they will not show up under /dev, meaning we have 5 enabled mixer devices, which is also what the value of oss_sysinfo->nummixers will be. What mixer(8) will do is loop from 0 to 5 (instead of 8), and start calling mixer_open() on /dev/mixer0, up to /dev/mixer4, and as is expected, the first call will fail right away, hence the error shown in the bug report. To fix this, modify oss_sysinfo->nummixers to hold the value of the maximum unit in the system, which, although not necessarily "correct", is more intuitive for applications that will want to use this value to loop through all mixer devices. Additionally, notify applications that a device is unavailable/unregistered instead of skipping it. The current implementations of SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO and SNDCTL_CARDINFO break applications that expect to get information about a device that is skipped. Related discussion can be found here: https://reviews.freebsd.org/D45135#1029526 It has to be noted, that other applications, apart from mixer(8), suffer from this. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45256 (cherry picked from commit 5d980fadf73df64a1e0eda40a93170ed76ce6f14) lib/libmixer/mixer.3 | 7 +- sys/dev/sound/pcm/dsp.c | 23 +- sys/dev/sound/pcm/mixer.c | 201 -- sys/dev/sound/pcm/mixer.h | 2 - sys/dev/sound/pcm/sound.c | 41 ++ 5 files changed, 155 insertions(+), 119 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279201] mptutil(8) use date from the future: May 24, 2024
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279201 Ed Maste changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org CC||ema...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279268] [patch] xdm dies when pressing CTRL-C if pam_xdg.so is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279268 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 Oleh Vinichenko changed: What|Removed |Added Version|Unspecified |14.0-STABLE -- 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 cnba...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #1 from cnba...@gmail.com --- https://cgit.freebsd.org/src/commit/?id=ff92493a4f6504c49a6c84ec65053f493ff5d708 Patches applied. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #5 from Oleh Vinichenko --- Created attachment 250944 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250944=edit output of `mixer` command -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #4 from Oleh Vinichenko --- Created attachment 250943 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250943=edit cat /dev/sndstat -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 Oleh Vinichenko changed: What|Removed |Added Summary|no sound on stable/14 with |no sound on stable/14 with |vchans and bitperfect |vchans disabled and |setup. |bitperfect setup. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #3 from Oleh Vinichenko --- Created attachment 250942 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250942=edit relevant part of sysctl.conf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #2 from Oleh Vinichenko --- Created attachment 250941 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250941=edit sysctl dev.hdac -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #1 from Oleh Vinichenko --- Created attachment 250940 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250940=edit sysctl dev.pcm -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279285] no sound on stable/14 with vchans and bitperfect setup.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 Bug ID: 279285 Summary: no sound on stable/14 with vchans and bitperfect setup. Product: Base System Version: Unspecified Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: moonlaps...@gmail.com Created attachment 250939 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250939=edit sysctl hw.snd i follow stable/14 on my thinkpad t480 with vchans disabled and bitperfect mode enabled for intel hda. it worked well until very recent added changes to sound(4). now i hearing no sound at all while the application is working ( musicpd in my case ). either from speakers or headphones. reverting the src tree all the way back until commit 8771127d75a1295dd32abd0022ff3750bc564706, which is the first commit of sound system changes restores the state with working sound. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272787] Add asmc support for MacBookPro10,1 and MacMini6,2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272787 --- Comment #1 from James --- Used this patch on a mid-2012 MBP Retina running 14-STABLE to adjust the fan speeds. Quite pleased to find it as the unit runs a bit too warm without the battery. -- 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 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #1 from Warner Losh --- It breaks kernel panics: they are useless w/o symbols. It breaks all the data we harvest from the kernel by reading it directly, though most of those things are sysctl'd, but some reporting would be affected. I'm glad it works for you, but I think that it's a really bad idea to do by default. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261440] vt newcons breaks suspend/resume for all graphics cards that do not use KMS drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261440 --- Comment #5 from Stefan B. --- (In reply to Ed Maste from comment #4) Not yet, had no time yet, but testing again with 14 and current is on my todo list, as I have read some reports that suspend/resume now works with Nvidia+vt. As I would like to drop SC from my scripts to not have to maintain different handling for two consoles SC (for Nvidia+Matrox) and vt (Intel, AMD). So I need to also test whether the proposed fix for Matrox (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270509#c29) works, and whether it is already committed/incorporated, as Matrox is a very common onboard graphics chip for Supermicro and other server boards. I will set up a dedicated test PC for these graphics card tests and report back. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 233356] vt(4) doesn't support rc.conf parameters saver= or blanktime=
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233356 Ed Maste changed: What|Removed |Added Summary|12.0-RC1 vt(4) doesn't |vt(4) doesn't support |support rc.conf parameters |rc.conf parameters saver= |saver= or blanktime= |or blanktime= Version|12.0-STABLE |CURRENT --- Comment #3 from Ed Maste --- Source code link has gone stale, it is supposed to be a link to the unimplemented CONS_BLANKTIME: case CONS_BLANKTIME: /* XXX */ return (0); -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261440] vt newcons breaks suspend/resume for all graphics cards that do not use KMS drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261440 --- Comment #4 from Ed Maste --- (In reply to Stefan B. from comment #3) Any update? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276206] Setting kern.vty="sc" will hang the loader boot process, but vt(4) says we can do that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276206 Ed Maste changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276206] Setting kern.vty="sc" will hang the loader boot process, but vt(4) says we can do that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276206 --- Comment #8 from Ed Maste --- https://reviews.freebsd.org/D45357 for a vt(4) man page update to note this -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276206] Setting kern.vty="sc" will hang the loader boot process, but vt(4) says we can do that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276206 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #7 from Ed Maste --- Note that this is documented in syscons(4): Note that the syscons driver is not compatible with systems booted via UEFI(8). Forcing use of syscons on such systems will result in no usable console. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279270] WITHOUT_UNDEFINED_VERSION fails with WITHOUT_NIS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279270 Ed Maste changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279270] WITHOUT_UNDEFINED_VERSION fails with WITHOUT_NIS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279270 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=61639bb3fc5abe0bb7b096e643b51c30703ac432 commit 61639bb3fc5abe0bb7b096e643b51c30703ac432 Author: Ed Maste AuthorDate: 2024-05-24 17:27:29 + Commit: Ed Maste CommitDate: 2024-05-24 20:47:37 + libc: move NIS xdr_* symbols from rpc's to yp's Symbol.map To fix WITHOUT_NIS build. Building yp_xdr.c is gated by MK_NIS. PR: 279270 Reported by:peterj Reported by:matteo Reported by:Michael Dexter's Build Option Survey run Reviewed by:brooks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45347 lib/libc/rpc/Symbol.map | 31 --- lib/libc/yp/Symbol.map | 32 2 files changed, 32 insertions(+), 31 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279270] WITHOUT_UNDEFINED_VERSION fails with WITHOUT_NIS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279270 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- I had a go at this via these two: https://reviews.freebsd.org/D45346 https://reviews.freebsd.org/D45345 D45346 may still make sense to support similar cases that may come up in the future, but for this issue moving them to the existing lib/libc/yp/Symbol.map sounds like the right thing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279225] pfctl(8) displays the name of the anchors incompletely
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279225 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org Assignee|b...@freebsd.org|k...@freebsd.org Status|New |In Progress --- Comment #1 from Kristof Provost --- I see what's broken here and have a fix pending. I suspect I need to fix another bug too (basically, cfa1a13087096fe93d7a2976015ccda243476a64 needs to be done for nat rules too) so I can write a decent test case, so it may be a few more days. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279270] WITHOUT_UNDEFINED_VERSION fails with WITHOUT_NIS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279270 Bug ID: 279270 Summary: WITHOUT_UNDEFINED_VERSION fails with WITHOUT_NIS Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: pet...@freebsd.org Commit 4510f2ca9170927309a423274e03f1eb8e27da27 changed the linker default to fail if undefined symbols are found during shared library creation. If WITHOUT_NIS is specified, linking libc.so.7 fails: ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_domainname' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_keydat' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_mapname' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_peername' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_valdat' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_binding' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_resp' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_resptype' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_setdom' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmap_parms' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmaplist' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_yppush_status' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_yppushresp_xfr' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_key' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_nokey' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_xfr' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreqtype' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_yprequest' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_all' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_key_val' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_maplist' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_master' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_order' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_val' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresp_xfr' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresponse' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypresptype' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypstat' failed: symbol not defined ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypxfrstat' failed: symbol not defined These symbols are listed in /usr/src/lib/libc/rpc/Symbol.map but defined in yp_xdr.c, which is built from /usr/src/include/rpcsvc/yp.x via /usr/src/lib/libc/yp/Makefile.inc I believe the fix is to move those symbols into /usr/src/lib/libc/yp/Symbolmap -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271826] FreeBSD is disastrously slow on a PowerMac G5, freezing at every command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826 --- Comment #21 from Denis Ahrens --- If anyone can build a kernel without c583b02587 to test I can try that. Since 12.4 has not even working packages anymore I can't do anything. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] killpg(): Forking fast leads to livelock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Michael Gmelin changed: What|Removed |Added Flags|needs_errata? |needs_errata?(secteam@FreeB ||SD.org) CC||sect...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279268] [patch] xdm dies when pressing CTRL-C if pam_xdg.so is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279268
Bug ID: 279268
Summary: [patch] xdm dies when pressing CTRL-C if pam_xdg.so is
used
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: m...@fbsd2.e4m.org
Created attachment 250918
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250918=edit
patch
After updating to latest 14.1 BETA xdm crashed when Ctrl-C was pressed on the
logon screen. Running xdm in debug mode showed:
SetPrompt(0, , LOGIN_PROMPT_NOT_SHOWN(0))
SetPrompt(1, , LOGIN_PROMPT_NOT_SHOWN(0))
pam_msg: PAM_PROMPT_ECHO_ON (2): ' Login:'
SetPrompt(0,Login:, LOGIN_PROMPT_ECHO_ON(1))
RedrawFail('Login incorrect or forbidden by policy', 0)
dispatching :0
RedrawFail('Login incorrect or forbidden by policy', 0)
(CTRL-C now)
GreetDone: , (password is 0 long)
REMANAGE_DISPLAY
Done dispatch :0
xdm error (pid 8751): pam_authenticate failure: Conversation failure
Unsecure display :0
Greet connection closed
Manager wait returns pid: 8751 sig 11 core 0 code 0
Display exited with unknown status 2816
I fixed it with the attached patch (not knowing if this is correct :-)).
Apparently pam_get_item() can return NULL in but pam_xdg.c continues with
it...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 262457] "zfs-list -v" duplicates most of the output; lack of "device" property to use with "-o" option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262457 free...@bitter-almonds.com changed: What|Removed |Added CC||free...@bitter-almonds.com Status|New |Closed Resolution|--- |Feedback Timeout -- 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 #10 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87bf0aaba8f1bd743d4df24ae422dd8075260d45 commit 87bf0aaba8f1bd743d4df24ae422dd8075260d45 Author: Henrich Hartzer AuthorDate: 2024-05-10 23:03:14 + Commit: Warner Losh CommitDate: 2024-05-23 20:30:57 + Remove COMPAT_FREEBSD4/5/6/7/9 from MINIMAL and FIRECRACKER kernel configurations FIRECRACKER is not a legacy config, so remove the really old FreeBSD versions from it. MINIMAL has a similar history, and limited target audience which has little to no overlap with really old binaries. Either of these is really easy to get additional binary compat with the include directive, so balance things better. Leave GENERIC alone. PR: 231768 Signed-off-by: Henrich Hartzer Reviewed by: imp (MINIMAL), cperciva (FIRECRACKER) Pull Request: https://github.com/freebsd/freebsd-src/pull/1228 sys/amd64/conf/FIRECRACKER | 5 - sys/amd64/conf/MINIMAL | 5 - sys/i386/conf/MINIMAL | 5 - 3 files changed, 15 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279261] i2c -sv reports stack garbage in message
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279261 Bug ID: 279261 Summary: i2c -sv reports stack garbage in message Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: j...@mit.edu Created attachment 250908 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250908=edit Initialize i2c_opt.addr to 0 # i2c -sv dev: /dev/iic0, addr: 0x6cfb7d5c, r/w: r, offset: 0x00, width: 8, count: 1 Hardware may not support START/STOP scanning; trying less-reliable read method. Scanning I2C devices on /dev/iic0: 11 # i2c -f /dev/iic1 -rv dev: /dev/iic1, addr: 0x1903955c, r/w: r, offset: 0x00, width: 8, count: 1 Resetting I2C controller on /dev/iic1 The address 0x6cfb7d5c or 0x1903955c is an uninitialized field in variable i2c_opt and varies from run to run. It is not actually relevant when scanning or resetting. The attached patch avoids printing the "dev:" line when verbose in scan or reset mode. The bus name is printed elsewhere and the rest of the fields are not relevant. It also initializes the address to 0 just in case it gets used somehow now or in the future. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 221151] panic: tdsendsignal(): invalid signal 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221151 Bob Prohaska changed: What|Removed |Added CC||f...@www.zefox.net --- Comment #11 from Bob Prohaska --- Here's another example, from an armv7 Raspberry Pi 2 v1.1 running: FreeBSD 14.0-RELEASE-p6 #51 releng/14.0-n265417-d338712beb16: Sat Apr 6 23:48:20 PDT 2024 b...@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm May 22 17:46:00 www sshd[5112]: error: PAM: Authentication error for root from innovexportsv.com May 22 17:46:50 www sshd[5115]: error: PAM: Authentication error for root from innovexportsv.com May 22 17:47:43 www sshd[5118]: error: PAM: Authentication error for root from innovexportsv.com panic: tdsendsignal(): invalid signal 0 cpuid = 1 time = 1716425284 KDB: stack backtrace: #0 0xc0362488 at kdb_backtrace+0x40 #1 0xc0309cf4 at vpanic+0x140 #2 0xc0309bb4 at vpanic+0 #3 0xc03121c0 at tdsendsignal+0xe40 #4 0xc0311098 at trapsignal+0x310 #5 0xc0654db4 at abort_handler+0x1a4 #6 0xc0633b98 at exception_exit+0 #7 0x203c8074 at _binary_sdma_imx6q_bin_size+0x203c77e0 Uptime: 45d7h10m56s Resetting system ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 --- Comment #2 from Andriy Gapon --- (In reply to Vladimir Druzenko from comment #1) nvidia driver is only a victim here, it simply allocates memory and the allocator sees that the memory has been tampered with. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279249] quotactl(2) out of date w.r.t. ZFS, and missing information
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279249 Bug ID: 279249 Summary: quotactl(2) out of date w.r.t. ZFS, and missing information Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: g...@nxg.name CC: d...@freebsd.org The quotactl(2) manpage states bluntly that ‘Currently quotas are supported only for the "ufs" file system.’ But (a) bug #234413 from 2019/12.0, states that ‘ZFS implements quotactl(2) as of r336017; the man page needs to be updated.’ Also (b) quotactl does seem to work when called on a ZFS filesystem. Though it seems to work, does this work only by accident? (ie, is it going to stop working unexpectedly?). It would be good for the manpage to be explicit about this. Separately, the manpage doesn't give, or point to, relevant information on how to interpret the results of the call. I can call quotactl(2) on a ZFS filesystem and it produces numbers, which quota.h tells me are in units of disk blocks, and which are right if the block-size is 512B. But I can find nothing, neither in quotactl() nor in ufs/ufs/quota.h, which tells me that unequivocally, and in a way which I'm confident will work on a pool with a different ashift value. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Vladimir Druzenko changed: What|Removed |Added CC||v...@freebsd.org --- Comment #1 from Vladimir Druzenko --- Did you install the nvidia driver from ports or from packages? How do you load it? Have you tried another load options? Have you tried other driver versions? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) TX hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 Mark Linimon changed: What|Removed |Added Keywords||IntelNetworking Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) TX hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 Dr. Uwe Meyer-Gruhl changed: What|Removed |Added Summary|igc(4) I226 (and I225) |igc(4) I226 (and I225) TX |hangups |hangups -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245
Bug ID: 279245
Summary: igc(4) I226 (and I225) hangups
Product: Base System
Version: 13.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: freebsd_em...@congenio.de
When using an I226 under OpnSense (FreeBSD 13.2-RELEASE kernel - I also tried
FreeBSD 14.0-RELEASE), I experience connection hangups about once per day under
no specific circumstances (maximum was 3 times within one hour, I also had none
in three days).
This problem manifests in a dead connection (no packets are received, note are
sent), but the low-level counters (dev.igc.0.mac_stats) still increase.
The conditon can be cleard up by bringing the interface down and up again or by
shortly disconnecting the cable.
There are reports on this and other related problems all over the internet for
different OSes, see:
Windows:
https://forums.evga.com/PSA-Intel-I226V-25GbE-on-Raptor-Lake-Motherboards-Has-a-Connection-Drop-Issue-No-Fix-m3595279.aspx
OpnSense (FreeBSD):
https://forum.opnsense.org/index.php?topic=40404.msg199288#msg199288
pfSense (FreeBSD):
https://forum.netgate.com/topic/181571/chinese-i226-v-on-23-05-1-problems
My specific variant is an I226-V, rev.4, built into a Minisforum MS-01:
igc0@pci0:87:0:0: class=0x02 rev=0x04 hdr=0x00 vendor=0x8086
device=0x125c subvendor=0x8086 subdevice=0x
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-V'
class = network
subclass = ethernet
However, there are reports of the I226-LM connected to the same machine showing
the same behaviour, see: https://forum.opnsense.org/index.php?topic=40556
igc1@pci0:88:0:0: class=0x02 rev=0x04 hdr=0x00 vendor=0x8086
device=0x125b subvendor=0x8086 subdevice=0x
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-LM'
class = network
subclass = ethernet
This seems to indicate that at least the I226 family (which is a successor to
the problem-ridden I225 using the same driver module) is affected by this
problem.
I tried all possible settings I could think of to make this go away, like
reducing the speed from 2.5 to 1 Gbps, disabling EEE (which is off by default
anyway) to no avail.
Interestingly, the Minisforum-MS01 has gained much interest in the last few
months and there was a specific review on Youtube were the creator states in a
comment that he is not seeing this problem
(https://www.youtube.com/watch?v=_wgX1sDab-M). However, he uses OpnSense under
a Proxmox hypervisor, thus using the Linux driver modules (OpnSense itself uses
the virtualized virtio NICs).
This and the reports of gamers stating they had "micro-hangs" manifesting as
short lags in online games got me thinking.
So I compared the Linux and FreeBSD drivers and found, that the Linux driver
has a specific routine to catch, protocol and clear "TX hang" conditions, see
from line 3150 here:
https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/intel/igc/igc_main.c,
which reads:
if (test_bit(IGC_RING_FLAG_TX_DETECT_HANG, _ring->flags)) {
struct igc_hw *hw = >hw;
/* Detect a transmit hang in hardware, this serializes the
* check with the clearing of time_stamp and movement of i
*/
clear_bit(IGC_RING_FLAG_TX_DETECT_HANG, _ring->flags);
if (tx_buffer->next_to_watch &&
time_after(jiffies, tx_buffer->time_stamp +
(adapter->tx_timeout_factor * HZ)) &&
!(rd32(IGC_STATUS) & IGC_STATUS_TXOFF) &&
(rd32(IGC_TDH(tx_ring->reg_idx)) != readl(tx_ring->tail))
&&
!tx_ring->oper_gate_closed) {
/* detected Tx unit hang */
netdev_err(tx_ring->netdev,
"Detected Tx Unit Hang\n"
" Tx Queue <%d>\n"
" TDH <%x>\n"
" TDT <%x>\n"
" next_to_use <%x>\n"
" next_to_clean<%x>\n"
"buffer_info[next_to_clean]\n"
" time_stamp <%lx>\n"
" next_to_watch<%p>\n"
" jiffies <%lx>\n"
" desc.status <%x>\n",
tx_ring->queue_index,
rd32(IGC_TDH(tx_ring->reg_idx)),
readl(tx_ring->tail),
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Bug ID: 279243 Summary: panic: Memory modified after free, Most recently used by solaris 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: a...@freebsd.org This happens on every other boot for me. When it happens it always happens when loading nvidia driver. <118>Mounting local filesystems:. <118>Mounting ZFS filesystems: (354/354) <118>Loading kernel modules: nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io <6>nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 550.54.14 Thu Feb 22 01:05:40 UTC 2024 sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! <6>[drm] [nvidia-drm] [GPU ID 0x0100] Loading driver Memory modified after free 0xf800207cf900(376) val=101 @ 0xf800207cf900 panic: Most recently used by solaris cpuid = 2 time = 1716443221 KDB: stack backtrace: db_trace_self_wrapper() at 0x80614c2b = db_trace_self_wrapper+0x2b/frame 0xfe01985cc060 kdb_backtrace() at 0x8094a037 = kdb_backtrace+0x37/frame 0xfe01985cc110 vpanic() at 0x808fba29 = vpanic+0x169/frame 0xfe01985cc250 panic() at 0x808fb803 = panic+0x43/frame 0xfe01985cc2b0 mtrash_ctor() at 0x80bb25ee = mtrash_ctor+0x7e/frame 0xfe01985cc2d0 item_ctor() at 0x80bb1818 = item_ctor+0x108/frame 0xfe01985cc320 uma_zalloc_arg() at 0x80baac3b = uma_zalloc_arg+0x10b/frame 0xfe01985cc360 malloc() at 0x808d4f60 = malloc+0x70/frame 0xfe01985cc3a0 os_alloc_mem() at 0x857de5f7 = os_alloc_mem+0x37/frame 0xfe01985cc3c0 _nv013606rm() at 0x854fc874 = _nv013606rm+0x34/frame 0xfe01a322fc00 Uptime: 42s "Most recently used by solaris" makes me think that the problem is in ZFS. Also, because the module loading happens right after mounting ZFS filesystems. The zone is "malloc-384". 24 initial bytes are affected: (kgdb) x/48a item 0xf800207cf900: 0x101 0x0 0xf800207cf910: 0x0 0xdeadc0dedeadc0de 0xf800207cf920: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf930: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf940: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf950: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf960: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf970: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf980: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf990: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9a0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9b0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9c0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9d0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9e0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9f0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa00: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa10: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa20: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa30: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa40: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa50: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa60: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa70: 0xdeadc0dedeadc0de 0x8121a800 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 Christos Margiolis changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5d980fadf73df64a1e0eda40a93170ed76ce6f14 commit 5d980fadf73df64a1e0eda40a93170ed76ce6f14 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:17 + Commit: Christos Margiolis CommitDate: 2024-05-23 00:57:17 + sound: Handle unavailable devices in various OSS IOCTLs mixer(8)'s -a option is used to print information about all mixer devices in the system. To do this, it loops from 0 to mixer_get_nmixers(), and tries to open "/dev/mixer%d". However, this approach doesn't work when there are disabled/unregistered mixers in the system, or when an audio device simply doesn't have a mixer. mixer_get_nmixers() calls SNDCTL_SYSINFO and returns oss_sysinfo->nummixers, whose value is the number of currently _enabled_ mixers only. Taking the bug report mentioned below (277615) as an example, suppose a system with 8 mixer devices total, but 3 of them are either disabled or non-existent, which means they will not show up under /dev, meaning we have 5 enabled mixer devices, which is also what the value of oss_sysinfo->nummixers will be. What mixer(8) will do is loop from 0 to 5 (instead of 8), and start calling mixer_open() on /dev/mixer0, up to /dev/mixer4, and as is expected, the first call will fail right away, hence the error shown in the bug report. To fix this, modify oss_sysinfo->nummixers to hold the value of the maximum unit in the system, which, although not necessarily "correct", is more intuitive for applications that will want to use this value to loop through all mixer devices. Additionally, notify applications that a device is unavailable/unregistered instead of skipping it. The current implementations of SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO and SNDCTL_CARDINFO break applications that expect to get information about a device that is skipped. Related discussion can be found here: https://reviews.freebsd.org/D45135#1029526 It has to be noted, that other applications, apart from mixer(8), suffer from this. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45256 lib/libmixer/mixer.3 | 7 +- sys/dev/sound/pcm/dsp.c | 23 +- sys/dev/sound/pcm/mixer.c | 201 -- sys/dev/sound/pcm/mixer.h | 2 - sys/dev/sound/pcm/sound.c | 41 ++ 5 files changed, 155 insertions(+), 119 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0e80798518be673bdad7245b627cb5bd7ec0 commit 0e80798518be673bdad7245b627cb5bd7ec0 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:25 + Commit: Christos Margiolis CommitDate: 2024-05-23 00:57:25 + mixer(8): Ignore mixer_open() failures for the -a option The most likely reason mixer_open() will fail is because either the device doesn't exist, or because it is disabled, so there is not reason to kill the application. Instead, continue and print the rest of the enabled mixers. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45151 usr.sbin/mixer/mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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 #4 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=07b7dec1fe4296cdf470013087180a80a0d4a2cf commit 07b7dec1fe4296cdf470013087180a80a0d4a2cf Author: Konstantin Belousov AuthorDate: 2024-05-13 17:17:47 + Commit: Konstantin Belousov CommitDate: 2024-05-22 23:47:23 + SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information PR: 278949 (cherry picked from commit 87a156527563d0728bff355093e26943da3d7fad) 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 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 #3 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2a2f2f59132ad365203c5deb8ed16202a78585c1 commit 2a2f2f59132ad365203c5deb8ed16202a78585c1 Author: Konstantin Belousov AuthorDate: 2024-05-15 09:54:49 + Commit: Konstantin Belousov CommitDate: 2024-05-22 23:47:23 + vfs_domount_update(): postpone setting MNT_UNION until VFS_MOUNT() is done PR: 265311 (cherry picked from commit 21ccdb4119afdfdfeaa80e9c8514171c65b35862) 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 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b76674a73988eb708bdb53e11c5c54e8488b33a1 commit b76674a73988eb708bdb53e11c5c54e8488b33a1 Author: Konstantin Belousov AuthorDate: 2024-05-13 17:17:47 + Commit: Konstantin Belousov CommitDate: 2024-05-23 00:26:44 + SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information PR: 278949 (cherry picked from commit 87a156527563d0728bff355093e26943da3d7fad) 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 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 #2 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=625a622cc6511e250470ee3f84a8553c7c734de6 commit 625a622cc6511e250470ee3f84a8553c7c734de6 Author: Konstantin Belousov AuthorDate: 2024-05-15 09:54:49 + Commit: Konstantin Belousov CommitDate: 2024-05-23 00:26:43 + vfs_domount_update(): postpone setting MNT_UNION until VFS_MOUNT() is done PR: 265311 (cherry picked from commit 21ccdb4119afdfdfeaa80e9c8514171c65b35862) 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 279223] sed - "a\" command displays different results depending on use of -e option (closing new line)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric Vermetten changed: What|Removed |Added CC||ericvermet...@online.nl --- Comment #2 from Eric Vermetten --- In addition to previous comment: sed '/1/a\ -new line- ' behaviour, is mentioned in: sed & awk, 2nd edition; Arnold Robbin, Dale Dougherty at the "Command Summary for sed": " a [address]a\ text Append text following each line matched by address. If text goes over more than one line, newlines must be "hidden" by preceding them with a backslash. The text will be terminated by the first newline that is not hidden in this way. The text is not available in the pattern space and subsequent commands cannot be applied to it. The results of this command are sent to standard output when the list of editing commands is finished, regardless of what happens to the current line in the pattern space. " -- 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 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #5 from Konstantin Belousov --- https://reviews.freebsd.org/D45305 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] killpg(): Forking fast leads to livelock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Michael Gmelin changed: What|Removed |Added Severity|Affects Some People |Affects Many People Summary|logger: Forking many logger |killpg(): Forking fast |executables at once renders |leads to livelock |machine unresponsive| Component|bin |kern -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279231] wefwfeweffewwef
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279231 Li-Wen Hsu changed: What|Removed |Added Product|Base System |Other Version|15.0-CURRENT|unspecified Assignee|b...@freebsd.org|bugmeis...@freebsd.org Status|New |Closed Resolution|--- |Not A Bug CC||lw...@freebsd.org Component|gnu |Spam -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279231] wefwfeweffewwef
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279231 Bug ID: 279231 Summary: wefwfeweffewwef Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: gnu Assignee: b...@freebsd.org Reporter: fej...@tuta.io My life done I'm done with my life I just want to quit it all I can't get a job I'm sad I have no life I have no friends I have no hope I'm emotionless I'm worthless -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279227] csplit: handlesig is not async-signal-safe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279227 Dag-Erling Smørgrav changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1 from Dag-Erling Smørgrav --- yeah the comment is wrong, it is no safer on FreeBSD than on any other *nix, but just like on any other *nix it will "appear" to work fine until you manage to trigger a signal at just the wrong time. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279227] csplit: handlesig is not async-signal-safe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279227 Bug ID: 279227 Summary: csplit: handlesig is not async-signal-safe Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: kev...@freebsd.org handlesig calls cleanup(), which is itself not async-signal-safe if `doclean != 0` as it wants to use `snprintf` -- while it notes that it "appears" to be safe on FreeBSD, we should strive to be correct here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279226] sort(1) can deadlock with poorly timed signal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279226 Bug ID: 279226 Summary: sort(1) can deadlock with poorly timed signal Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: kev...@freebsd.org sort(1) has a semapahore to protect the tmp file list, and it catches numerous signals to trigger tmp cleanup before bailing out. If we receive a signal while tmp_files_sem is held, we can easily deadlock sort(1) as the signal handler tries to take it again. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279225] pfctl(8) displays the name of the anchors incompletely
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279225 Bug ID: 279225 Summary: pfctl(8) displays the name of the anchors incompletely Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: dt...@disroot.org Description: When pfctl(8) is used to display anchors or to display NAT rules, the name of the anchors is displayed incompletely compared to 14.0-RELEASE. This results in programs failing when they depends on the output of pfctl(8) [1]. [1] https://github.com/DtxdF/AppJail/issues/10 Steps to reproduce this issue: 15.0-CURRENT: ``` # freebsd-version 15.0-CURRENT # pfctl -sn nat-anchor "appjail" all nat-anchor "appjail" all rdr-anchor "appjail" all # pfctl -sA appjail-nat appjail-rdr ``` 14.0-RELEASE: ``` # freebsd-version 14.0-RELEASE-p6 # pfctl -sn nat-anchor "appjail-nat/jail/*" all nat-anchor "appjail-nat/network/*" all rdr-anchor "appjail-rdr/*" all # pfctl -sA appjail-nat appjail-rdr ``` Tested on: * 14.0-RELEASE-p6 * 15.0-CURRENT Notes: * I have used `FreeBSD-15.0-CURRENT-amd64-20240516-d7adf3b47a05-270169-bootonly.iso` install FreeBSD on bhyve using vm-bhyve. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 241697] i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invalid CPU in callout 256)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2792 ||24 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2416 ||97 Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 Bug ID: 279224 Summary: [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE 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: m...@fbsd2.e4m.org [If this is considered to be a ports issue feel free to modify the PR] 14.0-STABLE and 14.1-BETA as of today need drm-61-kmod (instead of drm-515-kmod as in earlier versions). Loading i915kms if the kernel had been built with either VT_MAXWINDOWS or SC_NO_CUTPASTE makes the system crash. Maybe this is something similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 which had hit me as well... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" command displays different results depending on use of -e option (closing new line)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric changed: What|Removed |Added Summary|sed - "a\" comand displays |sed - "a\" command displays |different results depending |different results depending |on use of -e option |on use of -e option ||(closing new line) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric changed: What|Removed |Added Version|14.0-RELEASE|13.3-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 --- Comment #1 from Eric --- Using 13.3-RELEASE and "pkg install gsed" (version 4.9). For the a\ command of sed(1), whether or not specifying the -e option, produces different results. sed ' ... ' (without the -e option) seems to be in error. $ cat t 1 2 $ cat sed-add.sh #!/bin/sh sed '/1/a\ -new line-' > sed -e '... '\n" sed -e '/1/a\ -new line-' > sed -e ' ... ' 1 -new line- 2 Using variants with double quotes, as in: sed "/1/a\\ -new line-" https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html but the behaviour of sed -e ' ... ' seems the correct one. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Bug ID: 279223 Summary: sed - "a\" comand displays different results depending on use of -e option Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: erichans...@gmail.com test -- 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 --- Comment #10 from Christos Margiolis --- I am not sure if this recent commit [1] is related to this issue, but I wasn't able to reproduce this bug on 14.0-RELEASE. I think it's better to close this. [1] https://cgit.freebsd.org/src/commit/?id=bed0b2146faa2e9a445d9f9196c7b46f50034631 -- 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 Enji Cooper changed: What|Removed |Added Status|Open|Closed Resolution|--- |Overcome By Events --- Comment #9 from Enji Cooper --- I no longer have access to this system and I don’t currently run any FreeBSD desktops or laptops with sound enabled on them. -- 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 #5 from commit-h...@freebsd.org --- A commit in branch releng/14.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=18f80d6d463495703f9eb2ccfd92bae93c7889a3 commit 18f80d6d463495703f9eb2ccfd92bae93c7889a3 Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:28 + Commit: Christos Margiolis CommitDate: 2024-05-22 13:22:26 + sound: Check user-supplied size passed to SNDSTIOC_ADD_USER_DEVS* SNDSTIOC_ADD_USER_DEVS* expects a user-supplied sndstioc_nv_arg->nbytes, however we currently do not check whether this size is actually valid, which results in a panic when SNDSTIOC_ADD_USER_DEVS* is called with an invalid size. sndstat_add_user_devs() calls sndstat_unpack_user_nvlbuf(), which then calls malloc() with that size. PR: 266142 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:brooks Differential Revision: https://reviews.freebsd.org/D45236 (cherry picked from commit 074d337ad618f9cc2a1d5ab18b484928e57bd72b) (cherry picked from commit 5830a00c2c5485ec17900558e4f29c459c6a1f3e) Approved by:re (cperciva) sys/dev/sound/pcm/sndstat.c | 5 + sys/sys/sndstat.h | 5 + 2 files changed, 10 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266144] bug in sndstat_unpack_user_nvlbuf()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266144 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch releng/14.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8d3f96bd85c9519cef76d0727b00082354a2134b commit 8d3f96bd85c9519cef76d0727b00082354a2134b Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:33 + Commit: Christos Margiolis CommitDate: 2024-05-22 13:22:40 + sound: Correctly check nvlist_unpack() error The current check is never false and if nvlist_unpack() fails, we might panic later down the road. PR: 266144 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch, emaste Differential Revision: https://reviews.freebsd.org/D45237 (cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a) (cherry picked from commit 45feaa73c68011bbba647d1eb6f86a166a0453e9) Approved by:re (cperciva) sys/dev/sound/pcm/sndstat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Michael Gmelin changed: What|Removed |Added Flags||mfc-stable13?, ||needs_errata? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279052] Request account removal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279052 Mark Linimon changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You reported the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 --- Comment #2 from Michael Gmelin --- Cherry-picking this commit fixes the issue for me: commit 7a70f17ac4bd64dc1a5020f963ba4380cf37b7e5 Author: Konstantin Belousov Date: Fri Jul 7 20:19:33 2023 +0300 killpg(): more carefully avoid LoR otherwise we could end up with the livelock. When pg_killsx trylock failed, ensure that we do wait for lock availability before retry. Reported and tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203
Michael Gmelin changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #1 from Michael Gmelin ---
This only seems to affect 13.3 and 13-STABLE after
https://cgit.freebsd.org/src/commit/?h=stable/13=2b0cd3b552942c642a84f8e224b989c02d97125d
("killpg(2): close a race with fork(2), part1").
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279208] filling up arp table with static entries leads to a crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279208] filling up arp table with static entries leads to a crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 martin changed: What|Removed |Added Summary|filling up arp table with |filling up arp table with |static entries can lead to |static entries leads to a |crash |crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279208] filling up arp table with static entries can lead to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208 Bug ID: 279208 Summary: filling up arp table with static entries can lead to crash Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: mar...@bxlr.sk Loading arp table with the arp -f command leads to a panic. Sometimes panic occurs immediately, sometimes after loading more entries (more subnets or wider subnet). Executing few arp -a processes and waiting few minutes does lead to panic too. To reproduce I've created an alias on interface and a list of dummy entries: # ifconfig em0 alias 172.17.1.1/24 # cat 1list 172.17.1.2 13:01:00:00:00:02 172.17.1.3 13:01:00:00:00:03 .. 172.17.1.255 13:01:00:00:00:ff # arp -f 1list # ps axl |grep arp 0 842 820 1 20 0 12956 2688 sbwait I+0 0:00.02 arp -a Those entries that arp command did show have obvious overflow: # arp -an ? (172.17.3.254) at 13:03:00:00:00:fe on em0 expires in -1716331940 seconds [ethernet] ? (172.17.3.222) at 13:03:00:00:00:de on em0 expires in -1716331940 seconds [ethernet] Sleeping thread (tid 100853, pid 0) owns a non-sleepable lock KDB: stack backtrace of thread 100853: #0 0x80b5028b at mi_switch+0xbb #1 0x80b4fa00 at _sleep+0x1f0 #2 0x80ba6c11 at taskqueue_thread_loop+0xb1 #3 0x80afdb7f at fork_exit+0x7f #4 0x80fe4b2e at fork_trampoline+0xe panic: sleeping thread cpuid = 1 time = 1716332236 KDB: stack backtrace: #0 0x80b9009d at kdb_backtrace+0x5d #1 0x80b431a2 at vpanic+0x132 #2 0x80b43063 at panic+0x43 #3 0x80ba8e9e at propagate_priority+0x29e #4 0x80ba99e4 at turnstile_wait+0x314 #5 0x80b3e9c9 at __rw_rlock_hard+0x279 #6 0x80d8c2af at dump_lle+0x1f #7 0x80c6c38c at htable_foreach_lle+0x5c #8 0x80d8c234 at dump_llts_iface+0x54 #9 0x80d8bfcd at rtnl_handle_getneigh+0x20d #10 0x80d882d2 at rtnl_handle_message+0x132 #11 0x80d85c0b at nl_taskqueue_handler+0x79b #12 0x80ba5992 at taskqueue_run_locked+0x182 #13 0x80ba6c22 at taskqueue_thread_loop+0xc2 #14 0x80afdb7f at fork_exit+0x7f #15 0x80fe4b2e at fork_trampoline+0xe Uptime: 4m49s -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Bug ID: 279203 Summary: logger: Forking many logger executables at once renders machine unresponsive Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: gre...@freebsd.org CC: r...@freebsd.org Forking logger many times like this: #!/bin/sh for id in $(jot 100); do logger -p local2.info -t pot "wledkjweldjwldjkwedj" & done sends the machine into some race condition, causing loads of 300-500. I can reproduce it on multicore machines (including within bhyve), not on single core. Load is mostly caused by system calls. When knowing pids, it's sometimes possible to recover the host by killing all logger processes (killall won't work though, as the machine is too loaded for that). I could not reproduce this on 13.2 (at least not as easily). When building logger without capsicum, this doesn't happen, but that could be a red herring. Happens on 13.3 as well as 13.3p2. This is causing quite some headache. We put logger under a lock to reduce concurrency, which made things better, but we still see the general situation (either other things call logger or, more likely, this is just a symptom of a bigger underlying issue). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276724] 'man 8 glabel': add extra content
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276724 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c80c104cbd52db994c0f2757bd1c6d014744022c commit c80c104cbd52db994c0f2757bd1c6d014744022c Author: Chris Moerz AuthorDate: 2024-05-21 18:10:11 + Commit: Joseph Mingrone CommitDate: 2024-05-21 18:49:17 + glabel.8: Describe cases related to permissions / existing mounts Specially, note some requirements for label changes: - glabel requires write permission on device - filesystems first need to be unmounted for new labels to persist across reboots - if the affected device node holds the filesystem root, single-user mode with r/o mount will be required. Also, while here, apply some formatting tweaks. PR: 276724 Reported by:Alex Matei Reviewed by:gbe, jrm, Alexander Ziaee Differential Revision: https://reviews.freebsd.org/D44394 lib/geom/label/glabel.8 | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 --- Comment #1 from Wolfram Schneider --- There is a similar problem with the PnetCDF manual pages: $ mandoc FreeBSD-ports-14.0-RELEASE/misc/man1/cdfdiff.1.gz | tail -n1 Printed: 1900-0-0 PnetCDF 1.12.3 cdfdiff(1) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266142] SNDSTIOC_ADD_USER_DEVS ioctl on /dev/sndstat passes unchecked size from user to malloc() -> potential crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266142 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5830a00c2c5485ec17900558e4f29c459c6a1f3e commit 5830a00c2c5485ec17900558e4f29c459c6a1f3e Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:28 + Commit: Christos Margiolis CommitDate: 2024-05-21 17:45:49 + sound: Check user-supplied size passed to SNDSTIOC_ADD_USER_DEVS* SNDSTIOC_ADD_USER_DEVS* expects a user-supplied sndstioc_nv_arg->nbytes, however we currently do not check whether this size is actually valid, which results in a panic when SNDSTIOC_ADD_USER_DEVS* is called with an invalid size. sndstat_add_user_devs() calls sndstat_unpack_user_nvlbuf(), which then calls malloc() with that size. PR: 266142 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:brooks Differential Revision: https://reviews.freebsd.org/D45236 (cherry picked from commit 074d337ad618f9cc2a1d5ab18b484928e57bd72b) sys/dev/sound/pcm/sndstat.c | 5 + sys/sys/sndstat.h | 5 + 2 files changed, 10 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266144] bug in sndstat_unpack_user_nvlbuf()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266144 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=45feaa73c68011bbba647d1eb6f86a166a0453e9 commit 45feaa73c68011bbba647d1eb6f86a166a0453e9 Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:33 + Commit: Christos Margiolis CommitDate: 2024-05-21 17:45:55 + sound: Correctly check nvlist_unpack() error The current check is never false and if nvlist_unpack() fails, we might panic later down the road. PR: 266144 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch, emaste Differential Revision: https://reviews.freebsd.org/D45237 (cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a) sys/dev/sound/pcm/sndstat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 Brooks Davis changed: What|Removed |Added Resolution|--- |Works As Intended Status|New |Closed --- Comment #3 from Brooks Davis --- It's a little unfortunate that we can't cross build release/13.0 on 14.0 without patches, but ultimately there isn't much we can do. I don't think it would generally make sense to merge the changes back to old release branches. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 --- Comment #2 from Mark Shank --- (In reply to Brooks Davis from comment #1) I had checked out releng/13.0 in order to track down an issue for bug #271826 comment#20 Thank you for the quick response and the patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274423] A place to record all issues with the upgrade to mandoc 1.14.6 - metabug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274423 Wolfram Schneider changed: What|Removed |Added Depends on||279202 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 [Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 Wolfram Schneider changed: What|Removed |Added Blocks||274423 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274423 [Bug 274423] A place to record all issues with the upgrade to mandoc 1.14.6 - metabug -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279202] mandoc: displays wrong date for GNU Radius manual pages: "0, 1900"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279202 Bug ID: 279202 Summary: mandoc: displays wrong date for GNU Radius manual pages: "0, 1900" Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: wo...@freebsd.org mandoc(1) displays a wrong date for the GNU Radius manual pages: $ mandoc FreeBSD-ports-14.0-RELEASE/misc/man1/radgrep.1.gz | tail -n1 GNU Radius 0, 1900 radgrep(1) GNU troff (groff) version 1.23.0 works fine: $ zcat FreeBSD-ports-14.0-RELEASE/misc/man1/radgrep.1.gz |nroff -man | tail -n1 GNU Radius May 21, 2024 radgrep(1) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279201] mptutil(8) use date from the future: May 24, 2024
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279201 Bug ID: 279201 Summary: mptutil(8) use date from the future: May 24, 2024 Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: wo...@freebsd.org CC: d...@freebsd.org Today is May 21th, but the manual page for mptutil(8) reports itself as from May 24, 2024 $ man mptutil | tail -n1 FreeBSD 15.0-CURRENT May 24, 2024 FreeBSD 15.0-CURRENT -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199
Brooks Davis changed:
What|Removed |Added
CC||bro...@freebsd.org
--- Comment #1 from Brooks Davis ---
What source version are you building? This should have been fixed long ago
(the fixes were in the stable/14 when it was branched and MFC'd to stable/13).
If you need to merge them to a local branch, here are the changes:
commit b3b462229f972e2ed24d450d7d2f8855cdd58a87
Author: Ed Maste
Date: Fri Apr 1 09:58:47 2022 -0400
installworld: handle ldd including preloaded objects
The installworld target makes a temporary copy of binaries to be used
during the install. Libraries that they depend on are also included,
found by using `ldd`.
After commit 0913953c9ed0 ldd started listing preloaded objects,
including [vdso], under a [preloaded] header. Skip ldd output that is
enclosed in square brackets.
Reviewed by:cy, kib [earlier version]
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34734
and then I rewrote it to be zsh friendly with:
commit bda5d2a45c8dcc9bbeb71cddeef930ffa6a47f23
Author: Brooks Davis
Date: Fri Jul 1 08:33:16 2022 +0100
installworld: improve portability of ldd use
b3b462229f97 added a case statement to ignore lines containing strings
in square brackets such as "[vdso]" and "[preloaded]". On MacOS
Monterey where /bin/sh may be zsh, this fails with:
/bin/sh: -c: line 0: syntax error near unexpected token `;;'
Invoke grep in the pipeline to remove such lines instead.
Reviewed by:emaste
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D35618
diff --git a/Makefile.inc1 b/Makefile.inc1
index 20c537512273..12bb892dfd58 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1368,12 +1368,8 @@ distributeworld installworld stageworld:
_installcheck_world .PHONY
fi; \
done); \
if [ -z "${CROSSBUILD_HOST}" ] ; then \
- libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null |
sort -u | \
+ libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null |
sort -u | grep -Ev '\[.*]' | \
while read line; do \
- case $$line in \
- "["*"]") \
- continue;; \
- esac; \
set -- $$line; \
if [ "$$2 $$3" != "not found" ]; then \
echo $$2; \
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279174] POLA violation: Graphical Installer for a natively text UI OS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279174 Pierre Pronchery changed: What|Removed |Added CC||khor...@defora.org --- Comment #3 from Pierre Pronchery --- Hi Alexander, (all) [I understand that this is not the place for a discussion - we can take it privately from there - but I think some aspects deserve more clarity] First, thank you for your interest, and for the praise; much appreciated. While I totally agree with your evaluation of FreeBSD, I also believe that it can grow to be more than a text-based Operating System, and that graphical interfaces can be useful to many less tech-savvy users even while setting up a server. I have witnessed this myself, and this is also the reason behind projects like TrueNAS, PC-BSD, GhostBSD, or MidnightBSD for instance. With this in mind, this new graphical version of the installer does not replace the existing one. It adds a new possibility, by means of an additional installation image. It is only available there, and even then it still starts the text-based installer on the first VT as usual. This actually works as a failover mechanism if the graphical installer fails to start. In fact the current design of the graphical installer re-uses the code of the traditional text-based installer. This is an intentional decision on my part, which allows both implementations to improve each other in most situations: a fix in the graphical installer automatically applies to the other one, and vice versa. Win win :) Ed wrote a bit too fast, as by now almost every part is ready and pending review in Phabricator. However overall it is not an easy thing to just approve and push, as it adds weight to releases (currently 8 GB on amd64), flirts with what is acceptable in base (e.g., downloading ports to generate an image) and will probably require documentation updates as well. So this will still take time and broader approval before making it to a future release. Knowing this, I took it upon myself to travel to AsiaBSDCon and communicate about this project at the DevSummit and at the conference, and I also intend to present it to a broader group of FreeBSD developers next week during BSDCan. I would like to conclude by mentioning two related initiatives: Alfonso Siciliano, the author of bsddialog, is working on an additional installation step which would drop a graphical interface after installation if so desired - thus fixing the POLA violation - while a GSoC student, Leaf Yen, is working on extending the installation media for upgrading or repairing existing installations. I am very much looking forward to the first official release of such commercial-grade installation media for FreeBSD :) Anyhow hoping this clarifies, -- Pierre Pronchery -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279200] sysrc(8) fails to perform set operations for += and -= in -c (check only) mode.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279200 Bug ID: 279200 Summary: sysrc(8) fails to perform set operations for += and -= in -c (check only) mode. Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: cr...@rlwinm.de The sysrc command does not perform required set union/difference operations when asked to check if a variable contains certain values (or not) e.g. the following sequences of commands returns failure when it shouldn't: sysrc jail_list="jail1 jail2 jail3" && sysrc -c jail_list+=" jail2" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279199] cross-compile installworld fails attempting to copy vdso library
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279199 Bug ID: 279199 Summary: cross-compile installworld fails attempting to copy vdso library Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: marksh...@aol.com Attachment #250855 text/plain mime type: Created attachment 250855 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250855=edit console output from make installworld Cross compiling on amd64 for powerpc64. buildworld and buildkernel run fine. installworld fails attempting to copy non-existent vdso library. -- You are receiving this mail because: You are the assignee for the bug.
