Re: pcie realtek issue (re driver)
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. 0x7c80 ^^ If memory serves me right there would be no known controller for revision 0x7c80. 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=0x02 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 0xfe20-0xfe200fff,0xf000-0xf0003fff irq 18 at device 0.0 on pci4 re0: Chip rev. 0x2800 Hmm, this looks really weird. It now read as 0x2800 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. 0x 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=0x02 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 0xfe20, size 4096, disabled bar [20] = type Prefetchable Memory, range 64, base 0xf000, 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 ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
Re: pcie realtek issue (re driver)
On 5/31/2012 10:57 AM, John Baldwin wrote: 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? Hi, Here are some of the variations attached in a txt file. Could this just be a broken card ? I will try and boot up another OS on the box and see if it works. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ GENERIC kernel, no loader tuneables with if_re loaded from /boot/loader.conf none2@pci0:4:0:0: class=0x02 card=0x10ec 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 0, size 256, disabled bar [18] = type Memory, range 64, base 0xdfa0, size 4096, disabled bar [20] = type Prefetchable Memory, range 64, base 0, size 16384, disabled cap 01[40] = powerspec 7 supports D0 D1 D2 D3 current D3 pci4: ACPI PCI bus on pcib4 pci4: domain=0, physical bus=4 found- vendor=0x10ec, dev=0x8168, revid=0x03 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[10]: type I/O Port, range 32, base 0, size 8, port disabled map[18]: type Memory, range 64, base 0, size 12, memory disabled map[20]: type Prefetchable Memory, range 64, base 0, size 14, memory disabled re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet at device 0.0 on pci4 pcib0: allocated type 3 (0xdfa0-0xdfaf) for rid 20 of pcib4 pcib4: allocated initial memory window of 0xdfa0-0xdfaf pcib4: allocated memory range (0xdfa0-0xdfa00fff) for rid 18 of re0 re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xdfa0 re0: MSI count : 0 re0: MSI-X count : 0 pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 18 re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x7c80 re0: MAC rev. 0x0040 re0: reset never completed! re0: PHY write failed re0: PHY write failed re0: attaching PHYs failed device_attach: re0 attach returned 6 with if_re_load=YES hw.re.msi_disable=1 pci4: ACPI PCI bus on pcib4 pci4: domain=0, physical bus=4 found- vendor=0x10ec, dev=0x8168, revid=0x03 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0, size 8, enabled map[18]: type Memory, range 64, base 0, size 12, enabled map[20]: type Prefetchable Memory, range 64, base 0, size 14, enabled re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet at device 0.0 on pci4 pcib4: allocated memory range (0xfe20-0xfe200fff) for rid 18 of re0 re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xfe20 re0: MSI count : 1 re0: MSI-X count : 4 pcib4: allocated memory range (0xfe204000-0xfe207fff) for rid 20 of re0 re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xfe204000 re0: attempting to allocate 1 MSI-X vectors (4 supported) msi: routing MSI-X IRQ 266 to local APIC 0 vector 62 re0: using IRQ 266 for MSI-X re0: Using 1 MSI-X message re0: Chip rev. 0x2800 re0: MAC rev. 0x miibus0: MII bus on re0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: OUI 0x00e0fc, model 0x003f, rev. 15 re0: PHY write failed re0: PHY write failed ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 100baseT4, 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow re0: PHY write failed re0: PHY write failed re0: bpf attached re0: Ethernet address: 00:0a:cd:1c:ba:89 re0@pci0:4:0:0: class=0x02 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 0, size 256, disabled bar [18] = type Memory, range 64, base 0xfe20, size 4096, disabled bar [20] = type Prefetchable Memory, range 64, base 0xfe204000, size 16384, disabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64
Re: pcie realtek issue (re driver)
On Thursday, May 31, 2012 1:42:07 pm Mike Tancsa wrote: On 5/31/2012 10:57 AM, John Baldwin wrote: 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? Hi, Here are some of the variations attached in a txt file. Could this just be a broken card ? I will try and boot up another OS on the box and see if it works. So it seems it is not honoring our writes to the command register to turn on I/O or memory decoding. Oh weird, in your last case it seems they are enabled. (Driver not loaded at all). Wonder if something in the driver startup is stomping on the PCI command register (e.g. in the firmware). Might be interesting to add printfs in re_attach() and see when the relevant bits in the command register change (e.g. do they get turned off by re_reset()). -- John Baldwin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
Re: pcie realtek issue (re driver)
On Thu, May 31, 2012 at 02:05:53PM -0400, Mike Tancsa wrote:
On 5/31/2012 1:42 PM, Mike Tancsa wrote:
On 5/31/2012 10:57 AM, John Baldwin wrote:
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?
Hi,
Here are some of the variations attached in a txt file. Could this
just be a broken card ? I will try and boot up another OS on the box
and see if it works.
Oh, and doing a load post reboot,
0{intel-i3}# kldload if_re
pci0: driver added
found- vendor=0x8086, dev=0x1c3a, revid=0x04
domain=0, bus=0, slot=22, func=0
class=07-80-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=16
powerspec 3 supports D0 D3 current D0
MSI supports 1 message, 64 bit
pci0:0:22:0: reprobing on driver added
found- vendor=0x8086, dev=0x1c22, revid=0x05
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=18
pci0:0:31:3: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
found- vendor=0x10ec, dev=0x8168, revid=0x03
domain=0, bus=4, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
powerspec 3 supports D0 D1 D2 D3 current D0
MSI supports 1 message, 64 bit
MSI-X supports 4 messages in map 0x20
pci0:4:0:0: reprobing on driver added
re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet at device
0.0 on pci4
pci4: child re0 requested type 3 for rid 0x18, but the BAR says it is an
ioport
pcib4: allocated I/O port range (0xd000-0xd0ff) for rid 10 of re0
re0: Lazy allocation of 0x100 bytes rid 0x10 type 4 at 0xd000
This is the first time I saw BAR2 is I/O space on RealTek PCI
express device. re(4) switched to use BAR0 with I/O space after
failing to use BAR2. Could you try attached patch?
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf000
re0: attempting to allocate 1 MSI-X vectors (4 supported)
msi: routing MSI-X IRQ 270 to local APIC 1 vector 52
re0: using IRQ 270 for MSI-X
re0: Using 1 MSI-X message
re0: Chip rev. 0x2800
re0: MAC rev. 0x
miibus0: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0
rgephy0: OUI 0x00e04c, model 0x0011, rev. 2
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 100baseT4, 1000baseSX,
1000baseSX-FDX, 1000baseSX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
re0: PHY write failed
re0: PHY write failed
re0: bpf attached
re0: Ethernet address: 00:0a:cd:1c:ba:89
pci5: driver added
pci6: driver added
0{intel-i3}#
0{intel-i3}# ifconfig re0 up
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
0{intel-i3}#
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 236345)
+++ sys/dev/re/if_re.c (working copy)
@@ -1191,7 +1191,7 @@
const struct rl_hwrev *hw_rev;
u_int32_t cap, ctl;
int hwrev;
- u_int16_t devid, re_did = 0;
+ u_int16_t cmd, devid, re_did = 0;
int error = 0, i, phy, rid;
int msic, msixc, reg;
uint8_t cfg;
@@ -1220,8 +1220,12 @@
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)
+ if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E) {
sc-rl_res_id = PCIR_BAR(2);
+ cmd = pci_read_config(dev, PCIR_BAR(2), 2);
+ if (PCI_BAR_IO(cmd))
+sc-rl_res_type = SYS_RES_IOPORT;
+ }
} else {
sc-rl_res_id = PCIR_BAR(0);
sc-rl_res_type = SYS_RES_IOPORT;
@@ -3317,6 +3321,10 @@
mii = device_get_softc(sc-rl_miibus);
RL_LOCK(sc);
+ if ((ifp-if_flags IFF_UP) == 0) {
+ RL_UNLOCK(sc);
+ return;
+ }
mii_pollstat(mii);
ifmr-ifm_active = mii-mii_media_active;
ifmr-ifm_status = mii-mii_media_status;
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to
