Age | Commit message (Collapse) | Author |
|
ok kettenis@
|
|
pool_get() and pool_put(). This makes it clearer that the knote
allocation cannot fail and that the error check is unnecessary.
OK anton@, kettenis@, mpi@
|
|
OK millert@ visa@ benno@
|
|
|
|
drops graphics buffers that are cached and not in active use.
Help from beck@ for pointing out how to hook this up to our pagedaemon.
ok jsg@
|
|
turn them into proper sentences. Gets rid of 27 lines in total.
|
|
to simplify the locking pattern, revert back to using a hand-rolled I/O
lock just like FreeBSD and NetBSD does. The state of pipes is quite
different compared to when I made use of a rwlock for the I/O lock in
revision 1.96. Most notably, the pipe_lock can now be used while
sleeping. This does imply that witness(4) tracking of the I/O lock is
lost but the implementation ends up being simpler.
ok visa@
|
|
|
|
This flag is set whenever a timeout is put on the wheel and cleared upon
(a) running, (b) deletion, and (c) readdition. It serves two purposes:
1. Facilitate distinguishing scheduled and rescheduled timeouts. When a
timeout is put on the wheel it is "scheduled" for a later softclock().
If this happens two or more times it is also said to be "rescheduled".
The tos_rescheduled value thus indicates how many distant timeouts
have been cascaded into a lower wheel level.
2. Eliminate false late timeouts. A timeout is not late if it is due
before softclock() has had a chance to schedule it. To track this we
need additional state, hence a new flag.
rprocter@ raises some interesting questions. Some answers:
- This interface is not stable and name changes are possible at a
later date.
- Although rescheduling timeouts is a side effect of the underlying
implementation, I don't forsee us using anything but a timeout wheel
in the future. Other data structures are too slow in practice, so
I doubt that the concept of a rescheduled timeout will be irrelevant
any time soon.
- I think the development utility of gathering these sorts of statistics
is high. Watching the distribution of timeouts under a given workflow
is informative.
ok visa@
|
|
output.
|
|
only called from main(). There allocation must not fail, so better
use M_WAITOK and remove error handling. As it is not a temporary
buffer, M_TTYS is more appropriate.
OK deraadt@ mpi@
|
|
|
|
OK cheloha@, anton@, mpi@
|
|
|
|
IP forwarding is disabled. Issue reported by Daniel Jakots (danj@)
OK bluhm@
|
|
during kernel startup before syslogd(8) can receive it. Increase
message buffer size from 94k to 128k on amd64.
reported by Hrvoje Popovski; OK deraadt@
|
|
Document the new feature in boot(8) man page.
OK jmc@ deraadt@
|
|
this lets aggr come up on boot if there's a race with it being
brought up and the ports being up.
reported by holger glaess on misc@ and debugged with hrvoje popovski.
tested by hrvoje popovski too.
|
|
AMD SoCs/chipsets.
From James Hastings
|
|
These are straightforward except for the tsleep(9) conversion. ratchov@
had a bit to say about that code:
https://marc.info/?l=openbsd-tech&m=157665936017373&w=2
> The problem is that close(2) may reset the transmitter before the few
> bytes of its internal buffer is sent on the wire; there's no "wait for
> completion" feature in such simple hardware, so we just wait few
> milliseconds.
>
> The transmitter buffer size is around 16 bytes, the byte rate is 3125
> bytes/second. So if we wait at least 16B / 3125B/s = 5.12ms, we're
> safe. Waiting 10ms-20ms is enough and is unnoticeable.
Hence, in this diff we wait a flat 20ms in that situation.
ok ratchov@
|
|
ok deraadt@
|
|
From Alex Deucher
33c1d3bc1d5e1062844a31acc85eb50f9447f006 in linux 4.19.y/4.19.91
008037d4d972c9c47b273e40e52ae34f9d9e33e7 in mainline linux
|
|
ok claudio@
|
|
OK mpi@
|
|
OK mpi@
|
|
Rename variables for clarity while here.
OK mpi@
|
|
|
|
than writing a hard-coded bit pattern to this register.
Matches what Intel's Linux driver does, so it should be the right thing to do.
Tested on 8265 by Tracey Emery and myself.
|
|
Matches what iwm(4) has been doing for a long time to ensure that
a good initial Tx rate will be chosen.
Tested by Tracey Emery on AR9281.
|
|
Some peers will eagerly try to negotiate block ack (asking us to reserve
buffer space) before they are done authenticating themselves. No thanks.
Just let them try again later.
ok mpi@
|
|
as well as pulling frames off the Rx block ack reordering queue, when
an incoming frame above the current seqnum window forces us to slide
the window forward, potentially losing frames within the old window.
Leaving the seqnum window out of sync with the queue would cause needlessly
long stalls in traffic until the window moved again for some other reason.
Problem observed on lossy wifi whenever netstat -W indicated an increasing
"input block ack window slides" counter. With this fix, stalled frames can
be observed only for a relatively short amount of time whenever one or more
frames in the current window are lost.
ok mpi@
|
|
Even with the latest microcode this is not set on all CPUs with TSX, but
is set on CPUs which don't need MDS mitigations.
MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't
done if the CPU claims to not be affected by MDS (MDS_NO).
According to "Deep Dive: Intel Transactional Synchronization Extensions
(Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations
for this are:
06-8e-0c Whiskey Lake (ULT refresh)
06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake
06-9e-0d Coffee Lake R
Currently TSX is disabled unconditionally when possible even if TAA_NO
is set.
We don't currently do MDS mitigations on i386. Attempt to disable TSX
regardless to match amd64.
|
|
Even with the latest microcode this is not set on all CPUs with TSX, but
is set on CPUs which don't need MDS mitigations.
MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't
done if the CPU claims to not be affected by MDS (MDS_NO).
According to "Deep Dive: Intel Transactional Synchronization Extensions
(Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations
for this are:
06-8e-0c Whiskey Lake (ULT refresh)
06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake
06-9e-0d Coffee Lake R
Currently TSX is disabled unconditionally when possible even if TAA_NO
is set.
ok bluhm@ guenther@ deraadt@
tested by bluhm@ on i5-8365U (06-8e-0c).
|
|
|
|
pipe_lock. This add a potential sleeping point in the kqueue filter
routines which should be fine by now thanks to changes made to the
kqueue subsystem by visa.
ok visa@
|
|
the kernel.
ok patrick@
|
|
the kernel.
ok mlarkin@, visa@
|
|
the kernel.
ok mlarkin@, visa@
|
|
ok visa@
|
|
Some drivers have returned ENXIO (6) if the device is not available
which incorrectly translates into POLLPRI|POLLOUT (2|4) in userland.
Change it to POLLERR for now, but it might as well be POLLHUP.
OK mpi@
|
|
There is an existing allocsize variable tracking size of allocations,
turns out we can pass it to free in the error path.
OK florian@, mpi@
|
|
ok deraadt@, dlg@
|
|
OK guenther@, kettenis@, mpi@
|
|
against codes in the known-codes table, like Linux does it.
Mark the known-codes table static so it won't ever collide with
symbols declared elsewhere in the kernel.
Also add some more cause codes found in iwlwifi. I still keep hitting
firmware SYSASSERT codes that aren't declared in this table, though :(
These changes only affect IWM_DEBUG builds.
|
|
Firmware-based Tx retries were disabled when it was found that MiRA
makes better choices while probing with a constant Tx retry rate.
Before that change, high Tx rates looked better than they actually
were. The change resulted in less retries and thus higher throughput
because a lower, but actually working, initial Tx rate eventually
became the preferred choice.
However, disallowing retries at lower rates also resulted in increased
amounts of observable packet loss, especially while the connection to
the AP was still fresh and bad Tx rates had not been discovered yet.
To get the best of both worlds, use a constant Tx rate for retries while
MiRA is probing and otherwise allow firmware fallback to lower rates.
tested by Tracey Emery, pamela, jasper, and myself, on 7265/8265/9260
|
|
in inteldrm(4).
ok guenther@
|
|
maps. This lets witness know that these really are different classes
avoiding false positives when detecting lock order reversals.
ok guenther@, visa@, mpi@
|
|
|
|
|
|
ok ratchov@
|