"Theo de Raadt" writes:
> We don't need a new subsystem.
>
> We just the operation changed, so it sends the event when the device is ready,
> rather than before it is ready.
Ok fair enough. More curiosity than anything on my part.
I need to find a way to make this information available for
Hi,
when hvn(4) attaches it sends commands and waits for replies to come
back in, hence the interrupt function is being polled. Unfortunately
it seems that the 'receive pipe' has both command completion and data
packets. As it turns out, while hvn(4) is just setting up the pipes,
it can already
Ping?
Ashton Fagg writes:
> I noticed this when looking through the nvme.c code the other day.
>
> Currently, nvme_poll() has a loop like this:
>
> while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) {
> if (nvme_q_complete(sc, q) == 0)
> delay(10);
On Tue, 11 May 2021 at 22:37:55 -0400, Ashton Fagg wrote:
> Inspiration for this diff was drawn from Joshua Stein [1], seeminly he
> had a use-case that was somewhat similar to mine at one point but it
> doesn't look like this was ever committed. Nor can I find any discussion
> on it.
I'm glad I
Hi,
Radek reported a problem to misc@ that multiple Windows clients
behind a NAT cannot use a L2TP/IPsec server simultaneously.
https://marc.info/?t=16099681611=1=2
There is two problems. First is pipex(4) doesn't pass the proper
ipsecflowinfo to ip_output(). Second is the IPsec
RFC5492 is fairly explicit when a capability should be enabled on a
session:
A BGP speaker that supports a particular capability may use this
capability with its peer after the speaker determines (as described
above) that the peer supports this capability. Simply put, a given
Hi,
Paul de Weerd mentioned off-list that the initial expiration for an
ITIMER_REAL timer is always at least one tick. I looked into it and
yes, this is the case, because the kernel rounds it_value up to one
tick if it is non-zero.
After thinking about it a bit I don't think we should do this
On Wed, May 12, 2021 at 10:03:13AM -0400, Ashton Fagg wrote:
> joshua stein writes:
>
> > I'm glad I could inspire you to repost the work I already did years
> > ago.
>
> I'm not sure if you're being sarcastic.
>
> > But either way, if a driver is causing a panic because it responds
> >
On Wed, 12 May 2021 17:26:51 +0300
Vitaliy Makkoveev wrote:
> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
>> Radek reported a problem to misc@ that multiple Windows clients behind a NAT
>> cannot use a L2TP/IPsec server simultaneously.
>>
>>
joshua stein writes:
> I'm glad I could inspire you to repost the work I already did years
> ago.
I'm not sure if you're being sarcastic.
> But either way, if a driver is causing a panic because it responds
> before it is ready, the same thing would happen without hotplug if
> it was
On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> Radek reported a problem to misc@ that multiple Windows clients behind a NAT
> cannot use a L2TP/IPsec server simultaneously.
>
> https://marc.info/?t=16099681611=1=2
>
> There is two problems. First is pipex(4)
> On 12 May 2021, at 18:42, YASUOKA Masahiko wrote:
>
> On Wed, 12 May 2021 17:26:51 +0300
> Vitaliy Makkoveev wrote:
>> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
>>> Radek reported a problem to misc@ that multiple Windows clients behind a NAT
>>> cannot use a
Hi,
In a separate mail thread, bluhm@ mentioned that panic(9) does not
cleanly handle multiple CPUs entering it simultaneously:
https://marc.info/?l=openbsd-tech=161908805925325=2
I'm unsure which part of panic(9) is causing the problem he mentions,
but one obvious issue I see is that panicstr
On 21.4.2021. 21:36, Alexander Bluhm wrote:
> We need more MP preassure to find such bugs and races. I think now
> is a good time to give this diff broader testing and commit it.
> You need interfaces with multiple queues to see a difference.
Hi,
while forwarding ip4 traffic over box with
ok mvs@
> On 13 May 2021, at 02:43, YASUOKA Masahiko wrote:
>
> On Wed, 12 May 2021 19:15:29 +0300
> Vitaliy Makkoveev wrote:
>>> On 12 May 2021, at 18:42, YASUOKA Masahiko wrote:
>>> On Wed, 12 May 2021 17:26:51 +0300
>>> Vitaliy Makkoveev wrote:
On Wed, May 12, 2021 at 07:11:09PM
Nicer than the garble...
It would be nice if we could see all the panics. Could we also have a
per-cpu panic buffer, and then adapt ddb to show them all?
Scott Cheloha wrote:
> In a separate mail thread, bluhm@ mentioned that panic(9) does not
> cleanly handle multiple CPUs entering it
It seems this lock order issue is not parallel diff specific.
> On 12 May 2021, at 12:58, Hrvoje Popovski wrote:
>
> On 21.4.2021. 21:36, Alexander Bluhm wrote:
>> We need more MP preassure to find such bugs and races. I think now
>> is a good time to give this diff broader testing and commit
On Wed, 12 May 2021 19:15:29 +0300
Vitaliy Makkoveev wrote:
>> On 12 May 2021, at 18:42, YASUOKA Masahiko wrote:
>> On Wed, 12 May 2021 17:26:51 +0300
>> Vitaliy Makkoveev wrote:
>>> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote:
Radek reported a problem to misc@ that
On Wed, 12 May 2021 19:11:09 +0900 (JST)
YASUOKA Masahiko wrote:
> Radek reported a problem to misc@ that multiple Windows clients behind
> a NAT cannot use a L2TP/IPsec server simultaneously.
>
> https://marc.info/?t=16099681611=1=2
>
> There is two problems. First is pipex(4) doesn't
Found this while poking around.
diff --git a/sys/scsi/scsi_base.c b/sys/scsi/scsi_base.c
index 2ba6a702fbc..6769449e2fa 100644
--- a/sys/scsi/scsi_base.c
+++ b/sys/scsi/scsi_base.c
@@ -478,7 +478,7 @@ scsi_io_get(struct scsi_iopool *iopl, int flags)
return NULL;
/* otherwise sleep until we
Hi,
With the removal of the kernel lock from timeout_barrier(9),
softclock() and the timeout thread do not need the kernel lock.
However, many timeouts implicitly rely on the kernel lock.
So to unlock softclock() and the timeout thread I propose adding a new
flag, TIMEOUT_MPSAFE. The flag
On Mon, Mar 15, 2021 at 08:21:56AM +, James Cook wrote:
> Hi tech@,
>
> The below patch removes calls to realpath(3) when looking up a qcow2
> base image. Previous thread:
> https://marc.info/?t=16156249642=1=2
>
> In short, the calls were failing inside vmctl, because of unveil. The
>
Hi Scott,
Thanks for this work! I see significant improvement with my test code
(see below; obviously focussing quite specificially on one thing).
Before your diff (snapshot from a few days ago; OpenBSD 6.9-current
(GENERIC.MP) #1: Mon May 3 11:04:25 MDT 2021) I got:
[weerd@pom] $ ./measure
James Cook writes:
> Hi tech@,
>
> The below patch removes calls to realpath(3) when looking up a qcow2
> base image. Previous thread:
> https://marc.info/?t=16156249642=1=2
>
> In short, the calls were failing inside vmctl, because of unveil. The
> other thread has alternative solutions
Hi,
I would be happy if iked(8) supports intermediate CAs and sends the
entire certificate chain to the clients. The diff attached adds
supports for intermediate CAs and multiple CERT payloads to iked(8).
What I would like to do is to use a LetsEncrypt certificate as a
server certificate of
There never was a real need for a distinction between the GFp and GF2m
variants of EC_POINT_{get,set}_affine_coordinates_{GFp,GF2m}() in
libcrypto. The EC_GROUP method has the correct function pointer set. Now
that we have EC_POINT_{get,set}_affine_coordinates(), let's use them and
avoid the
The _GFp() variants provide no benefit and are just wrappers around the
variants without _GFp(), so use the latter directly.
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.20
diff -u
27 matches
Mail list logo
