Re: [External] : arp mbuf queue

2021-04-25 Thread Jonathan Matthew
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; > >

Re: rge(4): move tx/rx descriptors into their own structs

2021-03-29 Thread Jonathan Matthew
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

Re: btrace: add dry run mode

2021-03-19 Thread Jonathan Matthew
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

btrace: add dry run mode

2021-03-19 Thread Jonathan Matthew
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

relayd check script memory explosion

2021-02-14 Thread Jonathan Matthew
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

Re: Uninitialized var in dev/pv/vmt.c

2021-02-11 Thread Jonathan Matthew
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

Re: sleep_setup/finish simplification

2021-01-08 Thread Jonathan Matthew
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: > >

Re: remove vmt(4) (superseeded by open-vm-tools package)

2021-01-08 Thread Jonathan Matthew
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

btrace: fix parsing of profile:hz:

2021-01-08 Thread Jonathan Matthew
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

convert i386 fix_f00f() uvm_km_zalloc

2021-01-03 Thread Jonathan Matthew
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

convert vga POST uvm_km_vallocs

2021-01-02 Thread Jonathan Matthew
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

sparc64 cpu uvm_km_valloc()

2020-12-20 Thread Jonathan Matthew
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

mpbios: replace uvm_km_valloc() with km_alloc()

2020-12-19 Thread Jonathan Matthew
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

converting uvm_km_valloc to km_alloc

2020-12-17 Thread Jonathan Matthew
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.

Re: uvm_fault: entering swap code

2020-12-13 Thread Jonathan Matthew
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: > > > >

Re: uvm_fault: entering swap code

2020-12-12 Thread Jonathan Matthew
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

Re: uvm_fault: entering swap code

2020-12-08 Thread Jonathan Matthew
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

Re: uvm_fault: kill goto in uvm_fault()

2020-12-08 Thread Jonathan Matthew
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 >

