with python3.8 from Focal triggers those.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25491
AcpiOsMapMemory is used for device memory when e.g. an _INI method wants
to access physical memory, however, aarch64 pmap_mapbios is hardcoded to
writeback. Search for the correct memory type to use in pmap_mapbios.
Submitted by: Greg V <greg_unrelenting.technology>
Differential Revision: https://reviews.freebsd.org/D25201
llvmorg-10.0.1-rc2-0-g77d76b71d7d.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement
MFC after: 3 weeks
Posix says that the interpretation of the locale string is
"implementation-defined", so we ought to document what is
actually recognized.
Also add a cross reference to locale(1).
PR: 247553
MFC after: 1 week
This flag will now show the processor number on which a process is running.
This change was inspired by PR129965. Initially I didn't think that the
patch attached to it was correct -- it sacrificed ki_estcpu use in "cpu"
for ki_lastcpu and I thought that the old functionality should be kept and
the new (cpu#) one added to it. But I've since discovered that ki_estcpu is
sched_4bsd-specific. What's worse, it represents the same thing as
ki_pctcpu, except ki_pctcpu is universal -- so "%cpu" has been using it
successfully. Therefore, I've decided to replace information based on
ki_estcpu with information based on ki_oncpu/ki_lastcpu.
Key parts of the code and manual changes were borrowed from top(1).
PR: 129965
Reported by: Nikola Knežević
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25377
in vanilla Linux git tree.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25385
These implementations of the bc and dc programs offer a number of advantages
compared to the current implementations in the FreeBSD base system:
- They do not depend on external large number functions (i.e. no dependency
on OpenSSL or any other large number library)
- They implements all features found in GNU bc/dc (with the exception of
the forking of sub-processes, which the author of this version considers
as a security issue).
- They are significantly faster than the current code in base (more than
2 orders of magnitude in some of my tests, e.g. for 12345^100000).
- They should be fully compatible with all features and the behavior of the
current implementations in FreeBSD (not formally verified).
- They support POSIX message catalogs and come with localized messages in
Chinese, Dutch, English, French, German, Japanese, Polish, Portugueze,
and Russian.
- They offer very detailed man-pages that provide far more information than
the current ones.
The upstream sources contain a large number of tests, which are not
imported with this commit. They could be integrated into our test
framework at a latter time.
Installation of this version is controlled by the option "MK_GH_BC=yes".
This option will be set to yes by default in 13-CURRENT, but will be off
by default in 12-STABLE.
Approved by: imp
Obtained from: https://git.yzena.com/gavin/bc
MFC after: 4 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19982
* bugpoint.1
* clang.1
* llc.1
* lldb.1
* lli.1
* llvm-ar.1
* llvm-as.1
* llvm-bcanalyzer.1
* llvm-cov.1
* llvm-diff.1
* llvm-dis.1
* llvm-dwarfdump.1
* llvm-extract.1
* llvm-link.1
* llvm-mca.1
* llvm-nm.1
* llvm-pdbutil.1
* llvm-profdata.1
* llvm-symbolizer.1
* llvm-tblgen.1
* opt.1
Add newly generated manpages for:
* llvm-addr2line.1 (this is an alias of llvm-symbolizer)
* llvm-cxxfilt.1
* llvm-objcopy.1
* llvm-ranlib.1 (this is an alias of llvm-ar)
Note that llvm-objdump.1 is an exception, as upstream has both a plain
.1 file, and a .rst variant. These will have to be reconciled upstream
first.
MFC after: 3 days
-d and -v are not equivalent options. The former is more verbose than the
latter and the former does not actually send the signals while the latter does.
Let them have their own paragraphs.
From the point of view of the output, -v is equivalent to -s, so describe them
close to each other. The difference is that former actually sends the signals
and the latter doesn't.
PR: 247411
Approved by: manpages(0mp)
Differential Revision: https://reviews.freebsd.org/D25413
This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
match keycache slots (they're "global" keys), but it could be useful
for tracking down CCMP decryption failures.
Right now it's a no-op - it mirrors what the AR9300 HAL does and it
just increments a counter. But, hey, maybe one day I'll use it for
diagnosing keycache/CCMP decrypt issues.
but in System III in the AT&T world.
Examination of the TUHS archives shows this was present in 4.3-Reno
and System III.
Reviewed by: 0mp@, allanjude@
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D25479
The vdev_init() does check for "known" vdev types, the [log] device removal will create "hole"
device, but vdev_init() does not allow it.
Obtained from: illumos
MFC after: 1 week
The only thing this tunable enables now is reporting to ACPI _OSC that
Active State Power Management and Clock Power Management Capability are
"supported" by the OS.
I've found that at least some Supermicro server boards do not allow OS
to support native PCIe hot-plug unless it reports those capabilities.
After spending significant time in PCIe specs I have found very little
motivation for that, and none of it applies to those motherboards, not
enabling ASPM themselves. So unless OS explicitly wants to save power,
I see nothing for it to do there actually.
I guess it may get sense to support ASPM when we get Thunderbolt support.
Otherwise I have no system with PCIe hot-plug where power saving matters.
It would be nice to enable this by default, but I worry that it affect
power saving of some laptops, even though I haven't noticed that myself.
Switch to the simplified while loop suggest by Aaron LI
Post commit review via: https://reviews.freebsd.org/rS301185#inline-232
Submitted by: Aaron LI <aly@aaronly.me>
Sponsored by: Klara Inc.
If the interfaces on which wpa_supplicant is to run are not known or do
not exist, wpa_supplicant can match an interface when it arrives. Each
matched interface is separated with -M argument and the -i argument now
allows for pattern matching.
As an example, the following command would start wpa_supplicant for a
specific wired interface called lan0, any interface starting with wlan
and lastly any other interface. Each match has its own configuration
file, and for the wired interface a specific driver has also been given.
wpa_supplicant \
-M -c wpa_wired.conf -ilan0 -D wired \
-M -c wpa1.conf -iwlan* \
-M -c wpa2.conf
PR: 247177
Reported by: greg@unrelenting.technology
MFC after: 1 month
Related to: ports r540412
Not all interrupt sources that affect CIS bit were acknowledged.
Specifically, bits in STATESTS (aka WAKESTS) were left set.
The fix is to disable WAKEEN and clear STATESTS bits before the HDA
interrupt is enabled. This way we should never get any STATESTS bits.
I also added placeholders for all event bits that we currently do not
enable, do not handle and do not clear. This might get useful when / if
we enable any of them.
Reported by: kib (Apollo Lake hardware)
Tested by: kib (earlier, different change)
MFC after: 2 weeks
X-MFC with: r362294
The TRB processing loop could potentially call a back-end twice
with the same status transaction. While this was generally benign,
some code paths in the tablet backend weren't set up to handle
this case, resulting in a NULL dereference.
Fix by
- returning a STALL error when an invalid request was seen in the backend
- skipping a call to the backend if the number of packets in a status
transaction was zero (this code fragment was taken from the Intel ACRN
xhci backend)
PR: 246964
Reported by: Ali Abdallah
Discussed with: Leon Dang (author)
Reviewed by: jhb (#bhyve), Leon Dang
Approved by: jhb
Obtained from: Intel ACRN (partially)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25228
