Re: Reproducible problems with re(4) on RELENG_7 and HEAD

Aryeh Friedman wrote:
>>   Disconnecting: Corrupted MAC on input.
> 
> I have not seen any error messages but your description sound
> identical to something happening on the same hardware to me (p35,
> e6850).... Daniel: does this happen to be a MSI Neo-F Mobo?
> 
>>   Ok, these were the symptones, now the device in the question:
>>
>>   I suppose that it is an integrated card (the machine is in
>>   collocation and I've never seen it by myself). This is the
>>   respective line from dmesg:
>>
>> re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff irq 19 at device 0.0 on pci2
>>
>>   pciconf -lv output:
>>
>> re0_at_pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00
>>     vendor     = 'Realtek Semiconductor'
>>     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>>     class      = network
>>     subclass   = ethernet
> 
> re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfcfff000-0xfcffffff irq 17 at device 0.0 on pci4
> re0: Using 2 MSI messages
> miibus0: <MII bus> on re0
> 
> re0_at_pci0:4:0:0: class=0x020000 card=0x360c1462 chip=0x816810ec rev=0x01 hdr=0x00
>     vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
>

========

Ok - here's what may be a slightly earlier rev on a Gigabyte GA G33-DS3R:

re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port 0xc000-0xc0ff mem 
0xf1000000-0xf1000fff irq 16 at device 0.0 on pci3
re0: Using 2 MSI messages
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:1a:4d:4e:22:e8
re0: [FILTER]
re0: [FILTER]

=======

re0_at_pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00
     vendor     = 'Realtek Semiconductor'
     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
     class      = network
     subclass   = ethernet

=======

OS build:

FreeBSD chameleon.triligon.to 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Sat Oct 20 
22:37:19 UTC 2007     root_at_chameleon.triligon.local:/usr/obj/usr/src/sys/WBH_ULE 
  i386

Core-2 Quad 2.6 GHz, 2 GB DDR-800. Supporting a Win 'server' with IIS 6.0 inside 
a Qemu container.

- We were hunting a Squid conf problem before switching to varnishd, (thanks 
phk_at_!), so ran some largish tcpdump -i to files and perused same.
Problem was not with the NIC.

*So far* - this one hasn't set a foot wrong with:

  - multiple, often long-running (days) ssh sessions

  - squid & varnish accelerators

  - multiple GB per file qcow2 .img backups

.. on either the re Gig-E (above), or the add-on fxp0 10/100.

Interested in the outcome, as this one is in 'production' now.

  - Might the issue be external to the box (cables, routers, network)?

  - Does a long-running 'ping' show packet loss?

  - Have you run tcpdump -i re0 >> {some.file} and looked at what it shows 
around the time of the aberrant behaviour?

Bill