Discussion:
pcie realtek issue (re driver)
(too old to reply)
Mike Tancsa
2012-05-26 02:15:06 UTC
Permalink
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
re0: MAC rev. 0x00400000
re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6


***@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 [18] = type I/O Port, range 32, base 0xfffffffc, size 4, disabled
bar [20] = type I/O Port, range 32, base 0xfffffffc, size 16384,
disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 15 type 15 IRQ 62 max data 16384(16384)
link x63(x63)
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
YongHyeon PYUN
2012-05-29 09:02:10 UTC
Permalink
Post by Mike Tancsa
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?
Post by Mike Tancsa
re0: MAC rev. 0x00400000
re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6
rev=0x03 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [18] = type I/O Port, range 32, base 0xfffffffc, size 4, disabled
bar [20] = type I/O Port, range 32, base 0xfffffffc, size 16384,
disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 15 type 15 IRQ 62 max data 16384(16384)
link x63(x63)
Mike Tancsa
2012-05-29 12:58:17 UTC
Permalink
Post by YongHyeon PYUN
Post by Mike Tancsa
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
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


***@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
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
YongHyeon PYUN
2012-05-30 01:32:30 UTC
Permalink
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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.
Post by Mike Tancsa
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?
Post by Mike Tancsa
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. :-(
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).
John Baldwin
2012-05-30 16:03:42 UTC
Permalink
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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.
Post by Mike Tancsa
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?
Post by Mike Tancsa
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. :-(
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().
--
John Baldwin
YongHyeon PYUN
2012-05-31 00:15:00 UTC
Permalink
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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.
Post by Mike Tancsa
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?
Post by Mike Tancsa
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
Post by YongHyeon PYUN
Post by Mike Tancsa
bar [20] = type Prefetchable Memory, range 64, base 0xf0000000,
size 16384, disabled
It does not even list MSI capability. :-(
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).
John Baldwin
2012-05-31 15:26:35 UTC
Permalink
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
Post by Mike Tancsa
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.
Post by Mike Tancsa
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?
Post by Mike Tancsa
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
Post by YongHyeon PYUN
Post by Mike Tancsa
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.
Post by YongHyeon PYUN
Post by Mike Tancsa
Post by YongHyeon PYUN
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
Mike Tancsa
2012-05-31 17:44:20 UTC
Permalink
Post by John Baldwin
Post by YongHyeon PYUN
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, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
Mike Tancsa
2012-05-31 18:06:56 UTC
Permalink
Post by Mike Tancsa
Post by John Baldwin
Post by YongHyeon PYUN
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=0x0000, 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
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf0000000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf0000000
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. 0x28000000
re0: MAC rev. 0x00000000
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}#
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
YongHyeon PYUN
2012-06-01 04:10:42 UTC
Permalink
Post by Mike Tancsa
Post by Mike Tancsa
Post by John Baldwin
Post by YongHyeon PYUN
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=0x0000, 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?
Post by Mike Tancsa
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf0000000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf0000000
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. 0x28000000
re0: MAC rev. 0x00000000
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}#
Mike Tancsa
2012-06-01 11:36:58 UTC
Permalink
Post by YongHyeon PYUN
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?
0(ich10)# patch < re.map.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: sys/dev/re/if_re.c
|===================================================================
|--- sys/dev/re/if_re.c (revision 236345)
|+++ sys/dev/re/if_re.c (working copy)
--------------------------
Patching file sys/dev/re/if_re.c using Plan A...
Hunk #1 succeeded at 1191.
Hunk #2 succeeded at 1220.
Hunk #3 succeeded at 3320 (offset -1 lines).
done
0(ich10)#

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=0x0000, 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
pcib4: allocated memory range (0xfe200000-0xfe200fff) for rid 18 of re0
re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xfe200000
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf0000000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf0000000
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. 0x28000000
re0: MAC rev. 0x00000000
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

***@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 0, 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
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in map 0x20
cap 03[cc] = VPD
ecap 0001[100] = AER 1 1 fatal 1 non-fatal 3 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 83050000684ce000


