https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #34 from Andriy Gapon ---
(In reply to stockhausen from comment #32)
1. Ah, you are right, I forgot that modern processors intercept C-state I/O
accesses at a core level.
Just to clarify, I assume that on your T620 cpucontrol -m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #35 from stockhau...@collogia.de ---
Phew, I see you found the culprit. Although I do not know every single function
I saw a lot of the names during my code analysis.
Regarding HP T620 settings: cpucontrol -m 0xC0010073 /dev/cpu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236853
Bug ID: 236853
Summary: panic: page fault on rtsock.c
Product: Base System
Version: CURRENT
Hardware: i386
OS: Any
Status: New
Severity: Affects Ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846
--- Comment #1 from Viktor Dukhovni ---
I switched to the 12.0-STABLE kernel, but still essentially the same panic:
panic: vm_fault_hold: fault on nofault entry, addr: 0xfe0075df2000
cpuid = 6
time = 1553772208
KDB: stack backtrace:
#0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236854
Bug ID: 236854
Summary: kernel exception at boot time
Product: Base System
Version: 11.2-RELEASE
Hardware: arm64
OS: Any
Status: New
Severity: Affec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #36 from John Baldwin ---
It may be that we need to fix the RF_SHAREABLE to propagate up when the
resource is first allocated by resource_list_reserve, etc. That might fix this
without requiring the BIOS to be patched. I haven
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #37 from John Baldwin ---
Created attachment 203218
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203218&action=edit
shareable_acpi_set_resource.patch
This is an untested hack that uses RF_SHAREABLE when reserving r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211771
Jeremy Shinall changed:
What|Removed |Added
CC||jeremyshin...@icloud.com
--- Comm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846
--- Comment #2 from Viktor Dukhovni ---
With fantastic help from Mark Johnston, the issue has been plausibly narrowed
down to the new epoch_tracker code in 12.0 not handling IPv6 via stf0 robustly.
The crash dump with "option INVARIANTS" l
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846
Viktor Dukhovni changed:
What|Removed |Added
Summary|FreeBSD 12.0-STABLE-p3 |FreeBSD 12.0-STABLE-p3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230876
Conrad Meyer changed:
What|Removed |Added
Assignee|b...@freebsd.org|c...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230875
Conrad Meyer changed:
What|Removed |Added
Assignee|b...@freebsd.org|c...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864
Bug ID: 236864
Summary: sys/netpfil/pf/ioctl/validation:addtables triggered a
GPF panic
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477
and...@tao11.riddles.org.uk changed:
What|Removed |Added
CC||and...@tao11.riddles.o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864
--- Comment #1 from Li-Wen Hsu ---
hmm, the commit r345660 doesn't seem to be related to this test, and the next
run this case passed. We need to find a reliable way to reproduce this panic.
--
You are receiving this mail because:
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870
Bug ID: 236870
Summary: libarchive directory traversal gives spurious
permission errors
Product: Base System
Version: 12.0-STABLE
Hardware: Any
OS: An
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870
--- Comment #1 from and...@tao11.riddles.org.uk ---
Sorry, this fix isn't quite complete; there are still error cases with
archiving "foo/bar/." where "foo" is not readable. Will post another fix
shortly.
--
You are receiving this mail bec
17 matches
Mail list logo
