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

[Chris H]

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

--Chris

>
>> --Chris
>>
>> >
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_nfe.c.tar.xz
Type: application/octet-stream
Size: 16588 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140403/bc0be93f/attachment.obj>