daily CVS update output
Updating src tree: P src/distrib/utils/x_fsck_ffs/Makefile P src/distrib/utils/x_newfs/Makefile P src/sys/arch/cats/conf/Makefile.cats.inc P src/sys/arch/shark/conf/Makefile.shark.inc P src/sys/arch/x86/x86/errata.c P src/sys/arch/xen/xen/xbd_xenbus.c P src/tests/usr.bin/xlint/lint1/c23.c P src/usr.bin/xlint/lint1/decl.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P sys/arch/x86/include/specialreg.h P sys/arch/x86/x86/errata.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.4 P sys/arch/x86/include/specialreg.h P sys/arch/x86/x86/errata.c P sys/arch/x86/x86/fpu.c P sys/dev/nvmm/x86/nvmm_x86_svm.c Updating release-9 xsrc tree (netbsd-9): Updating release-10 src tree (netbsd-10): U doc/CHANGES-10.0 P lib/libc/time/NEWS P lib/libc/time/localtime.c P lib/libc/time/private.h P lib/libc/time/zdump.c P lib/libc/time/zic.c P sys/arch/x86/include/cpu_extended_state.h P sys/arch/x86/include/specialreg.h P sys/arch/x86/x86/errata.c P sys/arch/x86/x86/fpu.c P sys/dev/nvmm/x86/nvmm_x86_svm.c P usr.sbin/bta2dpd/bta2dpd/bta2dpd.8 P usr.sbin/bta2dpd/bta2dpd/sbc_encode.c Updating release-10 xsrc tree (netbsd-10): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 46984469 Jul 26 03:13 ls-lRA.gz
Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"
Can you please try running with the attached patch and share the
warnings it produces? Should give slightly more information.
>From b6f360d9b1fdc418105fcc41b41f1206ca04334d Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Wed, 26 Jul 2023 01:36:28 +
Subject: [PATCH] WIP: attribution for l_stime updates
---
sys/kern/init_main.c| 4 +++-
sys/kern/kern_idle.c| 4 +++-
sys/kern/kern_softint.c | 4 +++-
sys/kern/kern_synch.c | 53 -
4 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
index 1d2dbd742fed..bc43f7dd18e9 100644
--- a/sys/kern/init_main.c
+++ b/sys/kern/init_main.c
@@ -254,6 +254,8 @@ static void configure2(void);
static void configure3(void);
void main(void);
+void updatestime(struct lwp *, const struct bintime *); /* XXX */
+
/*
* System startup; initialize the world, create process 0, mount root
* filesystem, and fork to create init and pagedaemon. Most of the
@@ -728,7 +730,7 @@ main(void)
mutex_exit(p->p_lock);
}
mutex_exit(&proc_lock);
- binuptime(&curlwp->l_stime);
+ updatestime(curlwp, NULL);
for (CPU_INFO_FOREACH(cii, ci)) {
ci->ci_schedstate.spc_lastmod = time_second;
diff --git a/sys/kern/kern_idle.c b/sys/kern/kern_idle.c
index dc1fc194f491..b5c6f7a4d90e 100644
--- a/sys/kern/kern_idle.c
+++ b/sys/kern/kern_idle.c
@@ -41,6 +41,8 @@ __KERNEL_RCSID(0, "$NetBSD: kern_idle.c,v 1.34 2020/09/05
16:30:12 riastradh Exp
#include/* uvm_idle */
+void updatestime(struct lwp *, const struct bintime *); /* XXX */
+
void
idle_loop(void *dummy)
{
@@ -53,7 +55,7 @@ idle_loop(void *dummy)
KASSERT(lwp_locked(l, spc->spc_lwplock));
kcpuset_atomic_set(kcpuset_running, cpu_index(ci));
/* Update start time for this thread. */
- binuptime(&l->l_stime);
+ updatestime(l, NULL);
spc->spc_flags |= SPCF_RUNNING;
KASSERT((l->l_pflag & LP_RUNNING) != 0);
l->l_stat = LSIDL;
diff --git a/sys/kern/kern_softint.c b/sys/kern/kern_softint.c
index 5aa4c786037c..370d22bb94ca 100644
--- a/sys/kern/kern_softint.c
+++ b/sys/kern/kern_softint.c
@@ -793,6 +793,8 @@ softint_thread(void *cookie)
panic("softint_thread");
}
+void updatestime(struct lwp *, const struct bintime *); /* XXX */
+
/*
* softint_dispatch:
*
@@ -841,7 +843,7 @@ softint_dispatch(lwp_t *pinned, int s)
* for it.
*/
if (timing) {
- binuptime(&l->l_stime);
+ updatestime(l, NULL);
membar_producer(); /* for calcru */
l->l_pflag |= LP_TIMEINTR;
}
diff --git a/sys/kern/kern_synch.c b/sys/kern/kern_synch.c
index 6695205ac900..13862681c9fb 100644
--- a/sys/kern/kern_synch.c
+++ b/sys/kern/kern_synch.c
@@ -545,6 +545,57 @@ updatertime(lwp_t *l, const struct bintime *now)
bintime_sub(&l->l_rtime, &l->l_stime);
}
+void updatestime(struct lwp *, const struct bintime *); /* XXX */
+void
+updatestime(struct lwp *l, const struct bintime *now)
+{
+ static bool backwards = false;
+ struct bintime bt;
+ void *hereaddr = __builtin_return_address(0);
+ unsigned herecpu = curcpu()->ci_index;
+
+ if (now == NULL) {
+ binuptime(&bt);
+ now = &bt;
+ }
+
+ if (__predict_false(bintimecmp(now, &l->l_stime, <)) && !backwards) {
+ char heresym[128], theresym[128];
+ void *thereaddr = l->l_sched.info; /* XXX */
+ unsigned therecpu = l->l___rsvd1;
+
+#ifdef DDB
+ db_symstr(heresym, sizeof(heresym),
+ (db_expr_t)(intptr_t)hereaddr, DB_STGY_PROC);
+ db_symstr(theresym, sizeof(theresym),
+ (db_expr_t)(intptr_t)thereaddr, DB_STGY_PROC);
+#else
+ snprintf(heresym, sizeof(heresym), "%p", hereaddr);
+ snprintf(theresym, sizeof(theresym), "%p", thereaddr);
+#endif
+ backwards = true;
+ printf("WARNING: lwp %ld (%s%s%s) flags 0x%x:"
+ " timecounter went backwards"
+ " from (%jd + 0x%016"PRIx64"/2^64) sec"
+ " at %s on cpu%u"
+ " to (%jd + 0x%016"PRIx64"/2^64) sec"
+ " at %s on cpu%u\n",
+ (long)l->l_lid,
+ l->l_proc->p_comm,
+ l->l_name ? " " : "",
+ l->l_name ? l->l_name : "",
+ l->l_pflag,
+ (intmax_t)l->l_stime.sec, l->l_stime.frac,
+ theresym, therecpu,
+ (intmax_t)now->sec, now->frac,
+ heresym, herecpu);
+ }
+
+ l->l_stime = *now;
+ l->l_sched.info = hereaddr;
+ l->l___rsvd1 = herecpu;
+}
+
/*
* Select next LWP from the current CPU to run..
*/
@@ -695,7 +746,7 @@ mi_switch(lwp_t *l)
u
Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"
Taylor R Campbell writes:
>> Date: Thu, 20 Jul 2023 21:50:26 -0400
>> From: Brad Spencer
>>
>> With a DOMU kernel compiled with KDTRACE_HOOKS I get the following with
>> either of those dtrace probes on the DOMU:
>>
>> dtrace -n 'sdt:xen:clock:, sdt:xen:hardclock:, sdt:xen:timecounter: {
>> printf("%d %d %d %d %d %d %d", arg0, arg1, arg2, arg3, arg4, arg5, arg6,
>> arg7) }'
>> dtrace: invalid probe specifier sdt:xen:clock:, sdt:xen:hardclock:,
>> sdt:xen:timecounter: { printf("%d %d %d %d %d %d %d", arg0, arg1, arg2,
>> arg3, arg4, arg5, arg6, arg7) }: "/usr/lib/dtrace/psinfo.d", line 46: syntax
>> error near "u_int"
>
> Can you please file a PR about that, and pass `-x nolibs' to dtrace in
> the mean time?
>
> dtrace -x nolibs -n 'sdt:xen:clock:...'
Back to the original problem
I got this on the console:
[ 159564.607341] WARNING: lwp 105 (system pgdaemon) flags 0x20020020:
timecounter went backwards from (159565 + 0x60917da1f41f3971/2^64) sec to
(159564 + 0x9b7aac0ce33a822d/2^64) sec in netbsd:mi_switch+0x112
I assume that this indicates some or other is going off the rails.
$ vmstat -e | grep -e tsc -e systime -e hardclock
vcpu0 missed hardclock16031340 92 intr
vcpu1 missed hardclock 534620 intr
The dtrace probes produced some amount of timecounter:backwards and tons
of hardclock:missed events.
The system is mostly idle right now with out the only thing going on
being a cvs update. Some some amount of disk activity.
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
video (nouveau) speed-up with 10.99.6
Well, I hadn't noticed any relevant commit messages, but I just upgraded from 10.99.4 to 10.99.6 and I was pleasantly surprised! Firefox (and several other large graphics programs which used to take 10-20 seconds to start up now seem to take only 2 or 3 seconds before being fully functional! Whoever/whatever is responsible, a huge *T*H*A*N*K*S* for this! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: fdisk and alignment
On Mon, 10 Jul 2023 at 10:06, Martin Husemann wrote: > > On Sun, Jul 09, 2023 at 08:54:56PM +0100, David Brownlee wrote: > > In practice I think it would be better not to penalise current use of > > "small" (120GB SSD or 64GB or or CF/USB devices) for an edge case of > > older hardware > > I am not sure what you see as penalty here. An offset of 63 sectors is guaranteed to be non-optimal for any device with larger than 512 byte internal block size. As such it's likely a poor choice for any solid state storage, and potentially some traditional disks (though any of the latter with > 512 byte sectors are almost certainly > 128GB and so avoid the behaviour). > I think two factors made the original size decisions sensible back then: > > - for large disks the space lost to alignment does not matter > - native block sizes > 512 byte only happened for larger disks initially > > Overall it would be better to enforce alignment as least as large as the > native block size on *any* disk - but IIRC it is quite hard to find that > value in all cases. We currently effectively have two values - 63 sectors and 1MB. We have the cutoff between them at 128GB. I propose moving that to 2GB, to gain the more optimal alignment on devices from 2GB to 128GB. Thanks David
