https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #42 from Martin Birgmeier ---
I have tried the native em driver several times in the past but have had to
continue using the net/intel-em-kmod from ports because of this.
Now at FreeBSD 12.3.
-- Martin
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
David O'Rourke changed:
What|Removed |Added
CC||dor@xm0.uk
--- Comment #41
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #40 from Marko Cupać ---
Hi,
I just got advice to try and disable LRO on em0 interface with base driver, and
it resulted in acceptable performance in my VirtualBox VMs with bridged
networking.
I noticed different options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Marko Cupać changed:
What|Removed |Added
CC||marko.cu...@mimar.rs
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #38 from Martin Birgmeier ---
Your are right, I forgot to remove this patch when updating to the latest 12.0
patchlevel. But I guess that should not adversely affect the driver.
Anyway, with the patch performance was just good
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #37 from Martin Birgmeier ---
(Adding Bruce's mail here:)
On 31.08.19 13:44, Bruce Evans wrote:
> On Thu, 15 Aug 2019 a bug that doesn't want replies at freebsd.org wrote:
>
>>
On Thu, 15 Aug 2019 a bug that doesn't want repl...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #36 from Martin Birgmeier ---
I just notice that the console and syslog have about 20 messages of
em: frame error: ignored
em: frame error: ignored
em:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #36 from Martin Birgmeier ---
I just notice that the console and syslog have about 20 messages of
em: frame error: ignored
em: frame error: ignored
em: frame error: ignored
em: frame error: ignored
em: frame error: ignored
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #35 from Martin Birgmeier ---
Update: Today I tried to revert to if_em from releng/12.0 updated to latest.
Result: The performance is still abysmal.
I'll switch to net/intel-em-kmod again.
This is with FreeBSD mizar.xyzzy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #34 from commit-h...@freebsd.org ---
A commit references this bug:
Author: marius
Date: Sun Jun 16 15:25:46 UTC 2019
New revision: 349112
URL: https://svnweb.freebsd.org/changeset/base/349112
Log:
MFC: r347221, r347245
o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #33 from Martin Birgmeier ---
Thank you for this interesting commit note.
Seeing that "the UDP performance with these MACs still is abysmal", should I
already backport these changes to 12.0 or will they not help in my case of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #32 from commit-h...@freebsd.org ---
A commit references this bug:
Author: marius
Date: Tue May 7 08:28:35 UTC 2019
New revision: 347221
URL: https://svnweb.freebsd.org/changeset/base/347221
Log:
o Use
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #31 from Martin Birgmeier ---
I guess bug #219428 is related?
Also https://lists.freebsd.org/pipermail/freebsd-stable/2019-April/090927.html
?
-- Martin
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Martin Birgmeier changed:
What|Removed |Added
CC||m...@swishmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #30 from Martin Birgmeier ---
Kris, one more thing: To get the driver from ports loading, you must remove
if_em_load="YES" from /boot/loader.conf and add if_em_updated_load="YES"
I am quite sure this is the reason you do not
04.02.2019 8:55, Andy Farkas пишет:
> On 02/02/2019 04:11, bugzilla-nore...@freebsd.org wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
> ...
>> The exactly same client runs fine under Hyper-V using de0 (de(4)).
>>
>
> de(4) is going away. Does this affect FBSD on Hyper-V into
On 02/02/2019 04:11, bugzilla-nore...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
...
The exactly same client runs fine under Hyper-V using de0 (de(4)).
de(4) is going away. Does this affect FBSD on Hyper-V into the future?
-andyf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #28 from Eugene Grosbein ---
(In reply to Rick Macklem from comment #27)
Hardware-assisted TSO itself may be not useful in case of 1Gbps or less
linerate for multiple reasons: overwhelming horsepower of modern (and even
pretty
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Rick Macklem changed:
What|Removed |Added
CC||rmack...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
--- Comment #26 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #25 from Martin Birgmeier ---
Just for the record, the le0 (le(4)) issue is with the client running head as
of Dec. 8:
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #24 from Martin Birgmeier ---
I have observed that using le0 in a VirtualBox virtual machine also has very
poor NFS performance. Is le0 affected by the same issues?
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #23 from Martin Birgmeier ---
Hi Rodney,
Thank you for your feedback, I very much appreciate it.
Best regards,
Martin
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Rodney W. Grimes changed:
What|Removed |Added
CC||rgri...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #21 from Martin Birgmeier ---
Hi,
Is there anybody out there who might want to take on this issue? It is a
regression from FreeBSD 11, so most likely should be fixable.
-- Martin
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #20 from Martin Birgmeier ---
With the switch to the "if_em_updated" kernel module from net/intel-em-kmod,
the issue described in bug #234520 is gone.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #19 from Martin Birgmeier ---
I have installed net/intel-em-kmod and switched the kernel module from if_em to
if_em_updated which is installed by that package. This results in the interface
running at full speed again.
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
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,
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
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
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
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
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
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
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
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.
___
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
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
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 which only has a 100 Mbps interface).
I believe
On Sun, 20 Jan 2019, Eugene Grosbein wrote:
19.01.2019 17:21, Bruce Evans wrote:
Your problem looks more like lost interrupts. All em NICs should interrupt
at the default interrupt moderation rate of 8 kHz under load. Once there
are are that many interrupts, there is not much else that can
19.01.2019 17:21, Bruce Evans wrote:
> Your problem looks more like lost interrupts. All em NICs should interrupt
> at the default interrupt moderation rate of 8 kHz under load. Once there
> are are that many interrupts, there is not much else that can go wrong (nfs
> would have to be working
On Fri, 18 Jan 2019 a bug that doesn't want repl...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Yes; I just thought it was going to help and wanted to make it permanent right
away. Bad idea.
In the meantime:
[0]# cat /var/db/ntpd.drift
-6.596
[0]#
What can
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #15 from Eugene Grosbein ---
(In reply to Martin Birgmeier from comment #13)
> What can you get from the ntp drift?
Now we see this machine has good enough hardware timer to rule out problems
linked with bad hardware timer.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #14 from Martin Birgmeier ---
Created attachment 201244
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201244=edit
sysctl.conf
This might be more interesting (kern.timecounter.hardware setting).
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #13 from Martin Birgmeier ---
Yes; I just thought it was going to help and wanted to make it permanent right
away. Bad idea.
In the meantime:
[0]# cat /var/db/ntpd.drift
-6.596
[0]#
What can you get from the ntp drift?
Is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #12 from Martin Birgmeier ---
Created attachment 201243
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201243=edit
loader.conf
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #11 from Eugene Grosbein ---
Do you have any non-default settings in your /boot/loader.conf or
/etc/sysctl.conf ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #10 from Eugene Grosbein ---
(In reply to Martin Birgmeier from comment #9)
>I added hw.pci.enable_msi=0 to /boot/loader.conf, which was a bad idea,
>because with this, after loading the kernel, the system does not find ada0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #9 from Martin Birgmeier ---
I added
hw.pci.enable_msi=0
to /boot/loader.conf, which was a bad idea, because with this, after loading
the kernel, the system does not find ada0 anymore. (I recovered using a pxe
netboot.)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #8 from Martin Birgmeier ---
[0]# egrep 'FreeBSD|em0' var/run/dmesg.boot
Copyright (c) 1992-2018 The FreeBSD Project.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.2-RELEASE-p5 #4 r341248M: Thu Nov 29
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #7 from Eugene Grosbein ---
Routing of interrupts not changed between 11.2 and 12.0.
Post output of grep em0
/z/backup/rsync/mizar/ROOT/.zfs/snapshot/backup.2018-12-24.21:03:49/var/run/dmesg.boot
Please restart ntpd with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
--- Comment #6 from Martin Birgmeier ---
Hi Eugene,
Thank you for looking into this.
I have always been using ntp on all (physical, not VMs) machines. But I am not
using a drift file because in my experience, the machines do not run long
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking, regression
55 matches
Mail list logo