Re: Use SMR_TAILQ for `ps_threads'

2020-12-05 Thread Jonathan Matthew
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

Re: srp_finalize(9): tsleep(9) -> tsleep_nsec(9)

2020-12-05 Thread Jonathan Matthew
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 > > >

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Jonathan Matthew
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

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Jonathan Matthew
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

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Jonathan Matthew
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

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Jonathan Matthew
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

Re: ldapd warning

2020-11-29 Thread Jonathan Matthew
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) >~~~ ^

Re: Locking of uvm_pageclean()

2020-11-19 Thread Jonathan Matthew
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

Re: uvm_fault: refactoring for case 2 faults

2020-11-19 Thread Jonathan Matthew
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 >

Re: uvm_fault: Kill goto Case2

2020-11-15 Thread Jonathan Matthew
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 >

Re: uvm_fault: is there an anon?

2020-11-13 Thread Jonathan Matthew
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

Re: amap: introduce amap_adjref_anons()

2020-11-12 Thread Jonathan Matthew
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

Re: Document art locking fields

2020-11-12 Thread Jonathan Matthew
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

ospf6d: use ROUTE_FLAGFILTER

2020-09-01 Thread Jonathan Matthew
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:

Re: ldapd(8): fix, simplify UUID timestamp code

2020-08-21 Thread Jonathan Matthew
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: use ROUTE_FLAGFILTER

2020-08-16 Thread Jonathan Matthew
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

RTM_DELETE messages for L2 routes have incorrect flags

2020-08-10 Thread Jonathan Matthew
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

filtering routing socket messages by flags

2020-08-05 Thread Jonathan Matthew
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;

acpicpu: remove acpicpu_sc array

2020-08-05 Thread Jonathan Matthew
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

Re: acpicpu(4) and ACPI0007

2020-08-01 Thread Jonathan Matthew
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

Re: acpicpu(4) and ACPI0007

2020-07-29 Thread Jonathan Matthew
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

Re: acpicpu(4) and ACPI0007

2020-07-28 Thread Jonathan Matthew
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

Re: acpicpu(4) and ACPI0007

2020-07-28 Thread Jonathan Matthew
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

Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Jonathan Matthew
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) RSS

2020-07-14 Thread Jonathan Matthew
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:

Re: multiple rings and cpus for ix(4)

2020-06-17 Thread Jonathan Matthew
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

urtwn(4) hardware crypto

2020-06-05 Thread Jonathan Matthew
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

mcx(4) vlan offload

2020-05-28 Thread Jonathan Matthew
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

vmx(4) msi-x

2020-05-25 Thread Jonathan Matthew
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

mcx(4) checksum offload

2020-05-18 Thread Jonathan Matthew
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

msi-x for ixl(4)

2020-04-27 Thread Jonathan Matthew
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

Re: Fix typo on if_mcx.c

2020-04-23 Thread Jonathan Matthew
On Thu, Apr 23, 2020 at 07:31:37PM +0100, Ricardo Mestre wrote: > Hi, > > This one looks like a typo and might cause a double free. > > CID 1492713 > > OK? ok jmatthew@ > > Index: if_mcx.c > === > RCS file:

Re: em(4) towards multiqueues

2020-02-18 Thread Jonathan Matthew
On Fri, Feb 14, 2020 at 06:28:20PM +0100, Martin Pieuchot wrote: > This diff introduces the concept of "queue" in the em(4) driver. The > logic present in ix(4) has been matched for coherency. > > Currently the driver uses a single queue and the diff below doesn't > change anything in that

Re: diff: nvme.c

2020-02-15 Thread Jonathan Matthew
On Sat, Feb 15, 2020 at 12:17:52PM +0900, YASUOKA Masahiko wrote: > Hi, > > I have a problem that kernel core dumping always hangs around first > 8MB. The diff attached fixes the problem. > > In nvme_poll(): > > 930 while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) { > 931

Re: nep(4) rx error interrupts

2020-02-12 Thread Jonathan Matthew
On Tue, Feb 11, 2020 at 06:44:12AM +1000, Jonathan Matthew wrote: > On Mon, Feb 10, 2020 at 02:04:06PM +0100, Mark Kettenis wrote: > > Jonathan Matthew schreef op 2020-02-10 13:19: > > > I'm trying to use aggr on top of nep(4), which has turned up a few bugs. > > &g

Re: nep(4) rx error interrupts

2020-02-10 Thread Jonathan Matthew
On Mon, Feb 10, 2020 at 02:04:06PM +0100, Mark Kettenis wrote: > Jonathan Matthew schreef op 2020-02-10 13:19: > > I'm trying to use aggr on top of nep(4), which has turned up a few bugs. > > Firstly, the nic appears to report rx errors in the second interrupt > > state vec

nep(4) rx error interrupts

2020-02-10 Thread Jonathan Matthew
I'm trying to use aggr on top of nep(4), which has turned up a few bugs. Firstly, the nic appears to report rx errors in the second interrupt state vector, which the driver doesn't expect, so I get this: nep3: nep_intr 0 8 0 and then, since the interrupt wasn't rearmed, the interface stops.

Re: vlan: use SMR_SLIST instead of SRP to protect instance lists

2020-01-26 Thread Jonathan Matthew
On Mon, Jan 27, 2020 at 12:48:49AM +0100, Alexandr Nedvedicky wrote: > Hello, > > > > > I'm not sure about your diff see below. > > > > visa@ pointed out that PF_LOCK will introduce a potential sleep inside > > if_vinput(), > > making this unsafe, so here's a less optimistic diff where

Re: vlan: use SMR_SLIST instead of SRP to protect instance lists

2020-01-26 Thread Jonathan Matthew
On Sun, Jan 26, 2020 at 11:02:29PM +0100, Alexandr Nedvedicky wrote: > Hello, > > > On Sun, Jan 26, 2020 at 10:06:24AM +1100, Jonathan Matthew wrote: > > Converting vlan(4) to use SMR instead of SRP to protect the instance lists > > is pretty simple. vlan_input()

vlan: use SMR_SLIST instead of SRP to protect instance lists

2020-01-25 Thread Jonathan Matthew
Converting vlan(4) to use SMR instead of SRP to protect the instance lists is pretty simple. vlan_input() doesn't keep a reference to vlan_softcs outside the read critical section, so we don't need to reference count them any more. After the smr_barrier() in vlan_clone_destroy, all pointers to

Re: MSI-X & Interrupting CPU > 0

2020-01-23 Thread Jonathan Matthew
On Thu, Jan 23, 2020 at 11:28:50AM +0100, Martin Pieuchot wrote: > I'd like to make progress towards interrupting multiple CPUs in order to > one day make use of multiple queues in some network drivers. The road > towards that goal is consequent and I'd like to proceed in steps to make > it

Re: em(4) diff to test

2020-01-22 Thread Jonathan Matthew
On Tue, Jan 21, 2020 at 12:31:52PM +0100, Martin Pieuchot wrote: > On 20/01/20(Mon) 16:42, Martin Pieuchot wrote: > > Diff below is a refactoring of the actual em(4) code and defines that > > will allows me to present a shorter diff to interrupt multiple CPUs and > > make use of multiple queues. >

Re: qle(4): tsleep(9) -> tsleep_nsec(9)

2020-01-14 Thread Jonathan Matthew
On Mon, Jan 13, 2020 at 06:32:00PM -0600, Scott Cheloha wrote: > These sleeps don't have units, though in practice they are 1 second. > Just prior in the code I see a delay(9) of 100 microseconds. Is the > 100 ticks here a typo? What is a reasonable sleep duration for this > hardware? Both of

Re: ipmi@acpi improvement

2020-01-06 Thread Jonathan Matthew
On Sat, Jan 04, 2020 at 08:22:56PM +0100, Mark Kettenis wrote: > > Date: Sat, 21 Dec 2019 12:30:50 +0100 (CET) > > From: Mark Kettenis > > > > On arm64 systems, IPMI can actually attach using mmio. The diff below > > implements this. It also sets the IPMI revision based on the _SRV > > method

Re: Add pcidev for Ryzen 3x ccp

2020-01-01 Thread Jonathan Matthew
On Thu, Jan 02, 2020 at 10:20:52AM +1100, Jonathan Gray wrote: > On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote: > > On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote: > > > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote: > > > > My CPU has a CCP that

Re: sparc64: find root device on hardware RAID

2019-12-30 Thread Jonathan Matthew
On Mon, Dec 30, 2019 at 03:36:54PM +0100, Klemens Nanni wrote: > On Mon, Dec 30, 2019 at 06:59:35PM +1000, Jonathan Matthew wrote: > > Here's the Solaris explanation: > > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/scsi/adapters/mpt_

Re: sparc64: find root device on hardware RAID

2019-12-30 Thread Jonathan Matthew
On Sun, Dec 29, 2019 at 05:58:02AM +0100, Klemens Nanni wrote: > On Sun, Dec 29, 2019 at 01:59:38PM +1000, Jonathan Matthew wrote: > > I think we have the wrong size for the volume name, hence the difference > > between the size reported by the controller and the size of vpg. >

Re: sparc64: find root device on hardware RAID

2019-12-29 Thread Jonathan Matthew
On Sun, Dec 29, 2019 at 07:40:01AM +0100, Klemens Nanni wrote: > On Sun, Dec 29, 2019 at 03:30:15AM +0100, Klemens Nanni wrote: > > > link->target isn't the right place to put this, for one thing it's only > > > 16 bits > > > and the wwn is 64 bits, and it's used throughout the driver to look up

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Jonathan Matthew
On Sun, Dec 29, 2019 at 03:30:15AM +0100, Klemens Nanni wrote: > On Sun, Dec 29, 2019 at 10:29:48AM +1000, Jonathan Matthew wrote: > > > + memset(, 0, sizeof(vpg)); > > > + pagelen = hdr.page_length * 4; > > > > We probably should check that this

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Jonathan Matthew
On Fri, Dec 27, 2019 at 07:50:34PM +0100, Klemens Nanni wrote: > On Fri, Dec 27, 2019 at 09:46:56AM +0100, Mike Belopuhov wrote: > > Looks like WWID for the RAID volume can be read from the RAID Volume > > Page 1 (mpii_cfg_raid_vol_pg1). > jmatthew also suggested that, thanks. > > I'm looking

Re: mpii: attach Flash Accelerator F80 800G eMLC

2019-12-27 Thread Jonathan Matthew
On Sat, Dec 28, 2019 at 03:23:51AM +0100, Klemens Nanni wrote: > On Sat, Dec 28, 2019 at 01:14:17PM +1100, Jonathan Gray wrote: > > drop the _PCIE and just have > > > > product SYMBIOS SSS6200 > Sure enough. I added it in analogy to other devices. What is the rule > here for such suffix? Only

Re: mpii: attach Flash Accelerator F80 800G eMLC

2019-12-27 Thread Jonathan Matthew
On Fri, Dec 27, 2019 at 05:54:56PM -0700, Theo de Raadt wrote: > > +product SYMBIOS F80_PCIE 0x007e Flash Accelerator F80 800GB eMLC > > Please keep it short, these strings land in every kernel. > > F80 eMLC > > That is probably enough, on top of SYMBIOS vendorID. It'd be better to use

Re: Support for Realtek RTL8125 2.5Gb Ethernet controller

2019-11-17 Thread Jonathan Matthew
On Fri, Nov 15, 2019 at 03:44:24PM +0800, Kevin Lo wrote: > Hi, > > The following diff adds support for Realtek RTL8125 chip. > Tested with Syba SD-PEX24065. > > Test reports and OKs are welcome. I don't have hardware to test with, but I've read through this and it looks good to me. One thing

exact meaning of bio(4) bv_level

2019-11-14 Thread Jonathan Matthew
Recently I plugged in an old box we got a while ago that used to crash weirdly during boot and to my surprise, everything works now. 'bioctl mfi0' gave me further surprises, as it claimed there was a four disk RAID17 volume. It turns out megaraids give us SNIA DDF raid levels, which include

Re: sparc64: use devid to match bootpath

2019-10-14 Thread Jonathan Matthew
On Mon, Oct 14, 2019 at 03:08:54PM +0200, Mark Kettenis wrote: > > Date: Mon, 14 Oct 2019 18:44:08 +1000 > > From: Jonathan Matthew > > > > Recently I discovered that (some?) mpii(4) controllers fill in > > link->port_wwn > > with a fake wwn (443322110

sparc64: use devid to match bootpath

2019-10-14 Thread Jonathan Matthew
Recently I discovered that (some?) mpii(4) controllers fill in link->port_wwn with a fake wwn (443322110200) for sata devices. When you're trying to boot a sparc64 box off a sata device attached to such a controller, this means the bootpath matching in device_register() doesn't work, so you

ifq_restart() in dwxe/dwge

2019-10-06 Thread Jonathan Matthew
I noticed the new dwge(4) locks up after a while running tcpbench. After scratching my head quite a lot I realised it wasn't restarting the send queue after processing tx completions, it was just clearing OACTIVE, Changing this to call ifq_restart() instead (as prescribed in ifq.h) things work

Re: bnxt: Support MSI-X

2019-09-02 Thread Jonathan Matthew
On Mon, Sep 02, 2019 at 04:47:32PM +0200, Stefan Fritsch wrote: > Tested with a BCM57412 > > OK? ok jmatthew@ > > diff --git a/sys/dev/pci/if_bnxt.c b/sys/dev/pci/if_bnxt.c > --- a/sys/dev/pci/if_bnxt.c > +++ b/sys/dev/pci/if_bnxt.c > @@ -102,6 +102,7 @@ > #define BNXT_FLAG_NPAR

iavf(4): intel adaptive virtual function driver

2019-07-28 Thread Jonathan Matthew
Normally I'm not very enthusiastic about nic virtual functions, but this seemed like it might be interesting to work on, because Intel documented the virtual function interface (it turns out this is only mostly true), they're claiming future nics will use the same vf interface (this is true for

Re: pf_state_key_link_reverse() needs atomic ops

2019-06-10 Thread Jonathan Matthew
On Mon, Jun 10, 2019 at 11:46:55AM -0300, Martin Pieuchot wrote: > On 10/06/19(Mon) 09:29, Alexandr Nedvedicky wrote: > > Hello, > > > > sorry for extra delay (was off-line over the weekend). > > > > On Sat, Jun 08, 2019 at 09:46:24PM +1000, Jonathan Matthew

Re: pf_state_key_link_reverse() needs atomic ops

2019-06-08 Thread Jonathan Matthew
On Tue, Jun 04, 2019 at 01:50:51AM +0200, Alexandr Nedvedicky wrote: > Hello, > > I've managed to get pf_test() running in parallel on forwarding path in my > experimental tree. And there was some fall out. PF died on ASSERT() in > pf_state_key_link_reverse() at line 7371: > > 7368

Re: MSI-X fix

2019-05-30 Thread Jonathan Matthew
On Thu, May 30, 2019 at 08:25:39PM +0200, Mark Kettenis wrote: > I started implementing MSI-X support for arm64 adn tried to use re(4) > for testing. This failed miserably and when I tried to use MSI-X with > re(4) on amd64 I noticed it didn't work either. > > Turns out the Realtek hardware

Re: net80211: fix ifconfig mode command

2019-05-27 Thread Jonathan Matthew
On Mon, May 27, 2019 at 01:36:38PM +0200, Stefan Sperling wrote: > Anyone? makes sense to me, ok jmatthew@ > > On Wed, May 22, 2019 at 02:49:43PM +0200, Stefan Sperling wrote: > > On Mon, Apr 15, 2019 at 04:56:52PM +0200, Stefan Sperling wrote: > > > The ifconfig mode command is broken; It is

tx reports for run(4)

2019-05-20 Thread Jonathan Matthew
This prepares run(4) for adding basic .11n support. In order to use MiRA for rate selection, we need per-frame status reports. In run(4), this is done by setting a packet ID on each frame we transmit, and reading the results from the tx status fifo shortly after (but not immediately after)

Re: iwm: move mbuf hacks down in iwm_rx_rx_mpdu()

2019-05-08 Thread Jonathan Matthew
On Wed, May 08, 2019 at 03:01:05PM -0400, Stefan Sperling wrote: > Don't write to mbuf memory before we've actually completed all > sanity checks and iwm_rx_addbuf() has succcessfully put a new > buffer on the ring. > > Same as dragonfly commit 96eaecf93d9f731459a0df8efc72cfad034320bd > "Avoids

Re: ifmedia_ioctl: ignore ENETRESET from ifm_change()

2019-04-24 Thread Jonathan Matthew
On Wed, Apr 24, 2019 at 12:21:47PM +0200, Stefan Sperling wrote: > On Sun, Apr 21, 2019 at 09:44:08PM +0800, Kevin Lo wrote: > > On Sun, Apr 21, 2019 at 01:02:39PM +1000, Jonathan Matthew wrote: > > > Currently we have some drivers with media_change > > > functio

Re: ifmedia_ioctl: ignore ENETRESET from ifm_change()

2019-04-20 Thread Jonathan Matthew
On Mon, Apr 15, 2019 at 04:48:02PM +0200, Stefan Sperling wrote: > ieee80211_media_change() will return ENETRESET if the interface is > switched into 11a/b/g/n mode from any other mode. > ifmedia_ioctl() considers this an error and reverts ifmedia's state > to the previous setting, even though

print msi/x details in pcidump

2019-04-01 Thread Jonathan Matthew
This makes pcidump -v show whether MSI/MSI-X interrupts are enabled for a device, and for MSI-X, the size of the interrupt table and which BAR/offset it's in. ok? Index: pcidump.c === RCS file: /cvs/src/usr.sbin/pcidump/pcidump.c,v

Re: athn(4): enable more calibration

2019-01-30 Thread Jonathan Matthew
On Tue, Jan 29, 2019 at 09:11:42PM +0100, Stefan Sperling wrote: > The diff below enables periodic ADC/IQ calibration on athn(4) devices. > Without this calibration athn devices might perform suboptimally > as they warm up during operation. > > The code is already there, it was just not being

decode snmpv3 in tcpdump

2018-11-25 Thread Jonathan Matthew
I'm implementing snmpv3 in our erlang snmp client at the moment, so I thought it'd be nice if tcpdump was able to understand it too. I've roughly copied the output formatting from tcpdump.org tcpdump, but the code is all my own work. Unlike the other tcpdump, this just says '[PDU encrypted]' for

Re: 6.4 - RX not working on new supported BCM574xx (bnxt)

2018-11-10 Thread Jonathan Matthew
t; On Sat, 10 Nov 2018 at 05:10, David Gwynne wrote: > > > > > > > > > On 10 Nov 2018, at 12:22 pm, Jonathan Matthew wrote: > > > > > > On Fri, Nov 09, 2018 at 04:35:38AM -0700, Luthing wrote: > > >> Hello there, > > >> &g

Re: 6.4 - RX not working on new supported BCM574xx (bnxt)

2018-11-09 Thread Jonathan Matthew
On Fri, Nov 09, 2018 at 04:35:38AM -0700, Luthing wrote: > Hello there, > > I am facing an issue with a Broadcom NIC (specs here > https://www.broadcom.com/products/ethernet-connectivity/controllers/bcm57416/#specifications). > > After some troubleshooting, I am not able to resolve listen ARP

Re: YP/NIS support in /etc/ethers, libc ether_ntohost/ether_hostton

2018-11-09 Thread Jonathan Matthew
On Thu, Nov 08, 2018 at 08:05:13PM -0500, Bryan Steele wrote: > These libc functions are used to map hardware MAC addresses to hostnames > and vice versa. If it exists, /etc/ethers will typically contain a > number of lines like so: > > 34:00:8a:56:10:20 superman > > In addition to that,

Re: Enabled bnxt on arm64

2018-09-10 Thread Jonathan Matthew
On 11/09/18 12:03, Carlos Cardenas wrote: Howdy. Attached is a patch to enable bnxt on arm64. Tested (and running) on mcbin with Broadcom BCM57404 (Dell variant). Comments? Ok? ok by me. +--+ Carlos

broadcom netxtreme-c/e driver

2018-07-08 Thread Jonathan Matthew
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. */ /* * Copyright (c) 2018 Jonathan Matthew * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyrigh

Re: Do you have an AMD Ryzen or Epyc CPU?

2018-06-20 Thread Jonathan Matthew
On Wed, Jun 20, 2018 at 10:38:41AM +0100, Stuart Henderson wrote: > On 2018/06/20 05:53, Leo Unglaub wrote: > > Hi, > > I applied your code on my AMD Ryzen 7 1700X. Below is the dmesg. I hope this > > helps, if you have any other AMD Ryzen related stuff that needs testing > > please let me know. >

mpii support for sas3.5 controllers

2018-06-16 Thread Jonathan Matthew
This adds support for SAS3.5 controllers in mpii(4). To get these working, I had to rearrange the initialisation code a bit. The new controllers don't like being hard reset, which means we have to call mpii_iocfacts() to determine whether soft reset is supported before calling mpii_init(). The

Re: mfii(4): add bio(4) support

2018-05-17 Thread Jonathan Matthew
On 15/05/18 14:13, Naoki Fukaumi wrote: Hi Jonathan Matthew, here is updated patch. could you review it? I've just committed a series of changes based on your patch. dlg and I decided that it'd be better if mfii_mgmt() took scsi flags rather than MFII_DATA_IN/OUT, so I reworked all

Re: ldapd: fix log and format string errors

2018-05-15 Thread Jonathan Matthew
On Tue, May 15, 2018 at 10:58:10AM +0200, Sebastian Benoit wrote: > Reyk Floeter(r...@openbsd.org) on 2018.05.15 09:40:27 +0200: > > On Mon, May 14, 2018 at 12:45:18PM +0200, Reyk Floeter wrote: > > > Hi, > > > > > > the following patch updates ldapd to use log.c from vmd/relayd/etc. > > > > > >

Re: ldapd: filter rules on attributes

2018-05-12 Thread Jonathan Matthew
On Fri, May 11, 2018 at 10:42:32PM +0200, Reyk Floeter wrote: > Hi! > > (resent to tech@) > the following ldapd patch allows filter rules to match on attributes. > > This can be used to allow users to change their password (and a few > other things) but not their entire dn. > > For example, in

Re: ignore memory past 512GB

2018-04-19 Thread Jonathan Matthew
On Fri, Apr 20, 2018 at 04:59:27AM +0200, Mark Kettenis wrote: > > Date: Fri, 20 Apr 2018 11:41:10 +1000 > > From: Jonathan Matthew <jonat...@d14n.org> > > > > We just got some R6415s with 512GB of memory and found it's hard to boot > > them > > beca

ignore memory past 512GB

2018-04-19 Thread Jonathan Matthew
We just got some R6415s with 512GB of memory and found it's hard to boot them because the kernel message buffer ends up past the 512GB boundary, but the direct map is "only" 512GB, so initmsgbuf() crashes. I found 'mach mem =1G' moves the buffer below 512GB (but 'mach mem =2G' doesn't!), which

  1   2   >