I'm trying to debug why reception upstairs here is so terrible and it
turns out ANI is buggy. (Which is no surprise, ANI is always buggy.)
Tested:
* Carambola2 (AR9331), STA/AP modes
- Fix data frames transmission via POWER_STATUS register setup -
it seems to be set by MACID_CONFIG firmware command, which was broken*
in r290439 and later disabled in r307529.
We can re-enable it later if / when firmware rate adaptation will be
ready; however, this step will be required anyway - for firmware-less
builds.
- Force RTS / CTS protection frame rate to CCK1 (this rate works fine
without any additional setup; no better workaround is known yet).
The problem was not observed on the channel 1 or with CCK1 rate enforced
('ifconfig wlan0 ucastrate 1' for 11 b/g; not possible for 11n networks
due to ifconfig(8) bug).
* I'm not sure if it works before r290439 because - AFAIR - I never seen
firmware rate adaptation working for 10-STABLE urtwn(4)
(It needs EN_BCN bit set and RSSI updates at least).
Tested with RTL8188CUS in STA mode
(in regular mode and with disabled MRR - DARFRC*8 is set to 0)
PR: 233949
MFC after: 2 weeks
Since in most configurations CTL serves as network service, we found
that this change improves local system interactivity under heavy load.
Priority of main threads is set slightly higher then worker taskqueues
to make them quickly sort incoming requests not creating bottlenecks,
while plenty of worker taskqueues should be less sensitive to latency.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
to call soabort() on a newborn socket created by sonewconn() in case
if further setup of PCB failed. Code in sofree() handles such socket
correctly.
Submitted by: jtl, rrs
MFC after: 3 weeks
FDT data. The sector size must be a multiple of the device's page size.
If not configured, use the historical default of the device page size.
Setting the disk sector size to 512 or 4096 allows a variety of standard
filesystems to be used on the device. Of course you wouldn't want to be
writing frequently to a SPI flash chip like it was a disk drive, but for
data that gets written once (or rarely) and read often, using a standard
filesystem is a nice convenient thing.
some #define'd names to be more descriptive. When reporting a post-write
compare failure, report the page number, not the byte address of the page.
The latter is the only functional change, it makes the number match the
words of the error message.
This is especially important for writes. SPI is inherently a bidirectional
bus; you receive data (even if it's garbage) while writing. We should not
receive that data into the same buffer we're writing to the device.
When reading it doesn't matter what we send to the device, but using the
dummy buffer for that as well is pleasingly symmetrical.
On very large powerpc64 systems (2x22x4 power9) it's very easy to run out of
available IRQs and crash the system at boot. Scale the count by mp_ncpus,
similar to x86, so this doesn't happen. Further work can be done in the future
to scale the I/O IRQs as well, but that's left for the future.
Submitted by: mmacy
MFC after: 3 weeks
When a vCPU is HLTed, interrupts with a priority below the processor
priority (PPR) should not resume the vCPU while interrupts at or above
the PPR should. With posted interrupts, bhyve maintains a bitmap of
pending interrupts in PIR descriptor along with a single 'pending'
bit. This bit is checked by a CPU running in guest mode at various
places to determine if it should be checked. In addition, another CPU
can force a CPU in guest mode to check for pending interrupts by
sending an IPI to a special IDT vector reserved for this purpose.
bhyve had a bug in that it would only notify a guest vCPU of an
interrupt (e.g. by sending the special IPI or by resuming it if it was
idle due to HLT) if an interrupt arrived that was higher priority than
PPR and no interrupts were currently pending. This assumed that if
the 'pending' bit was set, any needed notification was already in
progress. However, if the first interrupt sent to a HLTed vCPU was
lower priority than PPR and the second was higher than PPR, the first
interrupt would set 'pending' but not notify the vCPU, and the second
interrupt would not notify the vCPU because 'pending' was already set.
To fix this, track the priority of pending interrupts in a separate
per-vCPU bitmask and notify a vCPU anytime an interrupt arrives that
is above PPR and higher than any previously-received interrupt.
This was found and debugged in the bhyve port to SmartOS maintained by
Joyent. Relevant SmartOS bugs with more background:
https://smartos.org/bugview/OS-6829https://smartos.org/bugview/OS-6930https://smartos.org/bugview/OS-7354
Submitted by: Patrick Mooney <pmooney@pfmooney.com>
Reviewed by: tychon, rgrimes
Obtained from: SmartOS / Joyent
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19299
As a step towards adding other potential streaming ciphers. As well as just
pushing the loop down into the rijndael APIs (basically 128-bit wide AES-ICM
mode) to eliminate some excess explicit_bzero().
No functional change intended.
Reviewed by: delphij, markm
Approved by: secteam (delphij)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D19411
level socket option SCTP_GET_LOCAL_ADDRESSES in a getsockopt() call.
Thanks to Thomas Barabosch for reporting the issue which was found by
running syzkaller.
MFC after: 3 days
In all of the architectures we have today, we always use PAGE_SIZE.
While in theory one could define different things, none of the
current architectures do, even the ones that have transitioned from
32-bit to 64-bit like i386 and arm. Some ancient mips binaries on
other systems used 8k instead of 4k, but we don't support running
those and likely never will due to their age and obscurity.
Reviewed by: imp (who also contributed the commit message)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D19280
When porting code once written for Linux we find not only uints but also ushort and ulong.
Provide central typedefs as part of the linuxkpi for those as well.
Reviewed by: hselasky, emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19405
The plls frequency are now correctly calculated in fractional mode
and integer mode.
While here add some debug printfs (disabled by default)
Tested with powerd on the little cluster on a RockPro64.
MFC after: 1 week
We mistakenly used the extoff value from the last packet to patch the
next_header field. If a malicious host sends a chain of fragmented packets
where the first packet and the final packet have different lengths or number of
extension headers we'd patch the next_header at the wrong offset.
This can potentially lead to panics or rule bypasses.
Security: CVE-2019-5597
Obtained from: OpenBSD
Reported by: Corentin Bayet, Nicolas Collignon, Luca Moro at Synacktiv
Firmware needed by petitboot, for example, GPU firmware, can be installed to
a partition in the flash filesystem. This driver exposes the full flash
given by the device tree, letting the user manage firmware, etc, from
FreeBSD.
To use the partitions provided by the flash module, the fdt_slicer module is
needed, but the module isn't needed for raw access, so there's no direct
dependency link in here.
MFC after: 2 weeks
For some reason this seems to be required on aarch64, but I can build armv7
from clean without needing this in the list. (The file does get included,
so the mystery is why armv7 works.)
The OPAL firmware only supports a finite number of in-flight asynchronous
operations. Rather than have each subsystem try to manage its own, use a
central management service to hand out tokens.
More work can be done to improve asynchronous behavior, such as funneling
things through a future OPAL heartbeat handler, but capabilities will be
added as needed.
Augment the existing consumers (i2c and sensors) to use this new API.
MFC after: 4 weeks
SGE_QSETS is an upper bound -- fewer qsets may be allocated depending on
the number of CPUs.
Reviewed by: markj, np, vangyzen
X-MFC-With: r333288
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D17274
When the device is in attaching state, detach should return
EBUSY instead of success. In other case, there could be race
between attach and detach during the driver unloading.
If driver goes sleep and releases GIANT lock during attaching,
unloading module could start. In such case when attach continues
after module unload, page fault "supervisor read instruction,
page not present" occurred.
This patch works around the real issue, which is a locking
deficiency of the busses.
Submitted by: Rafal Kozik <rk@semihalf.com>
Reviewed by: imp
Obtained from: Semihalf
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D19375
geom_flashmap depends on a slicer being available in order to do any
work. On fdt platforms this is provided by fdt_slicer, but this needs
to be available. Often it's compiled into the kernel for platforms that
boot from the relevant media, but this is not always the case. Add the
file to the geom_flashmap module so that it can be used on platforms
which don't always need this functionality available.
Specifically, ccr(4) devices are also children of cxgbe nexus devices.
Rather than making assumptions about the child device's softc, walk
the list of ports from the nexus' softc to determine if a child is a
port in t4_child_location_str(). This fixes a panic when detaching a
ccr device.
Reviewed by: np
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D19399
They have no effect, as with filesystem file descriptors.
This improves compatibility with some existing userspace code.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19330
This was actually the known good configuration we used before.
Single MSI-X configuration doesn't even work there on my tests, just due
to lack of documentation not sure whether by design or I am doing something
wrong.
PR: 233654
MFC after: 1 week
not supported.
According to SDM rev. 69 vol. 3, for PDPTE registers loads:
- when PAT is not supported, access to the PDPTE page is performed as
UC, see 4.9.1;
- when PAT is supported, the access is WB, see 4.9.2.
So potentially CPU might load stale memory as PDPTEs if both PAT and
self-snoop are not implemented. To be safe, add total local cache
flush to pmap_cold() before initial load of cr3, and flush PDPTE page
in pmap_pinit(), if PAT is not implemented.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19365
@cem removed references to pdwait4(2) (a nonexistent syscall) in
r320058.
This change removes references to pdwait4(2) and `CAP_PDWAIT` in
rights(4) to not mislead the user into thinking that pdwait4(2)/`CAP_PDWAIT` is
actually implemented in the stock FreeBSD kernel.
The goal of this functionality was to simplify monitoring/manipulating
processes started with `pdfork`, et al, and avoid races with waiting on pids.
The syscall was never completed though--just discussed on the capsicum mailing
list back in 2015:
https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2015-May/msg00012.html
. That being said, there are members of the project (@rwatson, etc) who
have longterm goals to implement this syscall to better secure pdfork(2)
calls.
PR: 235871
Reviewed by: emaste
Discussed with: rwatson
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18950
These are 4Gb/s and pretty old and slow now, so I see no reason to fight
for their performance over stability.
PR: 233654
MFC after: 1 week
Sponsored by: iXsystems, Inc.
There are some problem reports possibly related to the new driver use of
multiple interrupts on older cards. Hopefully this allow to workaround
them.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
This allows us to limit the number of CPUs to use, e.g. to debug problems
seen when enabling multiple clusters.
Reviewed by: manu
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D19404
