From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:58:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB555848; Tue, 1 Apr 2014 06:58:48 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97680819; Tue, 1 Apr 2014 06:58:48 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so9131033pdj.13 for ; Mon, 31 Mar 2014 23:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qdn/KYoACp8kucYs+CTZ9d+Amk1W4QuXsORwpAfqyOQ=; b=iQhTRHdlnw7E/1oj2J/La2GUCUusfi3buQG3qbkfgy6s0tnVqQxHiUAmvUOgY6iZhd 90gyI7NBZcoEO3MauYXmDp7X0JZW4YJb34BOunUe5o7gSwX36OAn9Ipp0I2XlLP5y/7n iKvVBEh4mgYJnLOIxvP1OHUgVyhjjuRxze3/7BoPGKB4SF9SRBOJ4mFbV/oD5o/TRx8n d+SoQ97uwcPCbx+IqreYW/arAycupsw1PnusmLu9TptPS1+g/RELZ+S7W1lxV89lWkCB Z9SUhSVtrj46/iBx3RHmZ7vtGbok/yDP9zb0dd3BOpyJD0VP552LxhhPBd0uz5H+r4/D hNTw== X-Received: by 10.68.212.10 with SMTP id ng10mr29242884pbc.95.1396335528243; Mon, 31 Mar 2014 23:58:48 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id vg1sm47752672pbc.44.2014.03.31.23.58.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 31 Mar 2014 23:58:47 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 01 Apr 2014 15:58:42 +0900 From: Yonghyeon PYUN Date: Tue, 1 Apr 2014 15:58:42 +0900 To: Chris H Subject: Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Message-ID: <20140401065842.GA1364@michelle.cdnetworks.com> References: <2598eeb4c68e23df0789e5e3e8f46d76.authenticated@ultimatedns.net> <20140331050002.GC1359@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net , freebsd-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 06:58:48 -0000 On Mon, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote: > > On Sun, Mar 30, 2014 at 01:12:20PM -0700, chrish@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 > Features2=0x802009 > AMD Features=0xee500800 > AMD Features2=0x37fd [...] > nfe0: 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: on nfe0 > rlphy0: PHY 0 on miibus0 > rlphy0: OUI 0x000004, model 0x0020, rev. 1 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow > rlphy1: PHY 1 on miibus0 > rlphy1: OUI 0x000004, model 0x0020, rev. 1 > rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] > rlphy30: PHY 30 on miibus0 > rlphy30: OUI 0x000004, model 0x0020, rev. 1 > rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow > rlphy31: 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?