From owner-freebsd-net@FreeBSD.ORG Mon Apr 7 01:51:09 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 4CE0F5FF; Mon, 7 Apr 2014 01:51:09 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 0E8AF783; Mon, 7 Apr 2014 01:51:09 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so5971782pab.22 for ; Sun, 06 Apr 2014 18:51:08 -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=4JIjes/2O+r2UX4kmz4XHB+I3FDeXC9FomZdL60sXyI=; b=XQIJkI64oV3Q1SpgCBG3NE48M/fadWTPcbLKW+D4HIpm/dtpwsx3qXQ0rvel2MOJdX zUqukHKmUOCH1NLcl2DFWlvQinEbSWzHAsyXIdZaYFqzCRbvdpiuJIYNWgThOKJBHcuq amjZJWd/8GDhK0Ih8/4yG9jc/ksBwGHqsl0tVllbu8FZJgqLTzIaTbrymonQRoUDAoPh AjbMBlVeZx8+nN4TI0DkNMY8If8fSoQVdMLkyU1Izm1tf7C1RZGNDj7+A4u4BfVnbkDi Wc5ExZNDbfQDxVjqyfyfrZcPf3V5MhEhS8rGISQ8xp6OG6v1J93YNc5nZmoiaKyNB9o1 w7WQ== X-Received: by 10.68.252.165 with SMTP id zt5mr28219060pbc.17.1396835468624; Sun, 06 Apr 2014 18:51:08 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id pl10sm32950998pbb.56.2014.04.06.18.51.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 06 Apr 2014 18:51:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 07 Apr 2014 10:51:04 +0900 From: Yonghyeon PYUN Date: Mon, 7 Apr 2014 10:51:04 +0900 To: Chris H Subject: Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Message-ID: <20140407015104.GC3543@michelle.cdnetworks.com> References: <20140331050002.GC1359@michelle.cdnetworks.com> <20140401065842.GA1364@michelle.cdnetworks.com> <1396384167.81853.210.camel@revolution.hippie.lan> <41917a9e67d0f4519df4b55f3aa6ebe3.authenticated@ultimatedns.net> <20140402003912.GA2938@michelle.cdnetworks.com> <3f97f5646629043fed5e34a77c9c2f3d.authenticated@ultimatedns.net> <20140402020803.GB2938@michelle.cdnetworks.com> <70cd5de109845e30fcb6516af7a6f9de.authenticated@ultimatedns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70cd5de109845e30fcb6516af7a6f9de.authenticated@ultimatedns.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net , freebsd-stable , Ian Lepore 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: Mon, 07 Apr 2014 01:51:09 -0000 On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote: > > On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote: > >> > On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote: > >> >> > On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote: > >> >> >> [...] > >> >> >> miibus0: on nfe0 > >> >> >> rlphy0: PHY 0 on miibus0 > >> >> >> rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow > >> >> >> rlphy1: PHY 1 on miibus0 > >> >> > [...]---big-snip--8<--- > >> >> >> miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > >> >> >> > >> >> >> As you can see, it looks much the same. I have no idea what > >> >> >> I should do to better inform the driver/kernel how to better > >> >> >> handle it. Or is it the driver, itself? > >> >> >> > >> >> >> Thank you again, for your thoughtful response. > >> >> >> > >> >> >> --Chris > >> >> >> > >> >> > > >> >> > I think the way to fix a phy that responds at all addresses is to set a > >> >> > hint in loader.conf masking out the ones that aren't real, like so: > >> >> > > >> >> > hint.miibus.0.phymask="1" > >> >> > > >> >> > You might be able to set ="0x00000001" to make it more clear it's a > >> >> > bitmask, but I'm not sure of that. > >> >> > >> >> Thank you very much for the hint. I'll give it a shot. > >> >> Any idea why this is happening? I have 4 other MB's using the Nvidia > >> >> chipset, and the nfe(4) driver. But they don't respond this way. > >> >> > >> > > >> > If some nfe(4) variants badly behave in probing stage, this should > >> > be handled by driver. We already have too many hints and tunables > >> > and I don't think most users know that. In addition, adding > >> > additional NIC may change miibus instance number. > >> > > >> > Could you show me the output of 'kenv | grep smbios'? > >> Yes, of course. > >> > >> Here it is: > >> > >> smbios.bios.reldate="11/22/2010" > >> smbios.bios.vendor="American Megatrends Inc." > >> smbios.bios.version="V2.7" > >> smbios.chassis.maker="MSI" > >> smbios.chassis.serial="To Be Filled By O.E.M." > >> smbios.chassis.tag="To Be Filled By O.E.M." > >> smbios.chassis.version="2.0" > >> smbios.memory.enabled="2097152" > >> smbios.planar.maker="MSI" > >> smbios.planar.product="K9N6PGM2-V2 (MS-7309)" > >> smbios.planar.serial="To be filled by O.E.M." > >> smbios.planar.version="2.0" > >> smbios.socket.enabled="1" > >> smbios.socket.populated="1" > >> smbios.system.maker="MSI" > >> smbios.system.product="MS-7309" > >> smbios.system.serial="To Be Filled By O.E.M." > >> smbios.system.uuid="00000000-0000-0000-0000-406186cd4497" > >> smbios.system.version="2.0" > >> smbios.version="2.6" > >> > >> Hope this helps, and thank you for all your time, and trouble. > >> > > > > Thanks for the info. Try attached patch and let me know how it > > works. Make sure to remove the hint(hint.miibus.0.phymask="1") > > set in loader.conf before testing it. > > Hello, and thanks for all the attention. > Sorry for the delay. I chose to perform a dump(8) before attempting > the KERn rebuild with the patch. But the kernel threw a read error > message on one of the drives. So I had to sort out the problem on > the drive before I could complete the dump. Then, of course I had > to reslice, and format another drive to replace the ailing one, > before I could perform a restore(8), and start the nfe patch; build > && install kernel. Weird; the drive had only a few hours on it. > Well, anyway. The patch applied cleanly. So I built, and installed > a new kernel with it. X's out the hint.miibus.0.phymask="0x00000001" > in loader.conf(5), and bounced the box. Bad news: > miibus0: mii_mediachg: can't handle non-zero PHY instance 31 > miibus0: mii_mediachg: can't handle non-zero PHY instance 30 > miibus0: mii_mediachg: can't handle non-zero PHY instance 29 > miibus0: mii_mediachg: can't handle non-zero PHY instance 28 > miibus0: mii_mediachg: can't handle non-zero PHY instance 27 > miibus0: mii_mediachg: can't handle non-zero PHY instance 26 > miibus0: mii_mediachg: can't handle non-zero PHY instance 25 > miibus0: mii_mediachg: can't handle non-zero PHY instance 24 > miibus0: mii_mediachg: can't handle non-zero PHY instance 23 > miibus0: mii_mediachg: can't handle non-zero PHY instance 22 > miibus0: mii_mediachg: can't handle non-zero PHY instance 21 > miibus0: mii_mediachg: can't handle non-zero PHY instance 20 > miibus0: mii_mediachg: can't handle non-zero PHY instance 19 > miibus0: mii_mediachg: can't handle non-zero PHY instance 18 > miibus0: mii_mediachg: can't handle non-zero PHY instance 17 > miibus0: mii_mediachg: can't handle non-zero PHY instance 16 > miibus0: mii_mediachg: can't handle non-zero PHY instance 15 > miibus0: mii_mediachg: can't handle non-zero PHY instance 14 > miibus0: mii_mediachg: can't handle non-zero PHY instance 13 > miibus0: mii_mediachg: can't handle non-zero PHY instance 12 > miibus0: mii_mediachg: can't handle non-zero PHY instance 11 > miibus0: mii_mediachg: can't handle non-zero PHY instance 10 > miibus0: mii_mediachg: can't handle non-zero PHY instance 9 > miibus0: mii_mediachg: can't handle non-zero PHY instance 8 > miibus0: mii_mediachg: can't handle non-zero PHY instance 7 > miibus0: mii_mediachg: can't handle non-zero PHY instance 6 > miibus0: mii_mediachg: can't handle non-zero PHY instance 5 > miibus0: mii_mediachg: can't handle non-zero PHY instance 4 > miibus0: mii_mediachg: can't handle non-zero PHY instance 3 > miibus0: mii_mediachg: can't handle non-zero PHY instance 2 > miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > > Just as before. In case it should make any difference; I'm > going to attach my copy of src/sys/dev/nfe/if_nfe.c in case > there are any differences in mine, that do not coincide with > your version/copy (I'm on releng_9 - 9.2-STABLE) > > FreeBSD demon0 9.2-STABLE FreeBSD 9.2-STABLE #0 r263756M: > Thu Apr 3 12:42:03 PDT 2014 > root@demon0:/usr/obj/usr/src/sys/DEMON0 amd64 > > Best wishes, and thanks again. > Oops, could you show me the output of "pciconf -lcbv"?