[Bug 236513] Different power states (C1/C2/...) per CPU core

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #4 from stockhau...@collogia.de --- Speculative question in advance. If this situation does not change in 12.0: Might it be that the system only supports C2 state for the whole CPU package? And if yes: Shouldn't this be reflect

[Bug 236513] Different power states (C1/C2/...) per CPU core

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #3 from stockhau...@collogia.de --- Thanks for the quick response. I'll give 12.0 a try and give feedback asap. -- You are receiving this mail because: You are the assignee for the bug. _

[Bug 236513] Different power states (C1/C2/...) per CPU core

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #2 from Conrad Meyer --- (In reply to Conrad Meyer from comment #1) > I don't know if r326956 has been MFCed to 11.x FWIW, that change is not present in 11.x, but is in 12.0. Please try running 12.0, if possible. -- You are

[Bug 236513] Different power states (C1/C2/...) per CPU core

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #1 from Conrad Meyer --- This is a Jaguar-class (Family 16h) AMD CPU. This information is probed automatically out of the ACPI information presented by your BIOS. That code hasn't changed appreciably in 4 years. It seems your

[Bug 236513] Different power states (C1/C2/...) per CPU core

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 Bug ID: 236513 Summary: Different power states (C1/C2/...) per CPU core Product: Base System Version: 11.2-STABLE Hardware: amd64 OS: Any Status: New

[Bug 231923] [pci] AMD Ryzen X370 chipset PCIe bridge failed to allocate initial memory window

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231923 --- Comment #2 from Greg V --- Looks like hw.pci.enable_io_modes=0 fixes this. (Was discovered when installing an RX Vega GPU — that was actually panicking with "next resource mismatch", so I went to fiddle with pci tunables.) So this mig

[Bug 236510] ZFS ARC usage causes mlock(2) to fail with EAGAIN

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236510 --- Comment #2 from mar...@lispworks.com --- Thanks, I was not aware of this pending review. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org

[Bug 236510] ZFS ARC usage causes mlock(2) to fail with EAGAIN

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236510 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #1 f

[Bug 236510] ZFS ARC usage causes mlock(2) to fail with EAGAIN

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236510 Bug ID: 236510 Summary: ZFS ARC usage causes mlock(2) to fail with EAGAIN Product: Base System Version: 11.2-RELEASE Hardware: Any OS: Any Status: New

[Bug 224270] Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 Dave Cottlehuber changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1

[Bug 232544] general protection fault while in kernel mode - vdev_indirect

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232544 --- Comment #3 from Jeremy Faulkner --- After deleting snapshots the removed device remapping data was reduced to 4MB so the manipulation of the remapping data my be tied to the crash. doas tar zcvf vdev_indirect_mapping-panic.tar.gz /var/