Re: pfsync slpassert on boot and panic

2022-11-25 Thread Hrvoje Popovski
On 25.11.2022. 10:12, Alexandr Nedvedicky wrote: > Looks like we need to synchronize pfsync destroy with timer thread. > > thanks for great testing. > > regards > sashan > > 8<---8<---8<--8< > diff --git a/sys/net/if_pfsync.c

pfsync slpassert on boot and panic

2022-11-25 Thread Hrvoje Popovski
Hi, I think that this is similar problem as what David Hill send on tech@ with subject "splassert on boot" I've checkout tree few minutes ago and in there should be mvs@ "Remove netlock assertion within PF_LOCK()" and dlg@ "get rid of NET_LOCK in the pf purge work" diffs. on boot I'm getting

Re: replace SRP with SMR in the if_idxmap commit

2022-11-10 Thread Hrvoje Popovski
On 10.11.2022. 14:59, David Gwynne wrote: > 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

replace SRP with SMR in the if_idxmap commit

2022-11-09 Thread Hrvoje Popovski
Hi all, I've checkout cvs half an hour ago on two boxes and both boxes won't properly boot. First one stops here ppb10 at pci1 dev 28 function 4 "Intel 8 Series PCIE" rev 0xd5: msi pci12 at ppb10 bus 13 em4 at pci12 dev 0 function 0 "Intel I350" rev 0x01: msi, address 00:25:90:5d:c9:9a em5 at

Re: ifconfig, wireguard output less verbose, unless -A or

2022-10-24 Thread Hrvoje Popovski
On 14.10.2022. 23:57, Mikolaj Kucharski wrote: > Kind reminder. Below there is a comment with an OK from sthen@ > > Diff at the end of this email. > > Hi all, can this diff be committed? Less verbose output of ifconfig wg interface is quite nice when handling wg vpn server Thank you > On

Re: em(4) IPv4, TCP, UDP checksum offloading

2022-10-18 Thread Hrvoje Popovski
On 15.10.2022. 22:01, Moritz Buhl wrote: > With the previous diffs I am seeing sporadic connection problems in tcpbench > via IPv6 on Intel 82546GB. > The diff was too big anyways. Here is a smaller diff that introduces > checksum offloading for the controllers that use the advanced descriptors. >

Re: em(4) IPv4, TCP, UDP checksum offloading

