On Apr 1, 2014, at 12:58 AM, Yonghyeon PYUN <pyu...@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, chr...@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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"