Date: Thu, 31 May 2012 10:57:04 -0400 From: John Baldwin <jhb@freebsd.org> To: pyunyh@gmail.com Cc: Mike Tancsa <mike@sentex.net>, freebsd-hardware@freebsd.org Subject: Re: pcie realtek issue (re driver) Message-ID: <201205311057.05234.jhb@freebsd.org> In-Reply-To: <20120531161418.GF1467@michelle.cdnetworks.com> References: <4FC03C83.4030109@sentex.net> <201205301126.40105.jhb@freebsd.org> <20120531161418.GF1467@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> 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: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> 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: <MII bus> on re0 > > > > rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205311057.05234.jhb>