Date: Tue, 15 Jan 2013 10:47:38 +0400 From: Ruslan Makhmatkhanov <cvs-src@yandex.ru> To: pyunyh@gmail.com Cc: Jeremie Le Hen <jlh@freebsd.org>, freebsd-net@freebsd.org Subject: Re: if_vr(4) and DFE520-TX Message-ID: <50F4FB8A.6090100@yandex.ru> In-Reply-To: <20130115064011.GA1434@michelle.cdnetworks.com> References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> <50F177E9.3040003@yandex.ru> <20130114061553.GA3531@michelle.cdnetworks.com> <50F3F172.5060903@yandex.ru> <20130115024430.GA3152@michelle.cdnetworks.com> <50F4F7E6.7070004@yandex.ru> <20130115064011.GA1434@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
YongHyeon PYUN wrote on 15.01.2013 10:40: > On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote: >> YongHyeon PYUN wrote on 15.01.2013 06:44: >>> On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote: >>>> YongHyeon PYUN wrote on 14.01.2013 10:15: >>>>> On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote: >>>>>> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an >>>>>> patch attached, but whenever kldloading the modified if_vr, I got this: >>>> >>>> [...] >>>> >>>>>> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any >>>>>> hints? >>>>> >>>>> I recall D-Link was one of notorious vendor which used to >>>>> completely change its chip set in later revisions without notice. So >>>>> I'm afraid the controller you have may not be a VIA manufactured >>>>> one. >>>>> Could you take a picture of the chip set of controller and let >>>>> others see it? I guess it could be a RealTek 8139 or 8139C+. >>>> >>>> Here they are. Both front and back for the case (see no traces of >>>> RealTek though): >>>> >>>> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg >>>> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg >>> >>> Thanks. Try attached patch and let me know how it works. >>> If that patch does not work, try setting a loader tunable like the >>> following. >>> dev.rl.0.prefer_iomap=0 >> >> Terrific! It's now attaching fine, but network over it doesn't seems >> working (can't ping/access machine via this interface): > > Please use my patch. I think rl(4) is the right driver for your > controller. Jeremie's patch forces re(4) to attach. To be honest, your and Jeremie patches are identical. Your patch is against if_re/if_rlreg.h too :) >> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >> 1500 >> options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> >> ether 90:94:e4:82:d5:e6 >> inet 192.168.0.208 netmask 0xffffff00 broadcast 192.168.0.255 >> inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5 >> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >> media: Ethernet autoselect (100baseTX <full-duplex>) >> status: active >> >> re0@pci0:4:1:0: class=0x020000 card=0x11031186 chip=0x42001186 >> rev=0x10 hdr=0x00 >> vendor = 'D-Link System Inc' >> class = network >> subclass = ethernet >> >> I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no >> difference. I'll try to experiment with this later this day when there >> will be no active users on this machine, then let you know the results. > > It's not a valid option when you use re(4). > >> Thank you! Yes, it was unmindful copy/paste, sorry. -- Regards, Ruslan Tinderboxing kills... the drives.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F4FB8A.6090100>