miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Yonghyeon PYUN]

On Mon, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote:
> > On Sun, Mar 30, 2014 at 01:12:20PM -0700, chrish at UltimateDNS.NET wrote:
> >> Greetings,
> >>  I'm not sure whether this best belonged on net@, or stable@
> >> so I'm using both. :)
> >> I'm testing both releng_9, and MB, and I encountered a new
> >> message I don't usually see using the nfe(4) driver:
> >>
> >> miibus0: mii_mediachg: can't handle non-zero PHY instance 1
> >> ...
> >> miibus0: mii_mediachg: can't handle non-zero PHY instance 31
> >>
> >> Truncated for brevity (31 lines in total; 1-31). I don't know
> >> how interpret this. An issue with my version of the driver, or
> >> the hardware itself? This occurred with both GENERIC, as well
> >> as my custom kernel.
> >
> > Would you show me the dmesg output?
> Happily:
> 
> Calibrating TSC clock ... TSC clock: 3231132841 Hz
> CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x100f62  Family = 0x10  Model = 0x6  Stepping = 2
>   Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
>   Features2=0x802009<SSE3,MON,CX16,POPCNT>
>   AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
>   AMD Features2=0x37fd<LAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>

[...]

> nfe0: <NVIDIA nForce MCP61 Networking Adapter> port 0xe480-0xe487 mem 0xdff7d000-0xdff7dfff
> irq 20 at device 7.0 on pci0
> nfe0: attempting to allocate 8 MSI vectors (8 supported)
> msi: routing MSI IRQ 257 to local APIC 0 vector 56
> msi: routing MSI IRQ 258 to local APIC 0 vector 57
> msi: routing MSI IRQ 259 to local APIC 0 vector 58
> msi: routing MSI IRQ 260 to local APIC 0 vector 59
> msi: routing MSI IRQ 261 to local APIC 0 vector 60
> msi: routing MSI IRQ 262 to local APIC 0 vector 61
> msi: routing MSI IRQ 263 to local APIC 0 vector 62
> msi: routing MSI IRQ 264 to local APIC 0 vector 63
> nfe0: using IRQs 257-264 for MSI
> nfe0: Using 8 MSI messages
> miibus0: <MII bus> on nfe0
> rlphy0: <RTL8201L 10/100 media interface> PHY 0 on miibus0
> rlphy0: OUI 0x000004, model 0x0020, rev. 1
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> rlphy1: <RTL8201L 10/100 media interface> PHY 1 on miibus0
> rlphy1: OUI 0x000004, model 0x0020, rev. 1
> rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow

[...]

> rlphy30: <RTL8201L 10/100 media interface> PHY 30 on miibus0
> rlphy30: OUI 0x000004, model 0x0020, rev. 1
> rlphy30:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> rlphy31: <RTL8201L 10/100 media interface> PHY 31 on miibus0
> rlphy31: OUI 0x000004, model 0x0020, rev. 1
> rlphy31:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> nfe0: bpf attached
> nfe0: Ethernet address: 40:61:86:cd:44:97

mii(4) thinks it has 32 PHYs and this is the reason why mii(4)
complains.  Due to unknown reason, accessing PHY registers in
device probe stage got valid response which in turn makes the
driver think there are 32 PHYs.  Did you ever see this this kind of
message on old FreeBSD release? Or could you try cold-boot and see
whether it makes any difference?