Date: Tue, 8 Apr 2014 11:43:21 -0700 (PDT) From: "Chris H" <bsd-lists@bsdforge.com> To: pyunyh@gmail.com Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-stable <freebsd-stable@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Message-ID: <abd0b08725b541da8e66f5996127fdbe.authenticated@ultimatedns.net> In-Reply-To: <20140408043848.GA1372@michelle.cdnetworks.com> References: <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> <366dff3399e9d5960e5a89902cb81dc3.authenticated@ultimatedns.net> <20140408043848.GA1372@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Apr 07, 2014 at 09:40:53AM -0700, Chris H wrote: >> > 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? > > Thanks a lot for testing. Thank YOU for working on this! > I'll commit it within a couple of days. Good news. > >> 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 > > I don't think the patch may result in the change you've seen. > Auto-negotiation may take several seconds and that might be reason > you see the difference. Link up message does not necessarily mean > it resolved speed/duplex of link against link partner. nfe(4) > explicitly checks whether it established a valid link(i.e. link > should be up and speed/duplex also should be resolved). OK. I have 3 others using nfe(4), and they don't take as long. So thought it might be worth mentioning -- no finger pointing, just saying. :) I'll keep an eye on it. I'm guessing it's probably just the difference in version of chip, or something similar. Thanks again. --Chris > >> 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 >> >> >> > >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?abd0b08725b541da8e66f5996127fdbe.authenticated>