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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo