Age | Commit message (Collapse) | Author |
|
Based on a proposal of tobhe@.
ok tobhe@
|
|
If tcplro is activated on lo(4), ignore the MTU with TCP packets.
They are passed along with the information that they have to be
chopped in case they are forwarded later. New netstat(1) counter
shows that software LRO is in effect. The feature is currently
turned off by default.
tested by jan@; OK claudio@ jan@
|
|
Every platform made the clockintr switch at least six months ago.
The __HAVE_CLOCKINTR symbol is now redundant. Remove it.
Prompted by claudio@.
Link: https://marc.info/?l=openbsd-tech&m=168826181015032&w=2
"makes sense" mlarkin@
|
|
a ypconnect(2) from reading inside an incorrectly configured space.
ok kettenis
|
|
During clockintr_cpu_init(), we can't stagger by ncpus because not
every platform has fully incremented it yet. Instead, stagger by
MAXCPUS. The resulting intervals are smaller, but are probably still
sufficiently large to avoid aggravating lock contention, even on
platforms where MAXCPUS is large.
While here, don't bother staggering the statclock if it is randomized.
With input from claudio@.
|
|
|
|
ok kettenis@ patrick@
|
|
Will enable apm -A once cpu P-state driver is added.
|
|
This makes it easier to track down clock related issues.
ok kettenis@
|
|
This makes the eMMC and microSD mostly work on the Starfive VisionFive 2.
ok kettenis@
|
|
This adds temperature sensor support for the Starfive VisionFive 2.
ok kettenis@
|
|
awaiting concurrent sonewconn() threads termination.
ok bluhm
|
|
M_TEMP and M_IFADDR types are unreasonable for that purpose. This
dedicated statistics simplify the future pf(4) unlocking work by
decreasing search area of possible memory leaks.
ok bluhm sashan
|
|
Previously, any discovered GPE that could be enabled for wake was
being enabled prior to entering ACPI-based S3 or S4. On some newer
machines, this caused S3-based suspend to break as some devices we
don't fully control (e.g. lack of driver) might be capable of waking
the system and will do so almost instantly if the GPE is enabled for
wake up (i.e. the so called "instant wake" issue).
This changes to a model of having device drivers explicitly opt
into using their GPE for wake up.
The first driver to explicitly toggle a GPE for wake is acpibtn(4).
Variations of the above have been in snapshots for 2 weeks, so
tested by many.
ok deraadt@
|
|
|
|
from:
13th Generation Intel Core Processors
Datasheet, Volume 1 of 2, Doc. No.: 743844, Rev.: 005
Intel 700 Series Chipset Family On-Package Platform Controller Hub (PCH)
Datasheet, Volume 1 of 2, Doc. No.: 763122, Rev.: 001
0xa75d (IPU) 0xa72f 0xa76e (TBT PCIE) not in tables
inferred from a dmesg and pci dev:func descriptions in
13th Generation Intel Core Processors
Datasheet, Volume 2 of 2, Doc. No.: 764981, Rev.: 1.2
|
|
OK bluhm@
|
|
DIOCGETRULES."
regress/sbin/pfctl panics with "rw_enter: pfioctl_rw locking against myself"
as reported by bluhm on bugs@.
|
|
Replace hand-rolled reference counting with refcnt_init(9) and hook it up
with a new dt(4) probe.
OK bluhm mvs
|
|
Pass the timeout and sleep priority not only to sleep_setup() but also
to sleep_finish(). With that sls_timeout and sls_catch can be removed
from struct sleep_state.
The timeout is now setup first thing in sleep_finish() and no longer as
last thing in sleep_setup(). This should not cause a noticeable difference
since the code run between sleep_setup() and sleep_finish() is minimal.
OK kettenis@
|
|
The driver not only provides the temperature readings for the cores, cluster
and memory in hw.sensors, but also allows the thermal zone code to act on
temperature changes.
ok drahn@
|
|
for interface groups data allocations.
ok kn claudio bluhm
|
|
snmpd(8) and 'pfctl -s Interfaces' dump pf's internal list of interfaces.
pf's internal interface list is completely protected by the pf lock,
pf lock assertions since pf_if.c r1.110 from over a week ago support this.
pfi_*() iterate over net lock protected if_groups lists, but only to read,
so downgrade from exclusive write net lock to a shared read-only one.
Feedback mvs
OK sashan
|
|
pf.conf's 'set skip on ifN' and 'pfctl -F all|Reset' set and clear flags,
PFI_IFLAG_SKIP being the only flag. Nothing else in base uses these ioctls
and internal state is protected by the pf lock already.
OK sashan
|
|
from reyk@
|
|
|
|
|
|
This bug can cause all sorts of problems, but in particular it was
most easily reproduced as a double fault in the syscall return path on
this CPU model:
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Tons of help from guenther@ in narrowing down the root cause. Fix
tweaked by guenther@. Additional input from deraadt@ and kettenis@.
ok guenther@
|
|
found by mlarkin
|
|
|
|
|
|
Processes like snmpd or systat open pf(4) once and then issue many
DIOCGETRULES calls over their runtime. This accumulates many pf_trans
structs over their lifetime. At some point the kernel runs out of
memory because of that. By closing all transactions before creating
a new one, long living processes do no longer leak transactions.
This probably needs further refinement once more transactions types are
added but for now this solves the problem.
Problem found by florian@
OK sashan@ kn@
|
|
dwge(4) implementations. The counters are all 32 bit, so enable reset-on-read
and accumulate them into 64 bit software counters, and enable the MMC
interrupts that indicate one or more counters is halfway to overflowing.
Tested on an RK3399, which has the counters, and an Allwinner A20, which
doesn't.
ok dlg@
|
|
Goal is to run UDP input in parallel. Btrace kstack analysis shows
that SIP hash for PCB lookup is quite expensive. When running in
parallel, there is also lock contention on the PCB table mutex.
It results in better performance to calculate the hash value before
taking the mutex. The hash secret has to be constant as hash
calculation must not depend on values protected by the table mutex.
Do not reseed anymore when hash table gets resized.
Analysis also shows that asserting a rw_lock while holding a mutex
is a bit expensive. Just remove the netlock assert.
OK dlg@ mvs@
|
|
This adds initial support for the syscrg and pll clocks on the StarFive
VisionFive V2 JH7110 SoC.
ok kettenis@
|
|
OK dlg@
Reported-by: syzbot+a377d5cd833c2343429a@syzkaller.appspotmail.com
|
|
ok deraadt, brynet
|
|
clockintr_stagger()"
octeon machines do not increment the global variable "ncpus"
(init_main.c) in the same spot as other platforms, which violates the
KASSERT in clockintr_stagger(), causing a panic.
We need to bring octeon's behavior into alignment with every other
platform before proceeding with this patch.
Reported and debugged by bluhm@.
|
|
Result is the same and gets rid of a lbolt use.
OK miod@
|
|
From Thomas Zimmermann
4b4cae8e4b37c7ad4d9721dbda060a62e49e3c17 in linux-6.1.y/6.1.35
0e3172bac3f43759719384403fe2d1e4c61f87e0 in mainline linux
|
|
From Alex Deucher
21863dc45aed8d68a2573cce032ecbc8fe7c5bf5 in linux-6.1.y/6.1.35
e61f67749b351c19455ce3085af2ae9af80023bc in mainline linux
|
|
From Kenneth Feng
6f5b5ce9397d91b0a8bc8d15dc8fd72bc0aacaa4 in linux-6.1.y/6.1.35
7ca302d488f80cf4529620acc1c545f9022d8bb8 in mainline linux
|
|
From Mario Limonciello
b69a10df900386871703a4cc3be974485f52ff7c in linux-6.1.y/6.1.35
7ab1a4913d0051cf5196ef7987b5fa42c25e13b6 in mainline linux
|
|
From Mario Limonciello
b2706d862b6577b8218bdef1c238e175624b906d in linux-6.1.y/6.1.35
3eb1a3a04056ba3df3205e169b8acc9da0c65a94 in mainline linux
|
|
From Hersen Wu
ee8c6580c3106b0061c7cdff1804e5a1f1e1d7fe in linux-6.1.y/6.1.35
e749dd10e5f292061ad63d2b030194bf7d7d452c in mainline linux
|
|
From Sonny Jiang
5d1fdfb3d185a9726478ba174235eff7c16f1101 in linux-6.1.y/6.1.35
9db5ec1ceb5303398ec4f899d691073d531257c3 in mainline linux
|
|
From Sukrut Bellary
8ca9880735b0a33a4ff54328d6c5eb60fe2b0a6d in linux-6.1.y/6.1.35
60ecaaf54886b0642d5c4744f7fbf1ff0d6b3e42 in mainline linux
|
|
From Maya Matuszczyk
c45aed74318e65b8da938a593c124ad2ee1a1e66 in linux-6.1.y/6.1.35
1aa7f416175619e0286fddc5fc44e968b06bf2aa in mainline linux
|
|
ok stsp
|
|
Sometimes causes boot hang after mounting root partition.
Thread 1: https://marc.info/?l=openbsd-misc&m=168736497407357&w=2
Thread 2: https://marc.info/?l=openbsd-misc&m=168737429214370&w=2
|