Date: Fri, 9 Nov 2007 16:53:54 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Alexander Shikoff <minotaur@crete.org.ua> Cc: freebsd-net@freebsd.org Subject: Re: re0: RealTek 8168/8111B: no carrier Message-ID: <20071109075354.GC82809@cdnetworks.co.kr> In-Reply-To: <20071109052145.GA35604@crete.org.ua> References: <20071106141913.GA93023@crete.org.ua> <20071106143819.GA22249@crete.org.ua> <20071107002430.GA70832@cdnetworks.co.kr> <20071107073708.GA32211@crete.org.ua> <20071107075134.GD70832@cdnetworks.co.kr> <20071107083204.GA33900@crete.org.ua> <20071107101407.GF70832@cdnetworks.co.kr> <20071107115239.GA1462@crete.org.ua> <20071109010538.GA82809@cdnetworks.co.kr> <20071109052145.GA35604@crete.org.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 09, 2007 at 07:21:45AM +0200, Alexander Shikoff wrote: > On Fri, Nov 09, 2007 at 10:05:38AM +0900, Pyun YongHyeon wrote: > > Because re(4) is not running yet it's normal to see 'no carrier' from > > ifconfig(8) output. > > > > > 4. Force re0 UP with ifconfig re0 up. Then re0 starts and auto-negotiation > > > works: > > > # ifconfig re0 up > > > # ifconfig > > > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > > options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> > > > ether 00:1a:4d:52:4e:b1 > > > media: Ethernet autoselect (100baseTX <full-duplex>) > > > status: active > > > > > > So this problem turns into problem of automatic start of re0 interface. > > > > Probably not. If you want to get established valid link with link > > partner you should make re(4) up to start link negotiation with > > link partner. > > Of course, I can put ifconfig re0 up in rc.conf. But why re(4) does not > start up atomatically while another drivers (for example rl(4)) does? > I think there are some inconsistency here. It's interaction between MAC and PHY. PHY hardware of re(4) requires an explicit kick command as most other PHYs to establish a valid link with link partner. However rlphy(4) does not need the kick command and rl(4) does not honor link state correctly and its internal PHY also lacks some features to report correct link status. If you see the rl(4) code you will notice there is no link state change handler and rl(4) doesn't reprogram MAC to reflect negotiated duplex link. Also rememer that without up/running network driver you wouldn't get correct link status as both parties should agree on speed/duplex settings in order to operate correctly. The link state you can see prior to running a network driver would be transitional one and would be changed after driver running and link negotiation complete. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071109075354.GC82809>