From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 21:33:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 33D9E106573B; Mon, 19 Jan 2009 21:33:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: pyunyh@gmail.com Date: Mon, 19 Jan 2009 16:33:34 -0500 User-Agent: KMail/1.6.2 References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com> <496CAB07.5020404@holzleiter.name> <20090117044758.GB68290@cdnetworks.co.kr> In-Reply-To: <20090117044758.GB68290@cdnetworks.co.kr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200901191633.37309.jkim@FreeBSD.org> Cc: freebsd-stable@freebsd.org, Sascha Holzleiter Subject: Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 21:33:58 -0000 On Friday 16 January 2009 11:47 pm, Pyun YongHyeon wrote: > On Tue, Jan 13, 2009 at 03:53:59PM +0100, Sascha Holzleiter wrote: > > Jung-uk Kim wrote: > > >On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote: > > >>Hi, > > >> > > >>i see similar problems with a re card: > > >> > > >>re0@pci0:4:7:0: class=0x020000 card=0x816710ec chip=0x816710ec > > >>rev=0x10 hdr=0x00 > > >> vendor = 'Realtek Semiconductor' > > >> device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > > >> class = network > > >> subclass = ethernet > > >> > > >>After upgrading to 7.1-RELEASE (and also STABLE) the NIC > > >> doesn't seem to receive any frames. I can see the DHCP > > >> Requests on the DHCP Server but the DHCPOFFERS are never seen > > >> by the client with the re0 device. After setting promiscious > > >> mode on the interface (i.e. by tcpdump -ni re0) the interface > > >> begins to work fine. > > >> > > >>I've attached a complete dmesg output, but i think the > > >> detection works fine, here the short version: > > >> > > >>re0: port > > >>0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 > > >> on pci4 re0: Chip rev. 0x18000000 > > >>re0: MAC rev. 0x00000000 > > >>miibus0: on re0 > > >>rgephy0: PHY 1 on > > >> miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, > > >> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > >>re0: Ethernet address: 00:1a:92:35:29:fa > > >>re0: [FILTER] > > > > > >Please revert SVN r180519 (or CVS r1.95.2.22) and try again: > > > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.di > > >ff?r1=1.95.2.21;r2=1.95.2.22 > > > > Thanks! This fixed my problem. I now have DHCP and a running > > network interface again with a 7.1-STABLE and the reverted > > r180519 changes. If you need to test another version for the > > changes in r180519 let me know and i'll test them on this > > machine. > > It seems that RTL8169SC does not like memory mapping. Instead of > using io mapping for all revisions, how about attached patch? I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x18000000. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x98000000 (8110SCe) while working chip seems to be 0x18000000 (8110SCd) with 0xfc800000. FYI... Jung-uk Kim