Hi,
clockframe is sometimes defined in cpu.h, sometimes in frame.h, and
sometimes defined once each in both header files.
Can we put the clockframe definitions in frame.h? Always? It is, at
least ostensibly, a "frame".
I do not want to consolidate the clockframe definitions in cpu.h
because
On Wed, Aug 17, 2022 at 01:30:29PM +, Visa Hankala wrote:
> On Tue, Aug 09, 2022 at 09:54:02AM -0500, Scott Cheloha wrote:
> > On Tue, Aug 09, 2022 at 02:03:31PM +, Visa Hankala wrote:
> > > On Mon, Aug 08, 2022 at 02:52:37AM -0500, Scott Cheloha wrote:
> >
On Wed, Aug 17, 2022 at 02:28:14PM +1000, Jonathan Gray wrote:
> On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> > On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> > >
> > > In the future when the LAPIC t
On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> >
> > In the future when the LAPIC timer is run in oneshot mode there will
> > be no lapic_delay().
> >
> > [...]
> >
> >
On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
>
> In the future when the LAPIC timer is run in oneshot mode there will
> be no lapic_delay().
>
> [...]
>
> This is *very* bad for older amd64 machines, because you are left with
> i8254_delay().
>
>
Hi,
In the future when the LAPIC timer is run in oneshot mode there will
be no lapic_delay().
This is fine if you have a constant TSC, because we have tsc_delay().
This is *very* bad for older amd64 machines, because you are left with
i8254_delay().
I would like to offer a less awful delay(9)
This is a good one.
$ renice -n -1 -p 1 ; echo $?
renice: setpriority: 1: Operation not permitted
1
$ renice -n -1 -p 1 1 ; echo $?
renice: setpriority: 1: Operation not permitted
renice: setpriority: 1: Operation not permitted
2
$ renice -n -1 -p 1 1 1 ; echo $?
renice: setpriority: 1: Operation
On Thu, Aug 11, 2022 at 02:22:08AM +0200, Jeremie Courreges-Anglas wrote:
> On Wed, Aug 10 2022, Scott Cheloha wrote:
> > [...]
> >
> > 1. Our ksh(1) already checks for stdout errors in the echo builtin.
>
> So do any of the scripts in our source tree use /bin/echo fo
On Wed, Aug 10, 2022 at 02:23:08PM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > On Wed, Aug 10, 2022 at 12:26:17PM -0600, Theo de Raadt wrote:
> > > Scott Cheloha wrote:
> > >
> > > > We're sorta-kinda circling around adding the missing
On Wed, Aug 10, 2022 at 12:26:17PM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > We're sorta-kinda circling around adding the missing (?) stdio error
> > checking to other utilities in bin/ and usr.bin/, no? I want to be
> > sure I understand how to do the n
On Sat, Jul 30, 2022 at 05:23:37PM -0600, Todd C. Miller wrote:
> On Sat, 30 Jul 2022 18:19:02 -0500, Scott Cheloha wrote:
>
> > Bump. The standard's error cases for fflush(3) are identical to those
> > for fclose(3):
> >
> > https://pubs.opengroup.org/onlinepubs/96
On Fri, Jul 29, 2022 at 08:13:14AM -0500, Scott Cheloha wrote:
> On Wed, Jul 13, 2022 at 12:50:24AM -0500, Scott Cheloha wrote:
> > We reduce overhead if we only parse the user's format string once. To
> > achieve that, this patch does the following:
> >
> > [.
On Tue, Aug 09, 2022 at 06:02:10PM +, Miod Vallat wrote:
> > Other platforms (architectures?) (powerpc, powerpc64, arm64, riscv64)
> > multiplex their singular interrupt clock to schedule both a
> > fixed-period hardclock and a pseudorandom statclock.
> >
> > This is the direction I intend to
On Tue, Aug 09, 2022 at 02:56:54PM +, Miod Vallat wrote:
> > Do those machines not have Coprocessor 0? If they do, why would you
> > prefer glxclk over CP0?
>
> cop0 only provides one timer, from which both the scheduling clock and
> statclk are derived. glxclk allows two timers to be used,
On Tue, Aug 09, 2022 at 02:03:31PM +, Visa Hankala wrote:
> On Mon, Aug 08, 2022 at 02:52:37AM -0500, Scott Cheloha wrote:
> > One thing I'm still uncertain about is how glxclk fits into the
> > loongson picture. It's an interrupt clock that runs hardclock() and
> > stat
On Sun, Aug 07, 2022 at 11:05:37AM +, Visa Hankala wrote:
> On Sun, Jul 31, 2022 at 01:28:18PM -0500, Scott Cheloha wrote:
> > Apparently mips64, i.e. octeon and loongson, has the same problem as
> > powerpc/macppc and powerpc64. The timer interrupt is normally only
>
On Fri, Sep 18, 2020 at 03:59:05PM -0500, Scott Cheloha wrote:
>
> [...]
>
> - An HH:MM:SS format uptime is useful in top(1). It's also more
> visually consistent with the local timestamp printed on the line
> above it, so it is easier to read at a glance.
>
>
On Fri, Aug 05, 2022 at 12:34:59AM +0200, Jeremie Courreges-Anglas wrote:
> >> [...]
> >>
> >> You're adding the timer reset to plic_setipl() but the latter is called
> >> after softintr processing in plic_splx().
> >>
> >>/* Pending software intr is handled here */
> >>if
On Thu, Aug 04, 2022 at 09:39:13AM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Aug 01 2022, Scott Cheloha wrote:
> > On Mon, Aug 01, 2022 at 07:15:33PM +0200, Jeremie Courreges-Anglas wrote:
> >> On Sun, Jul 31 2022, Scott Cheloha wrote:
> >> > Hi,
> >&g
On Wed, Nov 17, 2021 at 08:37:53AM -0600, Scott Cheloha wrote:
> In wc(1) we currently count words, both ASCII and multibyte, in a
> getline(3) loop.
>
> This makes sense in the multibyte case because stdio handles all the
> nasty buffer resizing for us. We avoid splitting a mu
On Mon, Jul 25, 2022 at 06:44:31PM -0500, Scott Cheloha wrote:
> On Mon, Jul 25, 2022 at 01:52:36PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 24 Jul 2022 19:33:57 -0500
> > > From: Scott Cheloha
> > >
> > > On Sat, Jul 23, 2022 a
dmesg(8) doesn't use any positional arguments. It's a usage error if
any are present.
ok?
Index: dmesg.c
===
RCS file: /cvs/src/sbin/dmesg/dmesg.c,v
retrieving revision 1.31
diff -u -p -r1.31 dmesg.c
--- dmesg.c 24 Dec 2019
On Mon, Aug 01, 2022 at 07:15:33PM +0200, Jeremie Courreges-Anglas wrote:
> On Sun, Jul 31 2022, Scott Cheloha wrote:
> > Hi,
> >
> > I am unsure how to properly mask RISC-V timer interrupts in hardware
> > at or above IPL_CLOCK. I think that would be cleaner t
On Mon, Aug 01, 2022 at 03:03:36PM +0900, Masato Asou wrote:
> Hi, Scott.
>
> I tested v5 patch on my ESXi on Ryzen7.
> It works fine for me.
Is this the same Ryzen7 box as in the prior message?
Or do you have two different boxes, one running OpenBSD on the bare
metal, and this one running
> On Jul 31, 2022, at 23:48, Masato Asou wrote:
>
> Hi, Scott
>
> I tested your patch on my Ryzen7 box.
> And I got failed message:
>
> $ sysctl -a | grep tsc
> kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
> acpitimer0(1000)
> machdep.tscfreq=3593244667
> machdep.invarianttsc=1
Hi,
I am unsure how to properly mask RISC-V timer interrupts in hardware
at or above IPL_CLOCK. I think that would be cleaner than doing
another timer interrupt deferral thing.
But, just to get the ball rolling, here a first attempt at the timer
interrupt deferral thing for riscv64. The
Hi,
Apparently mips64, i.e. octeon and loongson, has the same problem as
powerpc/macppc and powerpc64. The timer interrupt is normally only
logically masked, not physically masked in the hardware, when we're
running at or above IPL_CLOCK. If we arrive at cp0_int5() when the
clock interrupt is
Hi,
At the urging of sthen@ and dv@, here is v5.
Two major changes from v4:
- Add the function tc_reset_quality() to kern_tc.c and use it
to lower the quality of the TSC timecounter if we fail the
sync test.
tc_reset_quality() will choose a new active timecounter if,
after the quality
On Mon, Jul 11, 2022 at 01:27:23PM -0500, Scott Cheloha wrote:
> On Mon, Jul 11, 2022 at 08:31:04AM -0600, Todd C. Miller wrote:
> > On Sun, 10 Jul 2022 20:58:35 -0900, Philip Guenther wrote:
> >
> > > Three thoughts:
> > > 1) Since stdio errors are sticky, is the
Recently I've been doing some MIPS64 stuff on my EdgeRouter PoE. It
has a USB disk, two 500MHz processors, and 512MB of RAM.
So, every time I reboot to test the next iteration of my kernel
patch, I get to here:
reordering libraries:
and I sit there for half a minute or more and wonder
On Wed, Jul 13, 2022 at 12:50:24AM -0500, Scott Cheloha wrote:
> We reduce overhead if we only parse the user's format string once. To
> achieve that, this patch does the following:
>
> [...]
>
> - When parsing the user format string in fmtfmt(), keep a list of
> w
On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>
> Stuart Henderson writes:
>
> > On 2022/07/28 12:57, Scott Cheloha wrote:
> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
> >> >
> >> > This is breaking ti
> On Jul 28, 2022, at 13:41, Stuart Henderson wrote:
>
> On 2022/07/28 12:57, Scott Cheloha wrote:
>>> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>>>
>>> This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
>
On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > Hi,
> >
> > Thanks to everyone who tested v3.
> >
> > Attached is v4. I would like to put this into snaps (bcc: deraadt@).
> >
> > If you've been f
On Wed, Jul 27, 2022 at 07:31:11AM +0100, Jason McIntyre wrote:
> On Tue, Jul 26, 2022 at 09:18:47PM -0500, Scott Cheloha wrote:
> > A few improvements I want to make to the sleep(1) manpage.
> >
> > DESCRIPTION
> >
> > - "for a minimum of" is better sa
A few improvements I want to make to the sleep(1) manpage.
DESCRIPTION
- "for a minimum of" is better said "for at least".
- The seconds argument can be zero, so say "non-negative".
- Specify that the number (the whole thing) is decimal to exclude
e.g. hex numbers. It then follows that the
On Mon, Jul 25, 2022 at 01:52:36PM +0200, Mark Kettenis wrote:
> > Date: Sun, 24 Jul 2022 19:33:57 -0500
> > From: Scott Cheloha
> >
> > On Sat, Jul 23, 2022 at 08:14:32PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> > >
> >
On Sat, Jul 23, 2022 at 08:14:32PM -0500, Scott Cheloha wrote:
>
> [...]
>
> I don't have a powerpc64 machine, so this is untested. [...]
gkoehler@ has pointed out two dumb typos in the prior patch. My bad.
Here is a corrected patch that, according to gkoehler@, actually
comp
Okay, we did this for powerpc/macppc, on to powerpc64.
It's roughly the same problem as before:
- On powerpc64 we need to leave the DEC unmasked at or above
IPL_CLOCK.
- Currently we defer clock interrupt work to the next tick if a DEC
interrupt arrives when the CPU's priority level is at
2 Jul 2022 18:34:14 -
@@ -1,6 +1,7 @@
.\"$OpenBSD: timeout.9,v 1.55 2022/06/22 14:10:49 visa Exp $
.\"
.\" Copyright (c) 2000 Artur Grabowski
+.\" Copyright (c) 2021, 2022 Scott Cheloha
.\" All rights reserved.
.\"
.\" Redistribution and use in sour
> On Jul 22, 2022, at 05:50, Klemens Nanni wrote:
>
> NAME has it right:
>... – execute a function after a specified period of time
>
> but DESCRIPTION says something else:
>The timeout API provides a mechanism to execute a function
>at a given time.
>
> The latter reads as if I
Hi,
Thanks to everyone who tested v3.
Attached is v4. I would like to put this into snaps (bcc: deraadt@).
If you've been following along and testing these patches, feel free to
continue testing. If your results change from v3 to v4, please reply
with what happened and your dmesg.
I made a
> On Jul 20, 2022, at 01:48, Masato Asou wrote:
>
> Sorry, my latest reply.
>
> I tested your patch on my Proxmox Virtual Environment on Ryzen7 box.
> It works fine for me.
This VM doesn't have the ITSC CPU flag,
how is it using the TSC as a timecounter?
> OpenBSD 7.1-current (GENERIC.MP)
We reduce overhead if we only parse the user's format string once. To
achieve that, this patch does the following:
- Move "format" into main(). We don't need it as a global anymore.
- Move buffer allocation into fmtfmt(). As claudio@ mentioned in a
different thread, we need at most (3 *
On Mon, Jul 11, 2022 at 08:31:04AM -0600, Todd C. Miller wrote:
> On Sun, 10 Jul 2022 20:58:35 -0900, Philip Guenther wrote:
>
> > Three thoughts:
> > 1) Since stdio errors are sticky, is there any real advantage to checking
> > each call instead of just checking the final fclose()?
My thinking
ok?
Index: echo.c
===
RCS file: /cvs/src/bin/echo/echo.c,v
retrieving revision 1.10
diff -u -p -r1.10 echo.c
--- echo.c 9 Oct 2015 01:37:06 - 1.10
+++ echo.c 10 Jul 2022 22:00:18 -
@@ -53,12 +53,15 @@ main(int
aux slot)
> wsmouse0 at pms0 mux 0
> /dev/ksyms: Symbol table not valid.
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (31879798ea82ad23.a) swap on sd0b dump on sd0b
>
> $ sysctl kern.timecounter
> ke
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 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
> 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) acpihpet
> 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:
>>>>
>&g
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
> On Jul 5, 2022, at 23:02, Mohamed Aslan wrote:
>
> Hi,
>
> Apologies. My bad, I applied the latest patch but booted into another
> kernel with an earlier patch!
>
> Here's what I got with your latest patch:
>
> $ dmesg | grep 'tsc'
> tsc: cpu0/cpu1: sync test round 1/2 failed
> tsc:
> On Jul 5, 2022, at 21:31, Mohamed Aslan wrote:
>
> Hello,
>
> I just tested your patch on my lenovo e495 laptop, unfortunately
> still no tsc.
>
> $ dmesg | grep 'tsc:'
> tsc: cpu0/cpu1 sync round 1: 20468 regressions
> tsc: cpu0/cpu1 sync round 1: cpu0 lags cpu1 by 5351060292 cycles
> tsc:
On Thu, Jun 23, 2022 at 09:58:48PM -0500, Scott Cheloha wrote:
>
> [...]
>
> Thoughts? Tweaks?
>
> [...]
miod: Any issues?
kettenis: Anything to add? ok?
drahn: Anything to add? ok?
--
It would be nice (but not strictly necessary) to test this on a
machine doing &quo
On Wed, Jul 06, 2022 at 09:14:03AM +0900, Yuichiro NAITO wrote:
> Hi, Scott.
>
> I tested your patch on my OpenBSD running on ESXi.
> It works fine for me and I never see monotonic clock going backward.
> There is nothing extra messages in my dmesg.
Great! Thanks for testing.
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 is the biggest machine we've tried so far.
> kern
On Tue, Jul 05, 2022 at 06:40:26PM +0200, Stuart Henderson wrote:
> On 2022/07/05 11:22, Scott Cheloha wrote:
> > On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> > > On 2022/07/04 21:06, Scott Cheloha wrote:
> > > > 4. OpenBSD VMs on other
On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> On 2022/07/04 21:06, Scott Cheloha wrote:
> > 4. OpenBSD VMs on other hypervisors.
>
> KVM on proxmox VE 7.1-12
>
> I force acpihpet0 on this; it defaults to pvclock which results in
> timekeeping so bad
On Tue, Jul 05, 2022 at 05:38:04PM +0200, Stuart Henderson wrote:
> On 2022/07/04 21:06, Scott Cheloha wrote:
> > 2. Other multisocket machines.
>
> This is from the R620 where I originally discovered the problems
> with SMP with the previous TSC test:
>
> $ d
On Tue, Jul 05, 2022 at 10:53:43AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
> >>
> >> Scott Cheloha writes:
> >>
> >> > [...]
> >> >
> >>
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 05:10:05PM -0500, Scott Cheloha wrote:
> > > &
On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > [...]
> >
> > If you fail the test you will see something like this:
> >
> > tsc: cpu0/cpu2: sync test round 1/2 failed
> > tsc: cpu0/cpu2: cpu2:
Hi,
Once again, I am trying to change our approach to TSC sync testing to
eliminate false positive results. Instead of trying to repair the TSC
by measuring skew, we just spin in a lockless loop looking for skew
and mark the TSC as broken if we detect any.
This is motivated in part by some
On Mon, Jul 04, 2022 at 11:15:24PM +0200, Claudio Jeker wrote:
> On Mon, Jul 04, 2022 at 01:28:12PM -0500, Scott Cheloha wrote:
> > Hi,
> >
> > Couple things:
> >
> > [...]
>
> I don't like the introduction of all these local variables that are just
>
Hi,
Couple things:
- Use additional timespec variables to make our intent more obvious.
Add "elapsed", "utc_offset", and "utc_start".
"roff" is a confusing name, "utc_offset" is better.
Yes, I know the clock is called CLOCK_REALTIME, but that's a
historical accident. Ideally they
On Wed, Jun 29, 2022 at 10:34:53PM -0400, George Koehler wrote:
> Hi. I have a question about splx, below.
>
> On Thu, 23 Jun 2022 21:58:48 -0500
> Scott Cheloha wrote:
>
> > My machine uses openpic(4). I would appreciate tests on a
> > non-openpic(4) Mac, thoug
On Wed, Jun 15, 2022 at 10:40:35PM -0500, Scott Cheloha wrote:
> On Wed, Jun 15, 2022 at 06:17:07PM -0600, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> >
> > > Well, I believe that Scott was trying to fix a race condition that can
> > > only happen if code i
Hi,
One of the problems obstructing my dynamic clock interrupt patch is
that clock interrupts on powerpc don't (can't?) behave the same as
clock interrupts on amd64, arm64, and sparc64.
In particular, for historical reasons, on powerpc you cannot mask
decrementer (DEC) interrupts without *also*
All PIDs after we fork init(8) are random. This has been the case for
over 8 years:
https://cvsweb.openbsd.org/src/sys/kern/init_main.c?rev=1.193=text/x-cvsweb-markup
Are we keeping this "randompid" global around to make it possible to
disable random PIDs by toggling it in ddb(4)?
Maybe we
On Wed, Jun 15, 2022 at 06:17:07PM -0600, Theo de Raadt wrote:
> Mark Kettenis wrote:
>
> > Well, I believe that Scott was trying to fix a race condition that can
> > only happen if code is using kbind(2) incorrectly, i.e. when the
> > threads deliberately pass different cookies to kbind(2) or
On Sun, Jun 12, 2022 at 12:12:33AM -0600, Theo de Raadt wrote:
> David Gwynne wrote:
>
> > On Wed, May 18, 2022 at 07:42:32PM -0600, Theo de Raadt wrote:
> > > Mark Kettenis wrote:
> > >
> > > > > Isn't the vm_map_lock enough?
> > > >
> > > > Could be. The fast path is going to take that
> On May 24, 2022, at 7:12 PM, Scott Cheloha wrote:
>
> In the future, the clock interrupt will need a working timecounter to
> accurately reschedule itself.
>
> Move tc_init(9) up before cpu_startclock().
>
> (I can't test this but it seems correct.)
>
> ok
In the future, the clock interrupt will need a working timecounter to
accurately reschedule itself.
Move tc_init(9) up before cpu_startclock().
(I can't test this but it seems correct.)
ok?
Index: clock.c
===
RCS file:
ok?
Index: rthread_rwlock_compat.c
===
RCS file: /cvs/src/lib/librthread/rthread_rwlock_compat.c,v
retrieving revision 1.1
diff -u -p -r1.1 rthread_rwlock_compat.c
--- rthread_rwlock_compat.c 13 Feb 2019 13:15:39 - 1.1
> On May 11, 2022, at 2:51 AM, Yuichiro NAITO wrote:
>
> On 5/11/22 14:34, Yuichiro NAITO wrote:
>> After applying your patch, cpu1 is not identified on my current kernel.
>> Dmesg shows as follows. I'll see it further more.
>
> I found that LAPIC is necessary for `delay` function that is used
On Wed, May 11, 2022 at 10:52:55AM +0900, Yuichiro NAITO wrote:
> Hi, Scott.
>
> Recently I started running OpenBSD on ESXi.
> I'm facing monotonic time going back problem as same as Yasuoka-san's report.
>
> https://marc.info/?l=openbsd-tech=161657532610882=2
>
> I've tried your v2 patch. It
On Tue, Mar 29, 2022 at 10:24:03AM -0500, Scott Cheloha wrote:
> On Tue, Mar 29, 2022 at 03:26:49PM +1100, Jonathan Gray wrote:
> > On Mon, Mar 28, 2022 at 10:52:09PM -0500, Scott Cheloha wrote:
> > > I want to use the IA32_TSC_ADJUST MSR where available when testing TSC
> >
> On May 3, 2022, at 17:16, Alexander Bluhm wrote:
>
> Hi,
>
> We have one comment that locking for ratecheck(9) is missing. In
> all other places locking status of the struct timeval *lasttime
> is unclear.
>
> The easiest fix is a global mutex for all lasttime in ratecheck().
> This covers
On Sat, Apr 30, 2022 at 01:27:44AM +0200, Alexander Bluhm wrote:
> On Thu, Apr 28, 2022 at 08:54:02PM -0500, Scott Cheloha wrote:
> > On Thu, Sep 17, 2020 at 06:29:48PM -0500, Scott Cheloha wrote:
> > > [...]
> > >
> > > Using nanosleep(2) to print the
> On Apr 29, 2022, at 10:40, Jeremie Courreges-Anglas wrote:
>
> On Thu, Apr 28 2022, Scott Cheloha wrote:
>> speaker(4) is a whimsical thing, but I don't think we should have a
>> dedicated chiptune interpreter in the kernel.
>
>> This patch unhooks the driver
> On Apr 29, 2022, at 09:33, Angelo wrote:
>
> Hello
>
>> On Thu, Apr 28, 2022 at 06:34:00AM -0500, Scott Cheloha wrote:
>> speaker(4) is a whimsical thing, but I don't think we should have a
>> dedicated chiptune interpreter in the kernel.
>>
>> Thi
> On Apr 29, 2022, at 10:06, j...@entropicblur.com wrote:
>
> On 2022-04-29 08:31, Angelo wrote:
>> Hello
>>> On Thu, Apr 28, 2022 at 06:34:00AM -0500, Scott Cheloha wrote:
>>> speaker(4) is a whimsical thing, but I don't think we should have a
>>> de
On Thu, Oct 14, 2021 at 04:13:18PM -0500, Scott Cheloha wrote:
>
> [...]
>
> When we compute high resolution time, both in the kernel and in libc,
> we get a 32-bit (or smaller) value from the active timecounter and
> scale it up into a 128-bit bintime.
>
> The scaling m
On Thu, Sep 17, 2020 at 06:29:48PM -0500, Scott Cheloha wrote:
> [...]
>
> Using nanosleep(2) to print the stats periodically causes the period
> to drift. If you use setitimer(2) it won't drift.
>
> ok?
19 month bump and rebase.
I have updated the patch according to inp
speaker(4) is a whimsical thing, but I don't think we should have a
dedicated chiptune interpreter in the kernel.
This patch unhooks the driver and the manpage from the build. The
driver is built for alpha, amd64, and i386.
A subsequent patch will move all relevant files to the attic and clean
On Tue, Mar 29, 2022 at 03:26:49PM +1100, Jonathan Gray wrote:
> On Mon, Mar 28, 2022 at 10:52:09PM -0500, Scott Cheloha wrote:
> > I want to use the IA32_TSC_ADJUST MSR where available when testing TSC
> > synchronization. We note if it's available during CPU identification.
>
I want to use the IA32_TSC_ADJUST MSR where available when testing TSC
synchronization. We note if it's available during CPU identification.
Can we do CPU identification earlier in cpu_hatch() and
cpu_start_secondary(), before we do the TSC sync testing?
This can wait until after release. I'm
The strdup(3) implementation in libc uses memcpy(3), not strlcpy(3).
There is no upside to using strlcpy(3) here if we know the length of
str before we copy it to the destination buffer.
... unless we're worried the length of str will change? Which would
be very paranoid. But if that's the
Hi,
Here is a second draft patch for changing our approach to TSC
synchronization.
With this patch, instead of trying to fix desync with a handshake we
test for desync with a (more) foolproof loop and then don't attempt to
correct for desync if we detect it.
The motivation for a more foolproof
The look(1) program needs to open(2) and fstat(2) exactly one file
during its runtime. Using unveil(2) seems like overkill here.
This seems closer to what we want:
- pledge(2) initially with "stdio rpath" at the top of main().
We know we need to read a file at this point but don't yet
know
On Sun, Jan 30, 2022 at 10:23:43AM -0600, Scott Cheloha wrote:
> In tr(1), we have these two global arrays, "string1" and "string2".
>
> I have a few complaints:
>
> 1. They are not strings. They are lookup tables. The names are
>misleading.
>
We don't need "rpath" if we're only processing the standard input.
ok?
Index: rev.c
===
RCS file: /cvs/src/usr.bin/rev/rev.c,v
retrieving revision 1.15
diff -u -p -r1.15 rev.c
--- rev.c 29 Jan 2022 00:11:54 - 1.15
+++
> On Feb 6, 2022, at 20:07, Todd C. Miller wrote:
>
> Since the input is opened read-only I don't see the point in checking
> the fclose() return value. However, if you are going to do so, you
> might as well combine it with the ferror() check. E.g.
>
>if (ferror(fp) || fclose(fp) ==
Add missing stdio error checks to head(1):
- Output errors are terminal. The output is always stdout.
- Input errors yield a warning and cause the program to fail
gracefully.
- Restructure the getc(3)/putchar(3) loop in head_file() to accomodate
checking for errors.
ok?
P.S.
> On Feb 2, 2022, at 13:29, Stuart Henderson wrote:
>
> Thanks for testing.
>
>> On 2022/02/02 13:51, Dave Voutila wrote:
>>
>> Jason McIntyre writes:
>>
>>> On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
This definitely wants testing on Ryzen ThinkPads (e.g.
On Tue, Feb 01, 2022 at 01:33:19PM -0700, Todd C. Miller wrote:
> On Tue, 01 Feb 2022 09:59:51 -0600, Scott Cheloha wrote:
>
> > To recap:
> >
> > - Refactor the open/close portions of cook_args() and raw_args() into a
> >single function, cat_file().
> &g
On Wed, Dec 15, 2021 at 11:51:48AM +, Ricardo Mestre wrote:
>
> [...]
>
> the filename parameter on cook_buf is just used to show a warning, but it
> should
> be "stdin" instead of "(stdin)" to keep the same old behaviour.
Yep, fixed.
> additionally, please add a blank line after the
In tr(1), we have these two global arrays, "string1" and "string2".
I have a few complaints:
1. They are not strings. They are lookup tables. The names are
misleading.
2. The arguments given to tr(1) in argv[] are indeed called "string1"
and "string2". These are the names used in the
On Fri, Jan 28, 2022 at 07:28:40AM -0700, Todd C. Miller wrote:
> On Thu, 27 Jan 2022 20:02:18 -0800, Philip Guenther wrote:
>
> > > I think futimens(2) and close(2) failures are exotic enough to warrant
> > > printing the system call name.
> >
> > I don't understand this. Can you give an
201 - 300 of 927 matches
Mail list logo
