From owner-freebsd-arm@freebsd.org Sat Dec 7 23:42:01 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15CD71D04B1 for ; Sat, 7 Dec 2019 23:42:01 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from mail.brickporch.com (mail.brickporch.com [52.33.181.202]) by mx1.freebsd.org (Postfix) with ESMTP id 47VmFg54NTz4Mbh for ; Sat, 7 Dec 2019 23:41:59 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from twill.home.brickporch.com (69-84-2-229.mxu.aerioconnect.net [69.84.2.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.brickporch.com (Postfix) with ESMTPSA id 3389C12CC9B for ; Sat, 7 Dec 2019 23:42:18 +0000 (UTC) From: Marcel Flores Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: ThunderX Networking Date: Sat, 7 Dec 2019 15:41:51 -0800 References: <340B43A0-8E12-4F8C-A7F0-844BF8A55DB8@brickporch.com> To: freebsd-arm@freebsd.org In-Reply-To: <340B43A0-8E12-4F8C-A7F0-844BF8A55DB8@brickporch.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47VmFg54NTz4Mbh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of marcel@brickporch.com designates 52.33.181.202 as permitted sender) smtp.mailfrom=marcel@brickporch.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[brickporch.com]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-0.85)[ipnet: 52.32.0.0/14(-2.89), asn: 16509(-1.30), country: US(-0.05)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:52.32.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 23:42:01 -0000 > On Jul 13, 2019, at 1:46 PM, Marcel Flores = wrote: >=20 > Hi All, >=20 > I had some time to poke around at the issue regarding: > https://lists.freebsd.org/pipermail/freebsd-arm/2019-April/019798.html >=20 > On boot, with 13-CURRENT (r349796) dmesg dumps the following message: >=20 > bgx0: Could not find Matching PHY >=20 > Which seems to come from here: > = https://github.com/freebsd/freebsd/blob/master/sys/dev/vnic/thunder_bgx_fd= t.c#L456 >=20 > Playing around with some debugging output, it seems like the check is = falling > through when it checks for matching device names: >=20 > = https://github.com/freebsd/freebsd/blob/master/sys/dev/vnic/thunder_bgx_fd= t.c#L196 >=20 > But when I dump the string that it=E2=80=99s comparing to, by adding = the following above line 196: >=20 > device_printf(bgx->dev, "Matching Names: %s to %s\n", phys_name, = type); >=20 > It seems like the match is very "close", but maybe something minute is = getting > in the way: >=20 > bgx0: Checking for length and name > bgx0: Matching names: xfi00 to xfi > bgx0: Matching names: xfi01 to xfi > bgx0: Matching names: xfi02 to xfi > bgx0: Matching names: xfi03 to xfi > bgx0: Could not find matching PHY > device_attach: bgx0 attach returned 6 > bgx0: mem = 0x87e0e1000000-0x87e0e13fffff,0x87e0e1400000-0x87e0e17fffff at device = 0.129 on pci1 > bgx0: Matching names: xlaui10 to xlaui > device_attach: bgx0 attach returned 6 >=20 > In particular, it seems to be failing the second part of the check, = that > ensure's a "\0" or a "@" after the name. >=20 > Could this be an issue with the FDT setup for the thunderx? Maybe = something > simple or an indicator of bigger issues? Am I barking up the wrong = tree? Happy > to do any further digging if anyone has any ideas! >=20 > Thanks, > -Marcel > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hi All, Took another look at the this. It seems the issue arose in this commit: https://reviews.freebsd.org/rS334880 Manually removing the additional check and building a kernel allowed it = to match the PHY device. Following the steps outlined here: = https://lists.freebsd.org/pipermail/freebsd-arm/2015-November/012612.html and was able to get the onboard NIC working. This feels very much like a bug in the check logic of rS334880 to me, = but I admit I'm out of my depth on what exactly it's checking for. -Marcel