The refactoring in r335479 overlooked the fact that the dynamic kenv can
also be switched to if hintmode == 0. This is problematic because the
checkmethod bits are only ever ran once, but it worked previously because
the use_kenv was a global state and the first lookup would enable it if
occurring after the dynamic environment has been setup.
Extending our local definition of use_kenv to include all non-STATIC
hintmodes as long as the dynamic_kenv is setup fixes this. We still have
potential issues if the dynamic kenv comes up while we're doing an anchored
search through the environment, but this is not much of a concern right now
because:
1.) The dynamic environment comes up super early in boot, just after kmem
2.) This is going to get rewritten to provide a safer mechanism for the
anchored searches, ensuring that we continue using the same environment
chain (dynamic env or static fallback) for all anchored search invocations
Reported by: mmamcy
X-MFC-With: r335479
than assigning spigen device names in order of creation, this uses a device
name that corresponds to the owning spibus and chip-select index.
Example: /dev/spigen0.1 would be a child of spibus0, and use cs = 1
The intent is for systems like Raspberry Pi to have a consistent way of
using an SPI interface with a specific cs value from a user application.
Otherwise, there is no consistent way of knowing which cs pin will be
assigned to a particular spigen device. The alternative is to specify
everything in "the right order" in an overlay file, which is less than
ideal. Additionally, this duplicates (to some extent) the way Linux handles
a similar situation with their 'spidev' device, so it would be somewhat
familiar to those who also use Linux.
A new kernel config option, SPIGEN_LEGACY_CDEVNAME, causes the driver to
also create /dev/spigenN device name aliases, with N incrementing in the
order of device instantiation. This is provided to ease the transition
for existing systems using the original naming convention (particularly
when these changes are MFC'd to stable branches).
Differential Revision: https://reviews.freebsd.org/D15301
So that the ptrace code will catch it and report it to attached
debugger. Enables debugging of threaded Linux binaries with FreeBSD
debugger.
Submitted by: Yanko Yankulov <yanko.yankulov@gmail.com>
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D15880
An RFSTOPPED thread can't clean TDB_STOPATFORK, which is done in the
fork_return() in its context, so parent is stuck forever. Triggered
when trying to ptrace linux process. Instead of waiting for the new
thread to clear TDB_STOPATFORK, tag it as traced and reparent to the
debugger in do_fork(), and let it only notify the debugger when run.
Submitted by: Yanko Yankulov <yanko.yankulov@gmail.com>
Reviewed by: jhb
MFC after: 1 week
X-MFC-Note: keep p_dbgwait placeholder intact
Differential revision: https://reviews.freebsd.org/D15857
time through the mbuf chain during copy and TSO limiting.
It is used by both Rack and now the FreeBSD stack.
Sponsored by: Netflix Inc
Differential Revision: https://reviews.freebsd.org/D15937
Post r335356 it is possible to have an inpcb on the hash lists that is
partially torn down. Validate before using. Also as a side effect of this
change the lock ordering issue between hash lock and inpcb no longer exists
allowing some simplification.
Reported by: pho@
Without a call to check_free_callbacks() clients waiting for grant
references would not be woken up even when there are sufficient grant
references available.
The check was likely left out as a mistake when the function was first
added.
Note that other functions used to free grant references already call
check_free_callbacks.
Submitted by: pratyush
Reviewed by: royger
Differential review: https://reviews.freebsd.org/D15899
We always install ELF Tool Chain's elfcopy as objcopy, so to avoid
confusion rename the src directory containing our reach-over Makefile
to match.
Requested by: jhb
Sponsored by: The FreeBSD Foundation
Summary: POWER8 and POWER9 use a single CPU register, per core, to change clock
speed. Everything else is handled by the on-chip controller. This change
necessitates a change to the cpufreq global kernel driver to bump supported
levels, as the device tree for these systems can have theoretically 256
different options. On my POWER9 Talos, the list consists of 100 items. At
16.67MHz intervals, that allows for a change of roughly 1.67GHz between lowest
and highest.
This has only been tested on the POWER9. However, since they're similar, this
should work on POWER8 as well.
Reviewed By: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D15932
Some complexity exists in these bits that isn't needed. The sysctl handler,
upon change to '2', runs through the current set of hints and sets them in
the kenv.
However, this isn't at all necessary if we're pulling hints from the kenv,
static or dynamic, as the former will get added to the latter in
init_dynamic_kenv (see: kern_environment.c). We can reduce this
configuration to just adding static_hints to the kenv if we were previously
using them.
The changes in res_find are minimal and based on the observation that once
use_kenv gets set to '1' it will never be reset to '0', and it gets set to
'1' as soon as we hit fallback mode. Later work will refactor res_find a
little bit and eliminate this now-local, because it's become clear that
there's some funkiness revolving around use_kenv=1 and it being used to
imply that we're certainly looking at the dynamic_kenv.
Reviewed by: ray
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D15940
Using MMCCAM on AllWinner boards is now possible, reaching highest
possible data transfer speed.
For now, MMCCAM doesn't scan cards on boot. This means that scanning
has to be done manually and that it's not possible to mount root FS
from MMC/SD card since there is no block device at the boot time.
For manually scanning the cards, run:
# camcontrol rescan X:0:0
Where X is the bus number (look at camcontrol devlist to determine
bus number assigned to the MMC controller).
Reviewed by: manu
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15891
The new stand/ structure installs loader.conf(5) and defaults/loader.conf
regardless of interpreter. The only thing gating installation now is
MK_BOOT.
Reported by: eadler
VERBOSE_SYSINIT is currently an all-or-nothing option. debug.verbose_sysinit
adds an option to have the code compiled in but quiet by default so that
getting this information from a device in the field doesn't necessarily
require distributing a recompiled kernel.
Its default is VERBOSE_SYSINIT's value as defined in the kernconf. As such,
the default behavior for simply omitting or including this option is
unchanged.
MFC after: 1 week
Many licenses on ar files contained small variations from the standard
FreeBSD license text. To avoid license proliferation switch to the usual
2-clause FreeBSD license after obtaining permission from all copyright
holders.
Approved by: jkoshy, kaiw, kientzle
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14561
This works similar to WITH_SYSTEM_COMPILER added in r300354. It only
supports lld via WITH_LLD_BOOTSTRAP.
When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
will not build in cross-tools. If either check fails though then
libclang is built.
The .info is reworked to notify when libclang will be built since if
either clang or lld needs to be rebuilt, but not the other, the
notification can lead to confusion on why "clang is building".
-fuse-ld= is not used with this method so some combinations of compiler
and linker are expected to fail.
A new 'make test-system-linker' target is added to see the logic results.
Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER. This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it. This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
Reviewed by: emaste (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15894
lld always needs these DWARF sources, as well as other default and extra
tools. XDL seems to be the best fit list.
Remove MK_LLD_IS_LD check from SRCS_MIW which is now reduced to just a
few files for llvm-objdump.
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15915
MK_LLD is for the installed lld while MK_LLD_BOOTSTRAP is for the build
tool. For WITH_SYSTEM_LINKER it is necesarry to separate the logic of
these two. When building libllvm TOOLS_PREFIX will be defined and
MK_LLD_BOOTSTRAP should be checked instead.
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15837
LLD_BOOTSTRAP (build) is independent of LLD_IS_LD (installed) so they
should not be based on each other.
This is related to upcoming WITH_SYSTEM_LINKER work.
Reviewed by: emaste
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15836
This is needed for efifb.
arm and ricv pmap (the two arch with arm64 that uses subr_devmap) have very
different implementation so for now only add this for arm64.
Tested with efifb on Pine64 with a few other patches.
Reviewed by: cognet
Differential Revision: https://reviews.freebsd.org/D15294
The values for tx/rx delays differs accross the different DTS.
Mainline Linux set it to 0x24/0x18
Mostly-Vendor u-boot (the one maintained and developped) to 0x18/0x18
Mostly-Vendor linux (the one maintained and developped) to 0x26/0x11
By experience only 0x18/0x18 works so until the issue is resolved rely on
the bootloader settings.
The property are named {t,r}x_delay and not {t,r}-delay.
The upper bits of the register are a mask of which bits is allowed
to be written, set it otherwise we write nothing.
OF_getencprop returns <0 = for an error.
Pointy Hat: myself
Reported by: jmcneill (delay and mask bits)
Summary: In order to use cpufreq(4), a dev.cpu attachment must be created. If
the IBM property is found denoting SMT, attach only to the first thread setup,
so that a cpufreq device can bind.
Reviewed by: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D15921
to FOREACH_PROC_IN_SYSTEM() to have a single pattern to look for.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D15916
