From owner-svn-src-head@freebsd.org Sun Jul 8 15:39:53 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A46441031596 for ; Sun, 8 Jul 2018 15:39:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C16937A20E for ; Sun, 8 Jul 2018 15:39:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 25e0be1e-82c5-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 25e0be1e-82c5-11e8-8837-614b7c574d04; Sun, 08 Jul 2018 15:39:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w68Fdm4Z031432; Sun, 8 Jul 2018 09:39:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531064388.1336.10.camel@freebsd.org> Subject: Re: svn commit: r334880 - head/sys/dev/vnic From: Ian Lepore To: Mark Johnston , Sean Bruno Cc: Andrew Turner , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sun, 08 Jul 2018 09:39:48 -0600 In-Reply-To: <20180708152621.GB18193@pesky> References: <201806091447.w59ElnpU026396@repo.freebsd.org> <20180707174351.GA95934@pesky> <20180708152621.GB18193@pesky> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 15:39:53 -0000 On Sun, 2018-07-08 at 11:26 -0400, Mark Johnston wrote: > On Sun, Jul 08, 2018 at 09:10:27AM -0600, Sean Bruno wrote: > > > > > > > > On 07/07/18 11:43, Mark Johnston wrote: > > > > > > On Sat, Jun 09, 2018 at 02:47:49PM +0000, Andrew Turner wrote: > > > > > > > > Author: andrew > > > > Date: Sat Jun  9 14:47:49 2018 > > > > New Revision: 334880 > > > > URL: https://svnweb.freebsd.org/changeset/base/334880 > > > > > > > > Log: > > > >   In the ThunderX BGX network driver we were skipping the NULL terminator > > > >   when parsing the phy type, however this is included in the length returned > > > >   by OF_getprop. To fix this stop ignoring the terminator. > > > >    > > > >   PR: 228828 > > > >   Reported by: sbruno > > > >   Sponsored by: DARPA, AFRL > > > This seems to break vnic on packet.net ThunderXs.  In particular, VF > > > creation fails.  It seems the problem in my case is that there are > > > multiple PHY devices in the device tree, e.g., xfi@0, xfi@1.  With this > > > change, bgx_fdt_phy_name_match() fails to match against any device > > > containing a unit address in the node name. > > > > > > > Huh ... this was *required* to get the ThunderXs we have in the FreeBSD > > cluster to work at all.  o.0 > > > > I guess "someone" needs to contact "someone" to figure out which is > > correct or we need to replace our FreeBSD cluster machines with ones > > that work like the packet.net machines? > I think the current code works fine if there's only one PHY device, so > my problem is probably just the result of having a different hardware > setup.  We can probably fix the code to handle both cases.  Could you > mail me the output of "ofwdump -ap" from the cluster machine? > ofwdump isn't very useful, you'll get much nicer output with:   sysctl -b hw.fdt.dtb | dtc -I dtb -O dts >somefile.dts BTW, the whole idea of searching for a phy by walking the node hierarchy doing string comparisons on node names sounds pretty antithetical to the whole design of fdt data. Are these nodes not properly cross-linked with phandles? -- Ian