Follow up on D43768 to properly deal with the non-default
pipe calculation. When CC_RTO is processed, the timeout
will have already pulled back snd_nxt. Further, snd_fack
is not pulled along with snd_una.
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43876
gcc 12 defaults to emitting DWARF 5, but this is not yet supported by
our libdwarf and thus by ctfconvert.
Reviewed by: emaste, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43837
Reapply 4cea05a273:
Make sh(1) recognize the default $HOME. By default /home
is a symlink; without this change, when you log in, sh(1)
won't realize the current directory (eg '/usr/home/test')
is the same as $HOME ('/home/test').
/home is no longer a symlink by default, but new users may be added on
systems that started out with an earlier version of FreeBSD (and still
have /home as a symlink) or admins may do so.
This test is not particularly expensive, so just restore it.
Suggested by: danfe, brooks
dlopen_basic just tests that libthr.so can be dlopen()ed, which will
just serve as a sanity check that "libthr.so" is a thing that can be
dlopened in case we get a weird failure in dlopen_recursing.
dlopen_recursing tests a regression reported after the libsys split,
where some dlopen() may cause infinite recursion and a resulting crash.
This case is inspired by bdrewery's description of what seemed to be
causing his issue.
The corresponding fix landed in commit
968a18975a ("rtld: ignore load_filtees() calls if we already [...]")
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43859
in addition to avoiding it for already loaded filtees. Issue is that
during load, rtld needs to resolve some special ABI symbols, like
executable stack fixer and static TLS initializer, which might trigger
recursion.
Example is libthr which is filter for libsys, and which exports
__pthread_distribute_static_tls.
Tested by: kevans, krion
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D43858
While we only support 4-byte registers in the uart code the physical
access may be to an 8-byte register. Support this as an option on
non-i386. On i386 we lack the needed 8-byte bus_space functions.
ACPI has an option for 8-byte register io width, and FDT can be given
any size. Support these sizes, even if we don't expect to see hardware
with an 8-byte io width.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43374
Add the pl011 uart to the list of supported uarts for use by
hw.uart.console. This is commonly found in Arm based devices, and a
variant is standardised in the Arm SBSA.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43363
Some uarts require a specific register width. Support setting this in
the kernel environment.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43362
When the uart is configured via the environment we need to find the
uart class with a specified name. Currently to do this with an
incomplete list of uarts. As we may not have included all uarts in the
kernel each class is defined as weak.
Switch to a linker set so the list is always up to date based on what
is included in the kernel, and the class can be static.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43361
Support selecting the early uart with "options EARLY_PRINTF=foo" in
the kernel configuration file. This allows us to not have to change
source files when enabling EARLY_PRINTF, simplifying enabling it.
New uart drivers can be enabled by defining a new early_printf_foo
value to be unique, then using "#if CHECK_EARLY_PRINTF(foo)" to decide
when to enable the uart.
While here add pl011 early printf support.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43360
Support socdev_va on arm and ensure the variable is available on arm64.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43359
Fixing the error messages when detaching the mana gdma devices
showed in dmesg: "Device leaked memory resources".
Reported by: NetApp
MFC after: 3 days
Sponsored by: Microsoft