[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #87 from Eugene Grosbein  ---
(In reply to Konstantin Belousov from comment #83)

> On my 16G machine I got the issue in approximately 1 week of uptime.

Should it help increasing kern.ipc.nmbjumbo9 and/or kern.ipc.nmbjumbo16?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Problem reports for n...@freebsd.org that need special attention

2020-07-19 Thread bugzilla-noreply
To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
In Progress |221146 | [ixgbe] Problem with second laggport  
In Progress |235700 | oce(4) driver causes fatal trap 12 on boot with e 
New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi 
New |205592 | TCP processing in IPSec causes kernel panic   
New |213410 | [carp] service netif restart causes hang only whe 
Open|  7556 | ppp: sl_compress_init() will fail if called anyth 
Open|187835 | ngctl(8) strange behavior when adding more than 5 
Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc 
Open|194453 | dummynet(4): pipe config bw parameter limited to  
Open|200319 | Bridge+CARP crashes/freezes   
Open|202510 | [CARP] advertisements sourced from CARP IP cause  
Open|207261 | netmap: Doesn't do TX sync with kqueue
Open|210726 | tcp connect() can return invalid EADDRINUSE (Eg:  
Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo 
Open|225438 | panic in6_unlink_ifa() due to race
Open|227720 | Kernel panic in ppp server
Open|230807 | if_alc(4): Driver not working for Killer Networki 
Open|235524 | igb(4): Ethernet interface loses active link stat 
Open|236888 | ppp daemon: Allow MTU to be overridden for PPPoE  
Open|236983 | bnxt(4) VLAN not operational unless explicit "ifc 
Open|237072 | netgraph(4): performance issue [on HardenedBSD]?  
Open|237840 | Removed dummynet dependency on ipfw   
Open|238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver   
Open|240530 | netgraph/ng_source: Allow ng_source to inject int 
Open|240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile 
Open|240969 | netinet6: Neighbour reachability detection broken 
Open|241106 | tun/ppp: panic: vm_fault: fault on nofault entry  
Open|241162 | Panic in closefp() triggered by nginx (uwsgi with 
Open|243463 | ix0: Watchdog timeout 
Open|244066 | divert: Add sysctls for divert socket send and re 
Open|244706 | panic: NULL dereference inside __mtx_lock_sleep() 
Open|118111 | rc: network.subr Add MAC address based interface  

32 problems total for which you should take action.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #86 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #85)

Yes. But, if you use GENERIC of RELEASE0pX then you don't need to keep source
trees at each server. Just compile the module once for major FreeBSD branch,
use "pkg create" to make a package and install the package to your servers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #85 from László Károlyi  ---
(In reply to Eugene Grosbein from comment #84)
I'd like to have this in the GENERIC kernel, at least as some kind of a
configurable option in loader.conf, so that I won't have to recompile the ports
module on each FreeBSD update ...

Keeping a kernel and ports tree just for that on production servers is
overkill.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #84 from Eugene Grosbein  ---
(In reply to Konstantin Belousov from comment #83)
How about using 4096 by default with a notice in pkg-message for users
requiring larger MTU?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #83 from Konstantin Belousov  ---
(In reply to László Károlyi from comment #82)
These numbers does not matter.  On my 16G machine I got the issue in
approximately 1 week of uptime.

The port (not the stock vendor driver) has the tunable hw.re.max_rx_mbuf_sz
that can be set eg. to 4096 to avoid use of two pages clusters.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #82 from László Károlyi  ---
(In reply to Eugene Grosbein from comment #81)
I have 64GB ram in the server with 54G being wired right now, so I don't think
such a condition will occur at my machine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #81 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #79)

You should monitor this driver's work in the long run. AFAIK this drivers uses
9KB mbufs unconditionally no matter if MTU is 1500 or more, so in the long run
as kernel memory gets fragmented the driver could cause lock up of the system
if it cannot allocate jumbo mbuf cluster.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #80 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #78)

> There were no "module_register" errors in the dmesg

This is a messages from loader. Loader messages do not get to kernel dmesg
buffer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: No connection between jails

2020-07-19 Thread Rodney W. Grimes
> I have two jails in the same subnet on two different hosts:
> 
> 
> HOST1 -- jail1
> 
> |
> 
> |
> 
> HOST2 - jail2
> 
> 
> HOST1: 10.70.7.13/16
> HOST2: 10.70.70.2/16
> jail1: 10.70.5.2/32
> jail2: 10.70.7.50/32
> 
> Default gateway in the network is 10.70.70.1 but I don't think it 
> matters in this issue.
> 
> 
> There is network connection between HOST1 and jail2, or HOST 2 and 
> jail1, or between any other host in the network and either jail1 or 
> jail2, however there is no network connection between jail1 and jail2. 
> By network connection I mean exchange of packets, e.g. "telnet 
> destination port". Both hosts and the default gateway are connected to 
> the same psychical switch.
> 
> There is actually more jails on HOST1 but the situation is analogous - 
> no connection between jails on HOST1 and any jails on HOST2.
> 
> What am I missing?
> 
> 
> Both hosts have gateway_enable="YES" in rc.conf (net.inet.ip.forwarding: 
> 1). I am not using VNET, jails are aliased directly in host's network 
> interfaces (lagg0 for HOST1 and em0 for HOST2).

Let me guess, lagg0 includes a wireless device?

I think you may have the issue that you can not run multiple MAC
addresses on a wireless device, and each of your jails on this
node are going to have a unique MAC.

> Thanks
> GrzegorzJ
> 
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


No connection between jails

2020-07-19 Thread Grzegorz Junka

I have two jails in the same subnet on two different hosts:


HOST1 -- jail1

|

|

HOST2 - jail2


HOST1: 10.70.7.13/16
HOST2: 10.70.70.2/16
jail1: 10.70.5.2/32
jail2: 10.70.7.50/32

Default gateway in the network is 10.70.70.1 but I don't think it 
matters in this issue.



There is network connection between HOST1 and jail2, or HOST 2 and 
jail1, or between any other host in the network and either jail1 or 
jail2, however there is no network connection between jail1 and jail2. 
By network connection I mean exchange of packets, e.g. "telnet 
destination port". Both hosts and the default gateway are connected to 
the same psychical switch.


There is actually more jails on HOST1 but the situation is analogous - 
no connection between jails on HOST1 and any jails on HOST2.


What am I missing?


Both hosts have gateway_enable="YES" in rc.conf (net.inet.ip.forwarding: 
1). I am not using VNET, jails are aliased directly in host's network 
interfaces (lagg0 for HOST1 and em0 for HOST2).


Thanks

GrzegorzJ

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 166724] if_re(4): watchdog timeout

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #79 from László Károlyi  ---
So, I have tested today, and the results are great.

I hit my server hard with transferring a 72GB file to an SMB mount on the local
network, and then I copied that file over from the SMB mount to backblaze B2
with rclone (--transfers 32). The system did 250Mbps at its peak. Here's a
munin chart about it: https://i.imgur.com/yg6R6ii.png

No watchdog timeouts whatsoever, no link drops, and the system stayed snappy
the entire time, while I was observing the copying.

I think we can safely say now that the new Realtek driver is stable and I'd
really like to have it merged into the GENERIC kernel.

My only concern about the driver is these lines in the dmesg:
---
This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.
---

I hope this doesn't mean that the FreeBSD project can't use the driver in its
kernel tree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


mlx5 interrupts

2020-07-19 Thread Slawa Olhovchenkov
Can anybody explain what purpose of unnamed interrupts of Mellanox
ConnectX-5 cards?

I am see 19 interrupts per card. I am mean last 16 is RX queue.
What about first 3?
Also I am see very high rate for irq287/irq306 -- is this good?

# vmstat -i | grep -e ^int -e mlx
interrupt  total   rate
irq286: mlx5_core0 1  0
irq287: mlx5_core0   5135992 20
irq288: mlx5_core0 1  0
irq289: mlx5_core0 76408  0
irq290: mlx5_core0 43054  0
irq291: mlx5_core0 93826  0
irq292: mlx5_core0 39457  0
irq293: mlx5_core0 36141  0
irq294: mlx5_core0 65526  0
irq295: mlx5_core0 53399  0
irq296: mlx5_core0120885  0
irq297: mlx5_core0140690  1
irq298: mlx5_core0193578  1
irq299: mlx5_core0178332  1
irq300: mlx5_core0 75334  0
irq301: mlx5_core0207118  1
irq302: mlx5_core0108803  0
irq303: mlx5_core0 24356  0
irq304: mlx5_core0 26713  0
irq305: mlx5_core1 1  0
irq306: mlx5_core1   5136296 20
irq307: mlx5_core1 1  0
irq308: mlx5_core1   3634544 14
irq309: mlx5_core1 22860  0
irq310: mlx5_core1564441  2
irq311: mlx5_core1 30503  0
irq312: mlx5_core1115549  0
irq313: mlx5_core1 49815  0
irq314: mlx5_core1 10272  0
irq315: mlx5_core1 85875  0
irq316: mlx5_core1134251  1
irq317: mlx5_core1 25151  0
irq318: mlx5_core1 73376  0
irq319: mlx5_core1  5879  0
irq320: mlx5_core1 39515  0
irq321: mlx5_core1  5390  0
irq322: mlx5_core1 22726  0
irq323: mlx5_core1 60408  0
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 221445] The absence of the accept_rtadv option causes an error "ping6: sendmsg: No buffer space available"

2020-07-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221445

--- Comment #8 from b...@schafweide.org ---
Same issue here with a box at ultravps.eu. The gateway is outside of the /64,
set a host route to it and the defaultroute onto the gateway, but it does not
work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"