On 09/10/13 04:15, Yonghyeon PYUN wrote:
On Fri, Sep 06, 2013 at 10:42:56PM +0200, Guido Falsi wrote:
On 09/06/13 08:15, Yonghyeon PYUN wrote:
On Wed, Jul 10, 2013 at 07:47:01PM +0200, Guido Falsi wrote:
On 07/10/13 09:04, Yonghyeon PYUN wrote:
On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote:
Hi,
I have a PC with an integrate re ethernet interface, pciconf identifies
it like this:
re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07
hdr=0x00
I'm running FreeBSD current r252261.
As stated in the subject after boot the interface does not work
correctly.
Using tcpdump on another host I noticed that packets (ICMP echo requests
for example) do get sent, and replies generated by the other host, but
the kernel does not seem to see them. Except that every now and then
some packet does get to the system.
I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on
>from a ping which has been running for some time. Just about one every
twenty. Some pattern is showing up.
this is the output of ifconfig re0 after boot:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:19:99:f8:d3:0b
inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255
inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
If I just touch any interface flag with ifconfig, anyone, tso, -txcsum
-rxcsum, it starts working flawlessly. It keeps working also if I
perform the opposite operation with ifconfig afterwards, so it is not
the flag itself fixing it.
This is an ifconfig after performing this exercise(it's the same, since
I disabled txcsum and reactivated it in this instance):
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:19:99:f8:d3:0b
inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255
inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
I don't know much about FreeBSD network drivers so i can't make theories
about this. I hope someone has an idea what the problem could be.
I'm available for any further information needed, test, experiment and
so on.
Could you show me dmesg output(re(4) and rgephy(4) only)?
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> port
0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at
device 0.0 on pci3
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: Chip rev. 0x2c800000
re0: MAC rev. 0x00000000
re0: Ethernet address: 00:19:99:f8:d3:0b
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
Also, I'm loading this as a module, but, for as much as I know, this
should not make any difference.
Did it ever work or you see the issue only on CURRENT?
Never worked on this machine (I own it since the last days of February).
I only installed current on it. If needed I can find time to test a
recent 9.x snapshot on it.
I worked around the problem till now using an USB ethernet adapter,
always wanted to report this problem, but I've been lazy :)
Would you try attached patch and let me know whether it makes any
difference?
Hi!
Thanks for looking into this and sorry for the delay in reporting back.
Unluckily the patch does not solve nor mitigates the problem. Symptoms
are very similar.
[...]
Only real difference is the re_eri_read timeout. It did not output that
error message before.
Oops, sorry. It seems there is logic error in the diff.
Try attached one again.
Hi,
This patch shows the same behavior as the unpatched kernel:
root@marvin:~ [1]# ping 172.24.42.1
PING 172.24.42.1 (172.24.42.1): 56 data bytes
64 bytes from 172.24.42.1: icmp_seq=3 ttl=64 time=0.569 ms
64 bytes from 172.24.42.1: icmp_seq=19 ttl=64 time=0.465 ms
^C
--- 172.24.42.1 ping statistics ---
35 packets transmitted, 2 packets received, 94.3% packet loss
round-trip min/avg/max/stddev = 0.465/0.517/0.569/0.052 ms
root@marvin:~ [0]# ifconfig re0 tso
root@marvin:~ [0]# ping 172.24.42.1
PING 172.24.42.1 (172.24.42.1): 56 data bytes
ping: sendto: No route to host
64 bytes from 172.24.42.1: icmp_seq=1 ttl=64 time=0.949 ms
64 bytes from 172.24.42.1: icmp_seq=2 ttl=64 time=0.726 ms
64 bytes from 172.24.42.1: icmp_seq=3 ttl=64 time=0.793 ms
64 bytes from 172.24.42.1: icmp_seq=4 ttl=64 time=0.624 ms
64 bytes from 172.24.42.1: icmp_seq=5 ttl=64 time=0.736 ms
64 bytes from 172.24.42.1: icmp_seq=6 ttl=64 time=0.923 ms
^C
--- 172.24.42.1 ping statistics ---
7 packets transmitted, 6 packets received, 14.3% packet loss
round-trip min/avg/max/stddev = 0.624/0.792/0.949/0.114 ms
I'd like to note that if I perform a tcpdump from the other machine
(which is also the dns server) I do see the packets getting out as usual
from this machine, and replies being sent. So the problem seems to be to
receive packets, while sending them works fine.
--
Guido Falsi <m...@madpilot.net>
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
