On Wed, Jul 27, 2022 at 06:47:56AM -0700, Andrew Hewus Fresh wrote:
> On Wed, Jul 27, 2022 at 11:06:39AM +0200, Alexander Hall wrote:
> > I think replacing '*' with '*([![:cntrl:]])' can be the droid your looking
> > for.
>
> As I was falling asleep last night I was trying to figure out how to ge
On 2.8.2022. 23:40, Stuart Henderson wrote:
> On 2022/08/02 22:28, Hrvoje Popovski wrote:
>>
>> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>>
>>
>> r7515$ sysctl | grep tsc
>> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
>> acpihpet0(1000) acpitimer0(1
On 2022/08/02 22:28, Hrvoje Popovski wrote:
>
> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>
>
> r7515$ sysctl | grep tsc
> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
> acpihpet0(1000) acpitimer0(1000)
> machdep.tscfreq=1996246800
> machdep.invari
On 2.8.2022. 22:28, Hrvoje Popovski wrote:
> Hi,
>
> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>
>
> r7515$ sysctl | grep tsc
> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
> acpihpet0(1000) acpitimer0(1000)
> machdep.tscfreq=1996246800
> machdep.i
On 31.7.2022. 5:13, Scott Cheloha wrote:
> 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()
On Mon, Aug 01, 2022 at 03:38:59PM +0200, Omar Polo wrote:
> 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 opera
On Mon, Aug 01, 2022 at 12:48:16PM +0200, Omar Polo wrote:
> 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
On 31.7.2022. 5:13, Scott Cheloha wrote:
> 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()
On 31.7.2022. 5:13, Scott Cheloha wrote:
> 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()
On Tue, 02 Aug 2022 11:52:33 -0500, Scott Cheloha wrote:
> dmesg(8) doesn't use any positional arguments. It's a usage error if
> any are present.
Sure. Ok millert@
- todd
I think you intend for that to be two seperate diffs, not merged into one.
For connect < 15 seconds, I think that is a bit strict.
For IO stalling 15 seconds, I suspect such IO stalls happen more than we
know, and will do harm to RPKI processing results.
I don't see any way this can be tested in
On Tue, Aug 02, 2022 at 03:59:40PM +0200, Claudio Jeker wrote:
> What makes you think that 15sec is enough to open connections in all
> scenarios? I feel this is one of those changes that just shows that
> maybe the current connect timeout from the system is too conservative.
Yeah, maybe. How abou
> Date: Tue, 2 Aug 2022 11:56:59 -0500
> From: Scott Cheloha
>
> 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, Ju
Job Snijders wrote:
> - /* Set up non-blocking mode. */
> -
> if ((flags = fcntl(*sd, F_GETFL, 0)) == -1) {
> - ERR("fcntl");
> - return -1;
> - } else if (fcntl(*sd, F_SETFL, flags|O_NONBLOCK) == -1) {
> ERR("fcntl");
> return -1;
On Tue, Aug 02, 2022 at 04:15:39PM +0200, Claudio Jeker wrote:
> On Tue, Aug 02, 2022 at 12:42:26PM +, Job Snijders wrote:
> > This adds '--contimeout' to rsync(1)
> >
> > $ time openrsync --contimeout=5 -rt rsync://203.119.21.1/test /tmp/k
> > openrsync: warning: connect timeout: 203.119.21.1
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 at 08:14:32PM -0500, Scott Cheloha wrote:
> > > >
> > > > [...]
>
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 13:2
On Tue, Aug 02, 2022 at 12:58:13PM +0100, Stuart Henderson wrote:
> On 2022/08/02 12:34, Claudio Jeker wrote:
> > On startup we load the routing table in bgpd and at that moment a cleanup
> > of old bgpd routes should happen. I noticed this is not the case because
> > fib_sync is not set and so sen
On Tue, Aug 02, 2022 at 12:42:26PM +, Job Snijders wrote:
> Hi all,
>
> This adds '--contimeout' to rsync(1)
>
> $ time openrsync --contimeout=5 -rt rsync://203.119.21.1/test /tmp/k
> openrsync: warning: connect timeout: 203.119.21.1, 203.119.21.1
> openrsync: error: cannot connect to host: 2
On Tue, Aug 02, 2022 at 01:42:43PM +, Job Snijders wrote:
> Hi,
>
> We were doing a lot of waiting in connect() for some (currently) broken
> repositories. Move on with life after MAX_CONTIMEOUT seconds.
>
> This changeset reduces the real time spent fetching the RIPE TAL (with
> hot cache) f
Hi,
We were doing a lot of waiting in connect() for some (currently) broken
repositories. Move on with life after MAX_CONTIMEOUT seconds.
This changeset reduces the real time spent fetching the RIPE TAL (with
hot cache) from 7m14.57s to 3m20.10s on an IPv4+IPv6 dual-stacked host.
This changeset
Hi all,
This adds '--contimeout' to rsync(1)
$ time openrsync --contimeout=5 -rt rsync://203.119.21.1/test /tmp/k
openrsync: warning: connect timeout: 203.119.21.1, 203.119.21.1
openrsync: error: cannot connect to host: 203.119.21.1
0m05.01s real 0m00.00s user 0m00.01s system
OK?
Ki
On 2022/08/02 12:34, Claudio Jeker wrote:
> On startup we load the routing table in bgpd and at that moment a cleanup
> of old bgpd routes should happen. I noticed this is not the case because
> fib_sync is not set and so send_rtmsg() just returns.
> I think we need to force fib_sync in fetchtable(
On Tue, Aug 02, 2022 at 01:44:42PM +0200, Theo Buehler wrote:
> On Tue, Aug 02, 2022 at 12:34:40PM +0200, Claudio Jeker wrote:
> > On startup we load the routing table in bgpd and at that moment a cleanup
> > of old bgpd routes should happen. I noticed this is not the case because
> > fib_sync is n
On Tue, Aug 02, 2022 at 12:34:40PM +0200, Claudio Jeker wrote:
> On startup we load the routing table in bgpd and at that moment a cleanup
> of old bgpd routes should happen. I noticed this is not the case because
> fib_sync is not set and so send_rtmsg() just returns.
> I think we need to force fi
Is there something wrong with my diff? I don't see it.
Please review it.
On startup we load the routing table in bgpd and at that moment a cleanup
of old bgpd routes should happen. I noticed this is not the case because
fib_sync is not set and so send_rtmsg() just returns.
I think we need to force fib_sync in fetchtable() to make sure the cleanup
happens correctly.
OK?
Hello,
On Mon, Aug 01, 2022 at 06:37:58PM +0200, Hrvoje Popovski wrote:
> 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
Hi,
bash has a PROMPT_COMMAND that allows a command to be executed before
each PS1 prompt is displayed. I've found this useful on occasion, so
this is the same thing for ksh(1).
In particular, this allows PROMPT_COMMAND to be set to a user-defined
shell function that can modify PS1, though it cou
29 matches
Mail list logo
