On Mon, Aug 15, 2022 at 01:09:55AM +0700, Robert Elz wrote:
> | N.B. It would be nice if there were a (MI) boot option that could be used
> | to influence HZ without recompiling. Booting into ddb and patching hz
> | and a few derived variables isn't that comfortable.
>
> It would be nice...
Date:Sun, 14 Aug 2022 15:52:35 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| N.B. It would be nice if there were a (MI) boot option that could be used
| to influence HZ without recompiling. Booting into ddb and patching hz
| and a few deri
k...@munnari.oz.au (Robert Elz) writes:
>Pity this won't help with PR 43997 - but I conclude from your response about
>that, that if the host running qemu had HZ set significantly higher than 100
>then qemu (hosting a kernel with HZ==100) would probably work just fine?
Yes.
FreeBSD has the follo
Date:Sun, 14 Aug 2022 00:28:38 +0200
From:Joerg Sonnenberger
Message-ID:
| Does the interrupt rate match HZ?
Yes. I rebooted the system I tested yesterday (which behaved just the
same as reported then .. which I guess was technically the early hours
of this morn
s...@stix.id.au (Paul Ripke) writes:
>This is likely somewhat similar to what I reported here:
>http://mail-index.netbsd.org/current-users/2019/07/29/msg036293.html
>tl;dr: weird clock behaviour on GCE micro instances. This at least
>provides a nice easy testbed.
| ACPI-Safe: ntp syncs fine, clo
This is likely somewhat similar to what I reported here:
http://mail-index.netbsd.org/current-users/2019/07/29/msg036293.html
tl;dr: weird clock behaviour on GCE micro instances. This at least
provides a nice easy testbed.
--
Paul Ripke
"Great minds discuss ideas, average minds discuss events, s
On Sun, Aug 14, 2022 at 09:00:20AM +0700, Robert Elz wrote:
> Date:Sun, 14 Aug 2022 00:28:38 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> | I'm more wondering about the LAPIC frequency here. That one is normally
> | used to drive the clockintr and if that fr
Date:Sun, 14 Aug 2022 00:28:38 +0200
From:Joerg Sonnenberger
Message-ID:
| I'm more wondering about the LAPIC frequency here. That one is normally
| used to drive the clockintr and if that frequency is off, interrupt rate
| would be off too. Does the interrupt
On Sun, Aug 14, 2022 at 02:38:07AM +0700, Robert Elz wrote:
> To avoid delays in a message turnaround, this is what sysctl says is
> available (this output is from a normal boot, not the PCIDUMP one).
>
> kern.timecounter.choice = TSC(q=3000, f=3417601000 Hz) clockinterrupt(q=0,
> f=100 Hz) lapic
mlel...@serpens.de (Michael van Elst) writes:
>In your case, you say it takes ~6 minutes between attachment and
>calibration and your hpet runs at 19.2MHz.
>This is enough for HPET_MCOUNT_LO to overflow.
This patch adds a separate delay of ~0.1 seconds to calibrate
the timers. This should avoi
On Sun, Aug 14, 2022 at 02:38:07AM +0700, Robert Elz wrote:
> Date:Sat, 13 Aug 2022 17:41:05 +0200
> From:Michael van Elst
> Message-ID:
>
> | If you boot the kernel in debug mode (netbsd -x),
>
> I did.
>
> | you may see output like:
>
> which was:
>
> [
Date:Sat, 13 Aug 2022 17:41:05 +0200
From:Michael van Elst
Message-ID:
| If you boot the kernel in debug mode (netbsd -x),
I did.
| you may see output like:
which was:
[ 1.03] cpu0: TSC freq CPUID 341760 Hz
[ 1.03] cpu0: TSC freq from CPUI
Date:Sun, 7 Aug 2022 09:17:52 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Does this help ?
|
| Index: sys/arch/x86/x86/cpu.c
Finally got a chance to test that patch properly - sorry for the delay.
The result: "not much" if anything a
On Sat, Aug 13, 2022 at 10:15:30PM +0700, Robert Elz wrote:
>
> The result: "not much" if anything at all.
If you boot the kernel in debug mode (netbsd -x), you may see
output like:
[ 1.03] cpu0: TSC freq from delay 2521276800 Hz
maybe also something like:
[ ] cpu0: TSC fr
Date:Sun, 7 Aug 2022 09:17:52 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Does this help ?
I'll try it and let you know. Thanks.It might take a few days.
kre
k...@munnari.oz.au (Robert Elz) writes:
>Date:Thu, 4 Aug 2022 12:49:35 - (UTC)
>From:mlel...@serpens.de (Michael van Elst)
>Message-ID:
> | The measurement runs with enabled interrupts. If you have lots of
> interrupts
> | or interrupts that take some time, th
Date:Thu, 4 Aug 2022 12:49:35 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| The measurement runs with enabled interrupts. If you have lots of interrupts
| or interrupts that take some time, the measurement is biased.
|
| Console output c
k...@munnari.oz.au (Robert Elz) writes:
>The issue only occurs when I boot a kernel with options PCI_CONFIG_DUMP
>enabled, which is (one way or the other) almost certainly responsible for
>the issue - though the problem you mention may be involved in the kernel's
>failure to detect that the TSC me
Date:Wed, 3 Aug 2022 22:30:34 +
From:David Holland
Message-ID:
| so if your previous kernel was fairly old and you
| still have older boot logs lying around you might check them for
| such notices.
This is an entirely new system, the oldest kernel it has e
dholland-curr...@netbsd.org (David Holland) writes:
>On Thu, Jul 14, 2022 at 08:59:25PM +0700, Robert Elz wrote:
> > I just booted a kernel that I built (from up to date at the time)
> > HEAD sources about 24 hours ago.
> >
> > Everything seemed to be working fine - until I noticed that all of
>
On Thu, Jul 14, 2022 at 08:59:25PM +0700, Robert Elz wrote:
> I just booted a kernel that I built (from up to date at the time)
> HEAD sources about 24 hours ago.
>
> Everything seemed to be working fine - until I noticed that all of
> my clocks (there are several, gkrellm, window manager, a
Date:Wed, 20 Jul 2022 21:18:33 + (UTC)
From:RVP
Message-ID:
| Yes indeed. src/sys/arch/x86/x86/genfb_machdep.c:1.17 _has_ fixed this
| little issue quite satisfactorily. Thank you, Michael :)
Oh, yes, Sorry - meant to send a message like that a couple of day
On Sat, 16 Jul 2022, Robert Elz wrote:
But it appears as if mlelstv@ might have fixed the colour issue now anyway.
Yes indeed. src/sys/arch/x86/x86/genfb_machdep.c:1.17 _has_ fixed this
little issue quite satisfactorily. Thank you, Michael :)
-RVP
Hi,
On 2022/07/15 21:38, Robert Elz wrote:
> Date:Fri, 15 Jul 2022 13:32:55 +0900
> From:Masanobu SAITOH
> Message-ID: <87553319-950b-7dad-ac64-29d2c25d1...@execsw.org>
>
> | Could you show me the full dmesg with verbose output?
>
> I could, but it turns out to be
Date:Sat, 16 Jul 2022 00:20:41 + (UTC)
From:RVP
Message-ID:
| On Fri, 15 Jul 2022, Robert Elz wrote:
| > If that is all it is, it is barely worth fixing ... though this
| > must have happened sometime in the 9.99.9[78] series (sometime
| > after early las
Date:Sat, 16 Jul 2022 06:09:26 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| For the green color it doesn't matter if the order is BGR or RGB.
| For cyan, the wrong order gives "brown" which is a dark yellow.
I tossed up what to call the co
r...@sdf.org (RVP) writes:
>Unsurprisingly, EFI also has a colour-index similar to VGA (see:
>/usr/src/sys/external/bsd/gnu-efi/dist/inc/eficon.h). I tried fixing the
>indexes like this, but, it doesn't for some (autoconfig?) reason. Can
>only look into this after I come back from my road-trip.
T
On Fri, 15 Jul 2022, Robert Elz wrote:
If that is all it is, it is barely worth fixing ... though this
must have happened sometime in the 9.99.9[78] series (sometime
after early last Dec).
Farther back than that I think: 9.2_STABLE does the same thing.
On Fri, 15 Jul 2022, Michael van Elst w
Date:Fri, 15 Jul 2022 13:32:55 +0900
From:Masanobu SAITOH
Message-ID: <87553319-950b-7dad-ac64-29d2c25d1...@execsw.org>
| Could you show me the full dmesg with verbose output?
I could, but it turns out to be about a megabyte, so unless you need
to see all that nois
Date:Fri, 15 Jul 2022 05:12:10 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Does the color shift also happen after a cold boot ?
Yes, it is yellow, rather than cyan, when the system boots,
cold or warm (or if booting warm after linux had bor
Date:Fri, 15 Jul 2022 05:12:10 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Does the color shift also happen after a cold boot ?
Not sure, I rarely do that, and don't think I ever have for a kernel
intended to have cyan text. I will try it
Date:Fri, 15 Jul 2022 13:32:55 +0900
From:Masanobu SAITOH
Message-ID: <87553319-950b-7dad-ac64-29d2c25d1...@execsw.org>
| Could you show me the full dmesg with verbose output?
Sure, it will take me a bit to get to a state where I can reboot again.
You do realize t
k...@munnari.oz.au (Robert Elz) writes:
> | Heh. It's not just Cyan/Yellow; Red and Blue are swapped too, because:
> |
> | /usr/src/sys/dev/wscons/wsdisplayvar.h and
> | /usr/src/sys/dev/ic/pcdisplay.h have different values for those colour=
>s.
>If that is all it is, it is barely worth fixin
Date:Thu, 14 Jul 2022 23:17:36 + (UTC)
From:RVP
Message-ID: <259960d6-9f5d-56c9-6f15-46766387f...@sdf.org>
| Works OK for me with an updated-just-now customized (ie. just a lot of stuff
| removed) GENERIC.
My kernel is similar (though still has too much unnec
On 2022/07/14 22:59, Robert Elz wrote:
> Hi,
>
> I just booted a kernel that I built (from up to date at the time)
> HEAD sources about 24 hours ago.
>
> Everything seemed to be working fine - until I noticed that all of
> my clocks (there are several, gkrellm, window manager, a dclock,
> and
On Thu, 14 Jul 2022, Robert Elz wrote:
Anyone have any ideas? Note that the CPU is an Alder Lake - has both
performance and economy cores which run at different rates (which NetBSD
knows nothing about, yet, but that's OK) - core speed is always subject
to variation anyway, so that should not m
Hi,
I just booted a kernel that I built (from up to date at the time)
HEAD sources about 24 hours ago.
Everything seemed to be working fine - until I noticed that all of
my clocks (there are several, gkrellm, window manager, a dclock,
and an xtu) were all wildly wrong (as in, were moving time for
37 matches
Mail list logo