2022-10-11 Thread Hrvoje Popovski
On 11.10.2022. 17:16, Stuart Henderson wrote: Hi, > I tried this on my laptop which has I219-V em (I run it in a trunk > with iwm). It breaks tx (packets don't show up on the other side). > rx seems ok. > > There is also a "em0: watchdog: head 111 tail 20 TDH 20 TDT 111" this em log can be

Re: em(4) IPv4, TCP, UDP checksum offloading

2022-10-11 Thread Hrvoje Popovski
On 11.10.2022. 15:03, Moritz Buhl wrote: > Here is a new diff for checksum offloading (ipv4, udp, tcp) for em(4). > > The previous diff didn't implement hardware vlan tagging for >em82578 > which should result in variable ethernet header lengths and thus > wrong checksums inserted at wrong

Re: problem with interrupts on machines with many cores and multiqueue nics

2022-10-02 Thread Hrvoje Popovski
On 1.10.2022. 23:28, Mark Kettenis wrote: > At least on some of these machines, you're simply running out of > kernel malloc space. The machines "hang" because the M_WAITOK flag is > used for the allocations, and malloc(9) waits in the hope someone else > gives up the memory. Maybe we need to

Re: sysupgrade - Reading from socket: Undefined error: 0

2022-09-20 Thread Hrvoje Popovski
On 20.9.2022. 8:50, Florian Obser wrote: > On 2022-09-19 22:27 +02, Hrvoje Popovski wrote: >> Hi all, >> >> when doing sysupgrade few minutes ago on multiple machines i'm getting >> error in subject >> >> smc24# sysupgrade -s >> Fetching from https:

Re: sysupgrade - timezone

2022-09-19 Thread Hrvoje Popovski
On 19.9.2022. 23:22, Todd C. Miller wrote: > There was a bad diff in that snapshot that caused tzset() to ignore > /etc/localtime. > > - todd > Thank you ...

Re: sysupgrade - timezone

2022-09-19 Thread Hrvoje Popovski
On 19.9.2022. 23:09, Todd C. Miller wrote: > On Mon, 19 Sep 2022 23:06:13 +0200, Hrvoje Popovski wrote: > >> after sysupgrade I'm having GMT >> >> OpenBSD 7.2 (GENERIC.MP) #736: Mon Sep 19 17:56:55 GMT 2022 >> r620-1# date >> Mon Sep 19 21:01:14 GMT 2022

sysupgrade - timezone

2022-09-19 Thread Hrvoje Popovski
Hi all, before sysupgrade I had CEST timezone OpenBSD 7.2 (GENERIC.MP) #733: Sun Sep 18 06:39:56 MDT 2022 r420-1# date Mon Sep 19 22:59:37 CEST 2022 r420-1# ls -apl /etc/localtime lrwxr-xr-x 1 root wheel 33 Nov 12 2019 /etc/localtime -> /usr/share/zoneinfo/Europe/Zagreb after sysupgrade

Re: sysupgrade - Reading from socket: Undefined error: 0

2022-09-19 Thread Hrvoje Popovski
On 19.9.2022. 22:27, Hrvoje Popovski wrote: > Hi all, > > when doing sysupgrade few minutes ago on multiple machines i'm getting > error in subject > > smc24# sysupgrade -s > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd6

sysupgrade - Reading from socket: Undefined error: 0

2022-09-19 Thread Hrvoje Popovski
Hi all, when doing sysupgrade few minutes ago on multiple machines i'm getting error in subject smc24# sysupgrade -s Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ SHA256.sig 100% |*| 2144 00:00 Signature Verified

Re: soreceive with shared netlock

2022-09-03 Thread Hrvoje Popovski
On 3.9.2022. 22:47, Alexander Bluhm wrote: > Hi, > > The next small step towards parallel network stack is to use shared > netlock in soreceive(). The UDP and IP divert layer provide locking > of the PCB. If that is possible, use shared instead of exclusive > netlock in soreceive(). The PCB

Re: ifconfig, wireguard output less verbose, unless -A or

2022-08-18 Thread Hrvoje Popovski
On 14.7.2022. 11:37, Mikolaj Kucharski wrote: > Hi, > > Per other thread, Theo expressed dissatisfaction with long ifconfig(8) > for wg(4) interface. Stuart Henderson pointed me at direction, which > below diff makes it work. > > I guess to questions are: > > - Does the behaviour of ifconfig(8)

Re: em(4) multiqueue

2022-08-15 Thread Hrvoje Popovski
On 12.8.2022. 22:15, Hrvoje Popovski wrote: > Hi, > > I'm testing forwarding over > > em0 at pci7 dev 0 function 0 "Intel 82576" rev 0x01, msix, 4 queues, > em1 at pci7 dev 0 function 1 "Intel 82576" rev 0x01, msix, 4 queues, > em2 at pci8 dev 0 functio

Re: em(4) multiqueue

2022-08-12 Thread Hrvoje Popovski
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 really applies to servers and network appliances (including > APU2).

Re: ix(4): Add support for TCP Large Receive Offloading

2022-08-12 Thread Hrvoje Popovski
On 25.6.2022. 22:29, Jan Klemkow wrote: > There is a bug in the firmware of ix(4) NICs, at least with chip 82599 and > x540. I could not test it with x550 chips, but i guess they have the same > bug. Hi, I've tested tso with latest snapshot on x552 with or without vlan and everything seems to

splassert: vlan_ioctl: want 2 have 0

2022-08-09 Thread Hrvoje Popovski
Hi all, I've sysupgrade firewall from OpenBSD 7.2-beta (GENERIC.MP) #651: Tue Jul 26 23:11:26 MDT 2022 to OpenBSD 7.2-beta (GENERIC.MP) #677: Mon Aug 8 18:58:49 MDT 2022 and on console there was lot's of spalassert like below. I'm having ix, aggr and vlan on that firewall splassert:

Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Hrvoje Popovski
On 2.8.2022. 23:40, Stuart Henderson wrote: > On 2022/08/02 22:28, Hrvoje Popovski wrote: >> >> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor >> >> >> r7515$ sysctl | grep tsc >> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) t

Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Hrvoje Popovski
On 2.8.2022. 22:28, Hrvoje Popovski wrote: > Hi, > > this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor > > > r7515$ sysctl | grep tsc > kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000) > acpihpet0(1000) acpitimer0(1000) >

Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Hrvoje Popovski
On 31.7.2022. 5:13, Scott Cheloha wrote: > Hi, > > At the urging of sthen@ and dv@, here is v5. > > Two major changes from v4: > > - Add the function tc_reset_quality() to kern_tc.c and use it > to lower the quality of the TSC timecounter if we fail the > sync test. > >

Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Hrvoje Popovski
On 31.7.2022. 5:13, Scott Cheloha wrote: > Hi, > > At the urging of sthen@ and dv@, here is v5. > > Two major changes from v4: > > - Add the function tc_reset_quality() to kern_tc.c and use it > to lower the quality of the TSC timecounter if we fail the > sync test. > >

Re: [v5] amd64: simplify TSC sync testing

