From owner-freebsd-hardware@FreeBSD.ORG Thu May 31 15:25:07 2012 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 640E91065675 for ; Thu, 31 May 2012 15:25:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 07C918FC0C for ; Thu, 31 May 2012 15:25:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 604C1B95B; Thu, 31 May 2012 11:25:06 -0400 (EDT) From: John Baldwin To: pyunyh@gmail.com Date: Thu, 31 May 2012 10:57:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FC03C83.4030109@sentex.net> <201205301126.40105.jhb@freebsd.org> <20120531161418.GF1467@michelle.cdnetworks.com> In-Reply-To: <20120531161418.GF1467@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205311057.05234.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 31 May 2012 11:25:06 -0400 (EDT) Cc: Mike Tancsa , freebsd-hardware@freebsd.org Subject: Re: pcie realtek issue (re driver) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:25:07 -0000 On Thursday, May 31, 2012 12:14:18 pm YongHyeon PYUN wrote: > On Wed, May 30, 2012 at 11:26:39AM -0400, John Baldwin wrote: > > On Wednesday, May 30, 2012 1:31:58 pm YongHyeon PYUN wrote: > > > On Tue, May 29, 2012 at 08:57:22AM -0400, Mike Tancsa wrote: > > > > On 5/29/2012 9:01 PM, YongHyeon PYUN wrote: > > > > > On Fri, May 25, 2012 at 10:14:27PM -0400, Mike Tancsa wrote: > > > > >> My recent batch of realtek nics seems to have a version that does not > > > > >> work with RELENG_8 or RELENG_9. Anyone know what the issue might be ? > > > > >> > > > > >> > > > > >> re0: at > > device > > > > >> 0.0 on pci4 > > > > >> re0: Using 1 MSI-X message > > > > >> re0: turning off MSI enable bit. > > > > >> re0: ASPM disabled > > > > >> re0: Chip rev. 0x7c800000 > > > > > ^^^^^^^^^^ > > > > > > > > > > If memory serves me right there would be no known controller for > > > > > revision 0x7c800000. Actually I wonder how re(4) can attach to > > > > > this unknown device. > > > > > Did you apply local patch? > > > > > > > > Hi, > > > > No, its a stock kernel. If I add > > > > > > > > hw.re.msix_disable=1 > > > > hw.re.msi_disable=1 > > > > > > > > it sort of comes up > > > > > > > > > > > > re0 pnpinfo vendor=0x10ec device=0x8168 subvendor=0x10ec > > > > subdevice=0x8168 class=0x020000 at slot=0 function=0 > > > > miibus0 > > > > rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 > > > > > > > > re0: port > > > > 0xd000-0xd0ff mem 0xfe200000-0xfe200fff,0xf0000000-0xf0003fff irq 18 at > > > > device 0.0 on pci4 > > > > re0: Chip rev. 0x28000000 > > > > > > Hmm, this looks really weird. It now read as 0x28000000 which > > > indicates this controller is RTL8168D. I remember there is no > > > MSI-X capability reported by pciconf(8) but previously re(4) used > > > MSI-X which I can't explain. Actually the output of pciconf(8) in > > > earlier mail looks wrong to me. > > > > > > > re0: MAC rev. 0x00000000 > > > > miibus0: on re0 > > > > rgephy0: PHY 1 on miibus0 > > > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > > > > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > > > > 1000baseT-FDX-flow-master, auto, auto-flow > > > > re0: Ethernet address: 00:0a:cd:1c:ba:89 > > > > > > > > but doing ifconfig re0 up, does not work as dmesg shows > > > > > > > > re0: reset never completed! > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > > > > > > > Probably controller was put into some kind of power saving state by > > > BIOS/firmware? > > > > > > > > > > > re0@pci0:4:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x03 > > > > hdr=0x00 > > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > > > class = network > > > > subclass = ethernet > > > > bar [10] = type I/O Port, range 32, base 0xd000, size 256, disabled > > > > bar [18] = type Memory, range 64, base 0xfe200000, size 4096, > > disabled > > > > bar [20] = type Prefetchable Memory, range 64, base 0xf0000000, > > > > size 16384, disabled > > > > > > > > > > It does not even list MSI capability. :-( He might have only used -lb and not -lbc. > > > The most interesting one is both BAR0/BAR2 was disabled even though > > > re(4) was successfully attached to the device. Probably this could > > > be main reason why re(4) does not work at all. I'm not sure this > > > issue could be related with pci(4)(CCed to John to get his advice). > > > > The BAR should be enabled if the driver uses RF_ACTIVE with > > bus_alloc_resource(). > > > > Right, but what if it is not(from the pciconf output)? > I'm pretty sure re(4) used RF_ACTIVE with bus_alloc_resource_any(9). Hmm, is this pciconf output when the driver is attached? -- John Baldwin