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.
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 receivi
___
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"
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 ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229331
Mark Johnston changed:
What|Removed |Added
Status|New |Closed
Resolution|---
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, whil
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
https://lists.freebsd.or
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 additi
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 m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234550
Martin Birgmeier changed:
What|Removed |Added
CC||d8zne...@aon.at
--- Comment #1
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 somethi
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.
___
freebsd-net@freebsd.or
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 ti
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 w
18 matches
Mail list logo