Date: Mon, 15 Nov 2010 18:33:42 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Zeus V Panchenko <zeus@ibs.dn.ua> Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 Message-ID: <20101116023342.GJ1257@michelle.cdnetworks.com> In-Reply-To: <20101113070918.GB15278@relay.ibs.dn.ua> References: <AANLkTinNydUwkyC9zb21P4DPbvBkEDKpNXbp3Nap%2BRvT@mail.gmail.com> <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20101113070918.GB15278@relay.ibs.dn.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--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: <RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet> 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: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> 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: <D-Link DGE-528(T) Gigabit Ethernet Adapter> port 0xd800-0xd8ff mem 0xfbeffc00-0xfbeffcff irq 17 at device 0.0 on pci1
> re1: Chip rev. 0x10000000
> re1: MAC rev. 0x00000000
> miibus1: <MII bus> on re1
> rgephy1: <RTL8169S/8110S/8211B media interface> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101116023342.GJ1257>