[nfe] DHCP failure on 8-stable
YongHyeon PYUN
pyunyh at gmail.com
Mon Apr 9 02:37:15 UTC 2012
On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote:
> YongHyeon PYUN <pyunyh at gmail.com> writes:
>
> > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote:
> >> YongHyeon PYUN <pyunyh at gmail.com> writes:
> >>
> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote:
> >> >> YongHyeon PYUN <pyunyh at gmail.com> writes:
> >> >>
> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote:
> >> >> >> YongHyeon PYUN <pyunyh at gmail.com> writes:
> >> >> >>
> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote:
> >> >> >> >> YongHyeon PYUN <pyunyh at gmail.com> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >> >> >> >> >> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> >> >> >> >> >> ether 00:1f:bc:00:19:dc
> >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
> >> >> >> >> >> media: Ethernet autoselect (1000baseT
> >> >> >> >> >> <full-duplex,flowcontrol,master,rxpause,txpause>)
> >> >> >> >> >> status: active
> >> >> >> >> >>
> >> >> >> >> >> nfe0: link state changed to UP
> >> >> >> >> >> nfe0: <NVIDIA nForce 430 MCP13 Networking Adapter> port 0xf200-0xf207
> >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0
> >> >> >> >> >> miibus1: <MII bus> on nfe0
> >> >> >> >> >
> >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was
> >> >> >> >> > attached to nfe(4)?
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> miibus1: <MII bus> on nfe0
> >> >> >> >> rgephy1: <RTL8169S/8110S/8211B media interface> 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 at 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.
-------------- next part --------------
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
More information about the freebsd-net
mailing list