[Bug 226578] panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/home/trasz/svn-ssh/head/sys/cam/scsi/scsi_da.c:2042
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226578 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25 commit bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25 Author: Robert Wing AuthorDate: 2022-01-04 01:21:58 + Commit: Robert Wing CommitDate: 2022-01-04 01:56:48 + cam: don't lock while handling an AC_UNIT_ATTENTION Don't take the device_mtx lock in daasync() when handling an AC_UNIT_ATTENTION. Instead, assert the lock is held before modifying the periph's softc flags. The device_mtx lock is taken in xptdevicetraverse() before daasync() is eventually called in xpt_async_bcast(). PR: 240917, 226510, 226578 Reviewed by:imp MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D27735 sys/cam/scsi/scsi_da.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226510] panic: Re-refing for reason 5, cnt = 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510 --- Comment #22 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25 commit bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25 Author: Robert Wing AuthorDate: 2022-01-04 01:21:58 + Commit: Robert Wing CommitDate: 2022-01-04 01:56:48 + cam: don't lock while handling an AC_UNIT_ATTENTION Don't take the device_mtx lock in daasync() when handling an AC_UNIT_ATTENTION. Instead, assert the lock is held before modifying the periph's softc flags. The device_mtx lock is taken in xptdevicetraverse() before daasync() is eventually called in xpt_async_bcast(). PR: 240917, 226510, 226578 Reviewed by:imp MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D27735 sys/cam/scsi/scsi_da.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260406] pfctl: Cannot allocate memory (after a time)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406 --- Comment #62 from tech-li...@zyxst.net --- (In reply to Diego Linke from comment #61) Hi, What do you have for the following sysctls: kern.maxdsiz net.pf.request_maxcount ? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #14 from Bob Frazier --- Additional followup: In order to test the concept completely (workaround) I restarted powerd (using hapd as before), the HPET event timer, and mwait idle method. Played various videos (including the ones that displayed the problem in earlier repro tests) for about 1 hour, some of which should have been long enough to at least have problems with the audio. Results: no observed audio glitches, and in one case, video performance seemed to be better (no dropped frames in a specific portion of the video that was dropping frames in all of the previous tests). Conclusion: the best workaround seems to be to use the HPET event timer and the 'mwait' idle method, with no need to disable powerd. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #13 from Bob Frazier --- followup with kern.eventtimer.timer=HPET and machdep.idle=mwait and powerd not running, played streaming audio for over an hour, and though I did not hear all of it, I did not notice any major audio glitches. It appears that this altered configuration may be a workaround to the problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260915] etcupdate extract fails with securelevel=2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260915 Bug ID: 260915 Summary: etcupdate extract fails with securelevel=2 Product: Base System Version: 12.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: anto...@hesiod.org Machine is set at kern_securelevel=2 in /etc/rc.conf etcupdate extract errors paris.hesiod.org:root[2]: etcupdate extract Failed to build new tree. paris.hesiod.org:root[12]: cat log >>> extract command: tarball= rm: /var/db/etcupdate/current/var/empty: Operation not permitted rm: /var/db/etcupdate/current/var: Directory not empty rm: /var/db/etcupdate/current: Directory not empty chflags: /var/db/etcupdate/current/var/empty: Operation not permitted rm: /var/db/etcupdate/current/var/empty: Operation not permitted rm: /var/db/etcupdate/current/var: Directory not empty rm: /var/db/etcupdate/current: Directory not empty etcupdate extract and other commands should function under securelevels. etcupdate (no args or resolve) is generally run single user and is ok because securelevel is not set. etcupdate seems not ready for production and general use -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #12 from Bob Frazier --- (In reply to Andriy Gapon from comment #10) re: test if changing sysctl machdep.idle to mwait helps I did this repeatedly, back and forth. The best way to describe the results is to say that while set to 'acpi' the random audio errors usually presented themselves, and while set to 'mwait' they usually did not. However, in one case, I still noticed a rather prominent audible distortion while machdep.idle was set to 'mwait'. In the few tests that I did perform 'mwait' seemed to correlate with the timing errors and distortion happening less, but not completely eliminated. as an additional test, I am stopping powerd, setting the event timer to HPET, and also the mechdep.idle to 'mwait'. I will let audio stream for a while (an hour or so) and see if I can hear any audible distortion. In my previous testing it usually happens at least once within about 10 minutes of streaming audio. So it will probably be a good overall test where I do not have to pay constant attention to it. I'll post later with the results. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259608] ixl0: Failed to remove 0/1 filters, error I40E_AQ_RC_ENOENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259608 --- Comment #2 from Peter Eriksson --- This looks related: https://patchwork.dpdk.org/project/dpdk/patch/20210928084042.1227848-1-robinx.zh...@intel.com/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259608] ixl0: Failed to remove 0/1 filters, error I40E_AQ_RC_ENOENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259608 Peter Eriksson changed: What|Removed |Added Version|12.2-RELEASE|12.3-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259608] ixl0: Failed to remove 0/1 filters, error I40E_AQ_RC_ENOENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259608 Peter Eriksson changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260868] possible i386 regression after ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260868
--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0e494a9e3fd86ef54899dcbe0268866629096c1e
commit 0e494a9e3fd86ef54899dcbe0268866629096c1e
Author: Mark Johnston
AuthorDate: 2022-01-03 15:14:41 +
Commit: Mark Johnston
CommitDate: 2022-01-03 18:00:50 +
x86: Skip late calibration if our reference timer has low quality
Some AMD Geode-based systems end up using the 8254 PIT to calibrate the
TSC during late calibration, which doesn't work because that
timecounter's mask (65535) is much smaller than its frequency (1193182).
Moreover, early calibration is done against the 8254 timer anyway.
Work around the problem by simply using early calibration results if no
high-quality timecounters exist.
PR: 260868
Fixes: 22875f88799e ("x86: Implement deferred TSC calibration")
Reported and tested by: m...@sentex.net, Stefan Hegnauer
Reviewed by:imp, kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33730
sys/x86/x86/tsc.c | 7 +++
1 file changed, 7 insertions(+)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 260910] lldb crash on amd64 with "bt all" in threaded program that generates SIGBUS.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260910 Bug ID: 260910 Summary: lldb crash on amd64 with "bt all" in threaded program that generates SIGBUS. Product: Base System Version: 13.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: free...@monkeyspunk.net lldb asked me to submit this bug report so I am. I am debugging some modifications I'm making to fluent-bit. fluent-bit is a threaded C program. The FreeBSD box is running under KVM (up to date Ubuntu 20.04 host) on workstation hardware with ECC RAM. I've had lldb crash on me a few times now. Below is the latest output from the full run minus the program output. # lldb --arch x86_64 -- /usr/local/bin/fluent-bit -c /usr/local/etc/fluent-bit/fluent-bit.conf -s 4096 (lldb) target create --arch=x86_64 "/usr/local/bin/fluent-bit" Current executable set to '/usr/local/bin/fluent-bit' (x86_64). (lldb) settings set -- target.run-args "-c" "/usr/local/etc/fluent-bit/fluent-bit.conf" "-s" "4096" (lldb) run Process 16204 launching Process 16204 launched: '/usr/local/bin/fluent-bit' (x86_64) fluent-bit output . Process 16204 stopped * thread #2, name = 'fluent-bit', stop reason = signal SIGBUS: hardware error frame #0: 0x000800c28945 libc.so.7`files_servent(retval=0x000801a6e400, mdata=0x000800f92210, ap=0x000801a6e400) at getservent.c:281:26 (lldb) bt all Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. Stack dump: 0. Program arguments: lldb --arch x86_64 -- /usr/local/bin/fluent-bit -c /usr/local/etc/fluent-bit/fluent-bit.conf -s 4096 1. HandleCommand(command = "bt all") 2. HandleCommand(command = "thread backtrace all") #0 0x03ae7aee PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x03ae5fa5 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18 #2 0x03ae8060 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x000804c35e00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 Abort trap -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260884] [zfs] Panic in zfs_onexit_destroy [fix available]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260884 --- Comment #4 from Michael Gmelin --- (In reply to Ed Maste from comment #2) Cherry-picking the change could be done this way: cd $(git rev-parse --show-toplevel) git pull git checkout releng/13.0 git pull git cherry-pick -n -m1 -X theirs -X subtree=sys/contrib/openzfs 9db44a8e git reset HEAD git add sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core.c git add sys/contrib/openzfs/include/sys/zfs_ioctl.h git checkout . git clean -fd git status git diff --staged # inspect changes git commit -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #11 from Bob Frazier --- ran a streaming audio test and several video tests with powerd running (hapd) and event timer alternating (several times) between LAPIC and HPET for comparison. LAPIC: a) streaming audio, heard 'disruptive' glitch after about 5 minutes b) several videos consistently exhibited random audio glitches, some minor, often disruptive (3 separate 'runs' involving multiple videos) c) also observed were an increase in dropped video frames and other anomolies HPET: a) streming audio for 10 minutes, no observed audio glitches. b) approximately same videos played in roughly the same order. Observed very few glitches. The few audio glitches observed were generally minor. c) dropped video frames were significantly less and/or less likely to be noticed. Other observations were that using 'max' for powerd produced fewer glitches, and disabling powerd produced fewer still. I have not yet tested with powerd off and HPET event timer selected. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #10 from Andriy Gapon --- Could you please test if changing sysctl machdep.idle to mwait helps? Alternatively, could you please try to disable CC6 state using this tool https://github.com/meowthink/ZenStates-FreeBSD ? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260805] sysctl: kern.sched.topology_spec shows bogus NUMA domains
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260805 Peter Much changed: What|Removed |Added Flags|maintainer-feedback?(pmc@ci |maintainer-feedback+ |tylink.dinoex.sub.org) | -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260805] sysctl: kern.sched.topology_spec shows bogus NUMA domains
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260805 --- Comment #2 from Peter Much --- @Konstantin I did now. 13/stable appers quite the same, but current (b406897911e) shows this: dev.cpu.19.%domain: 1 dev.cpu.19.%location: handle=\_SB_.SCK0.CP13 _PXM=1 dev.cpu.17.%domain: 1 dev.cpu.17.%location: handle=\_SB_.SCK0.CP12 _PXM=1 dev.cpu.15.%domain: 1 dev.cpu.15.%location: handle=\_SB_.SCK0.CP11 _PXM=1 dev.cpu.13.%domain: 1 dev.cpu.13.%location: handle=\_SB_.SCK0.CP10 _PXM=1 dev.cpu.11.%domain: 1 dev.cpu.11.%location: handle=\_SB_.SCK0.CP0F _PXM=1 dev.cpu.9.%domain: 0 dev.cpu.9.%location: handle=\_SB_.SCK0.CP0E _PXM=0 dev.cpu.7.%domain: 0 dev.cpu.7.%location: handle=\_SB_.SCK0.CP0D _PXM=0 dev.cpu.5.%domain: 0 dev.cpu.5.%location: handle=\_SB_.SCK0.CP0C _PXM=0 dev.cpu.3.%domain: 0 dev.cpu.3.%location: handle=\_SB_.SCK0.CP0B _PXM=0 dev.cpu.1.%domain: 0 dev.cpu.1.%location: handle=\_SB_.SCK0.CP0A _PXM=0 dev.cpu.18.%domain: 1 dev.cpu.18.%location: handle=\_SB_.SCK0.CP09 _PXM=1 dev.cpu.16.%domain: 1 dev.cpu.16.%location: handle=\_SB_.SCK0.CP08 _PXM=1 dev.cpu.14.%domain: 1 dev.cpu.14.%location: handle=\_SB_.SCK0.CP07 _PXM=1 dev.cpu.12.%domain: 1 dev.cpu.12.%location: handle=\_SB_.SCK0.CP06 _PXM=1 dev.cpu.10.%domain: 1 dev.cpu.10.%location: handle=\_SB_.SCK0.CP05 _PXM=1 dev.cpu.8.%domain: 0 dev.cpu.8.%location: handle=\_SB_.SCK0.CP04 _PXM=0 dev.cpu.6.%domain: 0 dev.cpu.6.%location: handle=\_SB_.SCK0.CP03 _PXM=0 dev.cpu.4.%domain: 0 dev.cpu.4.%location: handle=\_SB_.SCK0.CP02 _PXM=0 dev.cpu.2.%domain: 0 dev.cpu.2.%location: handle=\_SB_.SCK0.CP01 _PXM=0 dev.cpu.0.%domain: 0 dev.cpu.0.%location: handle=\_SB_.SCK0.CP00 _PXM=0 I didn't do any further validations, but this looks like fixed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260406] pfctl: Cannot allocate memory (after a time)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406 --- Comment #61 from Diego Linke --- (In reply to Diego Linke from comment #54) Just reporting that today I faced this issue again in another machine, after the upgrade from 12 to 13.0. Yes, this machine also doesn't have a lot of memory but I never faced this issue on 12. I think something changed in either PF or how FreeBSD 13.0 deal with memory allocation. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260406] pfctl: Cannot allocate memory (after a time)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406 --- Comment #60 from Diego Linke --- (In reply to Diego Linke from comment #54) Just reporting that today I faced this issue again in another machine, after the upgrade from 12 to 13.0. Yes, this machine also doesn't have a lot of memory but I never faced this issue on 12. I think something changed in either PF or how FreeBSD 13.0 deal with memory allocation. -- You are receiving this mail because: You are the assignee for the bug.
