- Avoid including sys/proc.h in linux_vdso_gtod.c. It's not needed, but
the implicit inclusion of sys/param.h via sys/ucred.h->bsm/audit.h was
bringing in some required definitions.
- Include a couple of required headers: sys/time.h (for struct bintime),
and limits.h (for INT_MAX).
- Move some helpers from linux.h, which depend on sys/param.h for NODEV,
to the one CU where they're actually used.
No functional change intended.
Reviewed by: imp, kib, emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56982
Without this patch, the maximum setting for
vfs.nfsd.srvmaxio was 1Mbyte. This patch increases
that to 4Mbytes.
The same as for any setting above 128Kbytes, settings up to
4Mbytes require that kern.ipc.maxsockbuf be increased.
(A message generated after setting vfs.nfsd.srvmaxio via
the /etc/rc.conf variable nfs_server_maxio will indicate
the minimum setting, which will be somewhat greater than
four times the setting of vfs.nfsd.srvmaxio.)
Requested by: Cedric Blancher <cedric.blancher@gmail.com>
MFC after: 2 weeks
Fixes: 13d3bd165e ("subr_uio.c: Remove a KASSERT() for large NFS server I/O")
When the NFS server is set to allow an I/O size greater
than 1Mbyte (not allowed in FreeBSD's main yet), a
KASSERT() in allocuio() can fail when:
zfs_freebsd_write()->zfs_write()->zfs_uiocopy()
->cloneuio()->allocuio()
is called for a large NFS server write.
Since the userland API callers to allocuio() already
check that the size does not exceed UIO_MAXIOV,
there does not seem to be a need to a KASSERT()
here.
Removing the KASSERT() allows NFS server writes
of greater than 1Mbyte to work, once the NFS code
is patched to allow them.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57005
Update a couple more cloudware images which I forgot about earlier.
Reviewed by: ziaee
Fixes: 464a351267 ("Cloud releases: Switch to firstboot_pkg_upgrade")
Differential Revision: https://reviews.freebsd.org/D57006
Cloud images are deployed with base system packages. Introduce a
firstboot package auto updater to patch the base system on first boot.
MFC after: 1 hour
MFC to: stable/15
Reviewed by: cperciva
Sponsored by: Google Cloud
Differential Revision: https://reviews.freebsd.org/D56890
Full release notes are available at
https://www.openssh.com/txt/release-10.3
Selected highlights from the release notes:
* ssh(1), sshd(8): remove bug compatibility for implementations
that don't support rekeying. If such an implementation tries to
interoperate with OpenSSH, it will now eventually fail when the
transport needs rekeying.
* ssh(1), sshd(8): support IANA-assigned codepoints for SSH agent
forwarding, as per draft-ietf-sshm-ssh-agent. Support for the new
names is advertised via the EXT_INFO message. If a server offers
support for the new names, then they are used preferentially.
* ssh(1): add a ~I escape option that shows information about the
current SSH connection.
* sshd(8): add 'invaliduser' penalty to PerSourcePenalties, which is
applied to login attempts for usernames that do not match real
accounts. Defaults to 5s to match 'authfail' but allows
administrators to block such attempts for longer if desired.
* Support the ed25519 signature scheme via libcrypto.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56999
This reverts commit 0a19464bf7. It's
incorrect for ahci attachments. Reverting to merge to stable/15
to merge to releng/15.1 for the release.
Sponsored by: Netflix
The amdgpu driver in drm-kmod will attempt to update/reserve certain GPU
VRAM ranges as write-combining. Depending on the system, this address
range may fall outside of FreeBSD's constructed DMAP. We cannot use
pmap_change_attr() in this case.
When INVARIANTS is enabled, this results in the following:
panic: physical address 0x880000000 not covered by the DMAP
Add a guard against triggering the KASSERT in PHYS_TO_DMAP().
This limitation in our implementation of arch_io_reserve_memtype_wc() is
already known in drm-kmod's amdgpu_bo_init(), and errors are ignored
there (see "BSDFIXME"). This change is only to eliminate the preventable
assertion failure within this scheme.
Tested by: kevans
Reviewed by: kib, emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56971
This device is not yet supported.
Unfortunately some recently purchased UB400 dongles also contain this
Realtek IC.
Sponsored by: The FreeBSD Foundation
This depended on header pollution only present when FDT is defined. As
FDT isn't check for in this file we can remove opt_platform.h and
include the correct set of vm header files.
Reported by: ivy
Fixes: 76a2904c35 ("arm64: Add RSI detection for CCA")
Sponsored by: Arm Ltd
Use unmapped bufs for indirect block buffers in bmap, and use sf_bufs
for transient mapping them when we need to read the specific pointer.
[kib note: I changed the original patch to use sf_buf instead of
explicit DMAP utilization, making the change MI].
Tested by: pho
Reviewed by: kib
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D53424
The flag indicates that the modifying ptrace op was issued, and clearing
it after transparent attach is needed to not leak the flag to later
operations, since it is cleared on the syscall enter.
But clearing it there unconditionally is too strong. The clearing
should be only done for attach situation.
Reported by: Alex S <iwtcex@gmail.com>
Fixes: 9997693427
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56928
Reduce bufqueue lock contention by delaying the BUF_UNLOCK to after
dropping the bufqueue lock. Still do the early BUF_UNLOCK if we
actually have to bd_flush.
Reviewed by: kib, markj
Sponsored by: Dell Inc.
Differential Revision: https://reviews.freebsd.org/D56948
Remove libkse as it has been obsolete for many years and drop 1:1 from
description of libthr.
Reviewed by: brooks
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D56850
WITH_CTF enables building userland components with CTF, and not the ctf*
tools as one might expect. The tools are actually included with the
DTRACE knob. Add a comment where the dependency is handled, as this has
caused confusion.
Reported by: ivy
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56977
...as a debugging aid, in order to be able to check that some functions
are effectively called and to identify them quickly if they cause
a hang.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56883
Which revisions to use for the Intel and AMD DSMs is unclear. For the
Intel one, the written specification indicates only 0, but Linux uses
1 (possibly an oversight). For the AMD one, for which there is no
specification, Linux uses 0, but at least on the Framework 13 AMD 7040
series, the "enumerate functions" function only returns a mask that
covers all the functions we expect when called with revision 2.
Introduce an auto-detection strategy where each revision starting from
0 is tried in turn up to some limit (included; default: 15). As soon as
a revision implements all expected functions, we stop the loop and use
that one, in effect selecting the minimum revision that implements all
we need, which should avoid potential backwards-compatibility problems.
If no revision implements all expected functions, the highest available
revision in the checked range is selected, but higher revisions that do
not bring new functions are discarded (see the explanatory comment in
acpi_spmc_probe_dsm()).
The revision policy is still tunable using the same existing sysctl(8)
knobs 'debug.acpi.spmc.intel_dsm_revision' and
'debug.acpi.spmc.amd_dsm_revision'. They have been extended so that
a negative value indicates to use the auto-detection mechanism up to
a revision of minus the value. As before, a 0 or positive value
requests a specific revision. A new knob is introduced for the
Microsoft DSM just in case ('debug.acpi.spmc.ms_dsm_revision').
Since now the revision can be auto-detected, and thus depends on
a particular device instance, move it into 'struct dsm_info' on the
softc. This also enables finishing the split between static and
dynamic/tunable information, allowing to constify all the DSM
descriptors.
Print the revision eventually used along with the supported functions.
Tested on an Intel Framework laptop.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56882
This is in preparation to adding the revision as a probed information.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56880
Examination of the DSDT in a Framework laptop generally hints at
firmware designers sometimes providing ACPI methods for convenience
(e.g., same firmware for multiple models) but not using them (or not
expecting them to be used) depending on tweaks or the actual hardware
platform.
On an Intel Framework laptop, we specifically observe the presence of
a Microsoft DSM that just reports availability of the SLEEP_ENTRY and
SLEEP_EXIT (7 and 8) functions although the Microsoft specification
requires other functions, whose purpose is similar to corresponding
Intel DSM's ones (such as DISPLAY_OFF). However, we currently always
call the latter even on the Microsoft DSM. On that laptop, fortunately,
the way the code is structured in the _DSM method leads to nothing being
executed on this call.
Given the similarity of intent between most functions from the Microsoft
DSM on one side and those of ADM and Intel on the other, it is
imaginable that other firmware developers could use a strategy where
functions are in fact aliased, in which case insisting on calling the
Microsoft's DSM function even if not enumerated would cause the action
to be performed twice (because we also call the corresponding function
on the Intel/AMD DSM), which may or may not cause other problems and in
any case seems a waste.
So, by default, do not try to run any function that is not enumerated,
as that looks like the safest approach. Add a debug sysctl(8) knob to
revert to the previous behavior, just in case
('debug.acpi.spmc.force_call_expected_functions').
acpi_spmc_run() now checks if a DSM/function combination has been
enumerated, and skips the actual call if it does not. This allows to
remove all checks from the acpi_spmc_*_notif() functions, making the
code much more compact.
acpi_spmc_get_constraints() now checks whether
DSM_GET_DEVICE_CONSTRAINTS is supported in order to determine which DSM
to use and whether to call the function at all.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56879
Since we are now keeping in the softc the information about which DSM
functions are available (in supported_functions[]), the 'dsms' field
there is somewhat redundant.
Make it completely redundant by keeping the bit representing the
enumeration function itself in each element of supported_functions[],
and then remove the field.
As a result, convert has_dsm() to rely on supports_function().
Adapt acpi_spmc_dsm_check_functions() so that it does not take into
account the enumeration function bit.
While here, use the self-explanatory stance
IDX_TO_BIT(DSM_ENUM_FUNCTIONS) instead of a hardcoded 1.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56878
This function actually runs a function of a given DSM. Remove the
'_dsm' suffix to remove the inaccuracy and make things simpler.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56877
Do not print by default details of failures that are unlikely to help
a normal user and to have a crucial influence on whether suspension
works correctly. Do so only on a verbose boot or if requested
explicitly by the user via 'debug.acpi.spmc.verbose'.
In particular:
- On an Intel Framework laptop, the Microsoft DSM only reports the
SLEEP_ENTRY and SLEEP_EXIT functions. That makes some sense since,
according to its specification, all functions of a Microsoft DSM
except these two are in fact redundant with Intel DSM's ones (also,
that of AMD DSM's ones). Those functions being missing are only
a potential problem if there is no other DSM than Microsoft's (yet to
be observed in the field).
- The details of malformed/unapplicable constraints or ones with a newer
format the driver does not know about are not readily actionable
pieces of information, but rather debug/developer-oriented ones. When
verbosity is not requested, only print the details of the first such
failure to encourage reporting and at the same time avoid cluttering
the output.
- Detecting and printing unknown DSM functions is not directly
actionable either, and the driver not using these functions may not
prevent suspending (but might, e.g., prevent reaching deeper sleep
states).
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56876
The driver will be more verbose on this knob being non-zero or
'bootverbose' being set. The corresponding variable is typed as an
integer to leave room for expansion. To be used in subsequent commits.
Reviewed by: obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56875
The handle is already held by the softc, which is also passed.
No functional change (intended).
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56818
Support the (so far hypothetical) case of a machine with multiple
instances of the PNP0D80 device (e.g., if multiple DSMs are not
implemented on the same device), by allowing multiple instances of the
device to co-exist.
This is achieved by moving 'supported_functions' from 'struct dsm' into
the softc, so each instance has its own view of which functions are
supported.
Consequently, the check on the instance unit on probe can be removed.
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56817
...in order to indicate to users that power state constraints will not
be checked at all.
Reviewed by: imp, obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56816
In acpi_spmc_get_constraints(), stop assuming that if there is no AMD
DSM, then the Intel one is present. Although this is likely to be the
overwhelming majority of cases on amd64, there is no technical reason
nor constraint in our code that really needs assuming that. On (so far
hypothetical) machines with only the Microsoft DSM, this assumption
would cause a cryptic and irrelevant error message (and, prior to the
previous commit, a panic on INVARIANTS).
Warn the user if both the Intel and AMD DSMs are present, and use the
constraints reported by the Intel one (see the comment for why).
Reviewed by: imp (older version), obiwac
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56813
Mateusz Piotrowski