This fixes userspace RDMA applications that would fail due to mmap
failure. The driver's mmap routine would succeed but later the
linux_compat.c mmap routine would fail because vma->vm_private_data
wasn't set properly.
This is catch-up with b633e08c70.
Reported by: Veeresh @ Chelsio
Sponsored by: Chelsio Communications
Add cap_lo and cap_hi sysctl to each nvme drive. This publishes the raw
capabilities of the drive. Now we can only discover these with
bootverbose.
Sponsored by: Netflix
Setting MPS in the CC should be a power of 2 number (it specifies the
page size of the host is 2^(12+MPS)), so adjust the calcuation. There is
no functional change because we do not support any architecutres != 4k
pages (yet). Other changes are needed for architectures with 16k or 64k
pages, especially when the underlying NVMe drive doesn't support that
page size (Most drives support a range that's small, and many only
support 4k), but let's at least do this calculation correctly. 12 - 12
is just as much 0 as 4096 >> 13 is :)
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D34707
FreeBSD detects serial ports twice: First, very early in the boot
process, in order to obtain a usable console; and second, during
the device probe/attach process. When a UART is discovered during
device probing, FreeBSD attempts to determine whether it is a
device which was already being used as a console; without this,
the console doesn't work in userland.
Unfortunately it's possible for a UART to be mapped to a different
location in memory when it is discovered on a bus than it has when
it is announced via the ACPI SPCR table; this breaks the matching
process, which relies on comparing bus addresses.
To address this, we introduce a concept of "unique" serial devices,
i.e. devices which are guaranteed to be present *only once* on any
system. If we discover one of these during device probing, we can
match it to a same-PCI-vendor-and-device-numbers console which was
announced via the ACPI SPCR table, regardless of the differing bus
addresses.
At present, the only unique serial device is the "Amazon PCI serial
device" (vendor 0x1d0f, device 0x8250) found in some EC2 instances.
This unbreaks the serial console on those systems.
Reviewed by: imp
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D34703
stge_attach() could fail at line 464, sc->sc_spec remains NULL when
calling stge_detach(), thus bus_release_resources() at line 704 will
trigger null pointer dereference. We need to check the nulliness before
calling bus_release_resources().
PR: 258420
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34629
Diff reduction between mpr and mps.
Fixes: e2997a03b7 ("Diagnostic buffer fixes for the mps(4)...")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
In vmbus_pcib_prepopulate_bars(), after writing all 1's to the
avialable device bars, those without being configured by device driver
are also set to its initialized values. However, this could cause
weird problem which results to device failure. The issue has been
reported to happen on LSI 9211-8i HBA card for DDA access on Hyper-V.
Writing back the orignal BAR values seem to work around this problem.
Reported by: Alexander Motin <mavbsd@gmail.com>
Tested by: Mathias Kraut <krautmaster@gmail.com>
Fixes: 75412a521f Hyper-V: vPCI: Prepopulate device bars
MFC after: 1 month
*_CFG_PAGE ioctl handlers in the mpr, mps, and mpt drivers allocated a
buffer of a caller-specified size, but copied to it a fixed size header.
Add checks that the size is at least the required minimum.
Note that the device nodes are owned by root:operator with 0640
permissions so the ioctls are not available to unprivileged users.
This change includes suggestions from scottl, markj and mav.
Two of the mpt cases were reported by Lucas Leong (@_wmliang_) of
Trend Micro Zero Day Initiative; scottl reported the third case in mpt.
Same issue found in mpr and mps after discussion with imp.
Reported by: Lucas Leong (@_wmliang_), Trend Micro Zero Day Initiative
Reviewed by: imp, mav
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34692
Some new AMD systems provide a HPET MMIO region smaller than the 1KB
specified, and a correspondingly small number of timers. Handle this in
the HPET driver rather than requiring a 1KB window. This allows the
HPET driver to attach on such systems.
PR: 262638
Reviewed by: markj
MFC after: 1 month
The firmware doesn't report FORCE_FEC in pcaps if the transceiver
plugged in at that time does not support a speed that may use FEC. It
is incorrect for the driver to assume that the FORCE_FEC value it read
during attach (in init_link_config) is permanent. Instead, it should
check pcaps just before issuing the L1CFG command.
MFC after: 1 week
Sponsored by: Chelsio Communications
The keyboard driver was initially protected via spl* interrupt priority
calls but (as part of a comprehensive effort) migrated to use the Giant
lock (mutex).
The spl calls left behind became NOPs but they can be confusing as they
have no bearing on the actual mutual exclusion that is now present.
Remove them from kbd and add assertions that Giant is held. markj notes
that there is conflation between the "bus topo" lock (which is Giant
under the hood) and Giant. The assertions could either be addressed as
a small item along with bus topology locking work or they'll be removed
if kbd is decoupled from Giant.
PR: 206680
Reviewed by: markj
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34645
PCM_REGISTERED(d) tests that d is not NULL, so perform that check first
as we may have cases where devclass_get_softc has a null entry.
PR: 262671
Reviewed by: hselasky
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34648
This has been safe since e9e7bc8250, which moved parts of error
handling from the ithread to a taskqueue.
MFC after: 1 week
Sponsored by: Chelsio Communications
