Hi,
mbg(4) is among the few remaining drivers using tsleep(9).
In a few spots, when the kernel is not cold, the driver will spin for
up to 1/10 seconds waiting for the MBG_BUSY flag to go low.
We can approximate this behavior by spinning 10 times and sleeping 10
milliseconds each iteration. 10
Hi,
srp_finalize(9) uses tsleep(9) to spin while it waits for the object's
refcount to reach zero. It blocks for up to 1 tick and then checks
the refecount again and again.
We can just as easily do this with tsleep_nsec(9) and block for 1
millisecond per interval.
ok?
Index: kern_srp.c
Hi,
tht(4) is another driver still using tsleep(9).
It uses it to spin while it waits for the card to load the firmware.
Then it uses it to spin for up to 2 seconds while waiting for
THT_REG_INIT_STATUS.
In the firmware case we can sleep for 10 milliseconds each iteration.
In the
Hi,
In hvn_alloc_cmd() we spin within a mutex while the freelist is empty.
Because we're using a mutex there is no way to miss the wakeup(9) from
hvn_free_cmd(), so we don't even need a timeout here. Instead of
doing msleep(9) for 1 tick repeatedly we can msleep_nsec(9) without a
timeout
Hi,
softraid(4) is another driver still using tsleep(9).
softraid(4) uses tsleep(9) in one spot to poll for completion. It
uses it in two other spots to momentarily yield the CPU to permit a
different thread to make progress.
In all cases the length of the timeout is totally arbitrary. We're
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote:
> On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > > On 01/12/20(Tue) 15:30, Claudio
On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > > [...]
> > > > Did you run a make build with that
On Mon, 30 Nov 2020 20:04:10 -0800
Greg Steuck wrote:
> Tested with a bunch of manual sysctl -w's.
>
> OK?
I'm not sure about this diff. I'm more likely to do
ddb{0}> set $radix = 0t2
and less likely to do
# sysctl ddb.radix=2
but you enforce the range check (radix in 8..16)
Hello,
>
> Just a style nit. Other errors do not put stdin:1 in brackes. One
> line per error. In pf.conf the rule direction matters. What about
>
> stdin:1 warning: synproxy used for inbound rules only, ignored for outbound
>
thanks, I like your suggestion.
below is updated diff.
On Thu, Dec 03, 2020 at 10:56:17PM +0300, Vitaliy Makkoveev wrote:
> > On 3 Dec 2020, at 13:20, Martin Vahlensieck
> > wrote:
> >
> > Hi
>
> Hi.
>
Hi
> >
> > This is unused. It has been in there since the import from NetBSD.
> > Their logs show that tcpgram.y and tcplex.l have been removed
On Thu, Dec 03, 2020 at 02:20:23AM -0500, VARIK VALEFOR wrote:
> Sir or Madam:
>
> This message contains some diffs which fix incorrect article usage, i.e.,
> the use of "a" where "an" should have been used, and vice-versa.
>
> "If you love something, and you set it free, and it doesn't come
Sure thing!
Tracing it out, it seems to happen after the function
psp_v11_0_ring_set_wptr is called, but I'm having trouble figuring out
*why* the timing is messing it up. It also runs fine if any print
statements are called before amdgpu_device_ip_init, however DRMDEBUG has to
be disabled. It
The use of roa-set, prefix-set and as-set is fairly common in bgpd.
Still sometimes it is not exactly clear how old the data in those tables
is. This diff is a first step at inproving inspection by adding
bgpctl show sets
Sample output is:
Type Name #IPv4
Sir or Madam:
This message contains some diffs which fix incorrect article usage, i.e.,
the use of "a" where "an" should have been used, and vice-versa.
"If you love something, and you set it free, and it doesn't come back,
you're a dumb-ass."
Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor
> On 3 Dec 2020, at 13:20, Martin Vahlensieck
> wrote:
>
> Hi
Hi.
>
> This is unused. It has been in there since the import from NetBSD.
> Their logs show that tcpgram.y and tcplex.l have been removed in 1995.
> I am not sure what the policy is for the getopt(3) call: Should Y be
> removed
On Wed, Dec 02, 2020 at 12:43:28AM +0100, Alexandr Nedvedicky wrote:
> the fix is to apply synproxy action on inbound packets only. Diff below
> does that exactly. Furthermore it also makes pfctl(8) to emit warning,
> when synproxy is being used in outbound/unbound rule:
Sounds reasonable.
>
> Date: Wed, 2 Dec 2020 19:44:02 +0100
> From: Anton Lindqvist
>
> On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > > On 01/12/20(Tue) 15:30, Claudio
Anyone?
While I could volunteer all y'all for testing that seems a bit silly.
I'd rather have someone to read the diff because
- The tricky cases will be very rare to hit in normal operations,
DNS answers are just not that big.
- I'd like to hear that this is actually a good pattern to do this
Here is a small optimization to SMR's naive grace period mechanism.
It makes use of the fact that some CPUs may cross a quiescent state
independently while the SMR thread is running smr_grace_wait().
Such CPUs can be skipped.
Index: kern/kern_smr.c
On Thu, Dec 03, 2020 at 03:48:00PM +0100, Christian Weisgerber wrote:
> Claudio Jeker:
>
> > In tal_parse() use strndup() to create the tal descr instead of the more
> > complex malloc, memcpy version. Result is the same but the strndup version
> > is a lot nicer.
>
> Yes, but...
>
> > ---
Hello -
I am using postgresql 12 on OpenBSD 6.8. After a while of running,
postgresql starts throwing out errors:
2020-12-03 08:18:35.052 CST [60288] ERROR: could not open shared memory
segment "/PostgreSQL.1780529043": No such file or directory
2020-12-03 08:18:35.052 CST [40083] ERROR:
Claudio Jeker:
> In tal_parse() use strndup() to create the tal descr instead of the more
> complex malloc, memcpy version. Result is the same but the strndup version
> is a lot nicer.
Yes, but...
> --- tal.c 11 Oct 2020 12:39:25 - 1.22
> +++ tal.c 3 Dec 2020 12:00:25 -
>
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote:
> I'm wondering if smr_grace_wait() could be improved on amd64, assuming
> SMT is disabled, by skipping offline CPUs.
>
> Index: kern/kern_smr.c
> ===
> RCS file:
On Wed, Dec 02, 2020 at 12:19:11PM +0100, Claudio Jeker wrote:
> The overflow check for the relative metric adjustments of filtersets
> assumes a certain overflow behaviour of signed integers. I think it is
> better to write this in a way that does not involve an overflow.
>
Here a small follow
Use asprintf with %.*s to construct the path based on the mft file
location and the filename of the referenced file.
Since the * field in printf(3) is expecting an int type, typecast the
ptrdiff_t to an int. Add an assert check to make sure there is no
overflow. Also do the same overflow check in
Hello Scott,
I tested this with Hyper-V on Windows 10 and it works fine so far.
Regards,
Andre
OpenBSD 6.8-current (GENERIC.MP) #6: Thu Dec 3 12:54:46 CET 2020
an...@dev.stoe.be:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4133171200 (3941MB)
random: good
In tal_parse() use strndup() to create the tal descr instead of the more
complex malloc, memcpy version. Result is the same but the strndup version
is a lot nicer.
OK?
--
:wq Claudio
Index: tal.c
===
RCS file:
Hi
This is unused. It has been in there since the import from NetBSD.
Their logs show that tcpgram.y and tcplex.l have been removed in 1995.
I am not sure what the policy is for the getopt(3) call: Should Y be
removed in the optstring as well (not done in this diff)?
Best,
Martin
Index:
28 matches
Mail list logo