[Bug 235097] ci runs failing with panic in IPv6 code with use-after-free in epair/pfctl when running sys/netpfil/pf/nat tests

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235097 --- Comment #1 from Li-Wen Hsu --- I'm also checking this one, it seems started from r341998 or r341999, although I cannot have a reliable way to reproduce it. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 235097] ci runs failing with panic in IPv6 code with use-after-free in epair/pfctl when running sys/netpfil/pf/nat tests

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235097 Enji Cooper changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are

Shell Thailand USA.

2019-01-20 Thread Shell Petroleum USA via freebsd-net
___ 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

2019-01-20 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

[Bug 229331] panic: refcount == 0 in in6m_release_deferred()

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229331 Mark Johnston changed: What|Removed |Added Status|New |Closed Resolution|---

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Mon, 21 Jan 2019, Bruce Evans wrote: ... For the em0 NIC on my client, even the null change from autoselect to 1000baseT full-duplex often corrupts the NIC state so that even ping doesn't work. I got tired of that and fixed the missing stopping: XX Index: iflib.c XX

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Martin Birgmeier
Hi Bruce, Thank you for your support. The machine A with the em0 issue is running at 1 Gbps and acts as NFS server. The NFS client B has a 100 Mbps interface. B gets a throughput of only 1 Mbyte/s when talking to A but the full 10 Mbyte/s when talking to another third machine C. In addition,

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Sun, 20 Jan 2019, Martin Birgmeier wrote: Regarding duplex, ifconfig shows the following: [0]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 ?? options=81249b ?? ether f0:de:f1:98:86:a9 ?? inet 192.168.1.19 netmask 0xff00 broadcast 192.168.1.255

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Sun, 20 Jan 2019, Martin Birgmeier wrote: I am not using resume at all... just normal startup/shutdown. You might be using media change, which has the same bug as resume had. Bruce ___ freebsd-net@freebsd.org mailing list

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Sun, 20 Jan 2019, Martin Birgmeier wrote: The machine A with the em0 issue is running at 1 Gbps and acts as NFS server. The NFS client B has a 100 Mbps interface. B gets a throughput of only 1 Mbyte/s when talking to A but the full 10 Mbyte/s when talking to another third machine C. In

[Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031 --- Comment #17 from Martin Birgmeier --- Because bug #234550 might be related to this one, I tried to issue "ifconfig -lro em0". This resulted in the interface not working anymore, with the already known syslog messages: Jan 20 09:29:18

[Bug 234550] Performance regression in em(4) driver with bridge/tap and used with bhyve

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234550 Martin Birgmeier changed: What|Removed |Added CC||d8zne...@aon.at --- Comment #1

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Martin Birgmeier
Regarding duplex, ifconfig shows the following: [0]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500     options=81249b     ether f0:de:f1:98:86:a9     inet 192.168.1.19 netmask 0xff00 broadcast 192.168.1.255     inet6 fe80::f2de:f1ff:fe98:86a9%em0 prefixlen 64 scopeid 0x1  

[Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031 --- Comment #16 from Martin Birgmeier --- In the tcpdump log shown in comment #4 it seems that there is always a lot of traffic in one direction followed by a lot of ACKs in the other (if I interpret it correctly). Could it be that

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Martin Birgmeier
I am not using resume at all... just normal startup/shutdown. -- Martin On 20.01.19 07:19, Bruce Evans wrote: > On Sun, 20 Jan 2019, Bruce Evans wrote: > >> [iflib_media_change() is missing iflib_stop(), like iflib_resume() was] >> >> I don't know what the media was after the broken resume.  Its

[Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031 --- Comment #18 from Martin Birgmeier --- Another candidate for being related is bug #234570. -- You are receiving this mail because: You are the assignee for the bug. ___

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Sun, 20 Jan 2019, Bruce Evans wrote: [iflib_media_change() is missing iflib_stop(), like iflib_resume() was] I don't know what the media was after the broken resume. Its reported result can't be trusted anyway. To recover from the broken resume, it usually worked to repeat down/up a few

Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior

2019-01-20 Thread Bruce Evans
On Sat, 19 Jan 2019, Martin Birgmeier wrote: I just tried the patch by Bruce (from the mail sent 10 hours ago), but it makes no difference. Also, it does not seem like bad frames or too high an interrupt rate are the problem (the machine should easily handle what is coming from its NFS client