Re: [v5] amd64: simplify TSC sync testing

From: Scott Cheloha Date: Mon, 1 Aug 2022 11:24:21 -0500 > 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? It's a same Ryzen7 box. > Or

Re: random(6): undefined cast and error checking

luci...@bronze.ctrl-c.club wrote: > This patch solves two problems. > > First, abort if denom is greater than UINT32_MAX. arc4random_uniform > expects an uint32_t. If floor(denom) is greater than UINT32_MAX then > the cast is undefined behaviour. This isn't a very important program, but the

random(6): undefined cast and error checking

Hi, This patch solves two problems. First, abort if denom is greater than UINT32_MAX. arc4random_uniform expects an uint32_t. If floor(denom) is greater than UINT32_MAX then the cast is undefined behaviour. Second, use consistent error checking for printing the lines. putchar sets errno while

OpenBSD Errata: August 2, 2022 (bgpd)

Errata patch for BGP daemon has been released for OpenBSD 7.1. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata71.html

Re: riscv64: trigger deferred timer interrupts from splx(9)

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 than doing > > another timer

Re: riscv64: trigger deferred timer interrupts from splx(9)

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 than doing > another timer interrupt deferral thing. > > But, just to get the ball rolling, here a first attempt at the

Re: fix NAT round-robin and random

On 20.7.2022. 22:27, Alexandr Nedvedicky wrote: > Hello, > > below is a final version of patch for NAT issue discussed at bugs@ [1]. > Patch below is updated according to feedback I got from Chris, claudio@ > and hrvoje@. > > The summary of changes is as follows: > > - prevent infinite loop

Re: [v5] amd64: simplify TSC sync testing

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

patch(1): fix locate_hunk for empty files

there's an edge case in locate_hunk with empty files; if `first_guess' is zero then main() assumes that locate_hunk has failed and aborts the patch operation. Instead, make sure to return 1 (the line number) so that the patch operation can continue. this issue was found by Neels Hofmeyr (I

patch(1) fix dwim for reversed patch

i was looking for a different issue in patch when i found this. patch(1) fails to recognize the reversal application of a patch that creates a file (this is test t3). since an empty context always matches, the idea is to run the dwim code also when locate_hunk succeeds, but only if the patch

Re: [v5] amd64: simplify TSC sync testing

Hi, Scott. I tested v5 patch on my ESXi on Ryzen7. It works fine for me. $ sysctl -a | grep tsc kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) machdep.tscfreq=3593269150 machdep.invarianttsc=1 $ sysctl kern.timecounter