On 18.10.2023. 15:35, Mischa wrote:
> Hi All,
>
> Just upgraded a couple of machines to 7.4. smooth as always!!
>
> I am however seeing issues with IPv4, slowness or no throughput at all.
> The machines I have upgraded are using an Intel X540-T network card and
> is connected on 10G.
>
> ix0 at
On 17.10.2023. 1:07, Vitaliy Makkoveev wrote:
>> On 13 Oct 2023, at 18:40, Hrvoje Popovski wrote:
>>
>> On 12.10.2023. 20:10, Vitaliy Makkoveev wrote:
>>> Hi, MP safe process timeouts were landed to the tree, so time to test
>>> them with network stack :)
On 14.10.2023. 11:07, Wouter Prins wrote:
> hello list,
>
> Was wondering if the veb interface is supported as a bridge for pseudowires?
> The manpage doesn't mention anything about the type of
> bridge interface required (bridge/veb)?
>
> /Wouter
Hi,
you could try tpmr(4) ...
This question is
On 12.10.2023. 20:10, Vitaliy Makkoveev wrote:
> Hi, MP safe process timeouts were landed to the tree, so time to test
> them with network stack :) Diff below makes tdb and ids garbage
> collector timeout handlers running without kernel lock. Not for commit,
> just share this for tests if someone i
On 11.9.2023. 6:27, Hrvoje Popovski wrote:
> On 11.9.2023. 2:48, Mike Larkin wrote:
>> On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote:
>>> Hi all,
>>>
>>> I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC
>>>
On 11.9.2023. 2:48, Mike Larkin wrote:
> On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote:
>> Hi all,
>>
>> I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC
>> 9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVM
Hi all,
I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC
9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVMe
disks directly connected to backplane and installation was fast and
without any problems.
But after that machine panics with this message
https://kosjen
Hi all,
in attachment you can find diff to add SK-Hynix NVMe to pcidevs
before diff
Sep 9 08:44:28 alt-vpn1 /bsd: nvme0 at pci13 dev 0 function 0 vendor
"SK hynix", unknown product 0x2839 rev 0x21: msix, NVMe 1.3
Sep 9 08:44:28 alt-vpn1 /bsd: nvme0: Dell DC NVMe PE8010 RI U.2 960GB,
firmware 1
On 7.7.2023. 11:24, Jonathan Matthew wrote:
> 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?
>
>
Hi,
with this diff box won't panic if I have em m
On 23.5.2023. 21:13, Klemens Nanni wrote:
> On Sat, Jan 14, 2023 at 02:28:27PM +, Stuart Henderson wrote:
>> On 2023/01/12 04:49, Mikolaj Kucharski wrote:
>>> Hi,
>>>
>>> Is there anything else which I can do, to help this diff reviwed and
>>> increase the chance of getting in?
>>>
>>> Thread a
On 22.5.2023. 22:17, Alexander Bluhm wrote:
> Hi,
>
> I noticed a missing checksum count in netstat tcp packets sent
> software-checksummed. Turns out that our syn cache does the checksum
> calculation by hand, instead of the established mechanism in ip
> output.
>
> Just set the flag M_TCP_CSUM
On 18.5.2023. 10:46, Jan Klemkow wrote:
> On Thu, May 18, 2023 at 12:01:44AM +0200, Alexander Bluhm wrote:
>> On Tue, May 16, 2023 at 09:11:48PM +0200, Jan Klemkow wrote:
>>> @@ -412,6 +412,10 @@ tcp_stats(char *name)
>>> p(tcps_outhwtso, "\t\t%u output TSO packet%s hardware processed\n");
>>>
On 21.5.2023. 22:41, Alexander Bluhm wrote:
> Hi,
>
> When sending TCP packets with software TSO to the local address of
> a physical interface, the TCP checksum was miscalculated.
>
> This bug was triggered on loopback interface, when sending to the
> local interface address of a physical interf
On 16.5.2023. 21:11, Jan Klemkow wrote:
> Hi,
>
> This diff introduces new counters for LRO packets, we get from the
> network interface. It shows, how many packets the network interface has
> coalesced into LRO packets.
>
> In followup diff, this packet counter will also be used to set the
> ph
On 15.5.2023. 19:39, Alexander Bluhm wrote:
> On Sun, May 14, 2023 at 11:39:01PM +0200, Hrvoje Popovski wrote:
>> I've tested this on openbsd box with 4 iperf3's. 2 for ip4 and 2 for ip6
>> and with 16 tcp streams per iperf. When testing over ix(4) there is big
On 15.5.2023. 9:47, Hrvoje Popovski wrote:
> On 12.1.2023. 5:49, Mikolaj Kucharski wrote:
>> Hi,
>>
>> Is there anything else which I can do, to help this diff reviwed and
>> increase the chance of getting in?
>>
>> Thread at https://marc.info/?t=1634782986
1 netmask 0xff00 broadcast 10.123.123.255
new ifconfig wg0
wg0: flags=80c3 mtu 1420
index 15 priority 0 llprio 3
wgport 12345
wgpubkey 123=
wgpeer 1111111=
wgdesc Hrvoje Popovski 1
wgpsk (presen
On 14.5.2023. 11:24, Alexander Bluhm wrote:
> On Sat, May 13, 2023 at 01:32:07AM +0200, Alexander Bluhm wrote:
>> I have not yet investigated where the dropped counter 83 comes from.
>> If you see that also, please report what you did.
> This is an ENOBUFS error in this chunk.
>
> /* netwo
On 12.5.2023. 16:21, Jan Klemkow wrote:
> On Thu, May 11, 2023 at 09:17:37PM +0200, Hrvoje Popovski wrote:
>> is it possible to change "ifconfig: SIOCSIFFLAGS: device not configured"
>> message that it has an interface name in it, something like:
>> ifconfig pf
Hi everyone,
is it possible to change "ifconfig: SIOCSIFFLAGS: device not configured"
message that it has an interface name in it, something like:
ifconfig pfsync0: SIOCSIFFLAGS: device not configured <- in my case.
I have many vlans and static routes in my setup and while testing some
diffs, it
On 9.5.2023. 9:56, Alexander Bluhm wrote:
> On Sun, May 07, 2023 at 09:00:31PM +0200, Alexander Bluhm wrote:
>> Not sure if I addressed all corner cases already. I think IPsec
>> is missing.
> Updated diff:
> - parts have been commited
> - works with IPsec now
> - some bugs fixed
> - sysctl net.in
On 26.4.2023. 12:15, Alexander Bluhm wrote:
> On Wed, Apr 26, 2023 at 11:17:32AM +0200, Alexander Bluhm wrote:
>> On Tue, Apr 25, 2023 at 11:57:09PM +0300, Vitaliy Makkoveev wrote:
>>> On Tue, Apr 25, 2023 at 11:44:34AM +0200, Alexander Bluhm wrote:
Hi,
Mutex arp_mtx protects the lli
On 25.4.2023. 22:57, Vitaliy Makkoveev wrote:
> On Tue, Apr 25, 2023 at 11:44:34AM +0200, Alexander Bluhm wrote:
>> Hi,
>>
>> Mutex arp_mtx protects the llinfo_arp la_... fields. So kernel
>> lock is only needed for changing the route rt_flags.
>>
>> Of course there is a race between checking and
On 6.4.2023. 22:46, Alexander Bluhm wrote:
> Hi,
>
> When removing these kernel locks from the ARP input path, the machine
> runs stable in my tests. Caller if_netisr() grabs the exclusive
> netlock and that should be sufficent for in_arpinput() and arpcache().
>
> To stress the ARP resolver I r
On 22.8.2022. 15:07, Alexander Bluhm wrote:
> On Sun, Aug 21, 2022 at 07:07:29PM +0200, Alexander Bluhm wrote:
>> On Fri, Aug 19, 2022 at 10:54:42PM +0200, Alexander Bluhm wrote:
>>> This diff allows to run udp_input() in parallel.
>
> Diff rebased to -current.
Hi,
is this diff still active? I
On 2.1.2023. 22:01, Mikolaj Kucharski wrote:
> This seems to work fine for me.
>
> Patch also available at:
>
> https://marc.info/?l=openbsd-tech&m=167185582521873&q=mbox
>
I've had some problems with 20+ wgpeers few days ago and at that time it
would have been good if I had wgdesc in ifconfig
On 15.8.2022. 20:51, Hrvoje Popovski wrote:
> 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 "
On 28.11.2022. 17:07, Alexandr Nedvedicky wrote:
> diff below should avoid panic above (and similar panics in pfsync_q_del().
> It also prints some 'error' system message buffer (a.k.a. dmesg)
>
> We panic because we attempt to remove state from psync queue which is
> already empty
On 27.11.2022. 9:28, Hrvoje Popovski wrote:
> On 27.11.2022. 1:51, Alexandr Nedvedicky wrote:
>> Hello,
>>
>> On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
>>
>>> I just need to say that with all pf, pfsync and with pf_purge diffs
&g
On 27.11.2022. 1:51, Alexandr Nedvedicky wrote:
> Hello,
>
> On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
>
>> I just need to say that with all pf, pfsync and with pf_purge diffs
>> after hackaton + this diff on tech@
>> https://www.mail-archive
Hi all,
sashan@ and dlg@ I'm sorry if your eyes bleeds from pfsync panics. I
just wanted to send panic log here after pf_purge backout.
I'm testing pfsync with NET_TASKQ=6 because I have 6 core boxes and that
way panics are faster to trigger.
In this test I sure that pf is hitting state limit quit
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 b/sys/net/
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 thi
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
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 pc
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 W
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.
>
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 trig
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 places.
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 all
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 h
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 ...
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
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 I
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
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
INSTALL
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 mut
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)
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 fu
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).
>
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
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: vlan_ioctl
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
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)
>
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.
>
> tc_reset_quality()
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.
>
> tc_reset_quality()
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.
>
> tc_reset_quality()
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
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
disabli
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 non-sta
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).
>
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:
>>>&
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
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: console
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 0x3f8/
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 dif
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 co
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
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
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
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
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
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
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
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 in a
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 ip
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
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.
> No
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 R
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 ...
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 from
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 p
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
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 co
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 route
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.
&
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 core
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 suppo
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 the
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
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 Ref
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
>> impre
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 ca
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 t
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->sn_upd_req_lis
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 reboo
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: 1
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 d
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 safe.
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 d
1 - 100 of 358 matches
Mail list logo
