Currently when a umb device gets a new IPv4 address, it just adds it to
the interface and tries to set the default route through it. If there's
a different previous address, it stays there, and any routes using it also
remain in place, so umb can't set the new default route. You see something
ypldap currently packs all the user and group lines into contiguous blocks
of memory so it can move from one entry to the next by pointer arithmetic.
This doesn't make much sense because the entries are also in red black trees
(that's how it looks up the entry in the first place) and RB_NEXT() is
On Fri, Sep 15, 2023 at 09:48:16AM +0200, Olivier Croquin wrote:
> Hi,
>
> The media capability 100GBase_LR4 is not listed in the mcx driver.
>
> Could you please take a look at this short patch ? I found the value of 23
> in the Linux mlx driver.
Thanks, I've committed it.
> Is this enough to
On Wed, Aug 30, 2023 at 01:19:42PM +0800, Kevin Lo wrote:
> On Tue, Aug 29, 2023 at 09:15:41PM +0200, Mark Kettenis wrote:
> >
> > > Date: Tue, 29 Aug 2023 11:58:23 +0200
> > > From: Mark Kettenis
> > >
> > > Upstreaming of the JH7110 PCIe device tree bindings isn't finished
> > > yet, but it
On Wed, Aug 30, 2023 at 01:19:42PM +0800, Kevin Lo wrote:
> On Tue, Aug 29, 2023 at 09:15:41PM +0200, Mark Kettenis wrote:
> >
> > > Date: Tue, 29 Aug 2023 11:58:23 +0200
> > > From: Mark Kettenis
> > >
> > > Upstreaming of the JH7110 PCIe device tree bindings isn't finished
> > > yet, but it
On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote:
> On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> > This is the next patch in the clock interrupt reorganization series.
> >
> > Before we continue breaking up the hardclock(9) we need to detour into
> > the MD code.
On Mon, Aug 14, 2023 at 06:24:14PM +1000, Jonathan Matthew wrote:
> On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> > This is the next patch in the clock interrupt reorganization series.
> >
> > Before we continue breaking up the hardclock(9) we need to d
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> This is the next patch in the clock interrupt reorganization series.
>
> Before we continue breaking up the hardclock(9) we need to detour into
> the MD code.
>
> This patch divides the "initialization" parts of cpu_initclocks()
One of the problems described here:
https://www.mail-archive.com/tech@openbsd.org/msg71790.html
amounts to ix(4) not checking that it allocated a dma map before trying to free
it.
ok?
Index: if_ix.c
===
RCS file:
Like dwqe(4), dwge(4) should also register its instances for lookup by ofw node
or phandle.
ok?
Index: if_dwge.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwge.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_dwge.c
--- if_dwge.c 5
On Wed, Jul 05, 2023 at 01:13:34PM +0200, Mark Kettenis wrote:
> > Date: Wed, 5 Jul 2023 12:46:36 +0300
> > From: Jonathan Matthew
> >
> > On the Banana Pi R1 (aka Lamobo R1), the dwge interface on the soc is
> > connected to a broadcom switch chip. It looks li
On the Banana Pi R1 (aka Lamobo R1), the dwge interface on the soc is
connected to a broadcom switch chip. It looks like this in the device
tree:
{
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
phy-mode = "rgmii";
phy-supply = <_gmac_3v3>;
status
ok jmatthew@
On Tue, Jul 04, 2023 at 12:20:32PM +0300, Alexander Bluhm wrote:
> anyone?
>
> On Fri, May 26, 2023 at 06:44:25PM +0200, Alexander Bluhm wrote:
> > Hi,
> >
> > in_ifcap_cksum() checks ifp == NULL
> > in_hdr_cksum_out() sets ip_sum = 0
> > in_proto_cksum_out() and
This adds kstats for the hardware counters available in bge(4) devices, BCM5705
and newer. The main complication is that some of the counters are already used
in bge_stats_update_regs() as part of a hardware bug workaround, some are
affected
by hardware bugs themselves, and some are read to
This adds kstats for hardware counters available in (some) dwge devices.
If the counters are not present, as in Allwinner A20 devices among others,
they just read 0. On an RK3399 device, they do exist, and they yield
something like this:
rp64$ kstat dwge0::dwge-stats:
dwge0:0:dwge-stats:0
tx
We sometimes run into situations where one of the three servers a ypldap
can talk to will accept a TCP connection but won't do TLS properly, or won't
perform LDAP searches. ypldap currently only tries servers until one accepts
the connection, so when this happens, it is less successful at
On the Turris Omnia, the host can't transmit over the interface linked to
the switch unless mvsw applies phy-mode settings to the port on its side,
specifically the rgmii delay settings.
ok?
Index: mvsw.c
===
RCS file:
On systems where we pull in around 100k users from ldap, ypldap uses a
fair bit of memory (over 300MB peak) moving data from the ldapclient process
to the main process.
The ldapclient process sends each user and group record to the parent process
in instances of struct idm_req, which includes a
On Sun, Jan 08, 2023 at 03:09:44PM -0500, Dave Voutila wrote:
>
> Philip Guenther writes:
>
> > On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote:
> >
> > Bringing this to tech@ to increase my chance of someone testing my
> > diff.
> >
> > As reported in this thread on misc@ [1], I believe
On Sun, Dec 04, 2022 at 02:31:41PM +, Visa Hankala wrote:
> Do not re-insert the event counter to evcount_list in evcount_percpu().
> Otherwise the list becomes corrupt when evcount_percpu() is called
> after evcount_init_percpu().
>
> OK?
clearly I never managed to test that path. oops.
ok
On a Dell R6515, acpimadt(4) prints this 512 times during boot:
acpimadt0: unknown apic structure type 80
Previous generations of machines had a few of these, and they were easy
enough to ignore, but 512 is a bit excessive.
On further inspection, it seems types 0x80 through 0xFF are reserved
While working on ypconnect(2), Theo suggested that ypldap(8) should
not default to plaintext LDAP connections, since the data it's dealing with
is pretty important to the security of the system. Here's a straightforward
diff implementing that, defaulting to what was previously called 'tls'
On Sat, Sep 17, 2022 at 04:28:15PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Inspired by Taylor's talk at EuroBSDCon I think a memory barrier
> in counters_zero() is missing. Reading uses two consumer barriers,
> so writing should also have two.
Will slides or notes from this talk be available at
This adds client certificate authentication to ypldap(8). libtls makes the
actual certificate part of this straightforward (I would still like it
reviewed, though), but there are some LDAP complications.
Depending on your LDAP server and how you connect to it (LDAPS on port 636
or LDAP+TLS on
On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote:
> Hi,
>
>
>
> This diff adds preliminary support for RTL8156B to ure(4) and
>
On Wed, Mar 23, 2022 at 04:59:06PM +0100, Otto Moerbeek wrote:
> On Wed, Mar 23, 2022 at 09:09:01PM +1000, Jonathan Matthew wrote:
>
> > We noticed that the ntpd engine process was getting a bit big on some boxes
> > that we'd accidentally cut off from the ntp server
We noticed that the ntpd engine process was getting a bit big on some boxes
that we'd accidentally cut off from the ntp servers (routing is hard).
Reading through the code, I noticed the 'query' member of struct ntp_peer
is never freed, which seems to account for the leak.
If you have a server
On Fri, Feb 18, 2022 at 04:03:28PM +0100, Florian Obser wrote:
> On 2022-02-18 12:17 +10, Jonathan Matthew wrote:
> > The only thing ping uses to determine whether a received icmp echo reply
> > packet is a
> > response to one of its requests is the 16 bit icmp ident fie
The only thing ping uses to determine whether a received icmp echo reply packet
is a
response to one of its requests is the 16 bit icmp ident field. If you ping
enough
stuff at the same time, eventually you'll have two concurrent pings using the
same ident,
and they will both see each other's
This is almost identical to the changes I made to dwge(4) recently, since
these drivers are very closely related. Unfortunately the only machine I
have with dwxe(4) in it is armv7, so I can't test this properly, but it
does still work there.
Could someone with an arm64 allwinner board try this
On Sun, Dec 19, 2021 at 01:31:24PM +0100, Claudio Jeker wrote:
> In LDAP there is two ways to remove an attribute.
> One can remove an attribute by just naming the attribute but it is also
> possible to remove a specific attribute: value combo.
>
> In ldapd the latter is broken if the last
ldapd currently can't reopen its database files, because it always passes
O_CREAT to open() when reopening (see ldapd_open_request()), which means it
needs the unveil 'c' flag. This may have been missed when ldapd was unveiled
because 'ldapctl compact' was broken (see other diff).
ok?
Index:
r1.5 of ldapctl.c accidentally inverted the conditionals meant to skip
compacting or indexing namespaces with referrals.
ok?
Index: ldapctl.c
===
RCS file: /cvs/src/usr.sbin/ldapctl/ldapctl.c,v
retrieving revision 1.15
diff -u -p -u
This applies our normal strategies for making network drivers mpsafe, and
also writes to GMAC_TX_POLL_DEMAND once per call to dwge_start() rather than
once per packet, and returns rx slots once per interrupt rather than once
per packet.
I've tested this on a rockpro64, where it makes tcpbench
On Tue, Oct 26, 2021 at 02:52:10PM +0200, Jan Klemkow wrote:
> On Tue, Oct 26, 2021 at 05:17:55PM +1000, Jonathan Matthew wrote:
> > First of all, thanks for looking at this, I forgot we hadn't done offloads
> > for ixl(4) yet.
>
> You're welcome.
>
> > In the
Hi Jan,
First of all, thanks for looking at this, I forgot we hadn't done offloads
for ixl(4) yet.
On Mon, Oct 25, 2021 at 05:27:28PM +0200, Jan Klemkow wrote:
> On Fri, Oct 22, 2021 at 03:39:01PM +0200, Hrvoje Popovski wrote:
> > On 22.10.2021. 13:39, Jan Klemkow wrote:
> > > Thats because, you
/null 1 Jan 1970 00:00:00 -
+++ if_uaq.c31 Aug 2021 23:41:35 -
@@ -0,0 +1,1397 @@
+/* $OpenBSD$ */
+/*-
+ * Copyright (c) 2021 Jonathan Matthew
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted
On Tue, Aug 10, 2021 at 12:58:05PM +0200, Martijn van Duren wrote:
> On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> > On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > > This diff allows sending traps in SNMPv3 messages.
> > > It defaults to the global seclevel, but it
While working on a new driver, I noticed we have a few places where we
pass USBD_EXCLUSIVE_USE as the flags parameter to usbd_open_pipe_intr(),
which is wrong.
The interrupt pipe is always opened exclusively, and the flags parameter is
actually passed to usbd_setup_xfer(), where it means
On Thu, Jul 22, 2021 at 10:19:59PM +0200, Martijn van Duren wrote:
> I'm currently working on adding SNMPv3 support to traps in snmpd(8).
> For sending traps we loop over sc_trapreceivers and can send each trap
> to 0 or more receivers.
>
> I want to high-jack snmpe_response() to do the heavy
On Thu, Jul 22, 2021 at 10:27:44PM +0200, Martijn van Duren wrote:
> Not an issue with read requests, but will set requests if they contain
> snmp application elements such as timeticks.
>
> Definitely needed for upcoming SNMPv3 trap support.
>
> OK?
ok jmatthew@
>
> martijn@
>
> Index:
On Thu, Jul 22, 2021 at 10:31:53PM +0200, Martijn van Duren wrote:
> This type-O snuck in when merging traphandler into snmpe.
> Not a big deal since it's there just for ASN1/SMI strictness, but it
> breaks when introducing SNMPv3 support.
>
> OK?
ok jmatthew@
>
> martijn@
>
> Index: snmpe.c
On Tue, Jul 27, 2021 at 08:43:20PM +0200, Martijn van Duren wrote:
> Previous diff failed to set the initial bit when not defining engineid
> in the config.
>
> On Fri, 2021-07-23 at 15:41 +0200, Martijn van Duren wrote:
> > This diff introduces setting the engineid for snmpd(8).
> > Although
On Wed, Jul 14, 2021 at 01:46:37PM +0800, Kevin Lo wrote:
> Hi,
>
> The diff below fixes Rx desc RSS type. This matches what Linux and FreeBSD
> do.
> ok?
ok jmatthew@
>
> Index: sys/dev/pci/if_ix.c
> ===
> RCS file:
On Thu, Jul 22, 2021 at 10:45:17PM -0400, Ashton Fagg wrote:
> I have two devices here based on the JMicron JMB585 chipset. This diff
> adds the required pcidev IDs and sets disables native command queuing in
> the driver. FreeBSD does something similar for this device:
>
>
On Tue, Jul 20, 2021 at 02:21:39PM +0200, Mark Kettenis wrote:
> > Date: Tue, 20 Jul 2021 21:55:56 +1000
> > From: Jonathan Matthew
> >
> > On Mon, Jul 19, 2021 at 07:37:10PM -0400, Ashton Fagg wrote:
> > > I have an Intel 82599 10 gigabit ethernet card I wanted
On Mon, Jul 19, 2021 at 07:37:10PM -0400, Ashton Fagg wrote:
> I have an Intel 82599 10 gigabit ethernet card I wanted to get working
> on my SiFive Unmatched board.
>
> I found the ix(4) driver has some weirdness around MSI-X
> interrupts. While the driver supports operating both with and
On Wed, Jun 23, 2021 at 09:37:10AM +0200, Martin Pieuchot wrote:
> On 16/06/21(Wed) 11:26, Martin Pieuchot wrote:
> > Diff below does two things:
> >
> > - Use atomic operations for incrementing/decrementing references of
> > anonymous objects. This allows us to manipulate them without holding
On Mon, Jun 14, 2021 at 05:35:07PM +0200, Mark Kettenis wrote:
> > Date: Mon, 14 Jun 2021 11:50:24 +0200
> > From: Martin Pieuchot
> >
> > Now that operations on amaps are serialized using a per-map rwlock
> > the KERNEL_LOCK() shouldn't be necessary to call amap_unref(). The
> > diff below
On Tue, Jun 01, 2021 at 08:24:10AM +1000, David Gwynne wrote:
>
>
> > On 1 Jun 2021, at 04:17, Patrick Wildt wrote:
> >
> > Hi,
> >
> > this call to sync the DMA mem wants to sync N - 1 number of prpl
> > entries, as the first segment is configured regularly, while the
> > addresses for the
On Tue, Jun 01, 2021 at 08:20:43AM +1000, David Gwynne wrote:
>
>
> > On 1 Jun 2021, at 04:15, Patrick Wildt wrote:
> >
> > Hi,
> >
> > mcx(4) seems to sync the whole mapsize on processing a received packet.
> > As far as I know, we usually only sync the actual size that we have
> > received.
On Sun, Apr 25, 2021 at 09:44:16AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> I think this should go in as-is. Though I have one question/idea
> to share at the moment.
>
>
> > @@ -672,20 +666,18 @@ arpcache(struct ifnet *ifp, struct ether
> >
> > la->la_asked = 0;
> >
On Thu, Mar 25, 2021 at 05:21:38PM +0800, Kevin Lo wrote:
> Hi,
>
> The diff below moves tx/rx descriptors into their own structs.
> This is a first step toward making rge work with multiple queues and
> interrupts.
> Only one queue is currently used.
>
> While here, update the RTL8125B
On Fri, Mar 19, 2021 at 08:24:12AM -0600, Todd C. Miller wrote:
> On Fri, 19 Mar 2021 13:22:35 +0100, Klemens Nanni wrote:
>
> > I argue it should be `-n' like all the daemons, e.g. vmd(8) and other
> > parsers such as pfctl(8) do.
>
> Yes, please. I was about to make the same point.
Fair
I'd like to add some regress tests for the btrace(8) parser.
To do that, it would help to have a dry-run mode where it just parses the
file and exits.
The way I've implemented it here, it exits immediately after parsing, so it
won't open /dev/dt and try to find the probes the program uses. This
It's fairly easy to accidentally configure relayd to try to run check scripts
faster than they finish, for example if you have a check interval of one
second and the check script makes a tcp connection to a host that doesn't
exist any more.
In this situation, the hce process will keep writing
On Thu, Feb 11, 2021 at 11:41:24AM +, Ricardo Mestre wrote:
> Hi,
>
> Uninitialized var and it's used in a condition != NULL a little bit
> afterwards.
> CID 1501713
>
> OK?
yes, ok jmatthew@
>
> Index: vmt.c
> ===
> RCS
On Fri, Jan 08, 2021 at 12:59:16PM -0600, Scott Cheloha wrote:
> On Mon, Dec 28, 2020 at 11:41:52AM -0300, Martin Pieuchot wrote:
> > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > > Diff below aims to simplify the API to put a thread on a sleep queue and
> > > reduce it to the following:
> >
On Fri, Jan 08, 2021 at 10:34:02PM +0100, Klemens Nanni wrote:
> The report on bugs shows vmt(4) lagging behind and I sent a working
> working open-vm-tools port to ports@ yesterday.
>
> In case the port gets imported and there are no further regressions wrt.
> the functionality vmt(4) already
Anton's fix for parsing of syscall names that are also tokens in the btrace
grammar broke parsing of 'profile:hz:number', because it forces 'hz' to be
handled as a string rather than a token. I can't see how we'd ever end up
with a syscall named 'hz', so one way we could fix this would be to
I don't have a real 586, but I can tell qemu to pretend to be one,
which at least executes this code.
Using kd_waitok here seems suspect, because if we're out of memory
this early I can't see anything else freeing any up, but
uvm_km_zalloc() will also sleep rather than return failure.
Should this
This code is now only here for some unfortunate Intel graphics chips
based on PowerVR, and I don't have a machine with one of those.
vga_post_init() gets called from vga_attach() in any case, and
vga_post_free() doesn't seem to be called at all. I've booted this on
amd64 (real) and i386
Continuing to convert uvm_km_valloc() calls to km_alloc(), sparc64's
struct cpu_info wants to be allocated on an 8 page boundary, so it needs
a custom kmem_va_mode. My T5120 didn't blow up with this, so I think it
works.
ok?
Index: arch/sparc64/sparc64/cpu.c
A few more km_alloc()s following the same pattern as acpi. I don't have any
machines that actually need mpbios(4) but I've booted amd64 and i386 smp qemu
vms with acpi disabled, which causes mpbios to attach instead.
ok?
Index: arch/amd64/amd64/mpbios.c
On Wed, Dec 16, 2020 at 12:00:38AM +0100, Mark Kettenis wrote:
> > Date: Tue, 15 Dec 2020 21:21:37 +0100
> > From: Alexander Bluhm
> >
> > On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> > > Does the diff below fix this?
> >
> > I can reproduce the panic and your diff fixes it.
On Sat, Dec 12, 2020 at 10:54:57PM +1000, Jonathan Matthew wrote:
> On Thu, Dec 10, 2020 at 10:46:58AM -0300, Martin Pieuchot wrote:
> > On 08/12/20(Tue) 22:55, Jonathan Matthew wrote:
> > > On Mon, Dec 07, 2020 at 03:15:50PM -0300, Martin Pieuchot wrote:
> > > >
On Thu, Dec 10, 2020 at 10:46:58AM -0300, Martin Pieuchot wrote:
> On 08/12/20(Tue) 22:55, Jonathan Matthew wrote:
> > On Mon, Dec 07, 2020 at 03:15:50PM -0300, Martin Pieuchot wrote:
> > > Getting a page from the fault handler might require poking at some
> &g
On Mon, Dec 07, 2020 at 03:15:50PM -0300, Martin Pieuchot wrote:
> Getting a page from the fault handler might require poking at some
> swap-related states.
>
> These are not in the hot-path of the fault handler so for the moment
> just assert that the KERNEL_LOCK() is held or grab it if the
On Mon, Dec 07, 2020 at 04:08:46PM -0300, Martin Pieuchot wrote:
> Diff below rewrites uvm_fault() using a loop.
>
> I added a KERNEL_LOCK/UNLOCK() dance around the part that won't be
> unlocked soon to illustrate where this is going.
>
> ok?
yes, ok jmatthew@
>
> Index: uvm/uvm_fault.c
>
On Fri, Dec 04, 2020 at 10:03:46AM -0300, Martin Pieuchot wrote:
> On 04/12/20(Fri) 12:01, Jonathan Matthew wrote:
> > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > > [...]
> > > Could you try the diff below that only call smr_barrier() for mult
On Fri, Dec 04, 2020 at 12:17:31PM -0600, Scott Cheloha wrote:
> On Fri, Dec 04, 2020 at 09:56:02AM +0100, Claudio Jeker wrote:
> > On Thu, Dec 03, 2020 at 10:05:30PM -0600, Scott Cheloha wrote:
> > > Hi,
> > >
> > > srp_finalize(9) uses tsleep(9) to spin while it waits for the object's
> > >
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:
> > > > O
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:
> > > > [...]
&g
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 smr_barrier() in it and checked that it
> > does not cause a slow down? I am sceptical, smr_barrier() is a very slow
> > construct which
On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote:
> On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote:
> > Every multi-threaded process keeps a list of threads in `ps_threads'.
> > This list is iterated in interrupt and process context which makes it
> > complicated to
On Sat, Nov 28, 2020 at 11:20:30PM +0100, Theo Buehler wrote:
> /usr/src/usr.sbin/ldapd/util.c:46:21: warning: comparison of integers of
> different signs:
> 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare]
> if (ret < 0 || ret >= size)
>~~~ ^
On Wed, Nov 18, 2020 at 08:31:23PM -0300, Martin Pieuchot wrote:
> I found another race related to some missing locking, this time around
> uvm_pageclean().
>
> Diff below fixes the two places in /sys/uvm where the page queue lock
> should be taken. To prevent further corruption I added some
On Tue, Nov 17, 2020 at 09:25:10AM -0300, Martin Pieuchot wrote:
> Here's another refactoring that moves the remaining logic of uvm_fault()
> handling lower faults, case 2, to its own function. This logic shouldn't
> be modified in the first step of unlocking amap & anon and will still be
>
On Fri, Nov 13, 2020 at 12:04:23PM -0300, Martin Pieuchot wrote:
> Another simple refactoring of uvm_fault() removing a goto, ok?
I like it, ok jmatthew@
>
> Index: uvm/uvm_fault.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
>
On Fri, Nov 13, 2020 at 12:17:04PM +0100, Theo Buehler wrote:
> On Wed, Nov 04, 2020 at 11:04:12AM -0300, Martin Pieuchot wrote:
> > Diff below introduces a helper that looks for existing mapping. The
> > value returned by this lookup function determines if there's an anon
> > at the faulting
On Fri, Oct 30, 2020 at 08:46:20PM +0100, Martin Pieuchot wrote:
> On 23/10/20(Fri) 10:31, Martin Pieuchot wrote:
> > More refactoring. This time let's introduce a helper to manipulate
> > references. The goal is to reduce the upcoming diff adding locking.
> >
> > This is extracted from a
On Wed, Nov 11, 2020 at 05:25:25AM -0300, Martin Pieuchot wrote:
> While discussing the new source address mechanism with denis@, I figured
> those ought to be documented.
>
> Note that `ar_rtableid' is unused and can die. The ART code is actually
> free from any network knowledge.
>
> ok?
ok
Like ospfd, ospf6d can use ROUTE_FLAGFILTER to opt out of receiving messages
relating to L2 and broadcast routes on its routing socket. We've been running
this for a week or so with no problems.
ok?
Index: kroute.c
===
RCS file:
On Wed, Aug 19, 2020 at 09:28:41PM -0500, Scott Cheloha wrote:
> Hi,
>
> I was auditing the tree for odd-looking time structure usage and I
> came across the UUID code in ldapd(8), uuid.c.
>
> time_cmp() is backwards. Or the caller is misusing it. One or the
> other. It returns -1 if tv1
ospfd is our first target for using ROUTE_FLAGFILTER to reduce pressure on the
route socket, so here's the diff we've been running for a couple of weeks now
(minus the fix for RTM_DELETE flags, notably).
ok?
Index: kroute.c
===
RCS
While looking into filtering out messages for L2 routes in the kernel to reduce
load on routing daemons, I noticed that the RTM_DELETE messages do not have
the RTF_LLINFO flag set, which is inconvenient because that's what I want to
filter on.
I tracked this down to r1.361 and r1.362 of
Most (all?) of our routing daemons don't care about layer 2 or broadcast
routing entries, so they do something like this after reading a message
off the socket:
/* Skip ARP/ND cache and broadcast routes. */
if (rtm->rtm_flags & (RTF_LLINFO|RTF_BROADCAST))
continue;
This came out of the work on supporting ACPI0007 devices in acpicpu(4), but
it's independent of that and I'd like to get it in the tree separately.
Since it was first added, acpicpu stores instances of itself in an array,
which it uses to find the acpicpu device for a cpu. This runs into
On Wed, Jul 29, 2020 at 08:29:31PM +1000, Jonathan Matthew wrote:
> On Wed, Jul 29, 2020 at 10:06:14AM +0200, Mark Kettenis wrote:
> > > Date: Wed, 29 Jul 2020 10:38:55 +1000
> > > From: Jonathan Matthew
> > >
> > > On Tue, Jul 28, 2020 at 07:30:36PM +02
On Wed, Jul 29, 2020 at 10:06:14AM +0200, Mark Kettenis wrote:
> > Date: Wed, 29 Jul 2020 10:38:55 +1000
> > From: Jonathan Matthew
> >
> > On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 28 Jul 2020 21:42:46
On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 21:42:46 +1000
> > From: Jonathan Matthew
> >
> > On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 28 Jul 2020 13:46:34
On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > From: Jonathan Matthew
> >
> > On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 27 Jul 2020 17:02:41 +020
On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > From: Mark Kettenis
> >
> > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > "Device()" nodes with a _HID() method that returns "ACPI0007". This
> > diff
mcx(4) is almost ready to enable RSS, except arm64 doesn't yet support
mapping interrupts to cpus. Until that's in place, here's a diff with the
missing pieces from the driver in case anyone wants to test. This will
enable up to 8 rx/tx queues, depending on the number of cpus available.
Index:
On Wed, Jun 17, 2020 at 12:50:46PM +0200, Hrvoje Popovski wrote:
> On 17.6.2020. 12:45, Hrvoje Popovski wrote:
> > On 17.6.2020. 11:27, Hrvoje Popovski wrote:
> >> On 17.6.2020. 10:36, David Gwynne wrote:
> >>> this is an updated version of a diff from christiano haesbaert by way of
> >>> mpi@ to
This enables use of hardware crypto for CCMP in urtwn(4). As with other
drivers, this reduces cpu usage significantly when moving lots of data.
I've tested this on an assortment of hardware (RTL8188CUS, RTL8188EU,
RTL8192EU) with no problems, and this is one of the few things that
remains constant
This implements vlan offload in mcx(4). vlan stripping is fairly
straightforward, as the nic just removes the tag and populates a field in
the completion queue entry. vlan insertion is a bit funny, as the nic doesn't
do any of the work here at all. The driver has to copy at least the L2 headers
This prepares vmx(4) for multi-queue operation, first by making use of msi-x
where available, and second by rearranging the queue structures to fit the
direction we're heading in. As with other drivers, here I'm reserving msi-x
vector 0 for events, then mapping tx/rx queues to the subsequent
So far I've completely ignored offloads in the ethernet drivers I've
written, but on having a quick look at the documentation I found that
mcx(4) checksum offload is extremely easy to use, and some simple testing
suggests that it helps quite a bit. I've seen tcpbench receive throughput
increase
This makes ixl(4) use MSI-X where available. The hardware is set up
for the same kind of approach as we're heading towards in em(4) and
ix(4) - interrupts for admin commands and events (link state etc.)
can only be delivered to vector 0, and the natural approach is to
map rx and tx queues to
1 - 100 of 220 matches
Mail list logo
