pci issues with SBC (AMD G-T40E) - PCEngines apu

John Baldwin jhb at freebsd.org
Wed Jun 25 15:22:23 UTC 2014


On Wednesday, June 25, 2014 7:57:12 am Daniel Braniss wrote:
> 
> On Jun 24, 2014, at 6:11 PM, John Baldwin <jhb at freebsd.org> wrote:
> 
> > On Tuesday, June 24, 2014 6:48:56 am Daniel Braniss wrote:
> >> Hi all,
> >> the short story is that not always all the devices are discovered
> >> correctly, i.e. there are 3 RealTek and sometimes all 3 are discovered,
> >> sometimes 2,sometimes only one.
> >> My guts are telling me it’s a timing issue, is there some delay I can put in?
> >> I tried booting verbose but the problem is till there.
> >> example:
> >> …
> >> re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x2000-0x20ff mem 0xf7b00000-0xf7b00fff,0xf7a00000-0xf7a03fff irq 17 at device 0.0 on 
pci2
> >> re1: MSI count : 1
> >> re1: MSI-X count : 4
> >> re1: attempting to allocate 1 MSI-X vectors (4 supported)
> >> msi: routing MSI-X IRQ 260 to local APIC 0 vector 55
> >> re1: using IRQ 260 for MSI-X
> >> re1: Using 1 MSI-X message
> >> re1: ASPM disabled
> >> re1: Chip rev. 0x2c000000
> >> re1: MAC rev. 0x00200000
> >> miibus1: <MII bus> on re1
> >> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus1
> >> rgephy1: OUI 0x00e04c, model 0x0011, rev. 4
> >> rgephy1:  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
> >> re1: bpf attached
> >> re1: Ethernet address: 00:0d:b9:34:28:c5
> >> pcib3: <ACPI PCI-PCI bridge> irq 18 at device 6.0 on pci0
> >> pcib0: allocated type 4 (0x3000-0x3fff) for rid 1c of pcib3
> >> pcib0: allocated type 3 (0xf7d00000-0xf7dfffff) for rid 20 of pcib3
> >> pcib0: allocated type 3 (0xf7c00000-0xf7cfffff) for rid 24 of pcib3
> >> pcib3:   domain            0
> >> pcib3:   secondary bus     3
> >> pcib3:   subordinate bus   3
> >> pcib3:   I/O decode        0x3000-0x3fff
> >> pcib3:   memory decode     0xf7d00000-0xf7dfffff
> >> pcib3:   prefetched decode 0xf7c00000-0xf7cfffff
> >> pci3: <ACPI PCI bus> on pcib3
> >> pci3: domain=0, physical bus=3
> >> found-> vendor=0x10ec, dev=0x8168, revid=0x06
> >>        domain=0, bus=3, slot=0, func=0
> >>        class=02-00-00, hdrtype=0x00, mfdev=0
> >>        cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
> >>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> >>        intpin=a, irq=10
> >>        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 0x3000, size  8, enabled
> >> pcib3: allocated I/O port range (0x3000-0x30ff) for rid 10 of pci0:3:0:0
> >>        map[18]: type Memory, range 64, base 0xf7d00000, size 12, enabled
> >> pcib3: allocated memory range (0xf7d00000-0xf7d00fff) for rid 18 of pci0:3:0:0
> >>        map[20]: type Prefetchable Memory, range 64, base 0xf7c00000, size 14, enabled
> >> pcib3: allocated prefetch range (0xf7c00000-0xf7c03fff) for rid 20 of pci0:3:0:0
> >> pcib3: matched entry for 3.0.INTA
> >> pcib3: slot 0 INTA hardwired to IRQ 18
> >> re2: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x3000-0x30ff mem 0xf7d00000-0xf7d00fff,0xf7c00000-0xf7c03fff irq 18 at device 0.0 on 
pci3
> >> re2: MSI count : 1
> >> re2: MSI-X count : 4
> >> re2: attempting to allocate 1 MSI-X vectors (4 supported)
> >> msi: routing MSI-X IRQ 261 to local APIC 0 vector 56
> >> re2: using IRQ 261 for MSI-X
> >> re2: Using 1 MSI-X message
> >> re2: ASPM disabled
> >> re2: Chip rev. 0x80000000
> >> re2: MAC rev. 0x00000000   <—————————------------ notice this is now zero!
> >> re2: Unknown H/W revision: 0x80000000
> >> device_attach: re2 attach returned 6
> > 
> > The chip rev also looks wrong.  I don't know why you are not getting the
> > correct values though.  I don't see anything obviously wrong like resource
> > issues with the BARs.
> 
> anything I can do to try and track this down?, except diving into the sources :-)
> i have almost no idea where to start (well, I could with the re driver …)
> a flashlight might help.

Normally when there are resource problems reads of registers return all 1's
(e.g 0xffffffff).  I would check to see if the register reads to determine the
chip rev are returning that first.

-- 
John Baldwin


More information about the freebsd-stable mailing list