but 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
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
John Baldwin
2012-06-01 15:33:38 UTC
Permalink
Post by Mike Tancsa
Post by YongHyeon PYUN
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?
0(ich10)# patch < re.map.diff
Hmm... Looks like a unified diff to me...
--------------------------
|Index: sys/dev/re/if_re.c
|===================================================================
|--- sys/dev/re/if_re.c (revision 236345)
|+++ sys/dev/re/if_re.c (working copy)
--------------------------
Patching file sys/dev/re/if_re.c using Plan A...
Hunk #1 succeeded at 1191.
Hunk #2 succeeded at 1220.
Hunk #3 succeeded at 3320 (offset -1 lines).
done
0(ich10)#
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=0x0000, 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
pcib4: allocated memory range (0xfe200000-0xfe200fff) for rid 18 of re0
re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xfe200000
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf0000000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf0000000
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. 0x28000000
re0: MAC rev. 0x00000000
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
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 0xfe200000, size 4096, disabled
bar [20] = type Prefetchable Memory, range 64, base 0xf0000000,
size 16384, disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in map 0x20
cap 03[cc] = VPD
ecap 0001[100] = AER 1 1 fatal 1 non-fatal 3 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 83050000684ce000
BTW, it would be interesting to see what the AER errors are. Can you apply
www.freebsd.org/~jhb/patches/pciconf_e.patch to pciconf and paste the output
of 'pciconf -lcbe' for re0?
--
John Baldwin
Mike Tancsa
2012-06-02 14:28:30 UTC
Permalink
Post by John Baldwin
BTW, it would be interesting to see what the AER errors are. Can you apply
www.freebsd.org/~jhb/patches/pciconf_e.patch to pciconf and paste the output
of 'pciconf -lcbe' for re0?
Hi,
Using the pciconf from HEAD,

***@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 0, 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
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap ff[50] = unknown
PCI errors = Master Data Parity Error
Sent Target-Abort
Received Target-Abort
Received Master-Abort
Signalled System Error
Detected Parity Error


---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
YongHyeon PYUN
2012-06-04 08:47:59 UTC
Permalink
Post by Mike Tancsa
Post by John Baldwin
BTW, it would be interesting to see what the AER errors are. Can you apply
www.freebsd.org/~jhb/patches/pciconf_e.patch to pciconf and paste the output
of 'pciconf -lcbe' for re0?
Hi,
Using the pciconf from HEAD,
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 0xfe200000, size 4096, disabled
bar [20] = type Prefetchable Memory, range 64, base 0xf0000000,
size 16384, disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap ff[50] = unknown
PCI errors = Master Data Parity Error
Sent Target-Abort
Received Target-Abort
Received Master-Abort
Signalled System Error
Detected Parity Error
Hmm, Target abort/parity error looks serious to me. Could you
remove re(4) driver in kernel and perform cold boot and check the
AER errors again?
(I assume your controller is not a stand-alone PCIe controller so
I excluded resitting the controller).
Post by Mike Tancsa
---Mike
Mike Tancsa
2012-06-06 18:05:48 UTC
Permalink
Post by YongHyeon PYUN
Hmm, Target abort/parity error looks serious to me. Could you
remove re(4) driver in kernel and perform cold boot and check the
AER errors again?
(I assume your controller is not a stand-alone PCIe controller so
I excluded resitting the controller).
Hi,
This is a stand alone card actually. Here it is after a power cycle.
Perhaps just a bad card ?

***@pci0:4:0:0: class=0x020000 card=0xffffffff 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 0, size 4096, disabled
bar [20] = type Prefetchable Memory, range 64, base 0, size 16384,
disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in maps 0x20 and 0x2c
PCI errors = Master Data Parity Error
Sent Target-Abort
Received Target-Abort
Received Master-Abort
Signalled System Error
Detected Parity Error
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, ***@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
YongHyeon PYUN
2012-06-07 05:46:13 UTC
Permalink
Post by Mike Tancsa
Post by YongHyeon PYUN
Hmm, Target abort/parity error looks serious to me. Could you
remove re(4) driver in kernel and perform cold boot and check the
AER errors again?
(I assume your controller is not a stand-alone PCIe controller so
I excluded resitting the controller).
Hi,
This is a stand alone card actually. Here it is after a power cycle.
Perhaps just a bad card ?
Probably yes. For parity errors there is nothing can be done in
driver side. It would be interesting to know how other operating
systems handle this.
Post by Mike Tancsa
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 0, size 4096, disabled
bar [20] = type Prefetchable Memory, range 64, base 0, size 16384,
disabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in maps 0x20 and 0x2c
PCI errors = Master Data Parity Error
Sent Target-Abort
Received Target-Abort
Received Master-Abort
Signalled System Error
Detected Parity Error
John Baldwin
2012-05-31 19:00:20 UTC
Permalink
Post by Mike Tancsa
Post by John Baldwin
Post by YongHyeon PYUN
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
Loading...