Date: Mon, 7 Apr 2014 18:20:19 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Chris Nehren <cnehren+freebsd-stable@pobox.com> Cc: FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: Note for those pulling in new ZFS feature flags Message-ID: <alpine.BSF.2.00.1404071759330.9102@mail.fig.ol.no> In-Reply-To: <20140407153040.GA17668@behemoth> References: <20140407135421.GA16385@behemoth> <CAFHbX1%2BCerhdfo-VB4dj_JZAkp79b_KD7T0TCxFWTLGFsu-Mpw@mail.gmail.com> <20140407145511.GA16747@behemoth> <alpine.BSF.2.00.1404071656540.9102@mail.fig.ol.no> <20140407153040.GA17668@behemoth>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Apr 2014 11:30-0400, Chris Nehren wrote: > On Mon, Apr 07, 2014 at 17:05:32 +0200, Trond Endrestøl wrote: > > See: > > > > http://svnweb.freebsd.org/base/stable/10/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c?view=markup#l4992 > > > > Consider this a lesson learned. Yes, I too was bitten by this once, > > but never again. ;-) Luckily, I recovered using a snapshot image. > > That's funny, because I *specifically* noted the absence of that > message when I upgraded my pool and spent about 5 minutes wondering > if it was needed or not. Browsing through the code, it appears that the message will only be shown if the current root fs is on one of the zpools you are upgrading. I chased this chain in zpool_main.c: zpool_do_upgrade() for_each_pool() upgrade_one() (used as a callback function by for_each_pool()) root_pool_upgrade_check() is_root_pool() Maybe the message should be shown unconditionally after the fact when all zpool upgrades has taken place, to warn the novice user and friendly remind the seasoned user. > Either way, I think I'll opt to doing the bootcode thing every time > as well. (Y) -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@FreeBSD.ORG Mon Apr 7 16:37:46 2014 Return-Path: <owner-freebsd-stable@FreeBSD.ORG> Delivered-To: freebsd-stable@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 0F0EB71; Mon, 7 Apr 2014 16:37:46 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89361694; Mon, 7 Apr 2014 16:37:45 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s37Gewm1008702; Mon, 7 Apr 2014 09:41:04 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s37GeqtQ008698; Mon, 7 Apr 2014 09:40:52 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 7 Apr 2014 09:40:53 -0700 (PDT) Message-ID: <366dff3399e9d5960e5a89902cb81dc3.authenticated@ultimatedns.net> In-Reply-To: <20140407060351.GA1357@michelle.cdnetworks.com> References: <20140401065842.GA1364@michelle.cdnetworks.com> <c73ef96319846b3da07db5785f48fb6a.authenticated@ultimatedns.net> <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> <20140407015104.GC3543@michelle.cdnetworks.com> <16934e2751614ab9235ac00c6b6bb2d7.authenticated@ultimatedns.net> <20140407060351.GA1357@michelle.cdnetworks.com> Date: Mon, 7 Apr 2014 09:40:53 -0700 (PDT) Subject: Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 From: "Chris H" <bsd-lists@bsdforge.com> To: pyunyh@gmail.com User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-stable <freebsd-stable@freebsd.org>, Ian Lepore <ian@freebsd.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>; List-Post: <mailto:freebsd-stable@freebsd.org> List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 07 Apr 2014 16:37:46 -0000 > On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote: >> > 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: <MII bus> on nfe0 >> >> >> >> >> rlphy0: <RTL8201L 10/100 media interface> PHY 0 on miibus0 >> >> >> >> >> rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow >> >> >> >> >> rlphy1: <RTL8201L 10/100 media interface> 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"? >> >> Yes. Of course. >> > > [...] > >> nfe0@pci0:0:7:0: class=0x068000 card=0x73091462 chip=0x03ef10de rev=0xa2 hdr=0x00 >> vendor = 'nVidia Corporation' >> device = 'MCP61 Ethernet' >> class = bridge >> bar [10] = type Memory, range 32, base 0xdff7d000, size 4096, enabled >> bar [14] = type I/O Port, range 32, base 0xe480, size 8, enabled >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> cap 05[50] = MSI supports 8 messages, 64 bit, vector masks enabled with 8 messages >> cap 08[6c] = HT MSI fixed address window enabled at 0xfee00000 > > Thanks a lot for the info. It seems I missed there are 4 variants > for MCP61. Try attached patch again. Greetings, and thank you for your continued efforts. I just applied the patch, and built/installed a kernel with it. The results are in: /boot/loader.conf: loader_logo="beastiebw" #hint.miibus.0.phymask="0x00000001" relevant output from dmesg(8): 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 nfe0: bpf attached nfe0: Ethernet address: 40:61:86:cd:44:97 ... vlan: initialized, using hash tables with chaining ... lo0: bpf attached ... Hmmm. I think we have a winner. No? The only thing that I noticed that appeared to be different. Is that it takes some 5 seconds to get from: nfe0: link state changed to DOWN nfe0: link state changed to UP to: Starting Network: ... output. I don't know that your patch had anything to do with that. Or it's just another anomaly with the driver/NIC. But it was a long enough period/change, that I thought it worth mentioning. Thank you again, for all your time, and efforts. --Chris >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1404071759330.9102>