From owner-freebsd-stable@FreeBSD.ORG Mon Mar 9 06:10:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43E7106564A; Mon, 9 Mar 2009 06:10:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 979128FC1A; Mon, 9 Mar 2009 06:10:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so1155528wah.27 for ; Sun, 08 Mar 2009 23:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=lUUrzt8el7dmHzHjKSCo4iLoNY2N0DKgrMzHGhZp/5o=; b=V3vKzQkXpfQ0RuIB5ecNJf2mxao1Y4vWvr/5mw4v03U36dGsJ2NMN3rAOuKG6MA6kf 9+hLypE/5w5/ZdNz79x03kLm5Db9bD2G8SBhLKdWq+HFkggvHlL4whk5lcaOdIEb6pYk Qdlrt5EgqGyjAXCsDPQegCcAYAeqqQUIXvoPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=d0WzwkcUh62YVQNCJbdC3T25Tg8N3qHYwms74P6mpU62rjMfEdO6Tecc8LNWP+rJH+ 3rWj65Q47x9QduZ8BgHbucxDzBKN9HJ1ZdZB+iXuobIqIEN+J3xszmZpKItULhN2X8es iHAliqdY45T0PdWV9QdsTwSB1xD3V8AB9NKDI= Received: by 10.140.174.20 with SMTP id w20mr1568037rve.0.1236579032007; Sun, 08 Mar 2009 23:10:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm7657035rvf.1.2009.03.08.23.10.29 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Mar 2009 23:10:31 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 9 Mar 2009 15:08:41 +0900 From: Pyun YongHyeon Date: Mon, 9 Mar 2009 15:08:41 +0900 To: ian j hart Message-ID: <20090309060841.GH5039@michelle.cdnetworks.co.kr> References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com> <200903071717.57915.ianjhart@ntlworld.com> <20090308023642.GB1531@michelle.cdnetworks.co.kr> <200903081705.12523.ianjhart@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903081705.12523.ianjhart@ntlworld.com> User-Agent: Mutt/1.4.2.3i Cc: Sascha Holzleiter , freebsd-stable@freebsd.org, Jung-uk Kim 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 Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 06:10:33 -0000 On Sun, Mar 08, 2009 at 05:05:12PM +0000, ian j hart wrote: > On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote: > > On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote: > > > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: > > > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: > > > > > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: > > > > > > 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... > > > > > > > > > > Now armed with the information, I made it work without reverting > > > > > memory mapped I/O. :-) > > > > > > > > > > http://people.freebsd.org/~jkim/re/re.current2.diff > > > > > http://people.freebsd.org/~jkim/re/re.stable2.diff > > > > > > > > I like the patch. Since only RTL8169 family uses mask 0xfc800000 > > > > it would be even better we can limit checking scope for RTL8169SC > > > > by comparing PCI device id. I don't know what other side effect > > > > would happen if the mask 0xfc800000 would be used on 8101/8168 > > > > controllers. > > > > If the patch works on RTL8169SC would you commit the patch? > > > > I'd like to see multiple commits separated by each enhancements > > > > as the patch contains several fixes which are not directly related > > > > with the issue. > > > > > > Where are we on this? > > > > > > I have a headless firewall box which is not happy with 7.1-RELEASE. I've > > > upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read > > > failed' errors, although the network did come up, which was an > > > improvement. > > > > > > Is there a patch I can try? > > > > > > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=AD3RT > > >LAN-G > > > > > > re0: port > > > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: > > > Chip rev. 0x18000000 > > > re0: MAC rev. 0x00000000 > > > re0: Ethernet address: 00:30:18:ae:1a:1b > > > re0: [FILTER] > > > re1: port > > > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0 > > > re1: Chip rev. 0x18000000 > > > re1: MAC rev. 0x00000000 > > > re1: Ethernet address: 00:30:18:ae:1a:1c > > > re1: [FILTER] > > > re2: port > > > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0 > > > re2: Chip rev. 0x18000000 > > > re2: MAC rev. 0x00000000 > > > re2: Ethernet address: 00:30:18:ae:1a:1d > > > re2: [FILTER] > > > > > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 > > > hdr=0x00 re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 > > > chip=0x816710ec rev=0x10 hdr=0x00 re2@pci0:0:12:0: class=0x020000 > > > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 > > > > Have you tried re(4) in HEAD? > > I had one report that re(4) in HEAD still does not fix the issue so > > I posted a possible workaround for that. Unfortunately he didn't > > report back so I don't know whether it was right workaround or not. > > If re(4) in HEAD does not fix the issue, would you try attached > > patch and let me know how it goes? > > Firstly IANAKH, my expertise in this area stops after "make kernel". > > I updated > > /usr/src/sys/dev/re/if_re.c > /usr/src/sys/pci/if_rlreg.h > > to HEAD > And after updating to HEAD did you apply my patch? > I still get "PHY read failed" with and without the patch. > That's odd. Another user who has the same controller reports the fix fixed the issue. I also committed the patch to HEAD so would you give it spin again (without applying any patches)?