On Thu, 07 Jul 2022 14:02:35 +0900 (JST)
YASUOKA Masahiko wrote:
> Hello Scott,
>
> With the patch, my machine on ESXi it doesn't show any extra message.
>
> *Without* the patch, the machine shows
>
> % grep 'TSC.*skew' dmesg.current-tsc-debug
> cpu1: disabling user TSC (skew=-2603)
>
Hello Scott,
With the patch, my machine on ESXi it doesn't show any extra message.
*Without* the patch, the machine shows
% grep 'TSC.*skew' dmesg.current-tsc-debug
cpu1: disabling user TSC (skew=-2603)
cpu2: disabling user TSC (skew=-2959)
cpu3: disabling user TSC (skew=-3784)
%
and
Over a decade ago there was some work in bsd.man.mk to build tbl pages
with mandoc. For example this commit from 2010:
revision 1.32
date: 2010/10/17 22:47:08; author: schwarze; state: Exp; lines: +8 -18;
Build tbl(1) pages with mandoc(1), not groff.
Xenocara
On 7/7/22 11:29, Scott Cheloha wrote:
On Thu, Jul 07, 2022 at 11:13:14AM +0900, Yuichiro NAITO wrote:
I had another try for the v3 patch that runs on FreeBSD bhyve.
In this case, I need the following patch for TSC to be chosen as a timecounter.
diff --git a/sys/arch/amd64/amd64/tsc.c
On Thu, Jul 07, 2022 at 11:13:14AM +0900, Yuichiro NAITO wrote:
> I had another try for the v3 patch that runs on FreeBSD bhyve.
> In this case, I need the following patch for TSC to be chosen as a
> timecounter.
>
> diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> index
This always happens when OpenBSD runs on FreeBSD bhyve.
Usually OpenBSD gets TSC frequency from CPUID 0x15,
but FreeBSD bhyve disables it by the following commit.
https://cgit.freebsd.org/src/commit/?id=ec048c755076befde5bf533911c70a01d59abdda
Then OpenBSD tries to measure TSC frequency by
I had another try for the v3 patch that runs on FreeBSD bhyve.
In this case, I need the following patch for TSC to be chosen as a timecounter.
diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
index c4d3acda8c7..ab34df4463c 100644
--- a/sys/arch/amd64/amd64/tsc.c
+++
On Wed, Jul 06, 2022 at 01:58:51PM -0700, Mike Larkin wrote:
> On Wed, Jul 06, 2022 at 11:48:41AM -0500, Scott Cheloha wrote:
> > > On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
> > >
> > > On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> > >> On Tue, Jul 05, 2022 at 01:38:32PM
On Wed, Jul 06, 2022 at 08:20:05PM -0400, Mohamed Aslan wrote:
> > First, you need to update to the latest firmware. Maybe they already
> > fixed the problem. I don't see any mention of the TSC in the BIOS
> > changelog for the e495 but maybe you'll get lucky.
> >
> > Second, if they haven't
> First, you need to update to the latest firmware. Maybe they already
> fixed the problem. I don't see any mention of the TSC in the BIOS
> changelog for the e495 but maybe you'll get lucky.
>
> Second, if they haven't fixed the problem with the latest firmware, I
> recommend you reach out to
On Wed, Jul 06, 2022 at 11:48:41AM -0500, Scott Cheloha wrote:
> > On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
> >
> > On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> >> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
> >>> On Mon, Jul 04, 2022 at 09:06:55PM
Now that the kernel supports the extended BOOTARG_CONSDEV struct and
snaps with that change are out there, here is the diff that changes
the amd64 bootloaders to switch to the extended struct and provide the
parameters necessary for using the non-standard UART on the AMD Ryzen
Embedded V1000 SoCs.
On Wed, Jul 06, 2022 at 06:56:28PM +0200, Claudio Jeker wrote:
> On Wed, Jul 06, 2022 at 06:15:45PM +0200, Theo Buehler wrote:
> > On Wed, Jul 06, 2022 at 05:07:45PM +0200, Claudio Jeker wrote:
> > > This diff changes various loops which call into up_generate_update() so
> > > that all these loops
> On Jul 6, 2022, at 10:04 AM, Christian Weisgerber wrote:
>
> Scott Cheloha:
>
>>> kern.timecounter.tick=1
>>> kern.timecounter.timestepwarnings=0
>>> kern.timecounter.hardware=i8254
>>> kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>>
>> This is expected
On Wed, Jul 06, 2022 at 06:15:45PM +0200, Theo Buehler wrote:
> On Wed, Jul 06, 2022 at 05:07:45PM +0200, Claudio Jeker wrote:
> > This diff changes various loops which call into up_generate_update() so
> > that all these loops call the same function peer_generate_update() which
> > then calls
> On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
>
> On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
>> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
>>> On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
[...]
>>>
>>> Here's the output from
On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
> > On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> >
> > Here's the output from a 4 socket 80 thread machine.
>
> Oh nice. I think this
On Wed, Jul 06, 2022 at 05:07:45PM +0200, Claudio Jeker wrote:
> This diff changes various loops which call into up_generate_update() so
> that all these loops call the same function peer_generate_update() which
> then calls up_generate_update(). This is a step to add an alternative path
> to
On Wed, Jul 06, 2022 at 01:48:39AM -0400, Mohamed Aslan wrote:
> > This is expected behavior with the patch.
> >
> > cpu0's TSC is way out of sync with every
> > other CPU's TSC, so the TSC is marked
> > as a bad timecounter and a different one is
> > chosen.
>
> Yes, I can see. Just want to add
This diff changes various loops which call into up_generate_update() so
that all these loops call the same function peer_generate_update() which
then calls up_generate_update(). This is a step to add an alternative path
to generate updates for add-path send support without altering many
Scott Cheloha:
> > kern.timecounter.tick=1
> > kern.timecounter.timestepwarnings=0
> > kern.timecounter.hardware=i8254
> > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>
> This is expected behavior with the patch.
>
> cpu0's TSC is way out of sync with every
>
On Wed, Jul 06, 2022 at 09:13:29AM +0200, Sebastien Marie wrote:
> Hi,
>
> I am currently debugging some unveil issues reported when process accounting
> in
> enabled (see acct(2)).
>
> xlock is currently doing some unveil(2) violation:
>
> $ lastcomm | grep U
> xlock-FU
On Tue, Jul 05, 2022 at 07:04:49AM -0500, Scott Cheloha wrote:
> On Tue, Jul 05, 2022 at 11:53:26AM +0200, Claudio Jeker wrote:
> > On Tue, Jul 05, 2022 at 11:34:21AM +, Job Snijders wrote:
> > > On Tue, Jul 05, 2022 at 11:08:13AM +0200, Claudio Jeker wrote:
> > > > On Mon, Jul 04, 2022 at
On Wed, Jul 06, 2022 at 09:13:29AM +0200, Sebastien Marie wrote:
> Hi,
>
> I am currently debugging some unveil issues reported when process accounting
> in
> enabled (see acct(2)).
>
> xlock is currently doing some unveil(2) violation:
>
> $ lastcomm | grep U
> xlock-FU
usage/synopsis should be consistent:
$ kstat -h
kstat: unknown option -- h
usage: kstat [-w wait] [name | provider:0:name:unit] ...
$ man -hs1 kstat
kstat [-w wait] [name | provider:instance:name:unit] ...
Stick with the manual text, which also has
Hi,
I am currently debugging some unveil issues reported when process accounting in
enabled (see acct(2)).
xlock is currently doing some unveil(2) violation:
$ lastcomm | grep U
xlock-FU semarie __
0.00 secs Wed Jul 6 07:13
26 matches
Mail list logo
