[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.
