> On 14 Oct 2023, at 23:18, Claudio Jeker wrote:
>
> On Sat, Oct 14, 2023 at 11:07:11AM +0200, Wouter Prins wrote:
>> hello list,
>>
>> Was wondering if the veb interface is supported as a bridge for pseudowires?
>> The manpage doesn't mention anything about the type of
>> bridge interface
> On 5 Oct 2023, at 21:50, Vitaliy Makkoveev wrote:
>
> Otherwise `if_snd' could still contain packets. If any of them has
> associated data with bumped reference counter, the corresponding
> refcnt_finalize() will sleep forever. I don't think we need to
> transmit these packets when
umb(4) is a hardware p2p driver, it just has ip coming in, so we can do
the same thing we do for the address family and input processing as
other p2p interfaces.
the short packet check that umb_input does is already done by the ip
stacks, so we're not losing anything.
i havent got a umb(4), so i
there are links between the pcb/socket layer and pf as an optimisation,
and links on mbufs between both sides of a forwarded connection.
these links let pf skip an rb tree lookup for outgoing packets.
right now these links are between pf_state_key structs, which are the
things that contain the
On Mon, Aug 07, 2023 at 05:36:27PM +0200, Tobias Heider wrote:
> On Mon, Aug 07, 2023 at 02:22:23PM +1000, David Gwynne wrote:
> > tobhe@ wrote the iked bits, so he'll commit them when he's ready.
> >
> > your config looks pretty much the same as mine except you specify
3072 \
> srcid $h_self \
> ikelifetime 28800 \
> lifetime 3600 \
> psk $h_s2s1_key \
> iface sec0
>
> In any case, IKEv1 worked fine! I plan to test this with Azure next
> since they're the second-most-requested IPsec tunnel I'm aske
BPF_DIRECTION_OUT);
> +#endif
> error = ipsp_process_packet(m, tdb,
> m->m_pkthdr.ph_family, /* already tunnelled? */ 0);
> if (error != 0)
>
> On Tue, 4 Jul 2023 at 14:33, David Gwynne wrote:
> >
> > tl
i'll fix this before i enable sec(4) in GENERIC. thanks for reading it.
cheers,
dlg
On Tue, 4 Jul 2023 at 20:04, Vitaliy Makkoveev wrote:
> On Tue, Jul 04, 2023 at 03:26:30PM +1000, David Gwynne wrote:
> > tl;dr: this adds sec(4) p2p ip interfaces. Traffic in and out of these
>
f needs-count
+file net/if_sec.c sec needs-count
file netinet/ip_ecn.c
file netinet6/in6_pcb.c inet6
file netinet6/in6.cinet6
Index: sys/net/if_sec.c
===
On Sun, Jul 02, 2023 at 12:44:17PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Thu, Jun 29, 2023 at 01:48:27PM +1000, David Gwynne wrote:
> > On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote:
> >
> > > net/if_pfsync.c
> > &g
On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> The new code looks much better. It's huge leap forward. I don't mind if this
> big diff will get committed. Hrvoje did test the whole diff. Trying to split
> it
> to smaller changes might bring in code which is
makes sense to me, ok.
maybe it's time to re-evaluate siphash?
> On 23 Jun 2023, at 05:50, Alexander Bluhm wrote:
>
> Hi,
>
> I am working on a diff to run UDP input in parallel. Btrace kstack
> analysis shows that SIP hash for PCB lookup is quite expensive.
> When running in parallel we get
> On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote:
>
>> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote:
>>
>> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
>>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
Hi,
I would suggest to
> On 2 Jun 2023, at 19:51, Alexander Bluhm wrote:
>
> On Wed, May 31, 2023 at 09:36:22AM +1000, David Gwynne wrote:
>> we could export these csum flags as part of the bpf header so we can
>> teach tcpdump to shut up in this situation.
>
> Linux does not do that a
On Tue, May 30, 2023 at 09:08:45PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Currently packets sent over loopback interface get their checksum
> calculated twice. In the output path it is set and during TCP/IP
> input it is calculated again to be compared with the previous value.
>
> This can be
> On 19 May 2023, at 19:35, Claudio Jeker wrote:
>
> On Fri, May 19, 2023 at 06:10:19PM +1000, David Gwynne wrote:
>> On Fri, May 19, 2023 at 08:11:13AM +0200, Claudio Jeker wrote:
>>> On Fri, May 19, 2023 at 01:56:38PM +1000, David Gwynne wrote:
>>>> t
On Fri, May 19, 2023 at 08:11:13AM +0200, Claudio Jeker wrote:
> On Fri, May 19, 2023 at 01:56:38PM +1000, David Gwynne wrote:
> > this is a tiny slice off a big pfsync diff i've been working on. when
> > you bring pfsync down i need it to wait until all the work it's been
> >
this is a tiny slice off a big pfsync diff i've been working on. when
you bring pfsync down i need it to wait until all the work it's been
doing in the network stack has finished, which means i need a barrier
for all the network taskqs. that's what this implements.
a barrier per taskq would mean
so in top you see softnet0, softnet1, etc.
the real change is putting a struct softnet in place to wrap the name
and taskq up with.
ok?
Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.695
diff -u -p -r1.695
> On 4 May 2023, at 20:52, Alexander Bluhm wrote:
>
> Hi,
>
> The mbuf_queue API allows read access to integer variables which
> another CPU may change simultaneously. To prevent miss-optimisations
> by the compiler, they need the READ_ONCE() macro. Otherwise there
> could be two read
On Wed, Apr 26, 2023 at 11:45:08PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Thu, Apr 27, 2023 at 06:51:52AM +1000, David Gwynne wrote:
>
> > > is that kind of check in KASSET() something you have on your mind?
> > > perhaps I can t
On Wed, Apr 26, 2023 at 01:47:31PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Wed, Apr 26, 2023 at 11:37:58AM +1000, David Gwynne wrote:
> > > fail:
> > > - if (flags & FWRITE)
> > > - rw_exit_write(_rw);
> > > - else
> >
On Wed, Apr 26, 2023 at 09:49:18AM +, Gerhard Roth wrote:
> On Wed, 2023-04-26 at 19:42 +1000, David Gwynne wrote:
> > On Wed, Apr 26, 2023 at 07:48:18AM +, Gerhard Roth wrote:
> > > On Wed, 2023-04-26 at 00:39 +0200, Alexandr Nedvedicky wr
On Wed, Apr 26, 2023 at 07:48:18AM +, Gerhard Roth wrote:
> On Wed, 2023-04-26 at 00:39 +0200, Alexandr Nedvedicky wrote:
> > Hello,
> >
> > This is the second diff. It introduces a transaction (pf_trans).
> > It's more or less diff with dead code.
> >
> > It's still worth to note those two
ok
> On 26 Apr 2023, at 11:10, Masato Asou wrote:
>
> Tne interface of nvgre(4) has SIOC[SGD]IFPARENT as below from man nvgre:
>
> nvgre interfaces support the following ioctl(2) calls:
>
>SIOCSIFPARENT struct if_parent *
>Configure which interface will be joined
On Wed, Apr 26, 2023 at 12:39:00AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> This is the second diff. It introduces a transaction (pf_trans).
> It's more or less diff with dead code.
>
> It's still worth to note those two chunks in this diff:
>
> @@ -1142,10 +1172,7 @@ pfioctl(dev_t dev,
> On 26 Apr 2023, at 08:25, Alexandr Nedvedicky wrote:
>
> Hello,
>
> below is diff which renames ruleset member `ticket` to `version`.
> the reason for this is to keep things clean. The word `ticket`
> will be used to identify transaction, while newly introduced `version`
> identifies
ok
> On 24 Apr 2023, at 17:55, Masato Asou wrote:
>
> The eoip interface has SIOC[SG]ETKALIVE as below:
>
> $ man eoip | grep KALIVE
>SIOCSETKALIVE struct ifkalivereq *
>SIOCGETKALIVE struct ifkalivereq *
>
> Can I append eoip to keepalive option?
>
> comment, ok?
> --
> ASOU
I can't recall a real device that worked with MSI but not with msi-x, so
I'm ok with chucking it in.
On Tue, 18 Apr 2023, 21:15 Patrick Wildt, wrote:
> Hi,
>
> I noticed that on Qemu with arm64 we're falling back to legacy
> interrupts with xhci(4) on PCI. Turns out that the virtual xHCI
>
:00 -
+++ dwmshc.c17 Apr 2023 01:39:19 -
@@ -0,0 +1,398 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 David Gwynne
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyrig
turns out OF_getprop is like memcpy, but sometimes you want something
like strlcpy. this is what OF_getpropstr aims to provide.
i know openfirm.h is used on other archs that don't use fdt as their
backend, but i figure we can port this wrapper over to them as need
demands.
ok?
Index: fdt.c
ethernet interfaces in device trees can have a "label" property which
is generally used (when it is used) to identify which connector it is on
the case or something like that. eg, eth2 in the turris omnia device
tree has 'label = "wan"' on the mvneta interface.
ive been using labels in the dts
the banana pi r2 pro has a usable sata port, but ahci wasnt finding
anything attached to it.
the fdt glue looked like it assumed the boot loader did a lot of
work to get things going. however, i havent figured out how to
configure u-boot to do ahci, and quartz_uefi doesn't have ahci/sata
working
On Tue, Apr 04, 2023 at 10:59:56PM +1000, David Gwynne wrote:
>
>
> > On 4 Apr 2023, at 20:37, Mark Kettenis wrote:
> >
> >> Date: Tue, 4 Apr 2023 09:49:40 +1000
> >> From: David Gwynne
> >>
> >> i did this when i was trying to figure o
> On 4 Apr 2023, at 20:37, Mark Kettenis wrote:
>
>> Date: Tue, 4 Apr 2023 09:49:40 +1000
>> From: David Gwynne
>>
>> i did this when i was trying to figure out why TX wasn't working on the
>> nanopi r5s before figuring out that problem
i did this when i was trying to figure out why TX wasn't working on the
nanopi r5s before figuring out that problem was because we didn't have
rkiovd.
at the very least it should future proof dwqe against more phy setups,
and provides a decent example of how to interpret those fdt properties.
these come from the linux user guide and should all work the same as the
e25 if the document can be believed.
ok?
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.752
diff -u -p -r1.752 usbdevs
---
i got a quectel ec25 to play with recently, and got side tracked
thinking the usb controller was not talking to the modem correctly
because when it attached it looked like this:
umb0 at uhub2 port 1 "Android Android" rev 2.00/3.18 addr
umb0: missing MBIM descriptor
and the usb descriptors looked
On Mon, Feb 13, 2023 at 08:30:03AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> This diff looks good to me. Though I still have some
> doubts about accuracy of comment here:
>
>
> > return (kn->kn_data > 0);
> > @@ -1510,6 +1599,15 @@ bpf_catchpacket(struct bpf_d *d, u_char
> >
deraadt@ noticed that pflogd wakes up twice a second, event if it has
nothing to do or log. the reason for this is how bpf works.
when you try and read from a bpf file descriptor, there are three
reasons that the read will finish.
the first is the obvious one: the bpf packet buffer in the kernel
>>>> On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote:
>>>>> On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote:
>>>>>> On Wed, Jan 18, 2023 at 03:49:25PM -0700, Theo de Raadt wrote:
>>>>>>> Jan Klemkow wrote:
>>
===
RCS file: net/if_rport.c
diff -N net/if_rport.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/if_rport.c 9 Jan 2023 04:13:20 -
@@ -0,0 +1,456 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 David Gwynne
+ *
+ * Permission to use
> On 5 Jan 2023, at 18:56, Alexandr Nedvedicky wrote:
>
> Hello,
>
> On Wed, Jan 04, 2023 at 09:36:38PM +1000, David Gwynne wrote:
>> and "stp" for pf_state ** variables.
>>
>I agree with established naming conventions.
>
>
and "stp" for pf_state ** variables.
there should be no functional change here.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1167
diff -u -p -r1.1167 pf.c
--- pf.c4 Jan 2023 10:31:55 -
> On 4 Jan 2023, at 20:20, Alexandr Nedvedicky wrote:
>
> Hello,
>
> I agree with change as-is. Though I have some suggestions
> for few finishing touches. see comments inline.
>
> On Wed, Jan 04, 2023 at 01:15:54PM +1000, David Gwynne wrote:
>> move the pf_s
move the pf_state_tree_id type from pfvar.h to pfvar_priv.h.
this is like the pf_state_tree change from yesterday. the
pf_state_tree_id type is private to the kernel, just like the
pf_state_tree type.
moving it from RB to RBT saves another 12k in pf.o on amd64.
i also changed some hand rolled
> On 3 Jan 2023, at 17:47, Alexandr Nedvedicky wrote:
>
> Hello,
>
> On Tue, Jan 03, 2023 at 03:31:42PM +1000, David Gwynne wrote:
>> the pf_state_tree type represents the rb tree that pf_state_key structs
>> go into. currently pf_state_key is declared in pf
the pf_state_tree type represents the rb tree that pf_state_key structs
go into. currently pf_state_key is declared in pfvar_priv.h (because
it's a kernel private data structure) but pf_state_tree was left in
pfvar.h. this moves it to pfvar_priv.h, because it is also kernel
private.
while here,
On Thu, Dec 29, 2022 at 03:05:35PM +0800, Kevin Lo wrote:
> The diff below makes the serial interface of the Genio 1200 demo board
> (FT232R)
> work. The upper 2 bits encode the fractional component of the FT232R is
> either
> 0 or 0.125.
>
> uftdi0 at uhub0 port 3 configuration 1 interface 0
On Mon, Dec 19, 2022 at 09:01:08AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> I don't object. diff improces things. Just few bike shedding nits
> further below.
> On Mon, Dec 19, 2022 at 04:48:57PM +1000, David Gwynne wrote:
>
> >
> > i hope i didn't mess up t
this prefixes (some of the) pf_state_key struct members with sk_, and
pf_state_item struct members with si_ (and renames one completely).
this makes searching for and the struct members so much easier, which in
turn makes tweaking code around them a lot easier too. sk_refcnt in
particular would
both struct pf_state_key and pf_state_item are kernel private data
structures, and do not need to be visible to userland.
i would like to move them to pfvar_priv.h to make it more obvious that
they are and should remain kernel private data structures, which in turn
will make it less scary to
On Mon, Dec 05, 2022 at 11:26:21AM +0100, Alexandr Nedvedicky wrote:
> Hello,
> On Mon, Dec 05, 2022 at 11:46:07AM +1000, David Gwynne wrote:
> >
> > yes, you're right. the diff below includes the simple fix to that.
> >
> > this demonstrates how subtle the refer
On Mon, Dec 05, 2022 at 11:32:06AM +1000, David Gwynne wrote:
> On Mon, Dec 05, 2022 at 12:45:29AM +0100, Alexandr Nedvedicky wrote:
> > Hello,
> >
> >
> > On Sat, Dec 03, 2022 at 09:53:45AM +1000, David Gwynne wrote:
> > > we (mostly sashan@ and me) have a
On Mon, Dec 05, 2022 at 12:45:29AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Sat, Dec 03, 2022 at 09:53:45AM +1000, David Gwynne wrote:
> > we (mostly sashan@ and me) have a problem where pfsync can be holding a
> > reference to a pf_state that pf has decided t
On Sat, Dec 03, 2022 at 08:14:37PM -0600, Scott Cheloha wrote:
> There are nearly a hundred vestigial question mark cases in the
> top-level getopt(3) loops of various programs. You know, this:
>
> switch (ch) {
> /* ... */
> case '?':
> default:
> usage();
we (mostly sashan@ and me) have a problem where pfsync can be holding a
reference to a pf_state that pf has decided to purge, and then pfsync
crashes because it tries to read the pf_state_key parts of the state,
but they been removed by the purge process.
the background to this is that pf_state
> On 30 Nov 2022, at 14:36, Greg Steuck wrote:
>
> Greg Steuck writes:
>
>> The watched kettle never boiled. No more crashes in over two weeks
>> (instead of two in the first week). I tried a loop of alternating iperf3
>> tcp and udp to no ill effect. I still see the growth in the metrics I
im ok with this, but you need sashan@ to ok it too. he's been working up to
this anyway.
dlg
> On 24 Nov 2022, at 06:18, Vitaliy Makkoveev wrote:
>
> On Wed, Nov 23, 2022 at 02:59:05PM -0500, David Hill wrote:
>> Hello -
>>
>> I am seeing splasserts on boot (before kern.splassert=2 can be
> On 22 Nov 2022, at 18:49, Alexandr Nedvedicky wrote:
>
> Hello,
>
> this change is required to unhook pf(4) from NET_LOCK().
> therefore I'd like to get it in.
ok dlg@
>
> On Mon, Nov 07, 2022 at 04:51:59AM +1000, David Gwynne wrote:
>>
>>
>
> On 22 Nov 2022, at 16:13, Andrew Hewus Fresh wrote:
>
> On Mon, Nov 21, 2022 at 04:56:07PM +0100, Martijn van Duren wrote:
>> On Sun, 2022-11-20 at 19:35 -0700, Theo de Raadt wrote:
>>> Steve Litt wrote:
>>>
Vitaliy Makkoveev said on Mon, 21 Nov 2022 03:48:21 +0300
>> On 20
this is ok by me, obviously.
On Sun, Nov 20, 2022 at 06:18:55PM -0600, Scott Cheloha wrote:
> Hi,
>
> systat(1)'s vmstat view should not use statclock() ticks to count
> elapsed time. First, ticks are very low resolution and they aren't
> always of equal length. Second, we're counting the
:12:34 reyk Exp $ */
+
+/*
+ * Copyright (c) 2017 David Gwynne
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies
ok
> On 11 Nov 2022, at 7:31 pm, Alexandr Nedvedicky wrote:
>
> Hello,
>
> Diff below changes KASSERT() to if (). We have to prevent
> packets to insert state to snapshot queue multiple times.
> Hrvoje@ can trigger situation where state updates to pfsync
> peer are more frequent than we are
On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> > I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> > waiting for cpus to run that aren't running cos we haven't finished b
Yes please. ok dlg@.
> On 10 Nov 2022, at 10:10 pm, Alexandr Nedvedicky wrote:
>
> Hello,
>
> David (dlg@) asked me to shrink the scope of the change. The new diff
> introduces a mutex to pf_state and adjust pf_detach_state() to utilize the
> newly introduced mutex. I've also added
> On 10 Nov 2022, at 10:56 pm, Claudio Jeker wrote:
>
> On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
>> So mpe(4) is a special device. It is a point-to-multipoint interface that
>> does not do multicast. So setting IFF_MULTICAST on the interface is not
>> correct but IPv6
On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> waiting for cpus to run that aren't running cos we haven't finished booting
> yet.
>
> I'll back it out and fix it up when I'm actually aw
I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
waiting for cpus to run that aren't running cos we haven't finished booting yet.
I'll back it out and fix it up when I'm actually awake.
dlg
> On 10 Nov 2022, at 6:28 am, Hrvoje Popovski wrote:
>
> Hi all,
>
> I've
i'm hacking on pfsync(4) at the moment, and i wasted way too much time
wondering how i broke the pfsync ioctls after i didn't the pfsync_status
output. turns out if you don't have a sync interface set, it skips
output.
i think it's useful to show that the sync interface is not set, so i
came up
On Tue, Jun 07, 2022 at 04:58:24PM +1000, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holdin
this is a small chunk to help sashan@ out with some of the pf ioctl work
he is doing.
he is looking at allocating config over multiple ioctls, and would like
to be able to throw it away in situations like if the userland program
creating the state goes away. with the current vnode and device
On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
> So mpe(4) is a special device. It is a point-to-multipoint interface that
> does not do multicast. So setting IFF_MULTICAST on the interface is not
> correct but IPv6 depends on it because neighbor discovery.
>
> Now there is no
usbdevs has "?" in the optstring is passes to getopt, but doesn't handle
it specially. this is unnecessarily different to everything else in the
tree, so i want to remove it. ok?
Index: usbdevs.c
===
RCS file:
On Tue, Oct 04, 2022 at 09:43:40AM +, Klemens Nanni wrote:
> On Tue, Oct 04, 2022 at 09:24:04AM +, Klemens Nanni wrote:
> > On Mon, Oct 03, 2022 at 06:43:26PM -0600, Theo de Raadt wrote:
> > > David Gwynne wrote:
> > >
> > > > On Sun, Oct 02, 2022 a
On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> untrusted clients are supposed to ever write anything.
>
> Either way, even when run without -c, a single file writable by _tftpd
> might be enough for a
> On 2 Jul 2022, at 08:44, Hrvoje Popovski wrote:
>
> On 28.6.2022. 15:11, Jonathan Matthew wrote:
>> This adds the (not quite) final bits to em(4) to enable multiple rx/tx
>> queues.
>> Note that desktop/laptop models (I218, I219 etc.) do not support multiple
>> queues,
>> so this only
On Tue, May 31, 2022 at 04:48:16PM +0200, Martin Pieuchot wrote:
> On 18/05/22(Wed) 15:53, Alexander Bluhm wrote:
> > On Tue, May 17, 2022 at 10:44:54AM +1000, David Gwynne wrote:
> > > + cookie = SCARG(uap, proc_cookie);
> > > +
On Wed, May 18, 2022 at 07:42:32PM -0600, Theo de Raadt wrote:
> Mark Kettenis wrote:
>
> > > Isn't the vm_map_lock enough?
> >
> > Could be. The fast path is going to take that lock anyway. This
> > would require a bit of surgery to uvm_map_extract() to make sure we
> > don't take the
> On 10 Jun 2022, at 08:24, Hrvoje Popovski wrote:
>
> On 9.6.2022. 19:25, Hrvoje Popovski wrote:
>> On 9.6.2022. 19:11, Jan Klemkow wrote:
>>> On Thu, Jun 09, 2022 at 08:25:22AM +0200, Hrvoje Popovski wrote:
On 8.6.2022. 22:01, Hrvoje Popovski wrote:
> On 8.6.2022. 15:04, Jan
the main change here is to move pf_purge out from under the kernel lock.
another part of the change is to limit the amount of work the state
purging does to avoid hogging a cpu too much, and to also avoid holding
NET_LOCK for too long.
the main part is acheived by using systqmp to run the purge
> On 6 Jun 2022, at 18:08, Claudio Jeker wrote:
>
> On Mon, Jun 06, 2022 at 12:03:06AM +0200, Alexandr Nedvedicky wrote:
>> Hello,
>>
>> I'll commit one-liner diff on Tuesday morning (Jun 6th) Prague time without
>> explicit OK, unless there will be no objection.
>
> The diff is OK
On Sun, Jun 05, 2022 at 03:57:39PM +, Visa Hankala wrote:
> On Sun, Jun 05, 2022 at 12:27:32PM +0200, Martin Pieuchot wrote:
> > On 05/06/22(Sun) 05:20, Visa Hankala wrote:
> > > Encountered the following panic:
> > >
> > > panic: kernel diagnostic assertion "(p->p_flag & P_TIMEOUT) == 0"
here's an updated diff.
the main changes are:
1. disable the phy code.
letting eephy attach seems to break autonegotiation.
it also looks like several generations of the marvell switches don't
supply a proper model id for the builtin phy, so the linux driver
fakes one and has extra code in
On Mon, May 30, 2022 at 09:14:47PM +0200, Mark Kettenis wrote:
> > Date: Sat, 28 May 2022 15:08:49 +1000
> > From: David Gwynne
> >
> > the espressobin is the least worst thing ive settled on. it's not
> > too expensive, it has a case, it has multiple interfaces
ive been hunting for a small box, ie, it has a case, with at least
two (non usb) gig interfaces for use/recommend as a cheap and
cheerful home router, and it feels like trying to find a unicorn
sometimes.
i was looking at ipq4018/ipq4019 devs for a while, but ive been
turned off those systems
On Fri, May 27, 2022 at 06:25:00PM +0200, Jan Klemkow wrote:
> Hi,
>
> The following diff enables the TCP Large Receive Offloading feature for
> ix(4) interfaces. It also includes a default off sysctl(2) switch.
>
> The TCP single stream receiving performance increased from 3.6 Gbit/s to
> 9.4
On Tue, May 17, 2022 at 10:14:18AM -0600, Theo de Raadt wrote:
> Martin Pieuchot wrote:
>
> > On 17/05/22(Tue) 10:44, David Gwynne wrote:
> > > this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall
> > > argument checks can be done without the
this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall
argument checks can be done without the kernel lock.
care is taken to allow the pc/cookie checks to run without any lock by
being careful with the order of the checks. all modifications to the
pc/cookie state are serialised by
this is basically the same as what i did for in_pcbselsrc, and
completely mechanical. im too tired to figure out if there's a smarter
way to do it.
lightly tested, and more eyes are welcome because of the tiredness
thing.
Index: in6_pcb.c
On Sun, Apr 24, 2022 at 11:32:53PM +0200, Claudio Jeker wrote:
> On Sun, Apr 24, 2022 at 02:30:37PM -0400, Bryan Steele wrote:
> > On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> > > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> > > excludes Zen APU CPUs)
re(4) hardware has some useful counters that are worth looking at:
dlg@router ~$ kstat re-stats
re0:0:re-stats:0
TxOk: 12697 packets
RxOk: 22919 packets
TxEr: 0 packets
RxEr: 0 packets
MissPkt: 0 packets
FAE: 8371 packets
> On 21 Apr 2022, at 02:14, Alexander Bluhm wrote:
>
> Hi,
>
> In pfsync there are some KASSERT hidden behind #ifdef PFSYNC_DEBUG.
> That does not make sense to me. Either they are correct, then they
> should actively check in production. Or they got wrong over time,
> then they should not
> On 2 Apr 2022, at 03:09, Stuart Henderson wrote:
>
> On 2022/04/01 17:13, Stuart Henderson wrote:
>> On 2022/04/01 10:26, Gerhard Roth wrote:
>>> On 4/1/22 07:41, Kevin Lo wrote:
ure0: RTL8153 (0x5c10), address 00:e0:4c:xx:xx:xx
rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0
On Tue, Mar 22, 2022 at 09:12:23AM +0100, Claudio Jeker wrote:
> On Tue, Mar 22, 2022 at 02:24:25PM +1000, David Gwynne wrote:
> > i couldnt find any good examples of what to do when you wanted to
> > receive multiple control messages from a single recvmsg call. the most
> > i
i couldnt find any good examples of what to do when you wanted to
receive multiple control messages from a single recvmsg call. the most
interesting bit is how much space the buffer needs to be.
if i struggled maybe someone else will too?
Index: CMSG_DATA.3
are you trying to add an i2c device to the sensor framework? or are you asking
how to touch i2c devices from userland?
> On 21 Mar 2022, at 16:21, Dr. T.I.S. wrote:
>
> I know the rule, try to research first on man pages, openbsd.org, ect,
> and ask people as a last resort. Unfortunately, I
in_pcbselsrc has this:
ifp = if_get(mopts->imo_ifidx);
if (ifp != NULL) {
if (ifp->if_rdomain == rtable_l2(rtableid))
IFP_TO_IA(ifp, ia);
if (ia == NULL) {
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomics fairly extensively in other
On Thu, Mar 10, 2022 at 10:26:21PM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote:
>
> Hello Mark,
>
> > If you think about it, the invariants being tested by those KASSERTs should
> > not depend on whether the old or the new value is read if another
1 - 100 of 1094 matches
Mail list logo
