From owner-freebsd-stable@FreeBSD.ORG Tue Mar 10 20:47:18 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 0E8BA1065674; Tue, 10 Mar 2009 20:47:18 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id E35708FC13; Tue, 10 Mar 2009 20:47:16 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090310204715.FEAW7670.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Tue, 10 Mar 2009 20:47:15 +0000 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090310204715.TBGI22934.aamtaout04-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Tue, 10 Mar 2009 20:47:15 +0000 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n2AKkxVU003328; Tue, 10 Mar 2009 20:46:59 GMT (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Tue, 10 Mar 2009 20:46:59 +0000 User-Agent: KMail/1.9.10 References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com> <20090309060841.GH5039@michelle.cdnetworks.co.kr> <200903092100.20436.ianjhart@ntlworld.com> In-Reply-To: <200903092100.20436.ianjhart@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903102046.59311.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=2zH3nbq_TooA:10 a=S-5L88vOh18A:10 a=6I5d2MoRAAAA:8 a=OhSNbSWiAAAA:8 a=P-sZp84FQIBDBwsvHcEA:9 a=sECqJQ4bTFjKAVXOWToA:7 a=yMomH1E85qdfKF8MxpaSlAsILZwA:4 a=LY0hPdMaydYA:10 a=jX-vGqPtjVFMeOjA:21 a=-ZbKJaXB8KzwT3lm:21 Cc: pyunyh@gmail.com, Sascha Holzleiter , 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 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:47:18 -0000 On Monday 09 March 2009 21:00:20 ian j hart wrote: > On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote: > > 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 > > > > >=A D3RT 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)? > > Clarification: > Updated the two files listed to HEAD > build/install/reboot > Still getting PHY read failed > Patch file > build/install/reboot > Still getting PHY read failed > > If HEAD is the now same as the patched version I can't see how this will be > any different, but I'll try it tomorrow. Patched version was the same, excepting the cardbus removal, so it's no surprise it's still broken. Still on cvs here. /usr/src/sys/dev/re/if_re.c rev 1.155 /usr/src/sys/pci/if_rlreg.h rev 1.95 -- ian j hart