[Bug 283815] listing dev.vgapci.X.%iommu hangs indefinitely on NVIDIA card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283815 --- Comment #8 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6ba2c036a0117ac02f9979b7dc49f15e9c1ea9c9 commit 6ba2c036a0117ac02f9979b7dc49f15e9c1ea9c9 Author: Konstantin Belousov AuthorDate: 2025-01-06 23:29:18 + Commit: Konstantin Belousov CommitDate: 2025-01-07 15:34:59 + pci_find_cap_method(): limit number of iterations for finding a capability Powered down device might return 0xff of extended config registers reads, causing loop. PR: 283815 Reviewed by:imp Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D48348 sys/dev/pci/pci.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283815] listing dev.vgapci.X.%iommu hangs indefinitely on NVIDIA card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283815 Ed Maste changed: What|Removed |Added Assignee|b...@freebsd.org|k...@freebsd.org Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 190787] OCZ-AGILITY3 SSD Not Detected
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190787 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #7 from Ed Maste --- Is this issue still reproducible on supported versions, and/or has this hardware been retired? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283747] kernel panic after telegraf service restart
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747 --- Comment #4 from Matthew L. Dailey --- I just had this happen this morning on two machines running 14.2-RELEASE. In both cases, I had used pkg to upgrade telegraf from 1.32.3 to 1.33.0. After restarting telegraf, both panicked. Unfortunately, I didn't have dumps set up properly on either system, but I did manage to catch a screenshot of the panic on one system. It was a "Fatal trap 12: page fault while in kernel mode" I'm attaching the screenshot and our telegraf config. I was unable to replicate this on a VM that had been up for about the same about of time (~30 days). The only difference I can see if that the VM has no user traffic, while the others have significant nfs and smb traffic. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283747] kernel panic after telegraf service restart
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747 --- Comment #5 from Matthew L. Dailey --- Created attachment 256501 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256501&action=edit Screenshot of panic -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283747] kernel panic after telegraf service restart
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747 --- Comment #6 from Matthew L. Dailey --- Created attachment 256502 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256502&action=edit Telegraf config -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283747] kernel panic after telegraf service restart
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747 --- Comment #7 from Matthew L. Dailey --- I should also add that the two machines that panicked for us this morning were both Intel, not AMD - Xeon Gold 5215 and Xeon E5-2650v3 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275086] Old i386 boot: CPU0: local APIC error 0x4 – Cannot boot any longer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275086
--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=254a2b767f9a39f1541e0a07a70bbe269e86ad70
commit 254a2b767f9a39f1541e0a07a70bbe269e86ad70
Author: Mark Johnston
AuthorDate: 2025-01-07 17:58:58 +
Commit: Mark Johnston
CommitDate: 2025-01-07 18:13:54 +
x86: Short-circuit ipi_all_but_self() on UP systems
Apparently this is required on old intel hw, see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275086#c3
PR: 275086
Reviewed by:mav, kib
Fixes: 279cd05b7e4d ("Use APIC_IPI_DEST_OTHERS for bitmapped IPIs
too.")
MFC after: 1 week
Diagnosed by: Ben Wilber
Differential Revision: https://reviews.freebsd.org/D48361
sys/x86/x86/mp_x86.c | 3 +++
1 file changed, 3 insertions(+)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 275086] Old i386 boot: CPU0: local APIC error 0x4 – Cannot boot any longer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275086 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|ma...@freebsd.org CC||ma...@freebsd.org Status|Closed |In Progress Resolution|Works As Intended |--- --- Comment #6 from Mark Johnston --- Reopening since it's a legitimate bug. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275086] Old i386 boot: CPU0: local APIC error 0x4 – Cannot boot any longer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275086 --- Comment #5 from Mark Johnston --- (In reply to ben from comment #3) Thanks for the analysis. I committed a modified version of the patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 173301] bsdinstall(8): default to SU instead of SU+J
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173301
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #4 from Ed Maste ---
I've suggested removing the advice to disable SU+J on SSDs in
https://reviews.freebsd.org/D48374, with the following justification:
The advice to turn off SU+J for SSDs came in with the original commit
50de5d07d3c5 ("Allow setting of parameters for file systems (e.g.
softupdates), turn on") without justification. I suspect this was based
on some decades-old impression about the way SSDs operate combined with
early concerns about the state of SU+J, neither of which are applicable
any longer.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283909] bsnmpget/walk: coredump when SNMPPASSWD is empty
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283909 Bug ID: 283909 Summary: bsnmpget/walk: coredump when SNMPPASSWD is empty 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: tphil...@potion-studios.com To repro, with a running bsnmpd listening on default port, not the empty password env var: $ env SNMPUSER=bsnmp SNMPPRIV=aes SNMPAUTH=sha SNMPPASSWD= bsnmpget 1 Floating point exception (core dumped) $ ls bsnmpget.core bsnmpget.core Same for bsnmpwalk -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283815] listing dev.vgapci.X.%iommu hangs indefinitely on NVIDIA card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283815 --- Comment #7 from Anton Saietskii --- (In reply to Konstantin Belousov from comment #6) Thanks for prompt response. I can confirm that with the patch applied, getting OID in question doesn't hang anymore -- I can see 'dev.vgapci.0.%iommu: rid=0x100' both before and after powering down NVIDIA. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283818] too-large rtmsg.rtm_family for RTM_GETADDR can cause wild pointer ref
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283818 --- Comment #1 from Zhenlei Huang --- I think we should do sanity check within `rtnl_handle_getroute()`. Meanwhile we can give netlink client a meaningful error message. -- You are receiving this mail because: You are the assignee for the bug.
