uart/pci: support 16550A PCI serial devices
Expand the current check to also attach the ns8250 driver to devices
reporting as 16550A. This has been tested to work on a real device.
From an inspection of the code in the ns8250 driver it seems like it should
support up to 16950A devices, but I don't have hardware to ensure that,
hence be conservative with the change.
MFC: 2 weeks
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D56095
uart/pci: always disable MSI for generic devices
The generic device pci_id structure in uart_pci_probe() already has
PCI_NO_MSI appended to it's flags, however that information is not
propagated into uart_pci_attach().
Assume that any device that doesn't match the known IDs is a generic UART
device, and hence prevent the usage of MSIs.
MFC: 2 weeks
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D56097
x86: move the NUM_ISA_IRQS symbol from atpic.c into x86/isa/icu.h
This is not the best location, but works for now.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56003
vm_fault: Avoid creating clean, writeable superpage mappings
The pmap layer requires writeable superpage mappings to be dirty.
Otherwise, during demotion, we may miss a hw update of the PDE which
sets the dirty bit.
When creating a managed superpage mapping without promotion, i.e., with
pmap_enter(psind == 1), we must therefore ensure that a writeable
mapping is created with the dirty bit pre-set. To that end,
vm_fault_soft_fast(), when handling a map entry with write permissions,
checks whether all constituent pages are dirty, and if so, converts the
fault to a write fault, so that pmap_enter() does the right thing. If
one or more pages is not dirty, we simply create a 4K mapping.
vm_fault_populate(), which may also create superpage mappings, did not
do this, and thus could create mappings which violate the invariant
described above. Modify it to instead check whether all constituent
pages are already dirty, and if so, convert the fault to a write fault.
Otherwise the mapping is downgraded to read-only.
[5 lines not shown]
kqueue: Fix a race when adding an fd-based knote to a queue
When registering a new kevent backed by a file descriptor, we first look
up the file description with fget(), then lock the kqueue, then see if a
corresponding knote is already registered. If not, and KN_ADD is
specified, we add the knote to the kqueue.
closefp_impl() interlocks with this process by calling knote_fdclose(),
which locks each kqueue and checks to see if the fd is registered with a
knote. But, if userspace closes an fd while a different thread is
registering it, i.e., after fget() succeeds but before the kqueue is
locked, then we may end up with a mismatch in the knote table, where the
knote kn_fp field points to a different file description than the knote
ident.
Fix the problem by double-checking before registering a knote. Add a
new fget_noref_unlocked() helper for this purpose. It is a clone of
fget_noref(). We could simply use fget_noref(), but I like having an
explicit unlocked variant.
[5 lines not shown]
rtld: properly handle update of several vars in rtld_set_var()
Besides setting the value in the array of the values, rtld sometimes
needs to recalculate some internal control variable for the change to
take effect. Allow the variable description to supply a method called
on the update. Lock the function with the bind lock for safe operation.
Mark several variables as allowed for update, since the on_update method
is provided for them. The list is LD_BIND_NOW, LD_BIND_NOT,
LD_LIBMAP_DISABLE, LD_LOADFLTR.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56055
fenv.h: stop declaring feclearexcept() extern inline
The function is already exported from libm. We only need to stop
declare it extern inline, and instead provide a macro which uses the
internal inline function __feclearexcept_int() instead.
PR: 277958
Reviewed by: dim (x86)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55975
x86: Handle when MPERF/APERF MSRs aren't writable
For performance and/or correct reasons some hypervisors allow
MPERF/APERF MSRs to be read but not written to. This change
modifies the handling of these MSRs to not rely on writes.
This patch is part of Google Cloud Engine (GCE) C4-LSSD turnup.
Sponsored by: Google
Tested by: NetApp (previous)
PR: 292808
MFC after: 3 days
Co-authored-by: Jim Mattson <jmattson at google.com>
Reviewed by: jrtc27, imp, kib, markj, olce, obiwac
Differential Revision: https://reviews.freebsd.org/D55996
x86: Guard clock frequency against a divide by 0
We may be running in a Virtual Machine which may not fully support
hardware performance counters. If the MPERF counter somehow ends up
at zero, return an error and fail gracefully instead of panicking.
This patch is part of Google Cloud Engine (GCE) C4-LSSD turnup.
Sponsored by: Google
Tested by: NetApp (previous)
PR: 292808
MFC after: 3 days
Co-authored-by: Aymeric Wibo <obiwac at google.com>
Co-authored-by: Jim Mattson <jmattson at google.com>
Suggested by: jrtc27 (split out this part)
Reviewed by: imp, obiwac, olce
Differential Revision: https://reviews.freebsd.org/D56056
timerfd: Guard expected performance failure
During the timerfd__periodic_timer_performance test, only expect
failures when the expiration count is less than 400000000. This
prevents the test from being reported as a true failure in environments
where scheduling latency is high enough to delay timerfd wakeups.
Fixes: cb692380f1e0 ("timerfd: Expect periodic timer ...")
MFC after: 1 week
sys: vt_efifb: EFI not supported on i386; move it back to amd64/NOTES
We do not support EFI boot on i386. Thus:
1. Move (back) 'device vt_efifb' from x86/NOTES to amd64/NOTES.
2. Remove 'device vt_efifb' from i386/MINIMAL.
Reported by: jhb
Fixes: f224591746bd ("Add ASMC_DEBUG make option")
Fixes: 67599eef01f5 ("sys/x86/NOTES: Add vt_efifb")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 9c25620e57f01d8227f0d53c6b2134ab37a49fdf)
