Date: Sat, 7 Feb 2009 02:20:58 -0000 From: "Graeme Dargie" <arab@tangerine-army.co.uk> To: "FreeBSD" <freebsd@optiksecurite.com> Cc: freebsd-questions@freebsd.org Subject: RE: Link UP/DOWN problem with re0 on FreeBSD 7.1 Message-ID: <01FB8F39BAD0BD49A6D0DA8F789739295630@Mercury.galaxy.lan.lcl> In-Reply-To: <498C699A.2080708@optiksecurite.com> References: <497DDDB7.4000702@optiksecurite.com><497E07D1.3030604@optiksecurite.com><01FB8F39BAD0BD49A6D0DA8F78973929561F@Mercury.galaxy.lan.lcl><497E24E5.5090701@optiksecurite.com><498A0ECA.2070002@optiksecurite.com><01FB8F39BAD0BD49A6D0DA8F78973929562F@Mercury.galaxy.lan.lcl> <498C699A.2080708@optiksecurite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: FreeBSD [mailto:freebsd@optiksecurite.com]=20 Sent: 06 February 2009 16:47 To: Graeme Dargie Cc: freebsd-questions@freebsd.org Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1 Graeme Dargie a =E9crit : > -----Original Message----- > From: FreeBSD [mailto:freebsd@optiksecurite.com]=20 > Sent: 04 February 2009 21:55 > Cc: freebsd-questions@freebsd.org > Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1 >=20 > FreeBSD a =E9crit : >> Graeme Dargie a =E9crit : >>> 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. >>> >>> Regards >>> Graeme >> Not a single time...sorry. >> >>> -----Original Message----- >>> From: FreeBSD [mailto:freebsd@optiksecurite.com] Sent: 26 January = 2009=20 >>> 18:58 >>> To: freebsd-questions@freebsd.org >>> Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1 >>> >>> FreeBSD a =E9crit : >>>> Hi everyone, >>>> >>>> Just to put you in context, I applied the following patch to make = the=20 >>>> 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=20 >>>> get link UP/DOWN a few times per hour on 3 identical machines that = I=20 >>>> dumped/restored. They are all pluged in a Cisco switch that works=20 >>>> 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@pci0:3:0:0: class=3D0x020000 card=3D0x02831028 = chip=3D0x816810ec=20 >>>> rev=3D0x02 hdr=3D0x00 >>>> vendor =3D 'Realtek Semiconductor' >>>> device =3D 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >>>> class =3D network >>>> subclass =3D 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=20 >>>> same IRQ? >>>> >>>> Thank you for your help, >>>> >>>> Martin >>> I just tried with a brand new Dell 2708 switch and the problem is=20 >>> still there. I just confirmed that the UP/DOWN occurs every 10 = minutes=20 >>> (+- a few seconds). >>> >>> Thanks again, >>> >>> Martin >>> >=20 > Just to follow-up on my own problem... >=20 > I tried to disable some options of the card with : > ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag >=20 > but nothing as changed. I just tried to download a big file (FreeBSD=20 > 7.1-REL DVD iso in fact) to see if the deconnection occurs even during = a=20 > transfer. The DVD downloaded successfully and I verified that the MD5=20 > 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 >=20 > during the transfer (which worked OK). I don't know if that can help=20 > someone to help me ;) >=20 > Thanks, >=20 > Martin >=20 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" >=20 > I have a solution to this well a work around. >=20 > Add -tso to the relevant line in /etc/rc.conf >=20 > ifconfig_re0=3D"inet 192.168.1.103 netmask 255.255.255.0 -tso" >=20 > 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. >=20 > It is a known problem and I site I read the bug had been submitted so = hopefully it wont exist in 8.0=20 >=20 > Regards >=20 > Graeme >=20 As I stated in my last post, I tried to disable a few options, including = TSO. Still, I gived a try to your workaround. I now have this line in=20 rc.conf: ifconfig_re0=3D"DHCP -tso" but I have the same problem (it disconnect every 10 minutes and ask for=20 an IP to the DHCP). Thanks for your suggestion, Martin _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" I don't use DHCP so it never causes me a problem, have you considered = setting a static IP address ? Regards Graeme
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01FB8F39BAD0BD49A6D0DA8F789739295630>