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:
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
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
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
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
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
16 matches
Mail list logo