From owner-freebsd-net@FreeBSD.ORG Tue Sep 10 23:31:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20C075F4 for ; Tue, 10 Sep 2013 23:31:53 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 86781269D for ; Tue, 10 Sep 2013 23:31:52 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3cZMvq4Z6NzFTsN; Wed, 11 Sep 2013 01:31:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXv5DvwOZk3t; Wed, 11 Sep 2013 01:31:49 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Wed, 11 Sep 2013 01:31:49 +0200 (CEST) Message-ID: <522FABE5.4090805@madpilot.net> Date: Wed, 11 Sep 2013 01:31:49 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130903 Thunderbird/17.0.8 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <20130906061521.GB3070@michelle.cdnetworks.com> <522A3E50.8080801@madpilot.net> <20130910021502.GA2962@michelle.cdnetworks.com> In-Reply-To: <20130910021502.GA2962@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:31:53 -0000 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 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> 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 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> 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 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> 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 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> 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: 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: on re0 >>>> rgephy0: 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