https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
--- Comment #8 from Tom Lane ---
Ah, now I see the tunable in msk(4). Installed and rebooted; no obvious change
in dmesg output or performance. Since the MTBF was a month or two already,
it'll be awhile before I can say if this fixed thin
Hi freebsd-net@,
I'm not sure if this mailing list is the right place to ask for code
review. If not, could you please direct me to the right mailing list?
I have three patches for ipfw(8) below:
* https://reviews.freebsd.org/D24011 (ipfw: Support {w:x:y::z}:port
(bracketed) IPv6 addresses
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
--- Comment #7 from Brad Smith ---
Looks like hw.msk.msi_disable=1 in /boot/loader.conf.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
--- Comment #6 from Tom Lane ---
> Have any of you guys tried using the tunable to disable MSI and
> see if it makes any difference?
Oh, thanks for the suggestion. I'm happy to try, but what change are you
suggesting exactly? I see multi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
Brad Smith changed:
What|Removed |Added
CC||b...@comstyle.com
--- Comment #5 from
Hi,
I noticed that my FreeBSD box was dropping vxlan packets with higher VNI's.
Looking at the code it seems that the check at line 2548 is not correct:
if (vxh->vxlh_flags != htonl(VXLAN_HDR_FLAGS_VALID_VNI) ||
vxh->vxlh_vni & ~htonl(VXLAN_VNI_MASK)) <- Incorrect?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
--- Comment #4 from Tom Lane ---
macOS has been rock solid reliable for ~14 years on that same hardware, so that
sounds like a pretty lame excuse to me. (I wonder whether digging into the
Darwin kernel sources would yield anything interest
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
Marek Zarychta changed:
What|Removed |Added
CC||zarych...@plan-b.pwste.edu.
On Wed, 18 Mar 2020 16:51:32 +
"Bjoern A. Zeeb" wrote:
> Can you then do a jexec test4 and run service sshd restart and see if it
> starts working?
I experienced the same problem as discussed in this thread when I set
up IPv6 with my server. Strangely, when I rebooted the host system and
si
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
Tom Lane changed:
What|Removed |Added
CC||t...@sss.pgh.pa.us
--- Comment #2 from
Bjoern A. Zeeb wrote:
>
> > > If it does, can you add a
> > >
> > > exec.start += "sleep 2 ";
> > >
> > > to your config
> >
> > OK, I've added it to the configs of 3 experimental jails.
> >
> > > and see if your problem goes away?
> >
> > It goes away partially (only for sshd in 2 of the
On 19 Mar 2020, at 2:14, Victor Sudakov wrote:
If it does, can you add a
exec.start += "sleep 2 ";
to your config
OK, I've added it to the configs of 3 experimental jails.
and see if your problem goes away?
It goes away partially (only for sshd in 2 of the 3 available jails),
a
On Thu, 19 Mar 2020 14:33:34 +0300
Lev Serebryakov wrote:
> On 19.03.2020 7:14, Neel Chauhan wrote:
>
> > However, if you know, where in the code does libalias use only 4096
> > buckets? I want to know incase I want/have to switch back to IPFW.
> 4096 is my mistake, it is 4001 and must be pri
On 19.03.2020 7:14, Neel Chauhan wrote:
> However, if you know, where in the code does libalias use only 4096
> buckets? I want to know incase I want/have to switch back to IPFW.
4096 is my mistake, it is 4001 and must be prime. It is here:
sys/netinet/libalias/alias_local.h:69-70:
#define LINK
19.03.2020 18:19, Lev Serebryakov wrote:
>> Don't you think that now as ipfw nat builds libalias in kernel context,
>> it could scale with maxusers (sys/systm.h) ?
>>
>> Something like (4001 + (maxusers-32)*8) so it grows with amount of physical
>> memory
>> and is kept small for low-memory syste
On 19.03.2020 9:42, Eugene Grosbein wrote:
>>> I’d expect both ipfw and pf to happily saturate gigabit links with NAT,
>>> even on quite modest hardware.
>>> Are you sure the NAT code is the bottleneck?
>> ipfw nat is very slow, really. There are many reasons, and one of them
>> (easy fixable, b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996
Kubilay Kocak changed:
What|Removed |Added
Priority|--- |Normal
--
You are receiving this
19.03.2020 13:42, Eugene Grosbein wrote:
> It's really 4001 that is (and sould be) prime number.
If we decide to auto-tune this, here is small table of prime numbers to stick
with:
4001
8011
12011
16001
24001
32003
48017
64007
___
freebsd-net@freebsd
Jacques Foucry wrote:
> > >
> > > >
> > > > Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> > > > wrong?
> > >
> > > Suppose to work, and work for me.
> > > >
> > > > Here is a test jail:
> > > >
> > > > test4 {
> > > > path = /d02/jails/test4 ;
> > > >
19 matches
Mail list logo
