Date: Thu, 30 Aug 2018 10:27:00 -0700 From: Navdeep Parhar <np@FreeBSD.org> To: Marius Halden <marius.h@lden.org>, freebsd-net@freebsd.org Subject: Re: cxl nic not working after reboot Message-ID: <8bb881ef-a701-1c94-3598-79a2724fa648@FreeBSD.org> In-Reply-To: <1535628110.3034153.1491191792.12397BCF@webmail.messagingengine.com> References: <1535379569.2132387.1487489784.45227861@webmail.messagingengine.com> <20180827151302.GA10167@ox> <1535395530.234212.1487804896.64257978@webmail.messagingengine.com> <1535448912.3229649.1488521184.1EE83C33@webmail.messagingengine.com> <20180829062843.GA25476@ox> <1535538153.459716.1489861176.29777B66@webmail.messagingengine.com> <1535628110.3034153.1491191792.12397BCF@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/30/18 4:21 AM, Marius Halden wrote: > On Wed, Aug 29, 2018, at 12:22, Marius Halden wrote: >> On Wed, Aug 29, 2018, at 08:28, Navdeep Parhar wrote: >>>>>> Provide the output of these commands when the link isn't up: >>>>>> # ifconfig -mvvv <interface> >>>>>> # sysctl -n dev.t5nex.0.misc.devlog >>> >>> Can you provide the output from when the port is working? >> >> Sure, the output from when it works follows. >=20 > I tried to downgrade to a the previous bsdrp version we were running ba= sed on 11.1-RELEASE-p10, but it did not start working again. ifconfig out= put and t5nex0 devlog follows (non-working state), but it all looks fine = to me (media has always been reported wrong). I did notice though that "h= w_mac_init_port[0], =E2=80=A6" will always be logged when it works but no= t when when it doesn't work. I confirmed this on a box still running the = old version which functions as intended. >=20 > The ones not working has a newer firmware version than the ones working= =2E >=20 > Non-working: > # sysctl dev.t5nex.0.firmware_version > dev.t5nex.0.firmware_version: 1.19.1.0 >=20 >=20 > Working: > # sysctl dev.t5nex.0.firmware_version > dev.t5nex.0.firmware_version: 1.16.45.0 >=20 > Any other ideas? >=20 I'm still looking into it. The current working theory is that the peer is trying to autonegotiate when it shouldn't (it's 1Gbps optics). If you know how to disable AN on the peer this should be easy to test. Regards, Navdeep
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8bb881ef-a701-1c94-3598-79a2724fa648>