I let it cool off overnight, and has been ok ever since,
very strange.
danny
On Jun 25, 2014, at 6:17 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Wednesday, June 25, 2014 7:57:12 am Daniel Braniss wrote:
>> =
>> On Jun 24, 2014, at 6:11 PM, John Baldwin <jhb@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=92s a timing issue, is there some delay I ca=
n put in?
>>>> I tried booting verbose but the problem is till there.
>>>> example:
>>>> =85
>>>> 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 dev=
ice 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 mii=
bus1
>>>> rgephy1: OUI 0x00e04c, model 0x0011, rev. 4
>>>> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100=
baseTX-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=3D0, physical bus=3D3
>>>> found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x06
>>>> domain=3D0, bus=3D3, slot=3D0, func=3D0
>>>> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0
>>>> cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords)
>>>> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n=
s)
>>>> intpin=3Da, irq=3D10
>>>> 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 pc=
i0:3:0:0
>>>> map[20]: type Prefetchable Memory, range 64, base 0xf7c00000, si=
ze 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 dev=
ice 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 <=97=97=97=97=97=97=97=97=97------------ no=
tice 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 resou=
rce
>>> issues with the BARs.
>> =
>> anything I can do to try and track this down?, except diving into the so=
urces :-)
>> i have almost no idea where to start (well, I could with the re driver =
=85)
>> 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 determin=
e the
> chip rev are returning that first.
> =
> -- =
> John Baldwin
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"