miibus0: mii_mediachg: can't handle non-zero PHY instance 31

Mon Apr 7 16:37:46 UTC 2014

> 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 at 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 at 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

>