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=165622
--- Comment #11 from Vlad Movchan ---
Thanks for the feedback and attention to this bug.
I can't argue why using mutex-protected local cache of fpu_kern_ctx structures
was faster than allocating/deallocating this structures when necessary,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165622
--- Comment #10 from Konstantin Belousov ---
(In reply to Oleksandr Tymoshenko from comment #9)
I do not have a strong opinion there, if you want to commit this, go ahead.
I do find it strange the unused fpu context list, why not simply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206186
Oleksandr Tymoshenko changed:
What|Removed |Added
CC||go...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165622
Oleksandr Tymoshenko changed:
What|Removed |Added
CC||go...@freebsd.org,
