Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Sep 2013 22:42:56 +0200
From:      Guido Falsi <mad@madpilot.net>
To:        pyunyh@gmail.com
Cc:        freebsd-net@freebsd.org
Subject:   Re: re0 not working at boot on -CURRENT
Message-ID:  <522A3E50.8080801@madpilot.net>
In-Reply-To: <20130906061521.GB3070@michelle.cdnetworks.com>
References:  <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Here's a small session:

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=6 ttl=64 time=0.621 ms
^C
--- 172.24.42.1 ping statistics ---
33 packets transmitted, 1 packets received, 97.0% packet loss
round-trip min/avg/max/stddev = 0.621/0.621/0.621/0.000 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
re0: re_eri_read: timed out
64 bytes from 172.24.42.1: icmp_seq=1 ttl=64 time=0.718 ms
64 bytes from 172.24.42.1: icmp_seq=2 ttl=64 time=0.471 ms
64 bytes from 172.24.42.1: icmp_seq=3 ttl=64 time=0.423 ms
64 bytes from 172.24.42.1: icmp_seq=4 ttl=64 time=0.567 ms
64 bytes from 172.24.42.1: icmp_seq=5 ttl=64 time=0.457 ms
64 bytes from 172.24.42.1: icmp_seq=6 ttl=64 time=0.364 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.364/0.500/0.718/0.115 ms
root@marvin:~ [0]#

Only real difference is the re_eri_read timeout. It did not output that 
error message before.

-- 
Guido Falsi <mad@madpilot.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?522A3E50.8080801>