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

[Warner Losh]

On Apr 1, 2014, at 12:58 AM, Yonghyeon PYUN <pyunyh at gmail.com> wrote:

> 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?

I’ve seen this a few times when the resources were AFU on CardBus cards.. But never this coherently… I’ve also seen it during early bring up when I got the MII address wrong, but you should be well past that with the rl driver :) The voices in Bill Paul’s head from that are almost old enough to collect retirement...

Warner