| Age | Commit message (Collapse) | Author |
|---|
|
From Jude Shih
734d5ce02cb069cccedc993d8f1dc0ea41cfa3dd in linux 5.15.y/5.15.58
e27c41d5b0681c597ac1894f4e02cf626e062250 in mainline linux
|
|
|
|
to the padded syscalls going away.
|
|
No change in behavior.
ok kn@, semarie@, kettenis@
|
|
|
|
KNOTE() is safe to use at IPL_AUDIO. Remove the now-unnecessary
deferring that uses soft interrupts.
Remove selwakeup() calls from audio_detach() because klist_invalidate()
wakes up any remaining kevent/poll/select waiters.
OK mpi@
|
|
.data. dt_blob is a basic device tree that is populated from ACPI tables
when booting with ACPI instead of DT. Since we're modifying its content we
need to put it somewhere writeable.
Found and proposed by mlarkin@
ok kettenis@ mlarkin@
|
|
but it appears to be too fragile and now that we are using a 48-bit VA space
for the EFI runtime we no longer need to call SetVirtualAddressMap() to
make address fit into our pmap. Unbreaks the x13s.
ok mlarkin@, patrick@
|
|
Pull inteldrm_refcnt out of NINTAGP > 0, otherwise it remains undefined but
still used in inteldrm_attachhook().
OK jsg
|
|
characteristics field in the COFF header. Makes our bootloader work in the
x13s. With help from mlarkin@.
ok mlarkin@
|
|
It makes uvm_swap_free() faster: extents have a cost of O(n*n) which doesn't
really scale with gigabytes of swap.
Based on initial work from mpi@
The blist implementation comes from DragonFlyBSD.
The diff adds also a ddb(4) 'show swap' command to show the blist and help
debugging, and fix some off-by-one in size printed during hibernate.
ok mpi@
|
|
Allocate the index of a new network interface early so that the index
is available when the interface's queues are set up. This avoids
unintended concentration on net_tq(0).
Replace the kernel lock with an rwlock to serialize index map updates.
The kernel lock is not reliable here because the memory allocation
can sleep.
Also, correct the "too many interfaces" condition because the valid
index range is from 1 to USHRT_MAX.
OK bluhm@
|
|
accessible from ddb. Implement "show all routes" to print routing
tables, and "show route 0xfffffd807e9b0000" for a single route
entry. Note that the rtable id is not part of a route entry, so
it makes no sense to print it there.
OK deraadt@
|
|
the mutex for the fragment list. Move this code before the critical
section. Use ISSET() to make clear which flags are checked.
OK mvs@
|
|
Removed in 2015 and 2002, respectively.
OK claudio
|
|
Added in 2002 r1.48 "sync with latest KAME [...]" along the attribute,
but nd6_free() became a global void function in 2017 r1.212.
Afaik static kernel functions are avoided to aid ddb'ugging and I
presume the "significant changes in the kernel" bits of the comment stem
from something 20 years ago no longer holding true today.
Afterall, this change has been safe for five years.
OK claudio
|
|
OK sashan, bluhm
|
|
ok hastings@
|
|
attaches. This prevents us from having to map the various EFI memory regions
early on. These early mappings use 1G blocks. On Apple M1 systems, these
blocks may overlap memory that isn't accessable. The CPU may speculatively
access this inaccessable memory which will result in SError exceptions.
ok deraadt@
|
|
to support the device tree binding for the "apple,admac" controller.
ok visa@, patrick@
|
|
Initialize the burst size register such that DMA channels that haven't
been initialized by Apple's bootloader also work.
ok patrick@
|
|
With softraid, OBP's boot-file variable aka. bootline may contain the
sofraid volume name and kernel file name delimited by a double colon, e.g.
"sr0", "sr0a", "sr0:", "sr0a:", "sr0:/bsd" or "sr0a:/bsd".
ofwboot parses this string, may fill in optional partition number ("a")
and/or optional kernel file name ("/bsd") and always prints the fully
qualified string reconstructed from parts as "Booting <bootline>":
{0} ok boot my-devalias sr0
[...]
Boot device: /virtual-devices@100/channel-devices@200/disk@0 File and args: sr0
[...]
Booting sr0:a/bsd
[...]
{0} ok boot my-devalias sr0a:/bsd
[...]
Boot device: /virtual-devices@100/channel-devices@200/disk@0 File and args: sr0a:/bsd
[...]
Booting sr0:a/bsd
[...]
Swap partition and delimiter to fix the reconstructed string, making it
suitable for copy/paste:
Booting sr0a:/bsd
This has not been an issue since the reconstructed string is only printed
and not (re)used anywhere.
OK kettenis
|
|
this path is called when running the intel xorg driver on broadwell
|
|
enabling more of __notify_execute_cb() and running the intel xorg driver
on broadwell would fault in __notify_execute_cb() on
movq 0x38(%rsi),%r12
offsetof(struct execute_cb, work.node.llist) 0x38
llist_entry(NULL must not return NULL, it needs to wrap around
and return NULL minus the offset
the iterators stop when the offset added back to the result of
llist_entry() is NULL
they test that the first node is not NULL or that the next pointer
stored in a previous iteration of the loop is not NULL
|
|
ok stsp@, jmatthew@, kevlo@
|
|
The Rise mp6 was an x86 compatible CPU that was available for about
a year from 1998 to 1999. Only the Kirin core was ever available
while the Lynx core did not make it to market. Shortly after this
CPU was released, SiS acquired Rise's technology and integrated it
into their SiS55x SoC which used a different vendor string.
Given how uncommon Rise CPUs are and given that we don't do anything
if we detect such a CPU, remove the small amount of code used to
identify them. OpenBSD should continue to run on these CPUs, they
just won't be recognized as Rise CPUs explicitly.
It is suspected that in the current code, a Rise CPU would not show
CX8 in the dmesg despite supporting the CMPXCHG8B instruction. The
Rise datasheet says that this cpuid feature bit is set to 0 to
"circumvent a reported bug in Windows NT". This is only a cosmetic
issue though as our kernel does not use CMPXCHG8B and our toolchain
assumes it exists (we default to -march=i586).
An interesting writeup on this topic is available here:
https://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm
ok mlarkin@, deraadt@, jsg@
|
|
libc YP support has a couple of places where the domainname is cached, and
this results in wildly incoherent behaviour which could even be risky.
If you want to change the domainname, you will have to reboot.
ok beck miod
|
|
Note that ip_ours() runs with shared netlock, while ip_local() has
exclusive netlock after queuing. Move existing the code into
function ip_fragcheck() and call it from ip_ours().
OK mvs@
|
|
is reflected in more recent device trees. Adjust the driver accordingly.
ok patrick@
|
|
A single "out of order" line is too generic.
OK kettenis
|
|
netlock anymore.
ok bluhm@ yasuoka@
|
|
We don't use "static" keyword for functions declaration to allow ddb(4)
debug. Also, many "Static" functions are called by pppx(4) layer outside
pipex(4) layer.
This is the mostly mechanic diff, except the `pipex_pppoe_padding' which
should be "static const".
ok bluhm@ yasuoka@
|
|
smr_tqh_last is not intended for lockless use with SMR_PTR_GET().
|
|
Let's try this again now that the kernel locking issue in nfsrv_rcv()
has been fixed.
The previous attempt of the conversion triggered hangs on NFS servers.
This was probably caused by the removal of the kernel-locked section
just prior to the socket upcall. The section had masked a locking error
in NFS code.
|
|
shared net lock. ip_deliver() needs exclusive net lock. Instead
of calling ip_deliver() directly, use ip6_ours() to queue the packet.
Move the write lock assertion into ip_deliver() to catch such bugs
earlier.
The assertion was only triggered with IPv6 multicast forwarding or
router alert hop by hop option. Found by regress test.
OK kn@ mvs@
|
|
|
|
The AR9280 half Mini Card (HB92) supports 5GHz as confirmed by athn(4)'s
"The AR9220, AR9223 and AR9280 (codenamed Merlin) ..." paragraph.
pcidevs however wrongly identifies this device as
athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
athn(4) says AR9281 is 2GHz only, so the first line (pcidevs string) does
not match the real information on the second line (from real hardware).
Looking around, the PCI Vendor ID: 168c, Product ID: 002a are described as
* https://pcilookup.com/?ven=168c&dev=002a&action=submit
"AR928X Wireless Network Adapter (PCI-Express)"
* https://pci-ids.ucw.cz/read/PC/168c/002a calls this
"AR928X Wireless Network Adapter (PCI-Express)"
* https://github.com/torvalds/linux/blob/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4/Documentation/devicetree/bindings/net/wireless/qca%2Cath9k.yaml#L27
says
- pci168c,002a # AR9280 and AR9283
* https://pcisig.com/membership/member-companies?combine=168c
(empty, no result)
* NetBSD pcidevs is like ours
product ATHEROS AR9281 0x002a AR9281
Im summary, "AR928X" seems more appropiate and matches both AR9280 and
AR9281 chipsets, so use that to avoid contradicting dmesg lines:
athn0 at pci2 dev 0 function 0 "Atheros AR928X" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
stsp confirms how "Atheros naming is very convoluted."
Feedback sthen
OK stsp
|
|
Found the hard way by mlarkin@ and deraadt@.
|
|
On PowerPC, by design, you cannot mask decrementer (DEC) interrupts
without also masking other interrupts that we want to leave unmasked
at or above IPL_CLOCK. So, currently, the DEC is left unmasked, even
when we're working at IPL_CLOCK or IPL_HIGH. If a DEC interrupt
arrives while we're at those priority levels, the current solution is
to postpone any clock interrupt work until the next hardclock(9) or
statclock tick.
This is a problem for a machine-independent clock interrupt subsystem
because the MD code, e.g. decr_intr(), ideally shouldn't need to know
anything about when the next event is scheduled to occur.
The most obvious solution to this problem that I can think of is to
instead postpone clock interrupt work until the next time our priority
level drops below IPL_CLOCK. This is something we can do from the MD
code without any knowledge of when the next clock interrupt event is
scheduled to occur.
So:
- Add a new boolean, ci_dec_deferred, to the PowerPC cpu_info struct.
- If we reach decr_intr() when the CPU's priority level is too high,
set ci_dec_deferred, clear the DEC exception, and return.
- If we reach decr_intr() and the CPU's priority level is low enough,
clear ci_dec_deferred and do any needed clock interrupt work.
- In splx(9) (there are three different versions we need to update),
check ci_dec_deferred. If it's set and our priority level is
dropping below IPL_CLOCK, raise a DEC exception.
Tested by me on PowerMac7,3 (openpic). Tested by miod@ on PowerMac1,1
(macintr) (`make build` completes). Tested by gkoehler@ on an unknown
PowerMac (probably openpic).
With lots of help from kettenis@.
ok gkoehler@ miod@
|
|
The timecounting subsystem computes elapsed time by scaling (64 bits)
the difference between two counter values (32 bits at most) up into a
struct bintime (128 bits).
Under normal circumstances it is sufficient to do this with 64-bit
multiplication, like this:
struct bintime bt;
bt.sec = 0;
bt.frac = th->tc_scale * tc_delta(th);
However, if tc_delta() exceeds 1 second's worth of counter ticks, that
multiplication overflows. The result is that the monotonic clock appears
to jump backwards.
When can this happen? In practice, I have seen it when trying to
compile LLVM on an EdgeRouter Lite when using an SD card as the
backing disk. The box gets stuck in swap, the hardclock(9) is
delayed, and we appear to "lose time".
To avoid this overflow we need to compute the full 96-bit product of
the delta and the scale.
This commit adds TIMECOUNT_TO_BINTIME(), a function for computing that
full product, to sys/time.h. The patch puts the new function to use
in lib/libc/sys/microtime.c and sys/kern/kern_tc.c.
(The commit also reorganizes some of our high resolution bintime code
so that we always read the timecounter first.)
Doing the full 96-bit multiplication is between 0% and 15% slower than
doing the cheaper 64-bit multiplication on amd64. Measuring a precise
difference is extremely difficult because the computation is already
quite fast.
I would guess that the cost is slightly higher than that on 32-bit
platforms. Nobody ever volunteered to test, so this remains a guess.
Thread: https://marc.info/?l=openbsd-tech&m=163424607918042&w=2
6 month bump: https://marc.info/?l=openbsd-tech&m=165124251401342&w=2
Committed after 9 months without review.
|
|
Apparently, we used to created several kthreads before the kernel
random number generator was up and running. A toggle, "randompid",
was needed to tell allocpid() whether it made sense to attempt to
allocate random PIDs.
However, these days we get e.g. arc4random(9) into a working state
before any kthreads are spawned, so the toggle is no longer needed.
Thread: https://marc.info/?l=openbsd-tech&m=165541052614453&w=2
Very nice historical context provided by miod@.
probably ok miod@ deraadt@
|
|
prevent cursor jumps when using the trackpoint on some lenovo laptops.
Known affected models:
- Lenovo Thinkpad X13 Gen1
- Lenovo Thinkpad T14(s)
- Lenovo Thinkpad E15 Gen3
- Lenovo A475
With help from stsp@
OK stsp@ miod@ deraadt@ bru@
|
|
Only used once, so use the macro directly like ND6_SLOWTIMER_INTERVAL
is used in many places.
OK florian
|
|
OK bluhm
|
|
There since KAME IPv6 import in 1999.
OK "Pool statistics has this info already." bluhm
|
|
nd6_timer_to is a global struct and nd6_timer() accesses it as such,
thereby ignoring its function argument.
Make that clear when setting the timeout, which now goes like the other
two timeouts.
OK bluhem
|
|
From Thomas Zimmermann
31f351eb534e889d11cd149de547d99eb5a15c64 in linux 5.15.y/5.15.56
bf43e4521ff3223a613f3a496991a22a4d78e04b in mainline linux
|
|
From Yefim Barashkin
8c37e7a2000d795aaad7256950f43c25f2aac67f in linux 5.15.y/5.15.56
0638c98c17aa12fe914459c82cd178247e21fb2b in mainline linux
|
|
From Mario Kleiner
cded1186f7e930045fb4ee17dbfa6bae41f3882c in linux 5.15.y/5.15.56
add61d3c31de6a4b5e11a2ab96aaf4c873481568 in mainline linux
|
|
From Thomas Hellstrom
a6cecaf058c48c6def2548473d814a2d54cb3667 in linux 5.15.y/5.15.56
c2ea703dcafccf18d7d77d8b68fb08c2d9842b7a in mainline linux
|
