Not sure what is wrong, if it is driver or chipset, but in freebsd I had to
'-rxcsum6 -txcsum6 -tso -vlanhwtso’ in order to make it function.
> On 16 apr. 2016, at 18:23, Hrvoje Popovski wrote:
>
> On 9.9.2013. 22:07, Mike Belopuhov wrote:
>> On 9 September 2013 21:48, Brad Smith wrote:
>>> He
Not sure how much I can test here, but my tunnels are up.
As well as my bgp sessions (this is "ART box” now) on top.
I use aes-128-gcm.
This is vmware.
//mxb
> On 26 mars 2016, at 16:25, Mike Belopuhov wrote:
>
> On Fri, Mar 25, 2016 at 22:43 +0100, Mark Kettenis wrote:
Even with updated diff, I see no breakage.
//mxb
> On 22 dec. 2015, at 13:48, Martin Pieuchot wrote:
>
> On 04/12/15(Fri) 11:54, Martin Pieuchot wrote:
>> Now that in_arpinput() only uses the routing table, if_get()/if_put()
>> and carp_iamatch being already mpsafe we c
I don’t have MPLS.
No regression.
> On 4 dec. 2015, at 14:51, Martin Pieuchot wrote:
>
> To reduce contention in the fast path we can use a mutex(9) to serialize
> read/write operations on the radix tree instead of the KERNEL_LOCK.
>
> Note that the KERNEL_LOCK is still needed to serialize walk
No regression here.
> On 4 dec. 2015, at 11:54, Martin Pieuchot wrote:
>
> Now that in_arpinput() only uses the routing table, if_get()/if_put()
> and carp_iamatch being already mpsafe we can kill the ARP input queue.
>
> This moves the ARP input path processing from the softnet interrupt
> con
No regression so far.
//mxb
> On 15 dec. 2015, at 14:18, Mike Belopuhov wrote:
>
> Hi,
>
> This has been in my tree for a while and I believe Yasuoka-san has
> tested it in the scenario where it was crashing.
>
> m_pulldown is done here with a zero offset which mean
Hey,
HTTP_METHOD_PATCH is not handled by relayd at all.
Well, actually in fals under default in switch().
PATCH is like PUT, eg. data is expected.
One-liner below fixes this. Tested in production.
--- relay_http.cMon Dec 14 16:16:07 2015
+++ relay_http.c.my Mon Dec 14 21:18:50 2015
@
> On 23 okt. 2015, at 20:27, Mikhail wrote:
>
> I think "государственного" should be capitalized too (флаг is okay)
+1
Is you disk is thick os thin provisioned?
In should be thick and eager zeroed.
There are ways to move from thin to thick. Google for it.
//mxb
> On 29 sep. 2015, at 22:52, Pedro Caetano wrote:
>
> Hi,
>
> While installing openbsd on vmware using today's snapshot 29-s
My tunnels are working as well.
//mxb
> On 25 sep. 2015, at 11:38, Martin Pieuchot wrote:
>
> As discussed in Calgary I don't think we need 6 different files for
> gif(4). None of them are standalone. Since all our other pseudo-
> drivers are self-contained, let'
l VHID (VHID 1
is what left) and balancing arp
and done ‘sh /etc/netstart carp1’ after on both machines.
node2 survived.
//mxb
> On 13 sep. 2015, at 10:34, David Gwynne wrote:
>
> i did this yesterday, but havent had a chance to beat on it properly
> yet.
>
> if anyone would
Applied.
> On 12 sep. 2015, at 19:20, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> very small first step towards MP(i) friendly PF. Patch adds mutex around
> fragment cache.
>
> Patch adds a lock around fragment cache. Unlike other parts of PF the fragment
> cache is self-contained subsystem.
This one in the tree, so it’s live on my side.
> On 14 sep. 2015, at 13:09, David Gwynne wrote:
>
> this is an attempt to make the interrupt path in vmx mpsafe.
>
> seems to hold up under load here, but more testing would be
> appreciated.
>
> Index: if_vmx.c
> ===
Sure
> On 4 jul 2015, at 01:44, Brent Cook wrote:
>
> Would you be comfortable adding some extra output to the various failure
> points in EVP_DecodeUpdate to see where we are bailing out?
OpenSSL 1.0.1o on OpenBSD-current does not have problem with this key as well.
> On 30 jun 2015, at 08:52, mxb wrote:
>
>
> I’m sorry but I can’t provide private key.
> It is basically production and not self-signed. Comes from Thawte.
>
> I’m able to produce output
irs from Thawte. Those are OK both on FC20 and
OpenBSD-current.
Question how do I debug this?
I’m happy to apply any patches for testing.
Br
//mxb
> On 30 jun 2015, at 05:25, Brent Cook wrote:
>
> On Mon, Jun 29, 2015 at 1:22 AM, mxb wrote:
>> Hey,
>>
>> getting follo
odulus -in key’
‘openssl version’: LibreSSL 2.2
This key is OK with openssl on Linux
Br
//mxb
And the rest of us is watching and waiting for diffs to apply :)
It is like exiting movie - I have popcorn in front.
Culmination must be soon, I guess :)
//mxb
On 2015-06-26 19:09, Martin Pieuchot wrote:
On 26/06/15(Fri) 17:19, Alexandr Nedvedicky wrote:
On Fri, Jun 26, 2015 at 04:34:06PM
Yes, "incomplete" is gone as well as "arpresolve: unresolved and
rt_expire == 0".
//mxb
On 2015-06-04 12:19, Martin Pieuchot wrote:
I'd like to put the link-layer address back into the gateway field of
RTF_LOCAL addresses. The problem is that RTF_LOCAL routes are
Any chance to get this committed?
Stepped on it once more without this patch.
//mxb
On 2015-05-22 19:53, Mike Belopuhov wrote:
On Fri, May 22, 2015 at 19:35 +0200, mxb wrote:
Hey,
got a panic as of todays ‘cvs up’
trace below
panic: vmxnet3_rxintr: NULL ring->m[44]
Stopped at Debug
I had an old kernel from 'Apr 28' laying around, as well as from 'May 15' .
Both are OK.
On 2015-06-01 23:04, mxb wrote:
Well, this is a vmware setup, thus I have vmx(4).
I just made a clean 'cvs co -P src' from anoncvs.eu.openbsd.org
and still have the same re
Well, this is a vmware setup, thus I have vmx(4).
I just made a clean 'cvs co -P src' from anoncvs.eu.openbsd.org
and still have the same result.
//mxb
On 2015-06-01 10:55, Martin Pieuchot wrote:
Any idea about how to reproduce it?
1.152 not fixed this, thus reversion far back to 1.150
> On 31 maj 2015, at 22:33, mxb wrote:
>
>
> Reverting if_ether.c from 1.153 to 1.150 fixes my problem.
>
> //mxb
>
>> On 31 maj 2015, at 22:05, mxb wrote:
>>
>>
>> Hello,
>
Reverting if_ether.c from 1.153 to 1.150 fixes my problem.
//mxb
> On 31 maj 2015, at 22:05, mxb wrote:
>
>
> Hello,
> any ideas regarding ?
> I see this in ‘dmesg’.
>
> Also all local (on machine itself) arp entries are incomplete:
>
> Host
(incomplete)vmx3 permanent l
//mxb
Don’t have tun(4), but applied.
As well as latest carp and bridge patches.
So far no problems, except that I see following in dmesg :
arpresolve: unresolved and rt_expire == 0
but this is probably not related to new diffs.
//mxb
> On 28 maj 2015, at 11:28, Martin Pieuchot wrote:
>
>
Hey,
so far no problems.
//mxb
> On 22 maj 2015, at 16:05, Martin Pieuchot wrote:
>
> Let's take carp(4) out of ether_input(). This is quite similar to what
> happened to trunk(4) and vlan(4).
>
> I appreciate tests of any kind, reviews and oks.
>
>
Not sure if I’ll be able to reproduce this at all.
Never seen this before.
But diff is applied.
//mxb
> On 22 maj 2015, at 19:53, Mike Belopuhov wrote:
>
> On Fri, May 22, 2015 at 19:35 +0200, mxb wrote:
>>
>> Hey,
>> got a panic as of todays ‘cvs up’
-12
0x184f48704eda:
ddb{0}> rebooting...
OpenBSD 5.7-current (GENERIC.MP) #0: Fri May 22 16:30:54 CEST 2015
//mxb
Diff is applied. So far no problems.
Unfortunately I can’t test this fully - no vlans on my side.
//mxb
> On 15 maj 2015, at 13:14, Martin Pieuchot wrote:
>
> I have one setup with multiple interfaces in a bridge and on some of
> these interfaces some vlan(4)s. But there'
No regression on my side.
//mxb
> On 15 maj 2015, at 12:54, Martin Pieuchot wrote:
>
> If we change the "rcvif" pointer of a packet we need to run if_input()
> again otherwise we might skip the handlers on the new interface.
>
> Ultimately it would be nice to only
Applied.
I don’t see any regressions so far.
I use bridge+vether.
//mxb
> On 28 apr 2015, at 23:06, Martin Pieuchot wrote:
>
> On 21/04/15(Tue) 12:35, Martin Pieuchot wrote:
>> This diff adds the necessary glue to bridge(4) to be able to convert
>> other pseudo-drivers
> On 16 dec 2014, at 06:40, David Gwynne wrote:
>
> others have hit this on r620s as well
I don’t see it on mine.
interrupt total rate
irq0/clock 9587998940 1599
irq0/ipi136166514 22
irq144/acpi02
Could you please, post updated version to the list?
//mxb
On 27 jun 2014, at 20:09, Leclerc, Sebastien
wrote:
>> Stuart Henderson , 2014-06-27 11:00
>>
>>> +/* Stolen from ftp-proxy */
>>
>> Old version of ftp-proxy I guess. It hasn't used DIOCN
This is
bnx0 at pci3 dev 4 function 0 "Broadcom BCM5706" rev 0x02
On 8 okt 2013, at 22:34, mxb wrote:
>
> I have it spinning now.
>
> bnx0:
> flags=28b43
> mtu 1500
>hwfeatures=36 hardmtu
> 1500
>lladdr 00:14:c2:5d:31:a8
>
problems.
//mxb
On 9 sep 2013, at 21:46, Brad Smith wrote:
> Here is a diff to enable the checksum offload support for bnx(4).
>
> Looking for any testing.
>
>
> Index: if_bnx.c
> ===
> RCS file: /home/cvs/sr
On 19 sep 2013, at 19:23, Brad Smith wrote:
> That is in the kernel not libc.
Yes, I know.
Can't it be re-used instead of maintaining same file in two places?
//mxb
This file is already in base.
/usr/src/sys/lib/libkern/arch/amd64/memset.S
On 18 sep 2013, at 20:28, Edd Barrett wrote:
> On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote:
>> In short, each experiment warms up by setting and checking a load of buffers
>> before setting as many buffe
I'v enabled CSUM for em(4) since Aug 6:th , in GENERIC.
So far, 34 days up and no problems.
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msi
em1 at pci6 dev 0 function 0 "Intel 82574L" rev 0x00: msi
//mxb
On 9 sep 2013, at 21:44, Brad Smith wrote:
>
This diff fixes my problem.
Thank you.
//maxim
On 30 nov 2012, at 20:44, Mike Belopuhov wrote:
> can you please try the diff below.
ng)sc->stats.crcerrs,
On 28 nov 2012, at 10:38, isnk00 wrote:
> I have the same issue with Linksys WUSB54GC v3 (Ralink Technology) device.
As long as 5.2-current boots up with the device attached there is no problem
to detect it. The device does not seem to authenticate properly if it is
Then running dhcpd with pf-support (-A -C ).
dhcpd spawns child process which is not handled by rc-script then stop/restart.
Here is a diff to fix it.
Yes, I know, normally one might want to flush PF-tables as well and this is not
handled by the diff.
But at least I don't have to kill child pro
There is however, no problem then:
plugged -> boot -> wait -> unplug -> wait -> plug in.
On 27 nov 2012, at 13:50, mxb wrote:
>
> Hi tech@,
>
> ix(4) does not detects link then cable is plugged in into already running
> machine.
>
> ix0:
> flags=
Hi tech@,
ix(4) does not detects link then cable is plugged in into already running
machine.
ix0:
flags=28b43
mtu 1500
lladdr bc:30:5b:f3:60:10
description: HW_EXT
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet
Hey tech@,
I'll more than gladly test any diffs for .
Regards,
Maxim
In my case,
it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre on
top of ipsec, running npppd,
and daily NAT/RDR for about 100 clients.
On 6 nov 2012, at 21:31, Stuart Henderson wrote:
> For people who are testing checksum-offload-enabling diffs, it would
> help if you
tested on
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msi, address
00:25:90:27:da:51
em1 at pci6 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi,
address 00:25:90:27:da:50
hwfeatures=36
on both
On 4 nov 2012, at 15:52, Brad Smith wrote:
> On Sat, Nov 03, 2012 at 09:49
Hope there'll be some numbers over how fast the stack became.
Great work!
On 5 nov 2012, at 19:23, Stuart Henderson wrote:
>> On 3 nov 2012, at 22:41, Christian Weisgerber wrote:
>>
>>> Henning's epic rewrite of the checksum handling has fixed
>
> O
Can someone, please, point me to the right cvs URL for those changes.
Thanks.
On 3 nov 2012, at 22:41, Christian Weisgerber wrote:
> Henning's epic rewrite of the checksum handling has fixed
03 PM, Henning Brauer
wrote:
>>>> * mxb [2012-09-10 17:51]:
>>>>> is there any plans to expand 'tagged' keyword in PF into list?
>>>> not that I am aware of, but it would make sense to have list expansion
>>>> there as well.
>>> woul
Hi list@,
is there any plans to expand 'tagged' keyword in PF into list?
Example of usage:
match in ... tag ABC
match in ... tag BCD
pass in on egress tagged { ABC, BCD }
If yes, is anyone already working on that? Any diff for testing?
Yes, I started to look at this, but it will take time for
On 05/16/2012 09:58 PM, chefren wrote:
> Thanks to all, we found someone, the machine will be sent off Friday
> morning at 9:00 and I presume it will be sure within a few weeks that
> we won't see it ever again.
>
> +++chefren
>
Great to hear!
Hopefully those 10G-cards will also get some drive
On 04/23/2012 10:39 AM, Brad Smith wrote:
On 23/04/12 4:32 AM, mxb wrote:
Diff below adds vmxnet3 to pcidevs.
vmxnet and vmxnet2 have the same PCI ID and thus catched by the same
macro - VMWARE NET.
While there, remove \t with space for MACHINE_2
The PCI id entries are sorted so this new
Diff below adds vmxnet3 to pcidevs.
vmxnet and vmxnet2 have the same PCI ID and thus catched by the same
macro - VMWARE NET.
While there, remove \t with space for MACHINE_2
//maxim
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/sr
On Apr 4, 2012, at 7:36 PM, YASUOKA Masahiko wrote:
> Hi,
>
> On Wed, 4 Apr 2012 13:19:06 +0200
> Claudio Jeker wrote:
>> On Wed, Apr 04, 2012 at 02:34:46PM +0900, Yasuoka Masahiko wrote:
>>> On Tue, 31 Jan 2012 13:59:17 +0100
>>> "Sebastian Reitenbach" wrote:
However, I noted with tcpdump,
On 04/04/2012 07:34 AM, YASUOKA Masahiko wrote:
On Tue, 31 Jan 2012 13:59:17 +0100
"Sebastian Reitenbach" wrote:
However, I noted with tcpdump, listening on tun0:
# tcpdump -n -i tun0
tcpdump: listening on tun0, link-type LOOP
13:51:15.354776
tcpdump: WARNING: compensating for unaligned libpca
Hi,
looks like npppd_arp.h is missing in the tree.
Is it in purpose or just a miss?
npppd.c:
#ifdef USE_NPPPD_ARP
#include "npppd_arp.h"
#endif
Regards,
Maxim
57 matches
Mail list logo
