Link UP/DOWN problem with re0 on FreeBSD 7.1
arab at tangerine-army.co.uk
Thu Feb 5 14:24:55 PST 2009
From: FreeBSD [mailto:freebsd at optiksecurite.com]
Sent: 04 February 2009 21:55
Cc: freebsd-questions at freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1
FreeBSD a écrit :
> Graeme Dargie a écrit :
>> If you do a dmesg are you also showing a watchdog time out for the nic ?
>> I only ask as I am having the exact same problem with the exact same
>> card and I have yet to find a solution, if I come across something I
>> will let you know.
> Not a single time...sorry.
>> -----Original Message-----
>> From: FreeBSD [mailto:freebsd at optiksecurite.com] Sent: 26 January 2009
>> To: freebsd-questions at freebsd.org
>> Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1
>> FreeBSD a écrit :
>>> Hi everyone,
>>> Just to put you in context, I applied the following patch to make the
>>> card available:
>>> SVN rev 186389 on 2008-12-22 00:46:22Z by yongari
>>> Since we don't request reset for rlphy(4), the link state 'UP'
>>> event from mii(4) may not be delivered if valid link was already
>>> established. To address the issue, check current link state after
>>> driving MII_TICK. This should fix a regression introduced in
>>> r185753 on fast ethernet controllers.
>>> I don't have any issue related to that anymore. The problem is that I
>>> get link UP/DOWN a few times per hour on 3 identical machines that I
>>> dumped/restored. They are all pluged in a Cisco switch that works
>>> fine for every other PCs.
>>> Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
>>> Jan 26 06:09:17 term005 kernel: re0: link state changed to UP
>>> I tried to switch cables, but I got the same result.
>>> There is the pciconf -lv output:
>>> re0 at pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec
>>> rev=0x02 hdr=0x00
>>> vendor = 'Realtek Semiconductor'
>>> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>>> class = network
>>> subclass = ethernet
>>> There is the output of vmstat -i:
>>> interrupt total rate
>>> irq18: re0 ehci0++ 63766 0
>>> irq19: atapci0 277001 3
>>> cpu0: timer 156068748 1961
>>> Total 156409515 1966
>>> Could it be related to the fact that there is re0 and ehci0++ on the
>>> same IRQ?
>>> Thank you for your help,
>> I just tried with a brand new Dell 2708 switch and the problem is
>> still there. I just confirmed that the UP/DOWN occurs every 10 minutes
>> (+- a few seconds).
>> Thanks again,
Just to follow-up on my own problem...
I tried to disable some options of the card with :
ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag
but nothing as changed. I just tried to download a big file (FreeBSD
7.1-REL DVD iso in fact) to see if the deconnection occurs even during a
transfer. The DVD downloaded successfully and I verified that the MD5
are OK. BUT, /var/log/messages continue to tell me that:
Feb 4 16:09:29 term003 kernel: re0: link state changed to UP
Feb 4 16:19:26 term003 kernel: re0: link state changed to DOWN
Feb 4 16:19:30 term003 kernel: re0: link state changed to UP
Feb 4 16:19:32 term003 kernel: re0: link state changed to DOWN
during the transfer (which worked OK). I don't know if that can help
someone to help me ;)
freebsd-questions at freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
I have a solution to this well a work around.
Add -tso to the relevant line in /etc/rc.conf
ifconfig_re0="inet 192.168.1.103 netmask 255.255.255.0 -tso"
Adding -tso stops the link up / link down problem. Now I am understand that this may increase cpu if the traffic on the nic is high. I am sure some one the list will know of any other implications this may have.
It is a known problem and I site I read the bug had been submitted so hopefully it wont exist in 8.0
More information about the freebsd-questions