From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 22:36:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59ECC65D for ; Tue, 1 Apr 2014 22:36:42 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 28E9365A for ; Tue, 1 Apr 2014 22:36:41 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kq14so10517710pab.37 for ; Tue, 01 Apr 2014 15:36:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LmWVpAF4vinXLom9A/4rd+m4q0W/6LAmgGEIHKXD3Ig=; b=lLlP3X0imZpC+uQnfdZO+fM5btNj64c4UWKCVYYHJdXl/3Oo1O8BlMOfNAmEt9t6F+ J1GrtyboYxxxCZz3f35IM+t09ztxJnvrtyspGtFgwE0ei/U3WmbU3861DoWGZyLUsc5M 6HYgyTehHP/1H3DHpQZ8dkwp1JTqvYgICNlcwI0RJRjU9SbP32rjO6tAZdT9RqMa1iK+ XeULtAZx4S3q817pIP80wxxoRS2rFnLrGh1+DvxgYabfhvhMChaikwPLqeoQbBaIMszn NYWP54oygO9yKXVctxk0vqqp8R9ZKRjckczDG47mJcWIxlVlTiMlW3j2vxPBi7hsfces h26Q== X-Gm-Message-State: ALoCoQlA6NfMcRQqH8U7RCZbVfJHQsPguyTH8/qNVkqheK8h07szTUCvOnUdRaDmxi0Tmz4GltPB X-Received: by 10.68.4.232 with SMTP id n8mr17726230pbn.114.1396391801191; Tue, 01 Apr 2014 15:36:41 -0700 (PDT) Received: from [10.64.24.154] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ha11sm37111pbd.17.2014.04.01.15.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 15:36:40 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 From: Warner Losh In-Reply-To: <20140401065842.GA1364@michelle.cdnetworks.com> Date: Tue, 1 Apr 2014 16:36:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2598eeb4c68e23df0789e5e3e8f46d76.authenticated@ultimatedns.net> <20140331050002.GC1359@michelle.cdnetworks.com> <20140401065842.GA1364@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1874) Cc: freebsd-net , freebsd-stable , Chris H X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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 22:36:42 -0000 On Apr 1, 2014, at 12:58 AM, Yonghyeon PYUN 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@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: >>>>=20 >>>> miibus0: mii_mediachg: can't handle non-zero PHY instance 1 >>>> ... >>>> miibus0: mii_mediachg: can't handle non-zero PHY instance 31 >>>>=20 >>>> 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. >>>=20 >>> Would you show me the dmesg output? >> Happily: >>=20 >> Calibrating TSC clock ... TSC clock: 3231132841 Hz >> CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU) >> Origin =3D "AuthenticAMD" Id =3D 0x100f62 Family =3D 0x10 Model =3D= 0x6 Stepping =3D 2 >> = Features=3D0x78bfbff >> Features2=3D0x802009 >> AMD = Features=3D0xee500800 >> AMD = Features2=3D0x37fd >=20 > [...] >=20 >> 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 >=20 > [...] >=20 >> 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 >=20 > 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=92ve seen this a few times when the resources were AFU on CardBus = cards.. But never this coherently=85 I=92ve 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=92s head from that = are almost old enough to collect retirement... Warner