From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 02:37:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DA9D106566C for ; Mon, 9 Apr 2012 02:37:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 652CB8FC08 for ; Mon, 9 Apr 2012 02:37:15 +0000 (UTC) Received: by dadz14 with SMTP id z14so16353390dad.17 for ; Sun, 08 Apr 2012 19:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ea1oxJ4phjDW+n/l1G/+N64HBj+ui/0gclG6o3waeSU=; b=dwtHQeR428coP3TUqjtlhNbE/AvnLSfZ3VAlqeDvSeKtR/z2rgidUFWKxs33FRr9Xe 8nDXO8s94cVuPGz2KzGgrINeFhysDc/HV4OWxhaJvQRskdZy1A/uMWskxxpcQzY0o3dz b87DZbZClXYlHrOD/shuqMz4fhQIARy1N+jXYMj4fnfCOalfCgWhmqyRy+DVobVXEVBj dfKow91m71GsvIUu9Sri5oXhwtHu/1UpYiNXE9kjnjFj1G0S4O/3h7TOKCuy0GI0vEku XQRUW9hyvSVhb4ljhxuNyLZXV+YqZpLv8gmHpdRN4vr27MJPco6ITJyRNmVxgMdoSq7/ pfpA== Received: by 10.68.136.1 with SMTP id pw1mr15066854pbb.105.1333939028962; Sun, 08 Apr 2012 19:37:08 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id i2sm13554500pbo.6.2012.04.08.19.37.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Apr 2012 19:37:06 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 09 Apr 2012 11:37:04 -0700 From: YongHyeon PYUN Date: Mon, 9 Apr 2012 11:37:04 -0700 To: enoch Message-ID: <20120409183704.GA1668@michelle.cdnetworks.com> References: <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <87iphejaar.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Mon, 09 Apr 2012 02:37:15 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> >> >> YongHyeon PYUN writes: > >> >> >> > >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> > >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >> >> >>>> > >> >> >> >> >> >>>> Can anyone help? > >> >> >> >> >> >>>> > >> >> >> >> >> >>> > >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >> >> >>> > >> >> >> >> >> >> > >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> >> >> > >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> >> >> first problems rather than solve by reboot. > >> >> >> >> >> > > >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> >> >> > incoming traffic. > >> >> >> >> >> > Does assigning static IP work? > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> >> >> > >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> >> >> options=82008 > >> >> >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> >> >> ) > >> >> >> >> >> status: active > >> >> >> >> >> > >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> > > >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> >> >> > attached to nfe(4)? > >> >> >> >> > > >> >> >> >> > >> >> >> >> miibus1: on nfe0 > >> >> >> >> rgephy1: PHY 1 on miibus1 > >> >> >> >> > >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> >> >> nfe0: [FILTER] > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> > >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> >> >> > > >> >> >> >> > >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> >> >> vendor = 'NVIDIA Corporation' > >> >> >> >> device = 'MCP51 Network Bus Enumerator' > >> >> >> >> class = bridge > >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> >> >> > >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> >> >> up properly. Are you interested in its good working? > >> >> >> > > >> >> >> > Yes I am. Would you try attached patch and let me know whether the > >> >> >> > patch makes any difference on your box? > >> >> >> > >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> >> >> leading ethernet header (len 0 pkt len 0)" messages. > >> >> > > >> >> > Ok, back out previous patch and try attached one. > >> >> > >> >> With these two patch files applied to the 8-stable code, buildkernel > >> >> fails as follows. > >> >> > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > >> >> *** Error code 1 > >> >> > >> > > >> > Oops, sorry I forgot that this part of change was not merged to > >> > stable/8. I've attached a minimal patch which would be cleanly > >> > applied to stable/8. > >> > >> Wasn't the attached diff3 already included in diff2? Seems to me the > >> wrong file was attached this time. Please advise. > > > > diff2 is subset of diff3 but it can be merged to stable/8 and > > stable/7. Probably diff2 may have better chance to fully > > reinitialize PHY but let's see whether diff3 also makes difference > > on your box. > > So back out any changes and apply diff3. > > I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency > is just the same. I guess I should consider migrating to 9-stable. The > problem with 9-stable is that most of the time it does not build :-( > > Thanks for your efforts. Enoch. Here is updated patch for stable/8. Let me know whether it makes any difference. --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.power.diff4" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 233484) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -338,7 +338,11 @@ { struct nfe_softc *sc; struct ifnet *ifp; + struct mii_softc *miisc; + struct mii_data *mii; bus_addr_t dma_addr_max; + uint32_t pwr; + uint16_t id1, id2; int error = 0, i, msic, reg, rid; sc = device_get_softc(dev); @@ -615,6 +619,30 @@ device_printf(dev, "attaching PHYs failed\n"); goto fail; } + mii = device_get_softc(sc->nfe_miibus); + miisc = LIST_FIRST(&mii->mii_phys); + /* + * XXX + * This kind of magic should live in PHY driver. + * Should have better to way to use MII_OUI_REALTEK, MII_OUI_xxREALTEK + * and MII_MODEL_REALTEK_RTL8169S/MII_MODEL_xxREALTEK_RTL8169S. + */ + id1 = nfe_miibus_readreg(dev, miisc->mii_phy, MII_PHYIDR1); + id2 = nfe_miibus_readreg(dev, miisc->mii_phy, MII_PHYIDR2); + if ((MII_OUI(id1, id2) == 0x000020 || MII_OUI(id1, id2) == 0x000732) && + MII_MODEL(id2) == 0x0011) { +#if 1 + device_printf(dev, "Forced PHY reset\n"); +#endif + pwr = NFE_READ(sc, NFE_PWR2_CTL); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr | NFE_PWR2_PHY_RESET); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + nfe_miibus_writereg(dev, miisc->mii_phy, 0x1F, 0); + } ether_ifattach(ifp, sc->eaddr); TASK_INIT(&sc->nfe_int_task, 0, nfe_int_task, sc); Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 233484) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -188,8 +188,9 @@ #define NFE_PWR_VALID (1 << 8) #define NFE_PWR_WAKEUP (1 << 15) -#define NFE_PWR2_WAKEUP_MASK 0x0f11 +#define NFE_PWR2_WAKEUP_MASK 0x0f15 #define NFE_PWR2_REVA3 (1 << 0) +#define NFE_PWR2_PHY_RESET 0x0004 #define NFE_PWR2_GATE_CLOCKS 0x0f00 #define NFE_MEDIA_SET 0x10000 --opJtzjQTFsWo+cga--