Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > >
> >
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
>
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
> ((unsigned long)(unsigned int) (-300*HZ))
>
> --
> :wq Claudio
>
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c 25 Jul 2023 18:16:19 - 1.109
> +++ kern_clock.c 31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
> int profprocs;
> int ticks = INT_MAX - (15 * 60 * HZ);
>
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>
> /*
> * Initialize clock frequencies and start both clocks running.
>
I think this is backwards.
Why are we changing the initial value of jiffies (wide) to resolve a
problem with the initialization of one struct (narrow)? Changing the
initial value of jiffies just masks the root cause.
Isn't the right thing here to initialize the last-write timestamp when
the struct is allocated?
pf(4) may cause relayd(8) to abort
Hello,
the issue has been reported by Gianni Kapetanakis month ago [1]. It took
several emails to figure out relayd(8) exists after hosts got disabled
by 'relayctl host dis ...'
The thing is that relayd(8) relies on pf(4) to create persistent
tables (PFR_TFLAG_PERSIST) as relayd requests that:
47 void
48 init_tables(struct relayd *env)
49 {
...
62 TAILQ_FOREACH(rdr, env->sc_rdrs, entry) {
63 if (strlcpy(tables[i].pfrt_anchor, RELAYD_ANCHOR "/",
64 sizeof(tables[i].pfrt_anchor)) >= PF_ANCHOR_NAME_SIZE)
65 goto toolong;
66 if (strlcat(tables[i].pfrt_anchor, rdr->conf.name,
67 sizeof(tables[i].pfrt_anchor)) >= PF_ANCHOR_NAME_SIZE)
68 goto toolong;
69 if (strlcpy(tables[i].pfrt_name, rdr->conf.name,
70 sizeof(tables[i].pfrt_name)) >=
71 sizeof(tables[i].pfrt_name))
72 goto toolong;
73 tables[i].pfrt_flags |= PFR_TFLAG_PERSIST;
74 i++;
75 }
unfortunately it's not the case as further investigation revealed [2].
the issue can be easily reproduced by pfctl(8) which also creates
persistent tables on behalf of command line:
pfctl -t foo -T add ...
command above always asks pf(4) to create persistent table, however
pf(4) does not honor persistent flag when table exists already.
One can verify that using commands as follows:
## create 'referenced' table only (table exists but has no active flag)
# echo 'pass from in to any' |pfctl -f -
# pfctl -sT -vg
r-- foo
# create instance of table using command line:
# pfctl -t foo -T add 192.168.1.0/24
1/1 addresses added.
# pfctl -sT -vg
--a-r-- foo
## create instance of table , note the table will get 'p' flag
# pfctl -t bar -T add 192.168.10.0/24
1 table created.
1/1 addresses added.
# pfctl -sT -vg
-pa bar
--a-r-- foo
one-liner change to sys/net/pf_table.c fixes that it also works for Gianni
Kapetanakis. I'm also adding tests to regress/sys/net/pf_table/Makefile
to cover it.
On system which runs current the test fails with error as follows:
pfctl -a regress/ttest -t instance -T add 192.168.1.0/24
1/1 addresses added.
pfctl -a regress/ttest -sT -vg | diff table-persist.out -
1c1
< -pa-r-- instanceregress/ttest
---
> --a-r-- instanceregress/ttest
*** Error 1 in . (Makefile:96 'flags')
FAILED
the failure is expected on system without patch. On system with
patch applied all tests do pass.
OK to commit?
thanks and
regards
sashan
[1] https://marc.info/?t=16881127045=1=2
[2] https://marc.info/?l=openbsd-bugs=168868165801905=2
8<---8<---8<--8<
diff --git a/sys/net/pf_table.c b/sys/net/pf_table.c
index 6f23a6f795d..c862c804f84 100644
--- a/sys/net/pf_table.c
+++ b/sys/net/pf_table.c
@@ -1565,8 +1565,10 @@ pfr_add_tables(struct pfr_table *tbl, int size, int
*nadd, int flags)
xadd++;
} else if (!(flags & PFR_FLAG_DUMMY) &&
!(p->pfrkt_flags & PFR_TFLAG_ACTIVE)) {
- p->pfrkt_nflags = (p->pfrkt_flags &
- ~PFR_TFLAG_USRMASK) | PFR_TFLAG_ACTIVE;
+ p->pfrkt_nflags =
+ (p->pfrkt_flags & ~PFR_TFLAG_USRMASK) |
+ (n->pfrkt_flags & PFR_TFLAG_USRMASK) |
+ PFR_TFLAG_ACTIVE;
SLIST_INSERT_HEAD(, p, pfrkt_workq);
}
}
diff --git a/regress/sys/net/pf_table/Makefile
b/regress/sys/net/pf_table/Makefile
index a71f0190c73..8911e8a1d35 100644
--- a/regress/sys/net/pf_table/Makefile
+++ b/regress/sys/net/pf_table/Makefile
@@ -1,15 +1,26 @@
# $OpenBSD: Makefile,v 1.3 2017/07/07 23:15:27 bluhm Exp $
-REGRESS_TARGETS= hit miss cleanup
-CLEANFILES=stamp-*
+REGRESS_TARGETS= hit miss cleanup flags
+CLEANFILES=stamp-* \
+ pf-reftab.conf \
+ pf-instance.conf\
+ table-ref.conf \
+ table-pgone.out \
+ table-persist.out \
+ table-ref.out \
+ table-refgone.out
+
stamp-setup:
+ ${SUDO} pfctl -a regress/ttest -Fa
${SUDO} pfctl -qt __regress_tbl -T add -f ${.CURDIR}/table.in
date >$@
cleanup:
rm -f stamp-setup
${SUDO} pfctl -qt __regress_tbl -T kill
+ ${SUDO} pfctl -q -a regress/ttest -Fr
+ ${SUDO} pfctl -q -a regress/ttest -qt instance -T kill
hit: stamp-setup
for i in `cat ${.CURDIR}/table.hit`; do \
@@ -27,6 +38,77 @@ miss: stamp-setup
done; \
exit 0
-.PHONY: hit
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > >
> >
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
>
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
> ((unsigned long)(unsigned int) (-300*HZ))
>
> --
> :wq Claudio
>
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c 25 Jul 2023 18:16:19 - 1.109
> +++ kern_clock.c 31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
> int profprocs;
> int ticks = INT_MAX - (15 * 60 * HZ);
>
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>
> /*
> * Initialize clock frequencies and start both clocks running.
>
This diff contains all of diffs you posted to this thread. Works fine
with hunks 1 and 2 together as with any of them separately.
Index: sys/dev/pci/drm/i915/display/intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
retrieving revision 1.14
diff -u -p -r1.14 intel_dp.c
--- sys/dev/pci/drm/i915/display/intel_dp.c 28 Jul 2023 06:56:32 -
1.14
+++ sys/dev/pci/drm/i915/display/intel_dp.c 31 Jul 2023 20:38:05 -
@@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
drm_dbg_kms(>drm, "Performing OUI wait\n");
+ if (intel_dp->last_oui_write == 0)
+ intel_dp->last_oui_write = jiffies;
wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
}
Index: sys/kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.109
diff -u -p -r1.109 kern_clock.c
--- sys/kern/kern_clock.c 25 Jul 2023 18:16:19 - 1.109
+++ sys/kern/kern_clock.c 31 Jul 2023 20:38:05 -
@@ -84,7 +84,7 @@ int profhz;
intprofprocs;
intticks = INT_MAX - (15 * 60 * HZ);
-volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
+volatile unsigned long jiffies;
/*
* Initialize clock frequencies and start both clocks running.
Index: sys/uvm/uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.44
diff -u -p -r1.44 uvm_meter.c
--- sys/uvm/uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
+++ sys/uvm/uvm_meter.c 31 Jul 2023 20:38:05 -
@@ -89,8 +89,6 @@ uvm_meter(void)
{
if ((gettime() % 5) == 0)
uvm_loadav();
- if (proc0.p_slptime > (maxslp / 2))
- wakeup();
}
/*
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> >
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
> > }
> >
>
> Please give this a try. I think on initialization
> intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> set and this results in a 10min timeout because our jiffies are set to
> ULONG_MAX - (10 * 60 * HZ);
>
> --
> :wq Claudio
>
> Index: intel_dp.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 intel_dp.c
> --- intel_dp.c28 Jul 2023 06:56:32 - 1.14
> +++ intel_dp.c31 Jul 2023 19:39:37 -
> @@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> drm_dbg_kms(>drm, "Performing OUI wait\n");
> + if (intel_dp->last_oui_write == 0)
> + intel_dp->last_oui_write = jiffies;
> wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
> }
>
I tested this on top of initial uvm_meter() diff. Your third jiffies
diff was not applied. Works fine on affected gen 12 ALDERLAKE_P and
unaffected gen 4 core2quad. Also the inteldrm delay is shorter on
ALDERLAKE_P.
Will do separate test for jiffies diff.
Re: uvm_meter: remove wakeup of proc0
The jiffies patch plus the patch in uvm_meter worked for me. It even booted a
little faster than normal.
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > >
> >
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
>
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
> ((unsigned long)(unsigned int) (-300*HZ))
>
> --
> :wq Claudio
>
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c 25 Jul 2023 18:16:19 - 1.109
> +++ kern_clock.c 31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
> int profprocs;
> int ticks = INT_MAX - (15 * 60 * HZ);
>
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>
> /*
> * Initialize clock frequencies and start both clocks running.
>
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > >
> >
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
>
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
> ((unsigned long)(unsigned int) (-300*HZ))
This patch on top of the original one doesn't hang my machine anymore.
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> >
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
> > }
> >
>
> Please give this a try. I think on initialization
> intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> set and this results in a 10min timeout because our jiffies are set to
> ULONG_MAX - (10 * 60 * HZ);
After talking with kettenis@ I think the following diff is better.
Starting with 0 jiffies should fix this issue.
Unless we want to do the linux madness and set it to
((unsigned long)(unsigned int) (-300*HZ))
--
:wq Claudio
Index: kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.109
diff -u -p -r1.109 kern_clock.c
--- kern_clock.c25 Jul 2023 18:16:19 - 1.109
+++ kern_clock.c31 Jul 2023 20:01:57 -
@@ -84,7 +84,7 @@ int profhz;
intprofprocs;
intticks = INT_MAX - (15 * 60 * HZ);
-volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
+volatile unsigned long jiffies;
/*
* Initialize clock frequencies and start both clocks running.
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
>
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }
>
Please give this a try. I think on initialization
intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
set and this results in a 10min timeout because our jiffies are set to
ULONG_MAX - (10 * 60 * HZ);
--
:wq Claudio
Index: intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
retrieving revision 1.14
diff -u -p -r1.14 intel_dp.c
--- intel_dp.c 28 Jul 2023 06:56:32 - 1.14
+++ intel_dp.c 31 Jul 2023 19:39:37 -
@@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
drm_dbg_kms(>drm, "Performing OUI wait\n");
+ if (intel_dp->last_oui_write == 0)
+ intel_dp->last_oui_write = jiffies;
wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
}
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
>
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }
Not really. The problem is lower in intel_dp_wait_source_oui().
Which either missed the wakeup and still hit the
schedule_timeout_uninterruptible() codepath or the wakeup() was issued
before the tsleep(). In anycase something is not quite correct in that
codepath. Will look into it.
--
:wq Claudio
Re: uvm_meter: remove wakeup of proc0
This is the culprit:
schedule_timeout_uninterruptible(long timeout)
{
tsleep(curproc, PWAIT, "schtou", timeout);
return 0;
}
Re: ualarm.3: cleanup, rewrites
On Sun, 30 Jul 2023 20:20:31 -0500, Scott Cheloha wrote: > This patch drags ualarm.3 over to where alarm.3 is. I think it reads > better and the wording is truer to what the function actually does. > In particular, ualarm(3) does not block or "wait": the alarm is > scheduled for asynchronous delivery by the operating system. > > I think I may have tried to clean this up two years ago. I don't > remember where that got sidetracked, but fwiw this was written from > scratch using alarm.3 as a guide. > > Two things I'm iffy on: > > - "high resolution" or "high-resolution"? nanosleep(2) uses "high resolution" so I think we should be consistent with that. > - The current manual mentions an upper bound (2147483647). I'm not > sure when, if ever, this was the real: useconds_t is unsigned, so an > upper bound of INT32_MAX seems off. This may have been copy pasta from alarm.3 which used to document the same limit (which was actually incorrect at the time due to itimerfix). > I am leaning toward just leaving the patch as-is instead of trying > to guide the end-user through the minefield of matching bespoke > "_t" types to real types and limits. > > Tweaks? ok? OK millert@ - todd
Re: uvm_meter: remove wakeup of proc0
On Sat, Jul 29, 2023 at 03:00:59PM +0300, Vitaliy Makkoveev wrote:
> On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> > proc0 aka the swapper does not do anything. So there is no need to wake it
> > up. Now the problem is that last time this was tried some inteldrm systems
> > did hang during bootup because the drm code unexpectedly depended on this
> > wakeup.
> >
> > I think I fixed all possible cases of this in the drm stack and so it is
> > time to retry this. People with affected machines please give this a try.
> >
>
> Hi,
>
> With this diff "inteldrm0: msi, ALDERLAKE_P, gen 12" sticks after "root
> on ...", "inteldrm0: apic 4 int 16, G45, gen 4" works fine.
Would it be possible to get a backtrace of proc0 from the system that
hangs?
I think the simplest way is to:
1. boot -d
2. in ddb:
w db_console 1
c
3. once you hang on "root on" line. Hit ctrl-alt-esc
4. in ddb:
tr /t 0
Thanks.
--
:wq Claudio
> > --
> > :wq Claudio
> >
> > Index: uvm/uvm_meter.c
> > ===
> > RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> > retrieving revision 1.44
> > diff -u -p -r1.44 uvm_meter.c
> > --- uvm/uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
> > +++ uvm/uvm_meter.c 29 Jul 2023 07:48:44 -
> > @@ -89,8 +89,6 @@ uvm_meter(void)
> > {
> > if ((gettime() % 5) == 0)
> > uvm_loadav();
> > - if (proc0.p_slptime > (maxslp / 2))
> > - wakeup();
> > }
> >
> > /*
> >
>
Re: uvm_loadav: don't recompute schedstate_percpu.spc_nrun
On Fri, Jul 28, 2023 at 07:36:41PM -0500, Scott Cheloha wrote:
> claudio@ notes that uvm_loadav() pointlessly walks the allproc list to
> recompute schedstate_percpu.spn_nrun for each CPU.
>
> We can just use the value instead of recomputing it.
Whoops, off-by-one. The current load averaging code includes the
running thread in the nrun count if it is *not* the idle thread.
Index: uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.44
diff -u -p -r1.44 uvm_meter.c
--- uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
+++ uvm_meter.c 31 Jul 2023 15:20:37 -
@@ -102,43 +102,29 @@ uvm_loadav(struct loadavg *avg)
{
CPU_INFO_ITERATOR cii;
struct cpu_info *ci;
- int i, nrun;
- struct proc *p;
- int nrun_cpu[MAXCPUS];
+ struct schedstate_percpu *spc;
+ u_int i, nrun = 0, nrun_cpu;
+ int s;
- nrun = 0;
- memset(nrun_cpu, 0, sizeof(nrun_cpu));
- LIST_FOREACH(p, , p_list) {
- switch (p->p_stat) {
- case SSTOP:
- case SSLEEP:
- break;
- case SRUN:
- case SONPROC:
- if (p == p->p_cpu->ci_schedstate.spc_idleproc)
- continue;
- /* FALLTHROUGH */
- case SIDL:
- nrun++;
- if (p->p_cpu)
- nrun_cpu[CPU_INFO_UNIT(p->p_cpu)]++;
- }
+ SCHED_LOCK(s);
+ CPU_INFO_FOREACH(cii, ci) {
+ spc = >ci_schedstate;
+ nrun_cpu = spc->spc_nrun;
+ if (ci->ci_curproc != spc->spc_idleproc)
+ nrun_cpu++;
+ if (nrun_cpu == 0)
+ continue;
+ spc->spc_ldavg = (cexp[0] * spc->spc_ldavg +
+ nrun_cpu * FSCALE *
+ (FSCALE - cexp[0])) >> FSHIFT;
+ nrun += nrun_cpu;
}
+ SCHED_UNLOCK(s);
for (i = 0; i < 3; i++) {
avg->ldavg[i] = (cexp[i] * avg->ldavg[i] +
nrun * FSCALE * (FSCALE - cexp[i])) >> FSHIFT;
- }
-
- CPU_INFO_FOREACH(cii, ci) {
- struct schedstate_percpu *spc = >ci_schedstate;
-
- if (nrun_cpu[CPU_INFO_UNIT(ci)] == 0)
- continue;
- spc->spc_ldavg = (cexp[0] * spc->spc_ldavg +
- nrun_cpu[CPU_INFO_UNIT(ci)] * FSCALE *
- (FSCALE - cexp[0])) >> FSHIFT;
}
}
Re: uvm_meter: remove wakeup of proc0
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wakeup.
>
> I think I fixed all possible cases of this in the drm stack and so it is
> time to retry this. People with affected machines please give this a try.
>
> --
> :wq Claudio
>
> Index: uvm/uvm_meter.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 uvm_meter.c
> --- uvm/uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
> +++ uvm/uvm_meter.c 29 Jul 2023 07:48:44 -
> @@ -89,8 +89,6 @@ uvm_meter(void)
> {
> if ((gettime() % 5) == 0)
> uvm_loadav();
> - if (proc0.p_slptime > (maxslp / 2))
> - wakeup();
> }
>
> /*
>
I tried this again, but bootup still hung at "root on "
I do have some kernel customizations normally, but this patch, applied to my
custom kernel and to a generic one, causes boot to hang.
Here's the dmesg of my machine:
OpenBSD 7.3-current (NOAMDGPU.MP) #45: Mon Jul 31 08:59:16 MDT 2023
me@sonofthief.private:/home/me/src/sys/arch/amd64/compile/NOAMDGPU.MP
real mem = 8346333184 (7959MB)
avail mem = 8087310336 (7712MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439de000 (69 entries)
bios0: vendor LENOVO version "FHCN54WW" date 07/05/2021
bios0: LENOVO 82FG
efi0 at bios0: UEFI 2.7
efi0: INSYDE Corp. rev 0x59474054
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT MSDM NHLT SSDT LPIT WSMT
SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT SSDT FPDT PTDT BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGA(S4) PEGP(S4) PEGP(S4) XHCI(S4)
XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4)
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0: not present
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.34 MHz, 06-8c-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
20-way L2 cache, 8MB 64b/line 8-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.35 MHz, 06-8c-01
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
20-way L2 cache, 8MB 64b/line 8-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 3791.27 MHz, 06-8c-01
cpu2:
Re: axppmic(4): axp313a support
> Date: Mon, 31 Jul 2023 22:12:35 +0900
> From: SASANO Takayoshi
>
> Hi,
>
> Mango Pi MQ-Quad and OrangePi Zero3 has X-Power AXP313A PMIC.
>
> Here is a diff, but AXP313A's dcdc1 is not fully supported.
>
> dcdc1 has three voltage ranges:
> 0.5-1.2V, 10mV/step (71 steps)
> 1.22-1.54V 20mV/step (17 steps)
> 1.6-3.4V 100mV/step (19 steps) *not supported this diff*
>
> This restriction comes from current axppmic.c supports two voltage ranges.
> At least MQ-Quad/OPiZero3 uses dcdc1 for Allwinner H616's SYS/GPU
> (near 0.9V) so no need to support highest voltage range.
maybe add a note that the data sheet is wrong for dcdc3?
ok kettenis@
> Index: axppmic.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/axppmic.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 axppmic.c
> --- axppmic.c 31 Jul 2023 12:23:35 - 1.19
> +++ axppmic.c 31 Jul 2023 13:00:12 -
> @@ -126,6 +126,21 @@ const struct axppmic_regdata axp221_regd
> { NULL }
> };
>
> +const struct axppmic_regdata axp313a_regdata[] = {
> + /* dcdc1: 1.6-3.4V (100mV step) not supported */
> + { "dcdc1", 0x10, (1 << 0), (1 << 0), (0 << 0),
> + 0x13, 0x7f, 50, 1, 71, 122000, 2, 17 },
> + { "dcdc2", 0x10, (1 << 1), (1 << 1), (0 << 1),
> + 0x14, 0x7f, 50, 1, 71, 122000, 2, 17 },
> + { "dcdc3", 0x10, (1 << 2), (1 << 2), (0 << 2),
> + 0x15, 0x7f, 50, 1, 71, 122000, 2, 32 },
> + { "aldo1", 0x10, (1 << 3), (1 << 3), (0 << 3),
> + 0x16, 0x1f, 50, 10, 31 },
> + { "dldo1", 0x10, (1 << 4), (1 << 4), (0 << 4),
> + 0x17, 0x1f, 50, 10, 31 },
> + { NULL }
> +};
> +
> const struct axppmic_regdata axp803_regdata[] = {
> { "dcdc1", 0x10, (1 << 0), (1 << 0), (0 << 0),
> 0x20, 0x1f, 160, 10, 19 },
> @@ -354,6 +369,7 @@ const struct axppmic_device axppmic_devi
> { "x-powers,axp221", "AXP221", axp221_regdata, axp221_sensdata },
> { "x-powers,axp223", "AXP223", axp221_regdata, axp221_sensdata },
> { "x-powers,axp305", "AXP305", axp806_regdata },
> + { "x-powers,axp313a", "AXP313A", axp313a_regdata },
> { "x-powers,axp803", "AXP803", axp803_regdata, axp803_sensdata },
> { "x-powers,axp805", "AXP805", axp806_regdata },
> { "x-powers,axp806", "AXP806", axp806_regdata },
>
> --
> SASANO Takayoshi (JG1UAA)
>
>
axppmic(4): axp313a support
Hi,
Mango Pi MQ-Quad and OrangePi Zero3 has X-Power AXP313A PMIC.
Here is a diff, but AXP313A's dcdc1 is not fully supported.
dcdc1 has three voltage ranges:
0.5-1.2V, 10mV/step (71 steps)
1.22-1.54V 20mV/step (17 steps)
1.6-3.4V 100mV/step (19 steps) *not supported this diff*
This restriction comes from current axppmic.c supports two voltage ranges.
At least MQ-Quad/OPiZero3 uses dcdc1 for Allwinner H616's SYS/GPU
(near 0.9V) so no need to support highest voltage range.
Index: axppmic.c
===
RCS file: /cvs/src/sys/dev/fdt/axppmic.c,v
retrieving revision 1.19
diff -u -p -r1.19 axppmic.c
--- axppmic.c 31 Jul 2023 12:23:35 - 1.19
+++ axppmic.c 31 Jul 2023 13:00:12 -
@@ -126,6 +126,21 @@ const struct axppmic_regdata axp221_regd
{ NULL }
};
+const struct axppmic_regdata axp313a_regdata[] = {
+ /* dcdc1: 1.6-3.4V (100mV step) not supported */
+ { "dcdc1", 0x10, (1 << 0), (1 << 0), (0 << 0),
+ 0x13, 0x7f, 50, 1, 71, 122000, 2, 17 },
+ { "dcdc2", 0x10, (1 << 1), (1 << 1), (0 << 1),
+ 0x14, 0x7f, 50, 1, 71, 122000, 2, 17 },
+ { "dcdc3", 0x10, (1 << 2), (1 << 2), (0 << 2),
+ 0x15, 0x7f, 50, 1, 71, 122000, 2, 32 },
+ { "aldo1", 0x10, (1 << 3), (1 << 3), (0 << 3),
+ 0x16, 0x1f, 50, 10, 31 },
+ { "dldo1", 0x10, (1 << 4), (1 << 4), (0 << 4),
+ 0x17, 0x1f, 50, 10, 31 },
+ { NULL }
+};
+
const struct axppmic_regdata axp803_regdata[] = {
{ "dcdc1", 0x10, (1 << 0), (1 << 0), (0 << 0),
0x20, 0x1f, 160, 10, 19 },
@@ -354,6 +369,7 @@ const struct axppmic_device axppmic_devi
{ "x-powers,axp221", "AXP221", axp221_regdata, axp221_sensdata },
{ "x-powers,axp223", "AXP223", axp221_regdata, axp221_sensdata },
{ "x-powers,axp305", "AXP305", axp806_regdata },
+ { "x-powers,axp313a", "AXP313A", axp313a_regdata },
{ "x-powers,axp803", "AXP803", axp803_regdata, axp803_sensdata },
{ "x-powers,axp805", "AXP805", axp806_regdata },
{ "x-powers,axp806", "AXP806", axp806_regdata },
--
SASANO Takayoshi (JG1UAA)
rpki-client: check CMS versions
Now that we have accessors for the SignedData and SignerInfo version
in libcrypto, let's put them to their intended use. For portable I have
made a PR to provide compat shims.
Index: cms.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cms.c,v
retrieving revision 1.38
diff -u -p -r1.38 cms.c
--- cms.c 29 Jun 2023 10:28:25 - 1.38
+++ cms.c 31 Jul 2023 08:31:10 -
@@ -100,6 +100,7 @@ cms_parse_validate_internal(X509 **xp, c
const ASN1_OBJECT *obj, *octype;
ASN1_OCTET_STRING *kid = NULL;
CMS_ContentInfo *cms;
+ long version;
STACK_OF(X509) *certs = NULL;
STACK_OF(X509_CRL) *crls;
STACK_OF(CMS_SignerInfo)*sinfos;
@@ -142,7 +143,6 @@ cms_parse_validate_internal(X509 **xp, c
}
/* RFC 6488 section 3 verify the CMS */
- /* the version of SignedData and SignerInfos can't be verified */
/* Should only return NULL if cms is not of type SignedData. */
if ((sinfos = CMS_get0_SignerInfos(cms)) == NULL) {
@@ -160,6 +160,23 @@ cms_parse_validate_internal(X509 **xp, c
goto out;
}
si = sk_CMS_SignerInfo_value(sinfos, 0);
+
+ if (!CMS_get_version(cms, )) {
+ warnx("%s: Failed to retrieve SignedData version", fn);
+ goto out;
+ }
+ if (version != 3) {
+ warnx("%s: SignedData version %ld != 3", fn, version);
+ goto out;
+ }
+ if (!CMS_SignerInfo_get_version(si, )) {
+ warnx("%s: Failed to retrieve SignerInfo version", fn);
+ goto out;
+ }
+ if (version != 3) {
+ warnx("%s: SignerInfo version %ld != 3", fn, version);
+ goto out;
+ }
nattrs = CMS_signed_get_attr_count(si);
if (nattrs <= 0) {
