From owner-freebsd-stable@FreeBSD.ORG Sun Mar 8 02:38:50 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 C9F62106566B; Sun, 8 Mar 2009 02:38:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by mx1.freebsd.org (Postfix) with ESMTP id 385328FC08; Sun, 8 Mar 2009 02:38:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so654481tib.3 for ; Sat, 07 Mar 2009 18:38:49 -0800 (PST) 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=TtG8boqFpoeMS5FuFD+JgiVzdXckz4P8paos5PQTvXc=; b=efIr9lRmVaAVhJdSEMQezIz6WYFuvuiiqQuMX43kWAtc+p7HlXxBgpsnVzMxCai4eA //i6cKsW0xqB/hTP7eDGEAWzU62TzUrmfFXDoXpSVr8AmLMhohSEyBKxBB/HCmK50hjz eHlRNC8qkXvnck8pMX4/CSzqbhvqmlG3WknjA= 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=EJbp1GQKMCo5Snpj2VZyH6y6zsoT6VSEj78t+Fw2P5NUYDcAw8sYTgnw2zi8ZFPKM8 gSuOYgfL2BmeU9QCtyH3VNs2E+bled2DIeYhhnb/QRfQZgkFhsrmD/iUjV0kFrEaXrh/ UZIUmedFdLFelUXN1VskL5qt/VYGMN5WRCIgM= Received: by 10.110.52.1 with SMTP id z1mr6410772tiz.50.1236479928773; Sat, 07 Mar 2009 18:38:48 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b7sm6626516tic.35.2009.03.07.18.38.45 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Mar 2009 18:38:47 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sun, 8 Mar 2009 11:36:42 +0900 From: Pyun YongHyeon Date: Sun, 8 Mar 2009 11:36:42 +0900 To: ian j hart Message-ID: <20090308023642.GB1531@michelle.cdnetworks.co.kr> References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com> <200901191833.51320.jkim@FreeBSD.org> <20090120024519.GB79785@cdnetworks.co.kr> <200903071717.57915.ianjhart@ntlworld.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <200903071717.57915.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: Sun, 08 Mar 2009 02:38:51 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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=AD3RTLAN-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? --2fHTh5uZTiUOsy+g Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.8169sc.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 187352) +++ sys/dev/re/if_re.c (working copy) @@ -158,6 +158,8 @@ /* Tunables. */ static int msi_disable = 1; TUNABLE_INT("hw.re.msi_disable", &msi_disable); +static int prefer_iomap = 0; +TUNABLE_INT("hw.re.prefer_iomap", &prefer_iomap); #define RE_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) @@ -1131,26 +1133,36 @@ pci_enable_busmaster(dev); devid = pci_get_device(dev); - /* Prefer memory space register mapping over IO space. */ - sc->rl_res_id = PCIR_BAR(1); - sc->rl_res_type = SYS_RES_MEMORY; - /* RTL8168/8101E seems to use different BARs. */ - if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E) - sc->rl_res_id = PCIR_BAR(2); + /* + * Prefer memory space register mapping over IO space. + * Because RTL8169SC does not seem to work when memory mapping + * is used always activate io mapping. + */ + if (devid == RT_DEVICEID_8169SC) + prefer_iomap = 1; + if (prefer_iomap == 0) { + sc->rl_res_id = PCIR_BAR(1); + sc->rl_res_type = SYS_RES_MEMORY; + /* RTL8168/8101E seems to use different BARs. */ + if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E) + sc->rl_res_id = PCIR_BAR(2); + } else { + sc->rl_res_id = PCIR_BAR(0); + sc->rl_res_type = SYS_RES_IOPORT; + } sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, &sc->rl_res_id, RF_ACTIVE); - - if (sc->rl_res == NULL) { + if (sc->rl_res == NULL && prefer_iomap == 0) { sc->rl_res_id = PCIR_BAR(0); sc->rl_res_type = SYS_RES_IOPORT; sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, &sc->rl_res_id, RF_ACTIVE); - if (sc->rl_res == NULL) { - device_printf(dev, "couldn't map ports/memory\n"); - error = ENXIO; - goto fail; - } } + if (sc->rl_res == NULL) { + device_printf(dev, "couldn't map ports/memory\n"); + error = ENXIO; + goto fail; + } sc->rl_btag = rman_get_bustag(sc->rl_res); sc->rl_bhandle = rman_get_bushandle(sc->rl_res); --2fHTh5uZTiUOsy+g--