2022-08-02 Thread Hrvoje Popovski
On 31.7.2022. 5:13, Scott Cheloha wrote: > Hi, > > At the urging of sthen@ and dv@, here is v5. > > Two major changes from v4: > > - Add the function tc_reset_quality() to kern_tc.c and use it > to lower the quality of the TSC timecounter if we fail the > sync test. > >

Re: fix NAT round-robin and random

2022-08-01 Thread Hrvoje Popovski
On 20.7.2022. 22:27, Alexandr Nedvedicky wrote: > Hello, > > below is a final version of patch for NAT issue discussed at bugs@ [1]. > Patch below is updated according to feedback I got from Chris, claudio@ > and hrvoje@. > > The summary of changes is as follows: > > - prevent infinite loop

ix(4) TSO and PPPoE problem

2022-07-10 Thread Hrvoje Popovski
Hi all, while testing mvs@ npppd diffs I've noticed that if TSO is enabled on pppoe server, forwarding from/to pppoe client from/to some host outside pppoe server is very slow. Interesting thing is that iperf between pppoe clients behaves ok with or without TSO on pppoe server. Enabling or

Re: amd64 serial console changes, part 2

2022-07-08 Thread Hrvoje Popovski
On 6.7.2022. 22:45, Mark Kettenis wrote: > Now that the kernel supports the extended BOOTARG_CONSDEV struct and > snaps with that change are out there, here is the diff that changes > the amd64 bootloaders to switch to the extended struct and provide the > parameters necessary for using the

Re: em(4) multiqueue

2022-07-01 Thread Hrvoje Popovski
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 really applies to servers and network appliances (including > APU2).

Re: amd64 serial console changes

2022-06-30 Thread Hrvoje Popovski
On 30.6.2022. 17:03, Stuart Henderson wrote: > On 2022/06/30 16:55, Hrvoje Popovski wrote: >> On 30.6.2022. 16:48, Hrvoje Popovski wrote: >>> On 30.6.2022. 15:14, Anton Lindqvist wrote: >>>> On Thu, Jun 30, 2022 at 01:07:46PM +0200, Mark Kettenis wrote: >>>&

Re: amd64 serial console changes

2022-06-30 Thread Hrvoje Popovski
On 30.6.2022. 16:48, Hrvoje Popovski wrote: > On 30.6.2022. 15:14, Anton Lindqvist wrote: >> On Thu, Jun 30, 2022 at 01:07:46PM +0200, Mark Kettenis wrote: >>> Ah right. Please commit! >> Here's the complete diff, ok? > > > Hi, > > with this diff :

Re: amd64 serial console changes

2022-06-30 Thread Hrvoje Popovski
On 30.6.2022. 15:14, Anton Lindqvist wrote: > On Thu, Jun 30, 2022 at 01:07:46PM +0200, Mark Kettenis wrote: >> Ah right. Please commit! > Here's the complete diff, ok? Hi, with this diff : dell r620 - serial console com1 at acpi0 COMA addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com1:

Re: amd64 serial console changes

2022-06-30 Thread Hrvoje Popovski
On 30.6.2022. 10:26, Mark Kettenis wrote: > Hi Hrvoje, > > I assume it was faster before? What hardware are you seeing this on? Hi, yes, it was faster before. dell r620 - serial console com1 at acpi0 COMA addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com1: console com0 at acpi0 COMB addr

Re: amd64 serial console changes

2022-06-30 Thread Hrvoje Popovski
On 27.6.2022. 23:44, Mark Kettenis wrote: > The Ryzen Embedded V1000 processors have an arm64-style Synposys > DesignWare UART instead if a PC-compatible NS16x50 UART. To make this > UART work as a serial console, we need to pass some more information > from the bootloader to the kernel. This

Re: kernel lock in arp

2022-06-27 Thread Hrvoje Popovski
On 18.5.2022. 17:31, Alexander Bluhm wrote: > Hi, > > For parallel IP forwarding I had put kernel lock around arpresolve() > as a quick workaround for crashes. Moving the kernel lock inside > the function makes the hot path lock free. I see slight prerformace > increase in my test and no lock

Re: rewrite amd64 cache printing

2022-06-24 Thread Hrvoje Popovski
On 24.6.2022. 11:19, Jonathan Gray wrote: > Rewrite amd64 printing of cache details. > Previously we looked at cpuid 0x8005 for L1/TLB details > which Intel documents as reserved. > And cpuid 0x8006 for L2 details. > > Intel also encode cache details in cpuid 4. > AMD have mostly the same

Re: pipex(4): protect global lists with mutex(9)

