re0 not working at boot on -CURRENT

Wed Sep 11 00:15:23 UTC 2013

On Wed, Sep 11, 2013 at 01:31:49AM +0200, Guido Falsi wrote:
> 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 at 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:

[...]

> 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.

Hmm, I thought the diff may reset internal RX filter but it seems
it has no effect.  If I find a clue I'll let you know.
BTW, I guess the diff have showed IC revision of MAC. Could you
show me the output of driver?
Thanks for testing!