From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 02:33:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A277C106564A for ; Tue, 16 Nov 2010 02:33:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52A0D8FC13 for ; Tue, 16 Nov 2010 02:33:47 +0000 (UTC) Received: by yxh35 with SMTP id 35so82466yxh.13 for ; Mon, 15 Nov 2010 18:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=//zsT+kGTcZf3ywmzo997W0OtSnowrYWJcWemQSTaJg=; b=HS/e6J7eLK3pUrndh6sZSPSoFaKndrNcg9pM5A/Iy0Oef583n+yJliH4qE25maeHIc tF8wefpe9/gJhgzUM2NGqUh6xugyy1c68JN7YYM14jL1/xA1WZGLeEqzReIno7/Dmquo wirHyqzzNalh4/w6iZio9/nc0NfPuXdZQl5Go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=IbflSijNqS/TxpIJrW55zJRiGgZj6N2zylU1O6S3+3sfpuwC+niAidtauGx2hQFFhJ rdfirKYETMDili0wYdOyvXYoXFKXzRbbLIoicteGY7n04WD00YQGRb1f4CWxDCW59EjN oWRuT43ltcATpeCNodlYnDaIhVNS2nnAWCmVs= Received: by 10.150.196.19 with SMTP id t19mr10752166ybf.299.1289874827465; Mon, 15 Nov 2010 18:33:47 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id k2sm3377472ybj.20.2010.11.15.18.33.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Nov 2010 18:33:45 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Nov 2010 18:33:42 -0800 From: Pyun YongHyeon Date: Mon, 15 Nov 2010 18:33:42 -0800 To: Zeus V Panchenko Message-ID: <20101116023342.GJ1257@michelle.cdnetworks.com> References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20101113070918.GB15278@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k4f25fnPtRuIRUb3" Content-Disposition: inline In-Reply-To: <20101113070918.GB15278@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 02:33:48 -0000 --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 13, 2010 at 09:09:18AM +0200, Zeus V Panchenko wrote: > Pyun YongHyeon (pyunyh@gmail.com) [10.11.13 01:01] wrote: > > > > Please be more specific for the issue. Your description is hard to > > narrow down possible cause. > > > > > i was sure it is the problem of the onboard rt nics ... > > > > > > > pciconf output of all re(4) controllers are useless because the > > vendor uses the same device id. Please show me the output of dmesg > > which will contain necessary information to identify your > > controller revision. > > > > oh, sorry :( > > here is what you say: > > the integrated onboard nic: > re0: port 0xe800-0xe8ff mem 0xfafff000-0xfaffffff,0xfaff8000-0xfaffbfff irq 17 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 48:5b:39:d2:1d:89 > re0: [FILTER] > > > external PCI nic: > re1: port 0xd800-0xd8ff mem 0xfbeffc00-0xfbeffcff irq 17 at device 0.0 on pci1 > re1: Chip rev. 0x10000000 > re1: MAC rev. 0x00000000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re1: Ethernet address: 00:21:91:f4:5f:e4 > re1: [FILTER] > > > all that data i was posting here before (several months ago) and > nothing changed since that time > > due to production state of the boxes i was forced finally to switch to > external nics and to configure it with vlans and even to unplug the > cable of the onboard nic > > since nic with plugged cable but without assigned ip address did begin > flap (may be it's specific of the swith it plugged in, it is TP-Link > TL-SG5426 but no other nic behaves this way) > > i have 7 boxes of this configuration and all 6 are running > now on external nics > > > if i can provide any debug/info/e.t.c. please let me know, i'd be > happy it'd work at last :) > Ok, please try latest re(4) in HEAD. If that does not change the behavior, give attached patch spin and let me know whether it makes any difference. Note, the attached may trigger watchdog timeouts under certain conditions but if you do not remove UTP cable that wouldn't happen. I have to verify whether it can really trigger watchdog timeouts and it takes more time on my side. --k4f25fnPtRuIRUb3 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.link.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 215345) +++ sys/dev/re/if_re.c (working copy) @@ -2151,9 +2151,10 @@ RL_LOCK_ASSERT(sc); mii = device_get_softc(sc->rl_miibus); - mii_tick(mii); - if ((sc->rl_flags & RL_FLAG_LINK) == 0) + if ((sc->rl_flags & RL_FLAG_LINK) == 0) { + mii_tick(mii); re_miibus_statchg(sc->rl_dev); + } /* * Reclaim transmitted frames here. Technically it is not * necessary to do here but it ensures periodic reclamation --k4f25fnPtRuIRUb3--