2022-06-20 Thread Hrvoje Popovski
On 20.6.2022. 16:46, Vitaliy Makkoveev wrote: > And use this mutex(9) to make the `session' dereference safe. > > Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4) > pppoe sessions: > Hi, I can trigger this splassert with plain snapshot and with only pppoe

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-10 Thread Hrvoje Popovski
On 10.6.2022. 0:24, Hrvoje Popovski wrote: > Hi, > > I tried with trunk lacp and tagged vlan700 over trunk0 and it's working > as expected. Everything is the same as before, only aggr0 is now trunk0. > > with tso > [ 4] 17.00-18.00 sec 1.09 GBytes 9.39 Gbits/sec 22

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-10 Thread Hrvoje Popovski
On 10.6.2022. 10:37, Hrvoje Popovski wrote: > while sending traffic from linux to openbsd ix0 with tso netstat while sending traffic smc24# netstat -sp tcp tcp: 1933441 packets sent 3923 data packets (684390 bytes) 0 data packets (0 by

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-10 Thread Hrvoje Popovski
On 10.6.2022. 10:20, David Gwynne wrote: > > >> 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 Pop

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-09 Thread Hrvoje Popovski
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 Klemkow wrote: >>>>&g

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-09 Thread Hrvoje Popovski
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 Klemkow wrote: >>>> Could you show me, how your setup and your configuration

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-09 Thread Hrvoje Popovski
On 8.6.2022. 22:01, Hrvoje Popovski wrote: > On 8.6.2022. 15:04, Jan Klemkow wrote: >> Could you show me, how your setup and your configuration looks like? > Yes, of course .. > > All my lab boxes are connected to switch (no flow-control). In this > setup ix0 and ix1 are

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-08 Thread Hrvoje Popovski
On 8.6.2022. 15:04, Jan Klemkow wrote: > Could you show me, how your setup and your configuration looks like? Yes, of course .. All my lab boxes are connected to switch (no flow-control). In this setup ix0 and ix1 are in aggr and vlans 700 and 800 are tagged on aggr3. I have tried tcpbench and

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-06 Thread Hrvoje Popovski
On 4.6.2022. 21:23, Hrvoje Popovski wrote: > On 1.6.2022. 11:21, Jan Klemkow wrote: >> I moved the switch to ifconfig(8) in the diff below. >> >> # ifconfig ix0 tso >> # ifconfig ix0 -tso >> >> I named it tso (TCP segment offloading), so I can reuse this sw

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-04 Thread Hrvoje Popovski
On 4.6.2022. 21:23, Hrvoje Popovski wrote: > Hi all, > > I've put this diff in production on clean source from this morning and > got panic. I'm not 100% sure if it's because of TSO because in a last > monts i had all kinds of diffs on production boxes. > Now I will run sp

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-04 Thread Hrvoje Popovski
On 1.6.2022. 11:21, Jan Klemkow wrote: > I moved the switch to ifconfig(8) in the diff below. > > # ifconfig ix0 tso > # ifconfig ix0 -tso > > I named it tso (TCP segment offloading), so I can reuse this switch > also for the sending part. TSO is the combination of LRO and LSO. > > LRO: Large

Re: ix(4): Add support for TCP Large Receive Offloading

2022-05-31 Thread Hrvoje Popovski
On 31.5.2022. 11:36, Theo Buehler wrote: >> smc24# cd /usr/src && make includes > > Do 'cd /usr/src && make obj' first. > Yes, thank you ...

Re: ix(4): Add support for TCP Large Receive Offloading

2022-05-31 Thread Hrvoje Popovski
On 27.5.2022. 18:25, 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 Gbit/s. Measured

pf_state_export panic with NET_TASKQ=6 and stuff ....

2022-05-27 Thread Hrvoje Popovski
Hi all, I'm running firewall in production with NET_TASKQ=6 with claudio@ "use timeout for rttimer" and bluhm@ "kernel lock in arp" diffs. After week or so of running smoothly I've got panic. I'm aware that it's not plain snapshot, but having two firewalls with carp and pfsync gives me room for

Re: kernel lock in arp

2022-05-21 Thread Hrvoje Popovski
On 18.5.2022. 20:52, Hrvoje Popovski wrote: > On 18.5.2022. 17:31, Alexander Bluhm wrote: >> Hi, >> >> For parallel IP forwarding I had put kernel lock around arpresolve() >> as a quick workaround for crashes. Moving the kernel lock inside >> the function mak

Re: kernel lock in arp

2022-05-18 Thread Hrvoje Popovski
On 18.5.2022. 17:31, Alexander Bluhm wrote: > Hi, > > For parallel IP forwarding I had put kernel lock around arpresolve() > as a quick workaround for crashes. Moving the kernel lock inside > the function makes the hot path lock free. I see slight prerformace > increase in my test and no lock

arpresolve: XXXXX route contains no arp information

2022-05-17 Thread Hrvoje Popovski
Hi all, here we have carp pfsync setup mostly for wireless and mobile users. Beside from pure forwarding and firewalling boxes are dhcp server with dhcpsync. >From time to time in logs i can see: May 17 11:44:18 bcbnfw1 /bsd: arpresolve: 10.30.0.0: route contains no arp information I've

Re: more generic cpu freq reporting

2022-04-26 Thread Hrvoje Popovski
On 25.4.2022. 19:38, Hrvoje Popovski wrote: > On 25.4.2022. 17:32, Claudio Jeker wrote: >> You may need to play with hw.setperf and maybe run a single cpu load to >> see boost behaviour. I noticed that my 7th gen Intel CPU behaves different >> to the AMD Ryzen CPUs I own. &

Re: more generic cpu freq reporting

2022-04-25 Thread Hrvoje Popovski
On 25.4.2022. 17:32, Claudio Jeker wrote: > You may need to play with hw.setperf and maybe run a single cpu load to > see boost behaviour. I noticed that my 7th gen Intel CPU behaves different > to the AMD Ryzen CPUs I own. This is like playing with new desktop environment... Thank you :) 2

Re: more generic cpu freq reporting

2022-04-25 Thread Hrvoje Popovski
On 25.4.2022. 16:50, Hrvoje Popovski wrote: > On 25.4.2022. 16:19, Claudio Jeker wrote: >> After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@ >> told me that this is a generic way to find the cpu frequency on modern x86 >> cpus (both intel and amd

Re: more generic cpu freq reporting

2022-04-25 Thread Hrvoje Popovski
On 25.4.2022. 16:19, Claudio Jeker wrote: > After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@ > told me that this is a generic way to find the cpu frequency on modern x86 > cpus (both intel and amd support it). > > So this diff cleans up the CPU frequency sensors and moves

Re: beef up ksmn(4) to show more temps and CPU frequency

2022-04-24 Thread Hrvoje Popovski
On 24.4.2022. 20:24, Hrvoje Popovski wrote: > after diff > smc24# sysctl | grep ksmn > hw.sensors.ksmn0.temp0=47.50 degC (Tctl) > hw.sensors.ksmn0.temp1=45.25 degC (Tccd0) > hw.sensors.ksmn0.temp2=46.00 degC (Tccd2) > hw.sensors.ksmn0.temp3=45.75 degC (Tccd4) > hw.sensors.k

Re: beef up ksmn(4) to show more temps and CPU frequency

2022-04-24 Thread Hrvoje Popovski
On 24.4.2022. 19:06, Claudio Jeker wrote: > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which > excludes Zen APU CPUs) this should show additional temp info. This is > based on info from the Linux k10temp driver. > > Additionally use the MSRs defined in "Open-Source Register

Re: [External] : Re: pfsync(4) snapshot lists must have dedicated link element

2022-04-21 Thread Hrvoje Popovski
On 20.4.2022. 23:22, Alexandr Nedvedicky wrote: > Hello, > > On Wed, Apr 20, 2022 at 03:43:06PM +0200, Alexander Bluhm wrote: >> On Sat, Apr 09, 2022 at 01:51:05AM +0200, Alexandr Nedvedicky wrote: >>> updated diff is below. >> I am not sure what Hrvoje actually did test and what not. My >>

Re: router timer mutex

2022-04-21 Thread Hrvoje Popovski
On 20.4.2022. 20:12, Alexander Bluhm wrote: > Hi, > > mvs@ reminded me of a crash I have seen in December. Route timers > are not MP safe, but I think this can be fixed with a mutex. The > idea is to protect the global lists with a mutex and move the rttimer > into a temporary list. Then the

Re: parallel IP forwarding

2022-04-18 Thread Hrvoje Popovski
On 8.4.2022. 12:56, Alexander Bluhm wrote: > Hi, > > I now the right time to commit the parallel forwarding diff? > > Known limitiations are: > - Hrvoje has seen a crash with both pfsync and ipsec on his production > machine. But he cannot reproduce it in his lab. This is resolved. At least

Re: [External] : Re: pfsync(4) snapshot lists must have dedicated link element

2022-04-17 Thread Hrvoje Popovski
On 9.4.2022. 1:51, Alexandr Nedvedicky wrote: > Hello, > > thank you for taking a look at it. > > >> I think there is a use after free in you diff. After you return >> from pfsync_delete_tdb() you must not access the TDB again. >> >> Comments inline. >> > >>> TAILQ_INIT(>sn_upd_req_list);

Re: dell and supermicro servers won't boot

2022-04-05 Thread Hrvoje Popovski
please delete this mail ... my fault .. On 5.4.2022. 18:51, Hrvoje Popovski wrote: > Hi all, > > I've did sysupgrade -s and then fetch source 10,20 minutes ago. Did that > on two boxes and both boxes won't boot. They stop on "entry point" and > then reboot .. if i

dell and supermicro servers won't boot

2022-04-05 Thread Hrvoje Popovski
Hi all, I've did sysupgrade -s and then fetch source 10,20 minutes ago. Did that on two boxes and both boxes won't boot. They stop on "entry point" and then reboot .. if i boot snapshot kernel boot works as expected dell R620 - real serial >> OpenBSD/amd64 BOOT 3.53 boot> booting hd0a:/bsd:

Re: ipsec acquire mutex refcount

2022-03-14 Thread Hrvoje Popovski
On 9.3.2022. 19:14, Alexander Bluhm wrote: > Hi, > > Hrvoje has hit a crash with IPsec acquire while testing the parallel > ip forwarding diff. Analysis with sashan@ concludes that this part > is not MP safe. Mutex and refcount should fix the memory management. > > Hrvoje: Could you test this

Re: ipsec acquire mutex refcount

2022-03-11 Thread Hrvoje Popovski
On 9.3.2022. 21:02, Hrvoje Popovski wrote: > On 9.3.2022. 19:14, Alexander Bluhm wrote: >> Hi, >> >> Hrvoje has hit a crash with IPsec acquire while testing the parallel >> ip forwarding diff. Analysis with sashan@ concludes that this part >> is not MP saf

Re: ipsec acquire mutex refcount

2022-03-09 Thread Hrvoje Popovski
On 9.3.2022. 19:14, Alexander Bluhm wrote: > Hi, > > Hrvoje has hit a crash with IPsec acquire while testing the parallel > ip forwarding diff. Analysis with sashan@ concludes that this part > is not MP safe. Mutex and refcount should fix the memory management. > > Hrvoje: Could you test this

Re: Please test: ix(4)+em(4) MSI-X towards multiqueues

2022-03-07 Thread Hrvoje Popovski
On 17.3.2020. 13:16, Martin Pieuchot wrote: > Diff below allows ix(4) and em(4) to establish two MSI-X handlers. > Multiqueue support is intentionally not included in this diff. > Hi all, if someone is willing to make em multiqueue i have em0 at pci6 dev 0 function 0 "Intel 82576" rev 0x01,

Re: [External] : Re: pfsync mutex

2022-02-28 Thread Hrvoje Popovski
On 28.2.2022. 10:49, Alexandr Nedvedicky wrote: > Hello, > > >>> i will still play with sasyncd setup, maybe something comes up >>> >> >> And when I thought everything is fine.. after 2 days of hitting sasyncd >> setup I've got this panic .. will stay in ddb if some other information >> is

Re: pfsync mutex

2022-02-28 Thread Hrvoje Popovski
On 26.2.2022. 21:36, Hrvoje Popovski wrote: > On 25.2.2022. 23:22, Alexander Bluhm wrote: >> On Fri, Feb 25, 2022 at 10:21:50PM +0100, Hrvoje Popovski wrote: >>> On 24.2.2022. 22:42, Alexander Bluhm wrote: >>>> Hi, >>>> >>>> Hrvoje

Re: pfsync mutex

2022-02-26 Thread Hrvoje Popovski
On 25.2.2022. 23:22, Alexander Bluhm wrote: > On Fri, Feb 25, 2022 at 10:21:50PM +0100, Hrvoje Popovski wrote: >> On 24.2.2022. 22:42, Alexander Bluhm wrote: >>> Hi, >>> >>> Hrvoje reported some crashes with pfsync, IPsec and parallel >>> forwarding.

Re: pfsync mutex

2022-02-25 Thread Hrvoje Popovski
On 24.2.2022. 22:42, Alexander Bluhm wrote: > Hi, > > Hrvoje reported some crashes with pfsync, IPsec and parallel > forwarding. Some locks were missing around the tdb flags in pfsync. before trying this diff i wanted to see if i could still trigger panic with sasyncd setup and parallel

Re: [v2] amd64: simplify TSC sync testing

2022-02-23 Thread Hrvoje Popovski
On 23.2.2022. 3:58, Scott Cheloha wrote: > Please test! In particular: > > - I'd love retests on systems that failed the test using the previous > patch. Almost all of these were AMD Ryzen CPUs. It's hard to say > what the issue is there. My vague guess is a firmware bug. > > One would

Re: parallel ip forwarding

2021-12-27 Thread Hrvoje Popovski
On 25.12.2021. 18:52, Alexander Bluhm wrote: > On Sat, Dec 25, 2021 at 09:24:07AM +0100, Hrvoje Popovski wrote: >> On 24.12.2021. 0:55, Alexander Bluhm wrote: >>> I think we can remove the ipsec_in_use workaround now. The IPsec >>> path is protected with the kernel l

Re: parallel ip forwarding

2021-12-25 Thread Hrvoje Popovski
On 24.12.2021. 0:55, Alexander Bluhm wrote: > I think we can remove the ipsec_in_use workaround now. The IPsec > path is protected with the kernel lock. > > There are some issues left: > - npppd l2pt ipsecflowinfo is not MP safe > - the acquire SA feature is not MP safe > - Hrvoje has seen a

Re: ipsec kernel lock

2021-12-23 Thread Hrvoje Popovski
On 22.12.2021. 14:52, Alexander Bluhm wrote: > Hi, > > IPsec is not MP safe yet. To allow forwarding in parallel without > dirty hacks, it is better to protect IPsec input and output with > kernel lock. We do not loose much as crypto needs the kernel lock > anyway. From here we can refine the

Re: boot stuck with latest cvs checkout

2021-12-22 Thread Hrvoje Popovski
On 22.12.2021. 17:20, Hrvoje Popovski wrote: > On 22.12.2021. 17:07, Hrvoje Popovski wrote: >> Hi all, >> >> i've sysupgrade box and reboot it and everything seems fine. then cvs >> checkout it, compile and then box stuck at boot >> >>>> OpenBSD/

Re: boot stuck with latest cvs checkout

2021-12-22 Thread Hrvoje Popovski
On 22.12.2021. 17:07, Hrvoje Popovski wrote: > Hi all, > > i've sysupgrade box and reboot it and everything seems fine. then cvs > checkout it, compile and then box stuck at boot > >>> OpenBSD/amd64 BOOT 3.53 > boot> > booting hd0a:/bsd: 10246939+2425860+258

boot stuck with latest cvs checkout

2021-12-22 Thread Hrvoje Popovski
Hi all, i've sysupgrade box and reboot it and everything seems fine. then cvs checkout it, compile and then box stuck at boot >> OpenBSD/amd64 BOOT 3.53 boot> booting hd0a:/bsd: 10246939+2425860+258068+0+1130496 [97+573872+611580]=0xe8c924 entry point at 0xd0201000

Re: ipsec ipo tdb mutex

2021-12-13 Thread Hrvoje Popovski
On 12.12.2021. 16:37, Hrvoje Popovski wrote: > On 11.12.2021. 20:03, Alexander Bluhm wrote: >> On Sat, Dec 11, 2021 at 12:53:35AM +0100, Alexander Bluhm wrote: >>> To cache lookups, the policy ipo is linked to its SA tdb. There >>> is a list of SAs that belong to a pol

Re: ipsec ipo tdb mutex

2021-12-12 Thread Hrvoje Popovski
On 11.12.2021. 20:03, Alexander Bluhm wrote: > On Sat, Dec 11, 2021 at 12:53:35AM +0100, Alexander Bluhm wrote: >> To cache lookups, the policy ipo is linked to its SA tdb. There >> is a list of SAs that belong to a policy. To make it MP safe we >> need a mutex around these pointers. >> >>

Re: em(4) vlan tagging support for 82576

2021-12-06 Thread Hrvoje Popovski
On 6.12.2021. 4:22, Yury Shefer wrote: > Hi all, > > I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual > says that hardware VLAN tagging should be supported but ifconfig output > shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q > tagging is

Re: parallel ip forwarding

2021-12-04 Thread Hrvoje Popovski
On 4.12.2021. 10:41, Hrvoje Popovski wrote: > On 3.12.2021. 20:35, Alexander Bluhm wrote: >> Hi, >> >> After implementing MP safe refcounting for IPsec TDB, I wonder how >> stable my diff for forwarding on multiple CPU is. >> >> Note that IPsec still has th

Re: parallel ip forwarding

2021-12-04 Thread Hrvoje Popovski
On 4.12.2021. 10:41, Hrvoje Popovski wrote: > Hi, > > with only plain forwarding it seems that everything works just fine, but > with ipsec i'm getting this panic. i will leave ddb console active if > something else will be needed regarding performance ... without diff i'm

Re: parallel ip forwarding

2021-12-04 Thread Hrvoje Popovski
On 3.12.2021. 20:35, Alexander Bluhm wrote: > Hi, > > After implementing MP safe refcounting for IPsec TDB, I wonder how > stable my diff for forwarding on multiple CPU is. > > Note that IPsec still has the workaround to disable multiple queues. > We do not have a mutex that protects the TDB

Re: ipsp_spd_lookup tdb refcount

2021-12-03 Thread Hrvoje Popovski
On 2.12.2021. 0:49, Alexander Bluhm wrote: > Hi, > > This adds TDB ref counting to ipsp_spd_lookup(). > > While there make ip6_output() look a bit more like ip_output(). > > ok? Hi, i'm hitting this diff for one day and sasyncd boxes didn't panic.

Re: ipsec: refactor TDBF_DELETED

2021-11-26 Thread Hrvoje Popovski
On 25.11.2021. 17:13, Tobias Heider wrote: > On Thu, Nov 25, 2021 at 03:50:29PM +0100, Tobias Heider wrote: >> As discussed in the previous thread we can simplify the tdb cleanup >> code by removing the TDBF_DELETED flag and instead checking if the >> tdb was already unlinked. >> >> ok? >> > >

Re: IPsec tdb ref counting

2021-11-25 Thread Hrvoje Popovski
On 25.11.2021. 9:52, Alexander Bluhm wrote: > On Sat, Nov 13, 2021 at 06:04:07PM +0100, Alexander Bluhm wrote: >> When testing, please check for tdb leaks. > The diff below was running on my performance setup for more than > 10 hours. iked SA lifetime was about 10 seconds. ipsecctl -F; > vmstat

Re: IPsec tdb ref counting

2021-11-23 Thread Hrvoje Popovski
On 23.11.2021. 14:18, Alexander Bluhm wrote: > On Tue, Nov 23, 2021 at 06:54:59AM +0100, Hrvoje Popovski wrote: >> after 24 hours hitting sasyncd setup one box panic > > Thanks for testing. > > I have reduced my iked lifetime to about 10 seconds and got the > same pan

Re: IPsec tdb ref counting

2021-11-22 Thread Hrvoje Popovski
On 21.11.2021. 23:36, Alexander Bluhm wrote: > Updated tdb refcounting diff after merging with mvs@'s commit. Hi, after 24 hours hitting sasyncd setup one box panic r620-2# panic: pool_do_get: tdb free list modified: page 0x812e; item addr 0 x812e2a88; offset 0x28=0xdead410f

Re: IPsec tdb ref counting

2021-11-17 Thread Hrvoje Popovski
On 16.11.2021. 0:08, Hrvoje Popovski wrote: > On 15.11.2021. 16:44, Hrvoje Popovski wrote: >> On 15.11.2021. 15:04, Vitaliy Makkoveev wrote: >>> On Mon, Nov 15, 2021 at 02:51:16PM +0100, Hrvoje Popovski wrote: >>> >>> And you don'n see "> tdb

Re: IPsec tdb ddb print

2021-11-15 Thread Hrvoje Popovski
On 15.11.2021. 17:23, Alexander Bluhm wrote: > Hi, > > To debug IPsec and tdb refcounting it may be useful to have "show > tdb" and "show all tdbs" in ddb. Here's panic with this and mvs@ version of "IPsec tdb ref counting" diff r620-1# > tdb_free() killing ourself panic: kernel

Re: IPsec tdb ref counting

2021-11-15 Thread Hrvoje Popovski
On 15.11.2021. 16:44, Hrvoje Popovski wrote: > On 15.11.2021. 15:04, Vitaliy Makkoveev wrote: >> On Mon, Nov 15, 2021 at 02:51:16PM +0100, Hrvoje Popovski wrote: >> >> And you don'n see "> tdb_free() killing ourself" in dmesg >> output? >

Re: IPsec tdb ref counting

2021-11-15 Thread Hrvoje Popovski
On 15.11.2021. 15:04, Vitaliy Makkoveev wrote: > On Mon, Nov 15, 2021 at 02:51:16PM +0100, Hrvoje Popovski wrote: > > And you don'n see "> tdb_free() killing ourself" in dmesg > output? I couldn't find that message anywhere

Re: IPsec tdb ref counting

2021-11-15 Thread Hrvoje Popovski
On 15.11.2021. 13:11, Vitaliy Makkoveev wrote: > Hi, > > Could you try this diff? It should still panic, but I suspect to see > "> tdb_free() killing ourself" string. panic with your diff r620-1# panic: kernel diagnostic assertion "refcnt != ~0" failed: file "/sys/kern/kern_synch.c",

Re: IPsec tdb ref counting

2021-11-15 Thread Hrvoje Popovski
On 14.11.2021. 22:50, Alexander Bluhm wrote: > New diff with fix from mvs@. Please continue testing with this one. Hi, i've applied this diff on sasyncd setup with two ipsec sessions and i'm getting this panic. Box didn't panic instantly but after some time. I will leave ddb console active...

Re: Dell R620 - latest snapshot

2021-10-25 Thread Hrvoje Popovski
On 25.10.2021. 22:58, Theo de Raadt wrote: > Can you checkout -current, and try this diff: > > It has one additional check for cpu_setperf being NULL, near the top of > setperf_auto() Hi, yes, with this diff box boot normally Tnx ..

Dell R620 - latest snapshot

2021-10-25 Thread Hrvoje Popovski
Hi all, with latest snaphost from few minutes ago Dell R620 box panic while booting vmm0 at mainbus0: VMX/EPT dt: 445 probes attempt to execute user address 0x0 in supervisor mode kernel: page fault trap, code=0 Stopped at 0TIDPIDUID PRFLAGS PFLAGS CPU COMMAND

  1   2   3   4   >