From owner-freebsd-arm@freebsd.org Sun Jul 5 00:07:08 2020 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 631C035BF16 for ; Sun, 5 Jul 2020 00:07:08 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zpsl1Mgfz4Gsc for ; Sun, 5 Jul 2020 00:07:06 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 06506n9n005115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 5 Jul 2020 10:06:55 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 06506hAA063436 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Jul 2020 10:06:43 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 06506h1s063435 for freebsd-arm@freebsd.org; Sun, 5 Jul 2020 10:06:43 +1000 (AEST) (envelope-from peter) Date: Sun, 5 Jul 2020 10:06:43 +1000 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: RK3328/Rock64 GigE testers needed. Message-ID: <20200705000643.GA63127@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 49zpsl1Mgfz4Gsc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-4.52 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,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.04)[-1.042]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[rulingia.com]; NEURAL_HAM_SHORT(-0.09)[-0.094]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 00:07:08 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Head r362736 has enabled the internal RGMII delay lines in the RK3328 (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've modded to use the higher RGMII bus voltage, as per the v3.0). gonzo@ and I would be interested in other people's experiences with this revision - particularly other people with Rock64 v2 or Rock64 v3 boards. --=20 Peter Jeremy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl8BGXtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLKMPA/+KuJRnoRDb1bAGONE3KKu5KfBMdQ5WsRkk9MVIpeV6LAgOKLierxs3eF8 V9Jwj6UvipANMwtmOOiK4neuKy5PE4cr3NUaVVqijn1rbCbA0xoPACdP5oym9owO BKupMVgvYJzM9szgmJQLtI4kBfpCOO0a65AfbOlEbj3avsuV9l+KdzxnyflnotAu BWAykholcg7d7DiBV+AykCAUhJhVXLkP52MfR1wrGVCNiPAcqaCv8GJf3SyQKVw1 BFb0Stq0mJd8PKj8PDRv9b693n1Jj3BA6BGXTC5+ALhSvnSvK7gN4iyOb4YVE9Kk OjQ0zmxA9ZgDBvvJobOrR4ZkWw+yQ0DX27xf1abmVRlGzdxUlislgd2nwc40OwIc uLd4/q8aAy7/JS/r6DludgffVJE3fklJHzvA4FOKKFyD6F8UZejaXqJZv2dPiDD3 lkIecbjC16Xmf+vgL1vYu1iutSYv/qgrJ2WJmz8elE3JM+KvthgFA1pyk37VfOq0 V+cT/x2wUbILL2lhikpx4JvSfK7bSSWRFMHxxgreF60ODOguDKRyqf0NlfjY2Xu1 Go2vvERFSU5qA47tn42/Jd4v0DuHvWUeDYHHUhL9r+w4uz1ANmi7S25ZmHgxQJH0 +x3gPuFj/4gzj+uQaQacI8VikPp2Icvv4gtqsqHCeZPcMVdnC/I= =WnVV -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-arm@freebsd.org Sun Jul 5 16:10:13 2020 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 0B4C336EB84 for ; Sun, 5 Jul 2020 16:10:13 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0DDz6xymz46KV for ; Sun, 5 Jul 2020 16:10:11 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1593965408; cv=none; d=zohomail.com; s=zohoarc; b=K13EhuEGshPZA/OShNQn/3GsbtfVK7DcI0cF49gnhUgZ0qCwLlgczFJNyVcgimQgXZVj4+sXravd8XqQ1OqXZ9wCd6FgOLHzj4FANt1LlAoSU4G7N6dQnJIsX8zGo39hQgsTfnL5XPbOUqk0Y3akz7zaRNjK5Cokn86HTkUhqtw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1593965408; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=E8Uk+6CVRB5DiNCqV3EzmpKJVnjG5DIMpEWZirnkFNY=; b=JMWrP0Fkn+wt/+9omLizc2Doyj/kcIgQMMUbS/kB9XEbncl3YpF6+mInODL5a4zYUVuib2ZMptjmOdCHSABvrqf6b2Cz3PfwILabgZt3OBzxl5BZDbVHlMNdVtTXOOvhWNWXrZPLqXj+bh325LNV0FomTVfZPKWOomTDQuHHOmU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1593965408; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; bh=E8Uk+6CVRB5DiNCqV3EzmpKJVnjG5DIMpEWZirnkFNY=; b=ci/Q5ItzhgW+pGsI3noOQ/6C9CT/SCroDShr6s9tTLuR2mlEeRM/gjmEYafkcUou IEeGz9qNQRCjRfQ+H62PEnk7Qd/BllWoP8XYvvjapuGOHXTas28ZrphYGk6ZOnyQDhX iYlXdhr/0lUYYLCsI8my/gG/hYcc8k9U4z8cXFFQ= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1593965407532421.30173377991764; Sun, 5 Jul 2020 09:10:07 -0700 (PDT) Date: Sun, 05 Jul 2020 19:10:07 +0300 From: Furkan Salman To: "freebsd-arm" Message-Id: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> In-Reply-To: References: Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 MIME-Version: 1.0 Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 4B0DDz6xymz46KV X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=ci/Q5Itz; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-5.13 / 15.00]; NEURAL_HAM_MEDIUM(-1.04)[-1.039]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/23]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fkardame.com:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; NEURAL_HAM_SHORT(-1.30)[-1.302]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 16:10:13 -0000 Hello Peter, I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or gonz= o@ can confirm if rockpie can be used to test RK3328 Lan issue then I am ha= ppy to help with testing. ---- On Sun, 05 Jul 2020 15:00:02 +0300 = wrote ---- Send freebsd-arm mailing list submissions to=20 =C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm@freebsd.org=20 =20 To subscribe or unsubscribe via the World Wide Web, visit=20 =C2=A0=C2=A0=C2=A0=C2=A0https://lists.freebsd.org/mailman/listinfo/freebsd-= arm=20 or, via email, send a message with subject or body 'help' to=20 =C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm-request@freebsd.org=20 =20 You can reach the person managing the list at=20 =C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm-owner@freebsd.org=20 =20 When replying, please edit your Subject line so it is more specific=20 than "Re: Contents of freebsd-arm digest..."=20 =20 =20 Today's Topics:=20 =20 1. RBPI3B/3B+ builtin WIFI support (Stefan Parvu)=20 2. RK3328/Rock64 GigE testers needed. (Peter Jeremy)=20 =20 =20 ----------------------------------------------------------------------=20 =20 Message: 1=20 Date: Sat, 4 Jul 2020 22:07:44 +0300=20 From: Stefan Parvu =20 To: mailto:freebsd-arm@freebsd.org=20 Subject: RBPI3B/3B+ builtin WIFI support=20 Message-ID: = =20 Content-Type: text/plain;=C2=A0=C2=A0=C2=A0=C2=A0charset=3Dus-ascii=20 =20 Hi,=20 =20 Is there any progress to have support for the built-in Wifi on RBPI3/3B+ ?= =20 We want to test our product based on FreeBSD for IoT. Preferable we dont wa= nt to use any additional USB dongles.=20 =20 Thank you,=20 Stefan=20 =20 ------------------------------=20 =20 Message: 2=20 Date: Sun, 5 Jul 2020 10:06:43 +1000=20 From: Peter Jeremy =20 To: mailto:freebsd-arm@freebsd.org=20 Subject: RK3328/Rock64 GigE testers needed.=20 Message-ID: =20 Content-Type: text/plain; charset=3D"us-ascii"=20 =20 Head r362736 has enabled the internal RGMII delay lines in the RK3328=20 (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've=20 modded to use the higher RGMII bus voltage, as per the v3.0).=20 =20 gonzo@ and I would be interested in other people's experiences with=20 this revision - particularly other people with Rock64 v2 or Rock64 v3=20 boards.=20 =20 --=20 Peter Jeremy=20 -------------- next part --------------=20 A non-text attachment was scrubbed...=20 Name: signature.asc=20 Type: application/pgp-signature=20 Size: 963 bytes=20 Desc: not available=20 URL: =20 =20 ------------------------------=20 =20 Subject: Digest Footer=20 =20 _______________________________________________=20 mailto:freebsd-arm@freebsd.org mailing list=20 https://lists.freebsd.org/mailman/listinfo/freebsd-arm=20 To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd.or= g"=20 =20 =20 ------------------------------=20 =20 End of freebsd-arm Digest, Vol 740, Issue 7=20 ******************************************* From owner-freebsd-arm@freebsd.org Sun Jul 5 17:14:50 2020 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 DBC0A3484CB for ; Sun, 5 Jul 2020 17:14:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0FgY5r3Kz4BYC for ; Sun, 5 Jul 2020 17:14:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id C84013484C9; Sun, 5 Jul 2020 17:14:49 +0000 (UTC) Delivered-To: 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 C7F753485C0 for ; Sun, 5 Jul 2020 17:14:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0FgX22lfz4BKd for ; Sun, 5 Jul 2020 17:14:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1593969279; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KwxHDwapje6ANL+KyzuwEkLGaifUfg4Xw7PreN7rXYA=; b=cEnFnifXqjEOjb3t9AETR19TvNQIhmAaOLtDCV08H23UqCxFfu5F+f5eTiQt3QL1QwmQUz yQ+v2RE6rpUi/8j6Rsqsy73sVVSr3xsAwWuNa07QOoJVdwR22GItEa32wVv2Ha3oUUaHjD QDqsUqPffziz4BbWqGaoJByrMOPhARo= Received: from skull.home.blih.net (lfbn-idf2-1-686-145.w86-247.abo.wanadoo.fr [86.247.139.145]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 74002f1e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 5 Jul 2020 17:14:39 +0000 (UTC) Date: Sun, 5 Jul 2020 19:14:35 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: Manuel =?ISO-8859-1?Q?St=FChn?= , "freebsd-arm@freebsd.org" Subject: Re: allwinner/i2c interrupt storm detected Message-Id: <20200705191435.c9c65caf64026ee881020f3a@bidouilliste.com> In-Reply-To: References: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> <20200704122944.64723bbb606d6e73128d2568@freenet.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B0FgX22lfz4BKd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=cEnFnifX; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.007]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.65)[-0.647]; NEURAL_HAM_MEDIUM(-1.04)[-1.044]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[freenet.de,freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 17:14:50 -0000 Hi Daniel, Manuel, On Sat, 4 Jul 2020 13:45:50 +0300 Daniel Braniss wrote: >=20 >=20 > > On 4 Jul 2020, at 13:29, Manuel St=FChn wrot= e: > >=20 > > On Tue, 30 Jun 2020 16:01:41 +0300 > > Daniel Braniss > wrote: > >=20 > >> Hi, > >>=20 > >> after a long time I decided to try and upgrade to stable 12.1 r362793 = since I saw some changes where done=20 > >> with respect to the DTS and twsi.c,=20 > >>=20 > >> if nothing is connected to the i2c, i2c -s just hangs, > >>=20 > >> if something is connected this is what i get on the console after typi= ng ?i2c -s? > >>=20 > >>=20 > >> Hardware may not support START/STOP scanning; trinterrupt storm detect= ed on "gic0,s6:"; throttling interrupt source > >> ying less-reliable read method. > >> interrupt storm detected on "gic0,s6:"; throttling interrupt source > >> interrupt storm detected on "gic0,s6:"; throttling interrupt source > >> ? > >>=20 > >> and > >> neo-04> vmstat -i > >> interrupt total rate > >> gic0,p13:-ic_timer0 16052 164 > >> gic0,s0: uart2 318 3 > >> gic0,s6: iichb0 13034 133 > >> gic0,s60: aw_mmc0 1293 13 > >> gic0,s82: awg0 334 3 > >> gic0,s120: pmu0 49725 509 > >> cpu0:rendezvous 18 0 > >> cpu1:rendezvous 50 1 > >> cpu2:rendezvous 51 1 > >> cpu3:rendezvous 40 0 > >> cpu0:preempt 2691 28 > >> cpu1:preempt 3165 32 > >> cpu2:preempt 2778 28 > >> cpu3:preempt 2986 31 > >> cpu0:hardclock 15 0 > >> Total 92550 946 > >>=20 > >>=20 > >> the hardware is an NanoPi Neo > >> ---<>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2020 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 > >> The Regents of the University of California. All rights reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 > >> danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AW= GEN arm > >> FreeBSD clang version 10.0.0 (git@github.com :l= lvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b) > >> VT: init without driver. > >> No PSCI/SMCCC call function found > >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > >> ? > >>=20 > >=20 > > I do not have a IRQ-Storm on my NanoPI NEO2, but a "i2s -s" does never = return. Commit v356609 broke i2c-support on my hardware (reverting this sin= gle commit fixed it, bugreport filed: https://bugs.freebsd.org/bugzilla/sho= w_bug.cgi?id=3D247576 ). > >=20 > > Perhaps it is worth a try for you also to revert this commit and test a= gain... > >=20 >=20 > before the latest changes it works fine, and if you add my patch to it, i= 2s -s will not hang: >=20 > > -- twsi.c (revision 346538) > > +++ twsi.c (working copy) > > @@ -458,8 +458,15 @@ > > if (sc->msg->len =3D=3D 1) > > sc->control_val &=3D ~TWSI_CONTROL_ACK; > > TWSI_WRITE(sc, sc->reg_control, sc->control_val | TWSI_CONTROL_START); > > - while (sc->error =3D=3D 0 && sc->transfer !=3D 0) { > > - pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0); > > + { > > + int count =3D 10; > > + while (sc->error =3D=3D 0 && sc->transfer !=3D 0) { > > + pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0); > > + if(count-- =3D=3D 0) { > > + sc->error =3D EDEADLK; > > + break; > > + } > > + } > > } > >=20 > > debugf(dev, "Done with msg[%d]\n", i); >=20 >=20 > cheers, > danny >=20 > >=20 > > BR > > Manuel Could you test the patch I've just attached to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 please ? It doesn't fix everything and I'm still working on doing test on a lot of different boards but this is clearly needed. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jul 6 05:51:48 2020 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 E007535AAA4 for ; Mon, 6 Jul 2020 05:51:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0ZT02GM5z4mNw for ; Mon, 6 Jul 2020 05:51:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 46E2335A9B2; Mon, 6 Jul 2020 05:51:48 +0000 (UTC) Delivered-To: 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 469FE35AAA3 for ; Mon, 6 Jul 2020 05:51:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0ZSy6YDlz4mcj for ; Mon, 6 Jul 2020 05:51:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=my3AfLss9b+xntX8wef3X7HrsCBf+yDrbq98m/wauuo=; b=k/brbT+yHTcWH/AxYvyrjvHVSQ1BjUYXJGn1EJkcTDWE6eO2Jl8bERkpTf8RAOVG7o/d8yaq7bgatOnm5I0/c2XnOrXvv4cFYbMGiXnrw3nvKu6j9/zLZ/x663roZbhupEPInXvQRVBoS8W64FpjKFPuuCl1Vw8RurKVO/4J9gwzDxaP+YZEGDh74Gn13QmRrNkWs9+J2iAhmfoXNgzSag167fZt9UA+3brMxjA4jJX6wnu9qNFw5IgHgrGOatb8L5l5O0Lwj+Jz4E7Jm2JsohIE+dA2gbuYzy7e0gsSP8EikmpB704k+3KZqzCAnPM0opzJ6TLQeXrc53GmhXIoCg==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1jsK2X-0002nZ-54; Mon, 06 Jul 2020 08:51:41 +0300 From: Daniel Braniss Message-Id: <6CEF2B3D-FDC1-4EBC-80A8-42C5E9A356FC@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Subject: Re: allwinner/i2c interrupt storm detected Date: Mon, 6 Jul 2020 08:51:40 +0300 In-Reply-To: <20200705191435.c9c65caf64026ee881020f3a@bidouilliste.com> Cc: =?utf-8?Q?Manuel_St=C3=BChn?= , "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> <20200704122944.64723bbb606d6e73128d2568@freenet.de> <20200705191435.c9c65caf64026ee881020f3a@bidouilliste.com> X-Mailer: Apple Mail (2.3445.9.5) X-Rspamd-Queue-Id: 4B0ZSy6YDlz4mcj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=k/brbT+y; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.037]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.988]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; RCVD_IN_DNSWL_NONE(0.00)[132.65.116.210:from]; NEURAL_HAM_SHORT(-0.45)[-0.447]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_CC(0.00)[freenet.de,freebsd.org] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 05:51:48 -0000 > On 5 Jul 2020, at 20:14, Emmanuel Vadot wrote: >=20 >=20 > Hi Daniel, Manuel, >=20 > On Sat, 4 Jul 2020 13:45:50 +0300 > Daniel Braniss > = wrote: >=20 >>=20 >>=20 >>> On 4 Jul 2020, at 13:29, Manuel St=C3=BChn = wrote: >>>=20 >>> On Tue, 30 Jun 2020 16:01:41 +0300 >>> Daniel Braniss > = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> after a long time I decided to try and upgrade to stable 12.1 = r362793 since I saw some changes where done=20 >>>> with respect to the DTS and twsi.c,=20 >>>>=20 >>>> if nothing is connected to the i2c, i2c -s just hangs, >>>>=20 >>>> if something is connected this is what i get on the console after = typing ?i2c -s? >>>>=20 >>>>=20 >>>> Hardware may not support START/STOP scanning; trinterrupt storm = detected on "gic0,s6:"; throttling interrupt source >>>> ying less-reliable read method. >>>> interrupt storm detected on "gic0,s6:"; throttling interrupt source >>>> interrupt storm detected on "gic0,s6:"; throttling interrupt source >>>> ? >>>>=20 >>>> and >>>> neo-04> vmstat -i >>>> interrupt total = rate >>>> gic0,p13:-ic_timer0 16052 = 164 >>>> gic0,s0: uart2 318 = 3 >>>> gic0,s6: iichb0 13034 = 133 >>>> gic0,s60: aw_mmc0 1293 = 13 >>>> gic0,s82: awg0 334 = 3 >>>> gic0,s120: pmu0 49725 = 509 >>>> cpu0:rendezvous 18 = 0 >>>> cpu1:rendezvous 50 = 1 >>>> cpu2:rendezvous 51 = 1 >>>> cpu3:rendezvous 40 = 0 >>>> cpu0:preempt 2691 = 28 >>>> cpu1:preempt 3165 = 32 >>>> cpu2:preempt 2778 = 28 >>>> cpu3:preempt 2986 = 31 >>>> cpu0:hardclock 15 = 0 >>>> Total 92550 = 946 >>>>=20 >>>>=20 >>>> the hardware is an NanoPi Neo >>>> ---<>--- >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> Copyright (c) 1992-2020 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>>> The Regents of the University of California. All rights = reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 >>>> = danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AWGEN = arm >>>> FreeBSD clang version 10.0.0 (git@github.com = :llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) >>>> VT: init without driver. >>>> No PSCI/SMCCC call function found >>>> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >>>> ? >>>>=20 >>>=20 >>> I do not have a IRQ-Storm on my NanoPI NEO2, but a "i2s -s" does = never return. Commit v356609 broke i2c-support on my hardware (reverting = this single commit fixed it, bugreport filed: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 = ). >>>=20 >>> Perhaps it is worth a try for you also to revert this commit and = test again... >>>=20 >>=20 >> before the latest changes it works fine, and if you add my patch to = it, i2s -s will not hang: >>=20 >>> -- twsi.c (revision 346538) >>> +++ twsi.c (working copy) >>> @@ -458,8 +458,15 @@ >>> if (sc->msg->len =3D=3D 1) >>> sc->control_val &=3D ~TWSI_CONTROL_ACK; >>> TWSI_WRITE(sc, sc->reg_control, sc->control_val | = TWSI_CONTROL_START); >>> - while (sc->error =3D=3D 0 && sc->transfer !=3D 0) { >>> - pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0); >>> + { >>> + int count =3D 10; >>> + while (sc->error =3D=3D 0 && sc->transfer !=3D = 0) { >>> + pause_sbt("twsi", SBT_1MS * 30, = SBT_1MS, 0); >>> + if(count-- =3D=3D 0) { >>> + sc->error =3D EDEADLK; >>> + break; >>> + } >>> + } >>> } >>>=20 >>> debugf(dev, "Done with msg[%d]\n", i); >>=20 >>=20 >> cheers, >> danny >>=20 >>>=20 >>> BR >>> Manuel >=20 > Could you test the patch I've just attached to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 = please ? >=20 > It doesn't fix everything and I'm still working on doing test on a lot > of different boards but this is clearly needed. >=20 > --=20 > Emmanuel Vadot > = > short version: it works! longer version: first tried with debugging on - worked next tried with no debugging- worked the next test will take some time, trying my app. if I feel up to it, i can try on a neopi neo2 - but that will take = longer. thanks Manu!!!! danny From owner-freebsd-arm@freebsd.org Mon Jul 6 07:44:42 2020 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 D947935EE2A for ; Mon, 6 Jul 2020 07:44:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0czF3smZz4vLC for ; Mon, 6 Jul 2020 07:44:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 8301235EE90; Mon, 6 Jul 2020 07:44:41 +0000 (UTC) Delivered-To: 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 82BC335EA7D for ; Mon, 6 Jul 2020 07:44:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0czD5LbKz4vLB for ; Mon, 6 Jul 2020 07:44:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zaZxG3RfhHgzNz12QAoubQe/aVb8Kusr/Qhg2TIoeKw=; b=jylZK5U4lifh+DBtUTujDzFnp8Fvs/8wmfXOswE+acdmR+vcrxcxZNzCElwgnpnTV3nYULLnEiqfShKRZ3etEjoKwM0+pczlyVarthFWRFupL/Ka8ekKh2qLaNr91LItVXyxvIhRc7aTunetJg/7JmbjBx/AyjdaMQc7flGvfRDTWYctivplCAZEkBa7Wma6NFKAfK08R4coQMQRjxF0V3q6fNtbfUJec/meGxh/GSJLi6GJ+9ym/Iv2kJLT0sXnsGXqqC7uytkkhBg97WYWJlEnUOk55TwtbgdSfP7kHz8zHqA7L2A4g/kMtQDbUVXYZQNUVVhb8ka4V7Zk/Y3N+w==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1jsLnp-0009Qz-9Z; Mon, 06 Jul 2020 10:44:37 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Subject: Re: allwinner/i2c interrupt storm detected From: Daniel Braniss In-Reply-To: <6CEF2B3D-FDC1-4EBC-80A8-42C5E9A356FC@cs.huji.ac.il> Date: Mon, 6 Jul 2020 10:44:36 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3C934887-775C-4A73-A510-D74C8786DF04@cs.huji.ac.il> References: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> <20200704122944.64723bbb606d6e73128d2568@freenet.de> <20200705191435.c9c65caf64026ee881020f3a@bidouilliste.com> <6CEF2B3D-FDC1-4EBC-80A8-42C5E9A356FC@cs.huji.ac.il> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.5) X-Rspamd-Queue-Id: 4B0czD5LbKz4vLB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=jylZK5U4; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.023]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[132.65.116.210:from]; NEURAL_HAM_SHORT(-0.67)[-0.667]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 07:44:42 -0000 > On 6 Jul 2020, at 08:51, Daniel Braniss wrote: >=20 >=20 >=20 >> On 5 Jul 2020, at 20:14, Emmanuel Vadot = wrote: >>=20 >>=20 >> Hi Daniel, Manuel, >>=20 >> On Sat, 4 Jul 2020 13:45:50 +0300 >> Daniel Braniss > = wrote: >>=20 >>>=20 >>>=20 >>>> On 4 Jul 2020, at 13:29, Manuel St=C3=BChn = wrote: >>>>=20 >>>> On Tue, 30 Jun 2020 16:01:41 +0300 >>>> Daniel Braniss > = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> after a long time I decided to try and upgrade to stable 12.1 = r362793 since I saw some changes where done=20 >>>>> with respect to the DTS and twsi.c,=20 >>>>>=20 >>>>> if nothing is connected to the i2c, i2c -s just hangs, >>>>>=20 >>>>> if something is connected this is what i get on the console after = typing ?i2c -s? >>>>>=20 >>>>>=20 >>>>> Hardware may not support START/STOP scanning; trinterrupt storm = detected on "gic0,s6:"; throttling interrupt source >>>>> ying less-reliable read method. >>>>> interrupt storm detected on "gic0,s6:"; throttling interrupt = source >>>>> interrupt storm detected on "gic0,s6:"; throttling interrupt = source >>>>> ? >>>>>=20 >>>>> and >>>>> neo-04> vmstat -i >>>>> interrupt total = rate >>>>> gic0,p13:-ic_timer0 16052 = 164 >>>>> gic0,s0: uart2 318 = 3 >>>>> gic0,s6: iichb0 13034 = 133 >>>>> gic0,s60: aw_mmc0 1293 = 13 >>>>> gic0,s82: awg0 334 = 3 >>>>> gic0,s120: pmu0 49725 = 509 >>>>> cpu0:rendezvous 18 = 0 >>>>> cpu1:rendezvous 50 = 1 >>>>> cpu2:rendezvous 51 = 1 >>>>> cpu3:rendezvous 40 = 0 >>>>> cpu0:preempt 2691 = 28 >>>>> cpu1:preempt 3165 = 32 >>>>> cpu2:preempt 2778 = 28 >>>>> cpu3:preempt 2986 = 31 >>>>> cpu0:hardclock 15 = 0 >>>>> Total 92550 = 946 >>>>>=20 >>>>>=20 >>>>> the hardware is an NanoPi Neo >>>>> ---<>--- >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> Copyright (c) 1992-2020 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, = 1993, 1994 >>>>> The Regents of the University of California. All rights = reserved. >>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 >>>>> = danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AWGEN = arm >>>>> FreeBSD clang version 10.0.0 (git@github.com = :llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) >>>>> VT: init without driver. >>>>> No PSCI/SMCCC call function found >>>>> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >>>>> ? >>>>>=20 >>>>=20 >>>> I do not have a IRQ-Storm on my NanoPI NEO2, but a "i2s -s" does = never return. Commit v356609 broke i2c-support on my hardware (reverting = this single commit fixed it, bugreport filed: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 = ). >>>>=20 >>>> Perhaps it is worth a try for you also to revert this commit and = test again... >>>>=20 >>>=20 >>> before the latest changes it works fine, and if you add my patch to = it, i2s -s will not hang: >>>=20 >>>> -- twsi.c (revision 346538) >>>> +++ twsi.c (working copy) >>>> @@ -458,8 +458,15 @@ >>>> if (sc->msg->len =3D=3D 1) >>>> sc->control_val &=3D ~TWSI_CONTROL_ACK; >>>> TWSI_WRITE(sc, sc->reg_control, sc->control_val | = TWSI_CONTROL_START); >>>> - while (sc->error =3D=3D 0 && sc->transfer !=3D 0) { >>>> - pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0); >>>> + { >>>> + int count =3D 10; >>>> + while (sc->error =3D=3D 0 && sc->transfer !=3D = 0) { >>>> + pause_sbt("twsi", SBT_1MS * 30, = SBT_1MS, 0); >>>> + if(count-- =3D=3D 0) { >>>> + sc->error =3D EDEADLK; >>>> + break; >>>> + } >>>> + } >>>> } >>>>=20 >>>> debugf(dev, "Done with msg[%d]\n", i); >>>=20 >>>=20 >>> cheers, >>> danny >>>=20 >>>>=20 >>>> BR >>>> Manuel >>=20 >> Could you test the patch I've just attached to >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 = please ? >>=20 >> It doesn't fix everything and I'm still working on doing test on a = lot >> of different boards but this is clearly needed. >>=20 >> --=20 >> Emmanuel Vadot > = > >=20 >=20 > short version: it works! >=20 > longer version: > first tried with debugging on - worked > next tried with no debugging- worked >=20 > the next test will take some time, trying my app. > if I feel up to it, i can try on a neopi neo2 - but that will take = longer. >=20 > thanks Manu!!!! >=20 not out of the woods yet :-( my app hangs the kernel. it=E2=80=99s now stuck in what seems waiting for an interrupt that never = comes =E2=80=A6 this is the debug: neo-001# iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 iichb0: twsi_reset: Using clock param=3D59 iichb0: TWSI_WRITE: Writing 0 to 18 iichb0: TWSI_WRITE: Writing 59 to 14 iichb0: TWSI_WRITE: Writing 40 to c iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 iichb0: twsi_reset: Using clock param=3D59 iichb0: TWSI_WRITE: Writing 0 to 18 iichb0: TWSI_WRITE: Writing 59 to 14 iichb0: TWSI_WRITE: Writing 40 to c iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_transfer: transmitting 2 messages iichb0: TWSI_READ: read f8 from 10 iichb0: twsi_transfer: status=3Df8 iichb0: TWSI_WRITE: Writing e4 to c iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 8 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Send the address(48) iichb0: TWSI_WRITE: Writing 48 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 18 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting the address (write) iichb0: twsi_intr: Sending byte 0 =3D 0 iichb0: TWSI_WRITE: Writing 0 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 1 =3D 0 iichb0: TWSI_WRITE: Writing 0 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 2 =3D ff iichb0: TWSI_WRITE: Writing ff to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 3 =3D 2 iichb0: TWSI_WRITE: Writing 2 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 4 =3D fe iichb0: TWSI_WRITE: Writing fe to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 5 =3D d4 iichb0: TWSI_WRITE: Writing d4 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 6 =3D 2 iichb0: TWSI_WRITE: Writing 2 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 7 =3D 2a iichb0: TWSI_WRITE: Writing 2a to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Sending byte 8 =3D 0 iichb0: TWSI_WRITE: Writing 0 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 28 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Ack received after transmitting data iichb0: twsi_intr: Done sending all the bytes for msg 0 iichb0: twsi_intr: Done TX data, send stop iichb0: TWSI_WRITE: Writing d4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts and here it hangs. reboot is necessary. > danny >=20 >=20 > _______________________________________________ > 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" From owner-freebsd-arm@freebsd.org Mon Jul 6 16:07:58 2020 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 B72DA36B498 for ; Mon, 6 Jul 2020 16:07:58 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0r7x6Dkzz4Dmf for ; Mon, 6 Jul 2020 16:07:57 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Mon, 06 Jul 2020 16:07:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1594051674; bh=NqCaPA8WjkMNVjEZ7PrDXDjj1gHq81VvZhhuozgkciM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=UmdHh/HTVFyEIZvVP2nGIjB6t8PBkEbxVAdwGM0evTKyDutP36n4QjAVrx2WzMLVC ZpWNKadVvsBoVBvr8h7yn8XnoQ5SPTeQtbdq4DfYw5aYstGNMR+6EDSd0/KW3tyC3r acCOwfieIshr0bfIN2DFJrnDePz+MsJY62XdDLnE= To: "greg@unrelenting.technology" From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> In-Reply-To: <8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology> References: =?us-ascii?Q?_=5F=5F=5F=5F=5F<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_____<8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology>?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B0r7x6Dkzz4Dmf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=UmdHh/HT; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.136 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.75 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.65)[-0.653]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.136:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.136:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:07:58 -0000 > > In the old firmware, under the Root Complex Nodes, `Output reference: 0= x30` points to the ITS Node > > with node offset 0x30. > > Then in the new firmware, under the Root Copmlex Nodes, `Output referen= ce: 0x48` points to the SMMU with node offset 0x48. > > Is this what you meant when you said everything is "behind the SMMU"? > > Yes. > > > What patches are we applying right now? I think some new builds would b= e good, including one with > > all the stuff we've fixed - like AHCI - but with the NXP PCIe code so I= can test on the old > > firmware. If I'm keeping track correctly, this includes: > > > > - D20835: enable tagged pointers > > - D20974: Port sbsawdt drive from NetBSD > > - D21017: armv8crypto: add AES-XTS support > > - D24423: arm/pmu: add ACPI attachment, more FDT names > > These are not directly related to running on NXP, just random improvement= s :) > > > - D25145: acpi_resource: support multiple IRQs > > - D25157: ahci_generic: add quirk for NXP0004 > > - D25179: acpi_iort: fix mapping end calculation > > Yes, these three. > > Here's the pci_layerscape patch: > > https://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b3dfeb1= 05d376.patch > > If we haven't tried it + acpi_iort fix before, which is quite likely, may= be that's a combination that would work. > (I remember when we tried it only, there was only the same interrupt prob= lem as usual..) > > It's honestly kinda weird that "old" FW requires the custom controller ac= cess while "new" FW requires not doing it >_< Any tips on where to add verbosity to dmesg during boot? You had a handful = of extras in there to print things things from the IORT. Also seeing that N= VMe hangs in nvme_ctrlr_start_config_hook, maybe we want to add some verbos= ity to sys/dev/nvme/nvme_ctrlr.c to see what it's waiting for? Also worth sharing, it looks like NXP's reference board also puts the root = complexes behind the SMMU, so that's coming from further upstream, not SR. https://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platform= s/tree/Platform/NXP/LX2160aRdbPkg/AcpiTables/Iort.aslc?h=3DLX2160_UEFI_ACPI= _EAR3 From owner-freebsd-arm@freebsd.org Mon Jul 6 17:00:33 2020 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 C73EB36C1CB for ; Mon, 6 Jul 2020 17:00:33 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (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 4B0sJc3GDJz4HkL for ; Mon, 6 Jul 2020 17:00:32 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1594054823; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HCsonnW2BUTt47pHkKkdduzi+J1nZhPGS4ne2j5LZnQ=; b=CCrXweoWK7w4NFKfnEvdTwkfeYfeO4FTn2BDs0PqTPN6K/ZAbK3Uk3jOovbqYISU/DQukw dRldUgeE5BugIvjXdek8cqLLxQ9CzTsu03KdhufQbYXx01VM6PaKC8cFJkKUejV+ZAnMLk bRzgRwEpOUC/uSYfemXmdoMO71S+aLk= Date: Mon, 06 Jul 2020 17:00:22 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" In-Reply-To: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> References: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> <8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 4B0sJc3GDJz4HkL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=CCrXweoW; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; NEURAL_HAM_LONG(-1.01)[-1.012]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.28)[-0.279]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:00:33 -0000 July 6, 2020 7:07 PM, "Dan Kotowski" wro= te:=0A=0A>> In the old firmware, under the Root Complex Nodes, `Output re= ference: 0x30` points to the ITS Node=0A>> with node offset 0x30.=0A>> Th= en in the new firmware, under the Root Copmlex Nodes, `Output reference: = 0x48` points to the SMMU=0A>> with node offset 0x48.=0A>> Is this what yo= u meant when you said everything is "behind the SMMU"?=0A>> =0A>> Yes.=0A= >> =0A>> What patches are we applying right now? I think some new builds = would be good, including one with=0A>> all the stuff we've fixed - like A= HCI - but with the NXP PCIe code so I can test on the old=0A>> firmware. = If I'm keeping track correctly, this includes:=0A>> =0A>> - D20835: enabl= e tagged pointers=0A>> - D20974: Port sbsawdt drive from NetBSD=0A>> - D2= 1017: armv8crypto: add AES-XTS support=0A>> - D24423: arm/pmu: add ACPI a= ttachment, more FDT names=0A>> =0A>> These are not directly related to ru= nning on NXP, just random improvements :)=0A>> =0A>> - D25145: acpi_resou= rce: support multiple IRQs=0A>> - D25157: ahci_generic: add quirk for NXP= 0004=0A>> - D25179: acpi_iort: fix mapping end calculation=0A>> =0A>> Yes= , these three.=0A>> =0A>> Here's the pci_layerscape patch:=0A>> =0A>> htt= ps://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b3dfeb105d= 376.patch=0A>> =0A>> If we haven't tried it + acpi_iort fix before, which= is quite likely, maybe that's a combination=0A>> that would work.=0A>> (= I remember when we tried it only, there was only the same interrupt probl= em as usual..)=0A>> =0A>> It's honestly kinda weird that "old" FW require= s the custom controller access while "new" FW=0A>> requires not doing it = >_<=0A> =0A> Any tips on where to add verbosity to dmesg during boot? You= had a handful of extras in there to=0A> print things things from the IOR= T.=0A=0AThat thing is here:=0Ahttps://github.com/freebsd/freebsd/blob/6ce= e1596c05e8a9ab64812444627b61c584ca6bc/sys/arm64/acpica/acpi_iort.c#L169= =0A=0A> Also seeing that NVMe hangs in nvme_ctrlr_start_config_hook,=0A> = maybe we want to add some verbosity to sys/dev/nvme/nvme_ctrlr.c to see w= hat it's waiting for?=0A=0A=0AWe know it's an interrupt.. everything is w= aiting for an interrupt. From owner-freebsd-arm@freebsd.org Mon Jul 6 20:47:16 2020 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 5BC9D348808 for ; Mon, 6 Jul 2020 20:47:16 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 4B0yLC1KP5z4Y1r for ; Mon, 6 Jul 2020 20:47:14 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jsY15-000OZM-Kf; Mon, 06 Jul 2020 13:47:07 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 066Kl734094447; Mon, 6 Jul 2020 13:47:07 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 6 Jul 2020 13:47:07 -0700 From: Oleksandr Tymoshenko To: Furkan Salman Cc: freebsd-arm Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 Message-ID: <20200706204707.GA94158@bluezbox.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Furkan Salman (furkan@fkardame.com) wrote: > Hello Peter, > > I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B0yLC1KP5z4Y1r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.59 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.25)[-0.254]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:47:16 -0000 Furkan Salman (furkan@fkardame.com) wrote: > Hello Peter, > > I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue then I am happy to help with testing. Hi Furkan, Yes, RockPi E seems to be a good test target. If you could check the GigE interface before and after the patch. Whether it works/doesn't work and if it works in both cases - try testing performance with iperf3, just to see if performance was affected in any way. Thanks -- gonzo From owner-freebsd-arm@freebsd.org Mon Jul 6 21:21:41 2020 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 9F53134932E for ; Mon, 6 Jul 2020 21:21:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0z5w0s9jz4ZfV for ; Mon, 6 Jul 2020 21:21:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: DF.zLGsVM1n.Hbg1p4eNDVJan8mGYNvsMrrR02EQVSKBvI7iylRZ7kDrmBBO8_E mCPz6QcG3ksBsd9T1lGjlB50P0of4_4DaA1Uld8fno1YIYdn8hbczc3e0SbNtPA4chysAhhs.JGT oI_Stci4ATZYDDoh7HsOodvykMHwjhtG3jWB8uEp92vYPva7boLsPiMWB9xrBGJEzU291c.dhbK7 q6yN6Z05vfsm1Qzj2daOoPEBDiCw0gYTp0cIznLY2gh4gimTyDox26vHKvx8lWs07NlZI3AVC_TM oSlvcdXR65BFAYBxpd4FOjeuau6Jp2h3a0E7fMWMZi9l1UXtfQtDZh.6ZfVvlXS53HvuPkcBYr7o VM5vY1H8PRXlnch.WhvPBizMJyzUwSpDSiyEFWX.1Nt2hco2EJbESKlHvnRcOXbrntz_4agizw0i FLQqBluy3KJt0FCafrNt.ZjDOXAaZlHOVUkz4yXCKqi7kYxXRGONFxyWxdE.295KZHSQHBA7XmS_ sPvZCnTH2IFVfi3P5Bv4Dk_.TwkzuaIU8VBwC7YBYQ8QXeaOUesLEFSB3ybMaUDpUQE62L9jRuam MQGxrN.iiRrHrGD4pLdQhXyy37zqrTg0NL2OVk8kTuWR9Ec0HBjR8T9qg7YSr1OtNbQDIkOmD3.R SdR6PvsHqSMn1xCbAaz8JYOhE5JJRhNJRVZ9wdkMEbMMKRbF7jqLm9OWSF4au5B4feCP4dNlbSX7 RO3x96q0PFi9JVswLgeZYJCUq6BHemqcmr4zF0T_qPn93T5miedvuoBHd99uX5HWcvMCHH9JTmB4 1M2e_f3bOVDfVIneotBG0j5ELao98KdcRPocyZxJcXGzRTvSXVmJbMI3hy59zcesxpITS7rQC6kY LivwZleMwU93xTcB.zSbcKmxXxwxG.USvxCAHlq4_GT9F7Jyv0DRuyNxZHQpGGqqPrLypVUpLZ8W xmhoujQbHN5KI0YNWxCiYFDJiA9YwtKKymFug8Y.qorL0LLUF08ouix.oI8kuydpUs2aSYbOeiNk mbT4tJVqHSD8xXRkAuhIaCmYoM4FeYGi7lA6kpzlSZNNG2uFirHf51S1S9KhIjYEwmf9a2Yw3bh6 YOdKfUqrdIOmAJgn18HZpuorYhV10OsxXhvGLHIq2efOS2I.5o3rA8viERE6b8hiog91hkNUqeZ8 dKvy9JN1JoRi9GNEG_N2YeEYWp.3lM6AmKHgwoaeyKKUNCOJe_ejyyLsQU456NC6GUD2LfnQrTiT 0jBCbnK7.mPDT2u_FFUwLH6gwHict9lX9XjHUbBazbJ2WYwVocHvJYPY0Aj_NnjTxLoO5bEfB8JL 2xtzsvd4HbQ8UwuOjUcWbMsEvaJNSmEAPNJboSJAWSA57l69foezbi3NHK6x0e8jc4www2w2_OQ0 yl9xJOyKuyFST_A8vDeapnm6xGl82DhejdHw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Jul 2020 21:21:38 +0000 Received: by smtp426.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0b7a9d525dc00f2fa59845623c75287e; Mon, 06 Jul 2020 21:21:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 From: Mark Millard In-Reply-To: <20200706204707.GA94158@bluezbox.com> Date: Mon, 6 Jul 2020 14:21:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B0z5w0s9jz4ZfV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.95 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.01)[-1.007]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; NEURAL_HAM_SHORT(-0.46)[-0.460]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 21:21:41 -0000 On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko = wrote: > Furkan Salman (furkan@fkardame.com) wrote: >> Hello Peter, >>=20 >> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ = or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue = then I am happy to help with testing. >=20 >=20 > Hi Furkan, >=20 > Yes, RockPi E seems to be a good test target. If you could check the > GigE interface before and after the patch. Whether it works/doesn't = work > and if it works in both cases - try testing performance with iperf3, > just to see if performance was affected in any way. For folks not familiar with the general type of activity or specifically with iperf3 (or other specifics), more detailed information to "collect and report . . ., collecting the information via the commands . . ." could help: more step-by-step. Also: Do you care between debug kernels vs. non-debug kernels? Debug ones of the appropriate vintage for head are available via artifacts.ci.freebsd.org but there might be performance consequences to using such. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 7 05:12:38 2020 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 B331F355BF9 for ; Tue, 7 Jul 2020 05:12:38 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 4B19YK5WxKz44lV for ; Tue, 7 Jul 2020 05:12:37 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jsftz-0004aG-V6; Mon, 06 Jul 2020 22:12:36 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 0675CJaS017623; Mon, 6 Jul 2020 22:12:19 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 6 Jul 2020 22:12:18 -0700 From: Oleksandr Tymoshenko To: Mark Millard Cc: freebsd-arm Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 Message-ID: <20200707051218.GA16838@bluezbox.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Mark Millard (marklmi@yahoo.com) wrote: > > > On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko wrote: > > > Furkan Salman (furkan@fkardame.com) wrote: > >> Hello Peter, > >> > >> [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B19YK5WxKz44lV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.48 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.21)[-0.214]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 05:12:38 -0000 Mark Millard (marklmi@yahoo.com) wrote: > > > On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko wrote: > > > Furkan Salman (furkan@fkardame.com) wrote: > >> Hello Peter, > >> > >> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue then I am happy to help with testing. > > > > > > Hi Furkan, > > > > Yes, RockPi E seems to be a good test target. If you could check the > > GigE interface before and after the patch. Whether it works/doesn't work > > and if it works in both cases - try testing performance with iperf3, > > just to see if performance was affected in any way. > > For folks not familiar with the general type of activity > or specifically with iperf3 (or other specifics), more > detailed information to "collect and report . . ., collecting > the information via the commands . . ." could help: more > step-by-step. Good idea. To test inteface performance you need two instances of the iperf3 program: server and client. Server can be FreeBSD, Linux, or macOS machine, shouldn't matter. Should be connected to the wired network though, as close to the board as possible, to make sure we're testing the board's interface and not the narrowest link between client and server. On the server machine install iperf3 package and run iperf -s On the board run iperf3 -c . This is normal mode: client sends as much data as possible and server receives, so the results are TX speed. Output should look like this: Connecting to host 192.168.10.1, port 5201 [ 5] local 192.168.10.117 port 56650 connected to 192.168.10.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 55.3 MBytes 464 Mbits/sec 0 403 KBytes [ 5] 1.00-2.00 sec 54.6 MBytes 458 Mbits/sec 0 567 KBytes [ 5] 2.00-3.00 sec 54.2 MBytes 455 Mbits/sec 0 692 KBytes [ 5] 3.00-4.00 sec 54.0 MBytes 453 Mbits/sec 0 798 KBytes [ 5] 4.00-5.00 sec 54.1 MBytes 454 Mbits/sec 0 892 KBytes [ 5] 5.00-6.00 sec 54.5 MBytes 457 Mbits/sec 0 927 KBytes [ 5] 6.00-7.00 sec 54.5 MBytes 457 Mbits/sec 0 927 KBytes [ 5] 7.00-8.00 sec 54.7 MBytes 459 Mbits/sec 0 929 KBytes [ 5] 8.00-9.00 sec 54.7 MBytes 459 Mbits/sec 0 929 KBytes [ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec 0 929 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec 0 sender [ 5] 0.00-11.15 sec 545 MBytes 410 Mbits/sec receiver To test RX speed run "iperf3 -R -c ". -R is for reverse mode: server sends and client receives. The output format is simmilar: root@:/ # iperf3 -R -c 192.168.10.1 Connecting to host 192.168.10.1, port 5201 Reverse mode, remote host 192.168.10.1 is sending [ 5] local 192.168.10.117 port 36908 connected to 192.168.10.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 18.7 MBytes 156 Mbits/sec [ 5] 1.00-2.01 sec 8.31 MBytes 69.0 Mbits/sec [ 5] 2.01-3.01 sec 18.3 MBytes 154 Mbits/sec [ 5] 3.01-4.00 sec 20.3 MBytes 171 Mbits/sec [ 5] 4.00-5.01 sec 9.92 MBytes 82.6 Mbits/sec [ 5] 5.01-6.00 sec 20.3 MBytes 171 Mbits/sec [ 5] 6.00-7.01 sec 11.4 MBytes 95.5 Mbits/sec [ 5] 7.01-8.00 sec 22.3 MBytes 188 Mbits/sec [ 5] 8.00-9.00 sec 20.8 MBytes 174 Mbits/sec [ 5] 9.00-10.00 sec 20.2 MBytes 170 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-11.00 sec 171 MBytes 130 Mbits/sec 1789 sender [ 5] 0.00-10.00 sec 170 MBytes 143 Mbits/sec receiver As you can see, download on my Firefly-RK3399 is much slower and high number of Retr indicates either packet corruption or packets dropped. > Also: Do you care between debug kernels vs. non-debug > kernels? Debug ones of the appropriate vintage for head > are available via artifacts.ci.freebsd.org but there > might be performance consequences to using such. TX speed difference between GENERIC-NODEBUG and GENERIC on the Firefly is ~40%, so I'd prefer results for NODEBUG, but even with DEBUG kernel it'd be nice to know if there is any effect of the commit. -- gonzo From owner-freebsd-arm@freebsd.org Tue Jul 7 06:03:50 2020 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 527EE356767 for ; Tue, 7 Jul 2020 06:03:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1BhP1yYFz46vR for ; Tue, 7 Jul 2020 06:03:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: lHlIsQ4VM1nbJyKCc_Z0I9bZIWViuwMdKVmEK5fmzWyAvRLpVUg6Y3HFRbl4hya sp41VoeqXxBmelJNsGz6ZroUAH0jfiv0lY2uoMOHX1Ty3O.VsNVM1bDDObkuaxRpRWBN6RyjWyAb VsgqOEi.NRE28EZ_oVxGo1ZU.ihqdxx.JrMWb5e9xRPR.OlXpqfVn.Ssj7nxZcnx2dArCSUoP5ts W2Dq_pnvUtOtHW5bsr5OHYA9GA76LR.MmgZncCPxgrlSVDPSGnjfXpn5n_eoE4sW_bhsIzHKc8lL YYb0qs8M.myWBFOAHj2Zb_0qdOboiz3YPdlO6WQD8SOyLiWbUI9e6opnMWjAxjEeziUYkOys5kGi 5NZlCc_50WSrtvPwpttwRtG10u7PniHYbKMzuVJCijVDaefaCuKVu18A.tSLnDXjALM8uddicXx0 yR92WWShXkCR__ISeRShqgLPu6NuRk3TjelWSLCOYntFDlm7EGD7RfAiguexGaz1qKoPt..Rkuud SnbD5N.OwkZ2aGVYO403CXB.v1SG_wS3ClQTrjhqcAlDqxV9R7MKikooBX_QNGwyL5TJODtlgKUD d9I9RenAwj7rUDfA6h3tqvtuBxU5g5QlPYJ9EZ1dNVr6HWyW_oLrpukaLYT78lBGxUGtxNf4.QAl blkxVb51yy3uzkoWxJdzRLjYMXrDtxuzC322kz0ZhoaHZ.yaITCRbH6O4NbZcmtaSI9FDOP17JXb 4NutZUay_LFDHE24mdmyyQk8EnIVzVnbRS83YrtDk8.RrJHY2WfZBDf.SifsuWt_mVvESrI6fQoG nnGg.x7EGQ1sHtLEkhcQUB7DyOnptLaHfKY5.XjWP25vWxWhC5ea_2zmhsgfDMrQ5v4tn0c7MMtv lZ5xRR3JNoeMsUl9lewd_cN6Rs33Pcq7xZIf5H1MR6onYsh_b3aCcMe9OEYNiIHQ8Nu9UDkuP5Ct df8uBKk5CPbdLMgkBnChBjYIyi7.Zp_InS8cz6M3adcceeNVsSbR62ksEiWfqWf9esfAnLJ5TDQB QaB9X6Tf0378ONfwjBHMciEkyznqgDee6kn4ihT.A6c4xzlbMKQuFuNH6DUYtM7xVkaenHJXGyfP Ei3mtjuWrDljwV9_xFK9P33yqCLhGXBkY5pe4LZ8i1x1ms4mZmOmiUu3tQHVkajRpxr1c6U3XVfx fuXzcNgHBQGQ.dhzj7qYU50NqgW2Cnu4qpbiURyCwVw7hz0N.9WINHtWGwLNmBp1_1LSpjvYeR0T iMxwOJHPbmDXyT2l2C0icoN_Kq5ZvbtvVKN1TLkKuj1zlSeurh9OKXf2Fu1IoMG0AZxqxeYpdfFK .M3ZlIt_nX7qWKP60mWOqj1YZpfc9qKN9JCqF_BU5AjOqn7Yr2WuyV9naFZQBxd5RjQpJUewPczR Yl1warrTqnK8nsisDyw2CfhliGUnecdNto82T9kvcjIb0hr0xM19dE7CbuU8Ti0taUfuTP0p94df qPy5s28glK5FD Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 Jul 2020 06:03:47 +0000 Received: by smtp429.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 458a54fcb17147c667bc096217e66520; Tue, 07 Jul 2020 06:03:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> Date: Mon, 6 Jul 2020 23:03:42 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> To: Oleksandr Tymoshenko , peterz@rulingia.com X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1BhP1yYFz46vR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.47 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; NEURAL_HAM_SHORT(-0.98)[-0.985]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:03:50 -0000 On 2020-Jul-6, at 14:21, Mark Millard wrote: > On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko = wrote: >=20 >> Furkan Salman (furkan@fkardame.com) wrote: >>> Hello Peter, >>>=20 >>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ = or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue = then I am happy to help with testing. >>=20 >>=20 >> Hi Furkan, >>=20 >> Yes, RockPi E seems to be a good test target. If you could check the >> GigE interface before and after the patch. Whether it works/doesn't = work >> and if it works in both cases - try testing performance with iperf3, >> just to see if performance was affected in any way. >=20 > For folks not familiar with the general type of activity > or specifically with iperf3 (or other specifics), more > detailed information to "collect and report . . ., collecting > the information via the commands . . ." could help: more > step-by-step. >=20 > Also: Do you care between debug kernels vs. non-debug > kernels? Debug ones of the appropriate vintage for head > are available via artifacts.ci.freebsd.org but there > might be performance consequences to using such. I put a copy of the -r362982 *debug* kernel from artifacts.ci.freebsd.org on the Rock64 V2.0 that I sometimes have access to. There are no hardware mods to the Rock64 V2.0. It did DHCP to pick up an address just fine during the boot. I ssh'd into it just fine after the boot. # uname -apKU FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue = Jul 7 03:41:02 UTC 2020 = root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64= .aarch64/sys/GENERIC arm64 aarch64 1300100 1300092 # ifconfig dwc0: flags=3D8843 metric 0 mtu = 1500 options=3D80008 ether # hwaddr # inet # netmask # broadcast # media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D29 . . . I'll note that the Rock64 is the only thing running a debug kernel for this note. An rsync copying an approximately 4 GiByte tar file to the Rock64 reported: # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) I'll note that at times it listed over 32MB/s. The storage media is a USB3 SSD plugged into the USB3 port. It has the Rock64's root filesystem. For reference, locally duplicating the file on the Rock64 via rsync reported: # rsync -axHh --info=3Dprogress2 -r = /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) (from/to: same media). I do not expect that the rsync over the network was limited by the target media on the Rock64. Copying from the same machine to a large, fast machine instead of to the Rock64: # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) So that should not be the side constraining the to-Rock64 rate. Copying from the Rock64 to the large, fast machine: rsync -axHh --info=3Dprogress2 --delete -r = /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) It did not list figures much higher than above, so slower than the copy to the Rock64 fairly generally. All this activity is over the local network, nothing remote. All machines were running head -r360311 (non-debug), except for the Rock64 having the -r362982 *debug* kernel instead.=20 I hope that the above helps. I see that there are now iperf3 usage instructions so at some point I may get that going and report the results, including doing a non-debug kernel build and install. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 7 06:22:22 2020 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 D9EE93571A2 for ; Tue, 7 Jul 2020 06:22:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1C5p0B81z47Rx for ; Tue, 7 Jul 2020 06:22:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZD1pQlcVM1k3nTQp4YXAo2bSlAcctui7VO1wzF0g9J42ELW2Ilq7.5BJwzZySzI pLiX.4i4vv5WbZsk.CpqfHqrpn0MFZdJ3cXl8Y_VL8MRZZp0bJQ6LtnyOP.SxWkWgQf9sf1pEVNK Xg47cVT1sAVoO2ya6yK0UcLtYuTTqZPfsjXnp2gQviQPB3Gt_GuLiqB2QuHsaSVC42OpR2YmPsBQ lC_4qY0vlz80GjDOsThjVrhMidx5oGmlqFdq8dPJ0lk3TCcbQ63YlV9iQAgdLNjZNWITb8Ng3xym yfFR2j3DQPveRBeY50QYiSAOcKXmy..eCFdbvriWpJwzh2oyiV92qCkY4LKAw5owypoeQGTCW2IO UvlWnBP1YX7DuioQRwpMh3bKzPVtdKBi1V75ru8vb3zuN90SeTQjGbS2fflQ1qlthU.NONyhp7X2 LLPh1gutlBEEXTmWBdQafQWiuaADDY1p3qmsdw5.BBOM9WDqIMWBjh4X6rwyCA7NDHA8vTG59Wns fL6xq9RdPIWRpEPinYsqO6zAZ2zxcaxnVbCyAOPwaXa_uMfHVii7z9Veaf6lp6Qc81wfP7R8zpK_ qS4rV.pQCpcvZKqTZDWAh52mqnUlPwcmd5MgS7BvAeL6ft_ecsSeRxH0n3C67OpwZGx5s7_x93IB nZZaHzlP_xrzNlrlFWu9qKv0wrjHB76I6c.EJsmcYYFAsLXvJE5D0U6mDU8u2MaSB5AGePFb_ArT QlAqVjruCKOa0VEWsDYck3Rm94vYhvxV8j8kmhUs_zx9an25i1d0TP.aYdFn8NrEoXhlON22iFp. pi27gcBB4WV3nD3Q0ZxbLEvuxlYoZ6R1BgsqBuylgTZZ8daQyWExmD_5IxGRKaseQrJFzEkX_H4J hYRzIef81n6Ojhgmq8d_FnczcF9VyJ34dPOzuHrqBp.oggJVsD2y2Bu0TObe6TIeDhcj5tNzPqjb xn9c7jqGz3abtAcA8.EMhmRSnbvPpuoyjdaZCHAe6GuOqPYvHvbxRnoj.AuLKHsZ3jwLtpZzfp7l QFfeYZ58o7pcTwHBkZRse1MfaQ4mSWiaV_bmnWL_A4ffu_W4I48s1V.zioNF3m6JN.bsLBU_z8Na t1V9NqBs9IDND595QrEQ4mQ3ZHExGVI9hJP.S5yDDBf3osmycly9r_M50mxA86SXpb606cajXRRV lIRBN119_zXYS9pB5eQ4rbSpDogBreyDj2JMGv7ryvebNThwB949N6eVvwyVy127j1_TOTbxjLuZ iB5RC0drHtSXN.RGz0m8TfciEcuRHGEANazdc6lYVN0f0p0uxPSe9lH4zFW21Bk9Rh3O3HfF7z_p 84juRaBlMCRLWh4VUIVm07w_dANPQvGqAFyKmJKjew_0tg7KBx8Al.9Tcos2AYiEnLK_axYKGaNK csEapk1FEvOtnAKWf1DyK8fKYeFXJbrPv8oQjaru5dk998uaq Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 Jul 2020 06:22:20 +0000 Received: by smtp416.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 04ec35c2a316ad91fd103c59f3b25d9a; Tue, 07 Jul 2020 06:22:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> Date: Mon, 6 Jul 2020 23:22:18 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> To: Oleksandr Tymoshenko , Peter Jeremy X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1C5p0B81z47Rx X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; NEURAL_HAM_SHORT(-0.89)[-0.889]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:22:22 -0000 On 2020-Jul-6, at 23:03, Mark Millard wrote: > On 2020-Jul-6, at 14:21, Mark Millard wrote: >=20 >> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko = wrote: >>=20 >>> Furkan Salman (furkan@fkardame.com) wrote: >>>> Hello Peter, >>>>=20 >>>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ = or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue = then I am happy to help with testing. >>>=20 >>>=20 >>> Hi Furkan, >>>=20 >>> Yes, RockPi E seems to be a good test target. If you could check the >>> GigE interface before and after the patch. Whether it works/doesn't = work >>> and if it works in both cases - try testing performance with iperf3, >>> just to see if performance was affected in any way. >>=20 >> For folks not familiar with the general type of activity >> or specifically with iperf3 (or other specifics), more >> detailed information to "collect and report . . ., collecting >> the information via the commands . . ." could help: more >> step-by-step. >>=20 >> Also: Do you care between debug kernels vs. non-debug >> kernels? Debug ones of the appropriate vintage for head >> are available via artifacts.ci.freebsd.org but there >> might be performance consequences to using such. >=20 > I put a copy of the -r362982 *debug* kernel from > artifacts.ci.freebsd.org on the Rock64 V2.0 that > I sometimes have access to. There are no hardware > mods to the Rock64 V2.0. >=20 > It did DHCP to pick up an address just fine during > the boot. I ssh'd into it just fine after the boot. >=20 > # uname -apKU > FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue = Jul 7 03:41:02 UTC 2020 = root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64= .aarch64/sys/GENERIC arm64 aarch64 1300100 1300092 >=20 > # ifconfig > dwc0: flags=3D8843 metric 0 = mtu 1500 > options=3D80008 > ether # > hwaddr # > inet # netmask # broadcast # > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=3D29 > . . . >=20 > I'll note that the Rock64 is the only thing running a debug > kernel for this note. >=20 > An rsync copying an approximately 4 GiByte tar file to the Rock64 > reported: >=20 > # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >=20 > 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) >=20 > I'll note that at times it listed over 32MB/s. The storage media > is a USB3 SSD plugged into the USB3 port. It has the Rock64's > root filesystem. >=20 > For reference, locally duplicating the file on the Rock64 via > rsync reported: >=20 > # rsync -axHh --info=3Dprogress2 -r = /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar > 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) >=20 > (from/to: same media). I do not expect that the rsync over the > network was limited by the target media on the Rock64. >=20 > Copying from the same machine to a large, fast machine instead > of to the Rock64: >=20 > # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) >=20 > So that should not be the side constraining the to-Rock64 > rate. >=20 > Copying from the Rock64 to the large, fast machine: >=20 > rsync -axHh --info=3Dprogress2 --delete -r = /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) >=20 > It did not list figures much higher than above, so slower than > the copy to the Rock64 fairly generally. >=20 > All this activity is over the local network, nothing remote. > All machines were running head -r360311 (non-debug), except > for the Rock64 having the -r362982 *debug* kernel instead.=20 >=20 > I hope that the above helps. >=20 > I see that there are now iperf3 usage instructions so at some > point I may get that going and report the results, including > doing a non-debug kernel build and install. >=20 Still using the debug kernel, but I figured I'd show the results from proving that I can get iperf3 to do the requested type of testing: # iperf3 -c 192.168.1.122 Connecting to host 192.168.1.122, port 5201 [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 KBytes = =20 [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 KBytes = =20 [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 KBytes = =20 [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes = =20 [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes = =20 [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 KBytes = =20 [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 KBytes = =20 [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 KBytes = =20 [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes = =20 [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 = sender [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec = receiver # iperf3 -R -c 192.168.1.122 Connecting to host 192.168.1.122, port 5201 Reverse mode, remote host 192.168.1.122 is sending [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec =20 [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec =20 [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec =20 [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec =20 [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec =20 [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec =20 [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec =20 [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec =20 [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec =20 [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 = sender [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec = receiver I'll note that I run with the following in /etc/sysctl.conf : # The Rock64 does not seem to automatically adjust from 600MHz, # so do so manually. (The specifics likely would not be # appropriate to the RPi4/3.) dev.cpu.0.freq=3D1200 It is a historical artifact that I've not checked on the status of in a very long time: it works so I leave it there. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 7 06:43:14 2020 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 7F31F3574C3 for ; Tue, 7 Jul 2020 06:43:14 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1CYs4GcGz488q for ; Tue, 7 Jul 2020 06:43:13 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-pg1-x530.google.com with SMTP id o13so16577751pgf.0 for ; Mon, 06 Jul 2020 23:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wIEgOi6B/qCIajRPdBGhEdnTbh6SYsf02FDAFQ0iUaI=; b=sJTl4GHEhx/gWdq1orbPWS6vpy6fP/gG11q2duCdseTsTTOwc8tjT5szuXmYerfp5u cKIB4EGLpnbZk1NMmqnV6hsO/wmf17aosU+RHsSTKu5NSEhbY4dWjoyvEKj8gLkmPEHQ qhgZlzfvjlfqfrAKJtHP70hSJedMkfK/t3VI01JDaHtRtAGZ0TgX7aKhhTWR3S7nPcpG j9m0YkdOrqtKno4ia8Dt1CktRBFVXea6rCeAENBrzUUDzxQCvNAtx/5ifC2HF2486Y52 iQaDbFQyKaa1O6U9BOjR+ejrSCu3FlS6saSFHESgYc316cogY9CSkuG8PdVAqJ50hEi6 pajA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wIEgOi6B/qCIajRPdBGhEdnTbh6SYsf02FDAFQ0iUaI=; b=JHWMlJdcblTQHZG6opz5X/kNilLTt9J9I/ActSeMCxcjjhm8m9RLRXTOF3T/N4kEMh i/+02DCQ719HRL2a4IXuWYogYRXFL/1wEvQivCMIVKBDqe0fxNnMJ7ZRdAHr+QSQfdfB 5rLIMMPGGsPHZSs4Fi136xgtDuEJ7+XSAbSjCqDpTkpU+49HVqcmCFlLDe1XtPiFU6Xi qHz1W8W73VSYOaE3H+DMWRQC8bIjlEmqtFyPvaLsov1VKsiPj6ktMXSX5HXlt7V913cJ PmvpwINUcsU7NFZhMi1vIJxHDAVas3+VlZBt264X7g21xnvsGgvLoLRXgM4llu/8Afc0 hB0g== X-Gm-Message-State: AOAM5323KJ1SBr5qcfHYMbw55ypZ2isYq1vYFW0zh7YI7RAHcgL8ctka mze8TMbz80R5QR13LGN987yN1P5j153ZXk2F1NE= X-Google-Smtp-Source: ABdhPJy+khGmErjth9Qz2sXSReQ40UmYrTLALVTHEKVUUbYmJaIs1NteqiblmtWVIod8rdsrH+gHrGRqEoQjlo+/4l0= X-Received: by 2002:a63:e008:: with SMTP id e8mr36921115pgh.50.1594104191429; Mon, 06 Jul 2020 23:43:11 -0700 (PDT) MIME-Version: 1.0 References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> In-Reply-To: From: Sleep Walker Date: Tue, 7 Jul 2020 09:42:51 +0300 Message-ID: Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) To: Mark Millard Cc: Oleksandr Tymoshenko , Peter Jeremy , freebsd-arm X-Rspamd-Queue-Id: 4B1CYs4GcGz488q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=sJTl4GHE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.005]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::530:from]; NEURAL_HAM_SHORT(-1.02)[-1.020]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:43:14 -0000 Hi! On NanoPC-T4 root@nanopc-t4:~ # uname -aUK FreeBSD nanopc-t4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362798M 0fb6ad5-c996(nanopi): Mon Jul 6 10:38:48 MSK 2020 root@dev.kubsu.ru:/usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/= sys/FREENAS arm64 1300100 1300100 root@nanopc-t4:~ # sysctl dev.cpu.0.freq dev.cpu.0.freq: 1416 root@nanopc-t4:~ # iperf3 -c 192.168.1.100 iperf3: error - unable to connect to server: Connection refused root@nanopc-t4:~ # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 65449 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 60.6 MBytes 509 Mbits/sec 0 418 KBytes [ 5] 1.00-2.00 sec 60.0 MBytes 504 Mbits/sec 0 592 KBytes [ 5] 2.00-3.00 sec 59.8 MBytes 501 Mbits/sec 0 724 KBytes [ 5] 3.00-4.00 sec 59.8 MBytes 501 Mbits/sec 0 835 KBytes [ 5] 4.00-5.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 5.00-6.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 6.00-7.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 7.00-8.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes [ 5] 8.00-9.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes [ 5] 9.00-10.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 599 MBytes 502 Mbits/sec 0 sende= r [ 5] 0.00-10.34 sec 599 MBytes 486 Mbits/sec receiver iperf Done. root@nanopc-t4:~ # iperf3 -R -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 57851 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 3.99 MBytes 33.1 Mbits/sec [ 5] 1.01-2.01 sec 3.78 MBytes 31.6 Mbits/sec [ 5] 2.01-3.01 sec 4.86 MBytes 40.9 Mbits/sec [ 5] 3.01-4.01 sec 2.19 MBytes 18.4 Mbits/sec [ 5] 4.01-5.00 sec 2.78 MBytes 23.4 Mbits/sec [ 5] 5.00-6.00 sec 6.57 MBytes 55.3 Mbits/sec [ 5] 6.00-7.00 sec 4.15 MBytes 34.8 Mbits/sec [ 5] 7.00-8.01 sec 3.42 MBytes 28.2 Mbits/sec [ 5] 8.01-9.01 sec 5.13 MBytes 43.2 Mbits/sec [ 5] 9.01-10.00 sec 2.26 MBytes 19.2 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.33 sec 39.2 MBytes 31.8 Mbits/sec 1276 sender [ 5] 0.00-10.00 sec 39.1 MBytes 32.8 Mbits/sec receiver iperf Done. root@nanopc-t4:~ # iperf3 -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 60441 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.018 ms 0/898 (0%) receiver iperf Done. root@nanopc-t4:~ # =D0=B2=D1=82, 7 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 09:22, Mark Millard= via freebsd-arm < freebsd-arm@freebsd.org>: > On 2020-Jul-6, at 23:03, Mark Millard wrote: > > > > On 2020-Jul-6, at 14:21, Mark Millard wrote: > > > >> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko > wrote: > >> > >>> Furkan Salman (furkan@fkardame.com) wrote: > >>>> Hello Peter, > >>>> > >>>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ > or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue > then I am happy to help with testing. > >>> > >>> > >>> Hi Furkan, > >>> > >>> Yes, RockPi E seems to be a good test target. If you could check the > >>> GigE interface before and after the patch. Whether it works/doesn't > work > >>> and if it works in both cases - try testing performance with iperf3, > >>> just to see if performance was affected in any way. > >> > >> For folks not familiar with the general type of activity > >> or specifically with iperf3 (or other specifics), more > >> detailed information to "collect and report . . ., collecting > >> the information via the commands . . ." could help: more > >> step-by-step. > >> > >> Also: Do you care between debug kernels vs. non-debug > >> kernels? Debug ones of the appropriate vintage for head > >> are available via artifacts.ci.freebsd.org but there > >> might be performance consequences to using such. > > > > I put a copy of the -r362982 *debug* kernel from > > artifacts.ci.freebsd.org on the Rock64 V2.0 that > > I sometimes have access to. There are no hardware > > mods to the Rock64 V2.0. > > > > It did DHCP to pick up an address just fine during > > the boot. I ssh'd into it just fine after the boot. > > > > # uname -apKU > > FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue > Jul 7 03:41:02 UTC 2020 > root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm= 64.aarch64/sys/GENERIC > arm64 aarch64 1300100 1300092 > > > > # ifconfig > > dwc0: flags=3D8843 metric 0 mtu > 1500 > > options=3D80008 > > ether # > > hwaddr # > > inet # netmask # broadcast # > > media: Ethernet autoselect (1000baseT ) > > status: active > > nd6 options=3D29 > > . . . > > > > I'll note that the Rock64 is the only thing running a debug > > kernel for this note. > > > > An rsync copying an approximately 4 GiByte tar file to the Rock64 > > reported: > > > > # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > > > 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) > > > > I'll note that at times it listed over 32MB/s. The storage media > > is a USB3 SSD plugged into the USB3 port. It has the Rock64's > > root filesystem. > > > > For reference, locally duplicating the file on the Rock64 via > > rsync reported: > > > > # rsync -axHh --info=3Dprogress2 -r > /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar > > 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) > > > > (from/to: same media). I do not expect that the rsync over the > > network was limited by the target media on the Rock64. > > > > Copying from the same machine to a large, fast machine instead > > of to the Rock64: > > > > # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) > > > > So that should not be the side constraining the to-Rock64 > > rate. > > > > Copying from the Rock64 to the large, fast machine: > > > > rsync -axHh --info=3Dprogress2 --delete -r > /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) > > > > It did not list figures much higher than above, so slower than > > the copy to the Rock64 fairly generally. > > > > All this activity is over the local network, nothing remote. > > All machines were running head -r360311 (non-debug), except > > for the Rock64 having the -r362982 *debug* kernel instead. > > > > I hope that the above helps. > > > > I see that there are now iperf3 usage instructions so at some > > point I may get that going and report the results, including > > doing a non-debug kernel build and install. > > > > Still using the debug kernel, but I figured I'd show > the results from proving that I can get iperf3 to do > the requested type of testing: > > # iperf3 -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 KBytes > > [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 KBytes > > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 KBytes > > [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 KBytes > > [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 KBytes > > [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 KBytes > > [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 > sender > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec > receiver > > # iperf3 -R -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > Reverse mode, remote host 192.168.1.122 is sending > [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec > [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec > [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec > [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 > sender > [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec > receiver > > I'll note that I run with the following in /etc/sysctl.conf : > > # The Rock64 does not seem to automatically adjust from 600MHz, > # so do so manually. (The specifics likely would not be > # appropriate to the RPi4/3.) > dev.cpu.0.freq=3D1200 > > It is a historical artifact that I've not checked on the > status of in a very long time: it works so I leave it > there. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Tue Jul 7 06:44:06 2020 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 E052C3574D5 for ; Tue, 7 Jul 2020 06:44:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1CZs5v4cz4875 for ; Tue, 7 Jul 2020 06:44:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5SEo1b0VM1n0h5o56u6piHqKQpd6Rz8ZCWqyMehq1dnGZzs9zCQGRfUR7HsAs07 p3T1EegRYpIvqY8AyYQRClVa9D8cRS.kaxgsu7qvAeYP.MnrXinPHsnuWMxUTwCvIw72_VCcdg4S l69fTrYkqrnm_t3kr6NL07uVQ50K7962SEKS1jZN2gluanIxGUbCIq4rN.mIwoAMLY5uC.Ac_ggW 0r0FeC46G62Stc15f6iD.nOmp.XwYDNlkXhkGQZ5Ti5o5rudDfxIlD_rFd2une1DEn.Tmllb_FeI ysgqoOMCZVWEB9mg1skR1f.WnTUu9Saf.kupPLLoPqgPN3qqPkqTypNCuIJQypS3A30bygO3Gn51 Ba7xmVUSNItH.ItBaGcfmPICxH_qgQFAGU.AIsskNMfuh0.7s_4YYAzuA5ImygC.jCaSegSazMzU SHLCn_y8fT6Ek5eEq81XWuTH5xLYx5txQz6wPKAftPgdp1leD.R1UmZK54wMBwmE2FKh_JqyHwh6 Heu7MCURHOVm2v7i05mBMSLtwb_ZxScwU9aukBdQvnu.yD5DUly8daeOxGMuyYJIvAtbwop4unMl hJ2waYpNsLDgvkqUXARImW3BwDAoGM1yF1tKKaAi_Jyt8rQWgkyNAjdF8vWc1_HjGdVKy5S30o1R rHVd9IrblUs5nVqgVTPiCrudwcmuMx7hDGzfwAPfonlG0asYA2HOY1PU2fASYz3P6mrDsrrbHDWH WWa3ZE8Hm1AQuH6zRt4uQF7JHBI4031VN0SGBTxaFkdNUnQe024txnsLL8CoA7341N97gKXWGrzM pE6dZNnah.Ti.9DqNzD7W9BaN0nvyDEHP33cbe7HshyzLpFJWKAHVm7QW_F3uTudwPtEkMiCWEpL HtnPVjWvMt3VBb2LzZUr9AkQWyavLUY_uXVhD36P5wQlKE2IAc30plYr2h13XEtHlLaX1hrSBhfb s0zoUY4DmPEaxL0dOZ6dmUZYLTQ.AEJtwBUT7mBVckCyn7GeG8i4WgmZtv_oq7K7kAiJj8oGW6FV cwPFwhvC_j5XeQD89Eve95JhLtLlqvqKt_Mga7jpBOR8sjzPvrogq6f6hXfsB1D7r1zbX3Ni5UMA cdu26YkJwMg8220l1MeEwjJz064dPttn.RmjDzXemWA.29ehOGGAvyE4aC0u_dhjHYCsmBSokiQz 0lwI2EheQwLBuQeNix46K2gE5DGqxO35MXIf92x8WBrKJl.JAva.BL7.GuRiWmQFS.BVn_Y5Bauf YcWuRk4k3j_jx2Rh5kMqQU0wtpMhjhcGG_EPfnGf6XCvlX4GE_Av8eOAN2qZyBda2EkGL_.RX2.f TpzG1XT5mCQ7e.w.B_1Q4rU3Qi9nQNiMGZblMEtrOmHHRVizpt5X6T1D8uHGcRK5iV5FrY1ZktnY rMPiWZLk6LVQk6pOOnSZGJhN7WFMQHuTOggRSsVcgnbYpiWIj Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 Jul 2020 06:44:02 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e9349ee6ad9b847e386dd754cd8fca37; Tue, 07 Jul 2020 06:44:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: Date: Mon, 6 Jul 2020 23:43:59 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> To: Oleksandr Tymoshenko , Peter Jeremy X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1CZs5v4cz4875 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; NEURAL_HAM_SHORT(-0.89)[-0.890]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:44:06 -0000 On 2020-Jul-6, at 23:22, Mark Millard wrote: > On 2020-Jul-6, at 23:03, Mark Millard wrote: >=20 >=20 >> On 2020-Jul-6, at 14:21, Mark Millard wrote: >>=20 >>> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko wrote: >>>=20 >>>> Furkan Salman (furkan@fkardame.com) wrote: >>>>> Hello Peter, >>>>>=20 >>>>> I have rockpiE which is somewhat similar to Rock64, If = s133pwa1k9r@ or gonzo@ can confirm if rockpie can be used to test RK3328 = Lan issue then I am happy to help with testing. >>>>=20 >>>>=20 >>>> Hi Furkan, >>>>=20 >>>> Yes, RockPi E seems to be a good test target. If you could check = the >>>> GigE interface before and after the patch. Whether it works/doesn't = work >>>> and if it works in both cases - try testing performance with = iperf3, >>>> just to see if performance was affected in any way. >>>=20 >>> For folks not familiar with the general type of activity >>> or specifically with iperf3 (or other specifics), more >>> detailed information to "collect and report . . ., collecting >>> the information via the commands . . ." could help: more >>> step-by-step. >>>=20 >>> Also: Do you care between debug kernels vs. non-debug >>> kernels? Debug ones of the appropriate vintage for head >>> are available via artifacts.ci.freebsd.org but there >>> might be performance consequences to using such. >>=20 >> I put a copy of the -r362982 *debug* kernel from >> artifacts.ci.freebsd.org on the Rock64 V2.0 that >> I sometimes have access to. There are no hardware >> mods to the Rock64 V2.0. >>=20 >> It did DHCP to pick up an address just fine during >> the boot. I ssh'd into it just fine after the boot. >>=20 >> # uname -apKU >> FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: = Tue Jul 7 03:41:02 UTC 2020 = root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64= .aarch64/sys/GENERIC arm64 aarch64 1300100 1300092 >>=20 >> # ifconfig >> dwc0: flags=3D8843 metric 0 = mtu 1500 >> options=3D80008 >> ether # >> hwaddr # >> inet # netmask # broadcast # >> media: Ethernet autoselect (1000baseT ) >> status: active >> nd6 options=3D29 >> . . . >>=20 >> I'll note that the Rock64 is the only thing running a debug >> kernel for this note. >>=20 >> An rsync copying an approximately 4 GiByte tar file to the Rock64 >> reported: >>=20 >> # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >>=20 >> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) >>=20 >> I'll note that at times it listed over 32MB/s. The storage media >> is a USB3 SSD plugged into the USB3 port. It has the Rock64's >> root filesystem. >>=20 >> For reference, locally duplicating the file on the Rock64 via >> rsync reported: >>=20 >> # rsync -axHh --info=3Dprogress2 -r = /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar >> 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) >>=20 >> (from/to: same media). I do not expect that the rsync over the >> network was limited by the target media on the Rock64. >>=20 >> Copying from the same machine to a large, fast machine instead >> of to the Rock64: >>=20 >> # rsync -axHh --info=3Dprogress2 --delete -r = /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >> 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) >>=20 >> So that should not be the side constraining the to-Rock64 >> rate. >>=20 >> Copying from the Rock64 to the large, fast machine: >>=20 >> rsync -axHh --info=3Dprogress2 --delete -r = /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >> 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) >>=20 >> It did not list figures much higher than above, so slower than >> the copy to the Rock64 fairly generally. >>=20 >> All this activity is over the local network, nothing remote. >> All machines were running head -r360311 (non-debug), except >> for the Rock64 having the -r362982 *debug* kernel instead.=20 >>=20 >> I hope that the above helps. >>=20 >> I see that there are now iperf3 usage instructions so at some >> point I may get that going and report the results, including >> doing a non-debug kernel build and install. >>=20 >=20 > Still using the debug kernel, but I figured I'd show > the results from proving that I can get iperf3 to do > the requested type of testing: >=20 > # iperf3 -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 = KBytes =20 > [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 = KBytes =20 > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 = KBytes =20 > [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 = KBytes =20 > [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 = KBytes =20 > [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 = KBytes =20 > [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 = KBytes =20 > [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 = KBytes =20 > [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 = KBytes =20 > [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 = sender > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec = receiver >=20 > # iperf3 -R -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > Reverse mode, remote host 192.168.1.122 is sending > [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port = 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec =20= > [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec =20= > [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec =20= > [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec =20= > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec =20= > [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec =20= > [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec =20= > [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec =20= > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec =20= > [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 = sender > [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec = receiver >=20 > I'll note that I run with the following in /etc/sysctl.conf : >=20 > # The Rock64 does not seem to automatically adjust from 600MHz, > # so do so manually. (The specifics likely would not be > # appropriate to the RPi4/3.) > dev.cpu.0.freq=3D1200 >=20 > It is a historical artifact that I've not checked on the > status of in a very long time: it works so I leave it > there. Looks like it will be some time before I deal with updating to a more modern kernel/world (non-debug). But I switched back to my non-debug head -r360311 kernel (and dtb) build and here are the iperf3 results for that context: # iperf3 -c 192.168.1.122 Connecting to host 192.168.1.122, port 5201 [ 5] local 192.168.1.109 port 39541 connected to 192.168.1.122 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 73.6 MBytes 617 Mbits/sec 0 1.07 MBytes = =20 [ 5] 1.00-2.00 sec 72.9 MBytes 612 Mbits/sec 0 1.60 MBytes = =20 [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes = =20 [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes = =20 [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes = =20 [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes = =20 [ 5] 6.00-7.00 sec 72.7 MBytes 610 Mbits/sec 0 1.60 MBytes = =20 [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes = =20 [ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes = =20 [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 729 MBytes 611 Mbits/sec 0 = sender [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec = receiver # iperf3 -R -c 192.168.1.122 Connecting to host 192.168.1.122, port 5201 Reverse mode, remote host 192.168.1.122 is sending [ 5] local 192.168.1.109 port 50696 connected to 192.168.1.122 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec =20 [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 3.00-4.00 sec 84.4 MBytes 708 Mbits/sec =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 = sender [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec = receiver =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 7 07:16:48 2020 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 BE9FA358154 for ; Tue, 7 Jul 2020 07:16:48 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1DJb387Lz49fS for ; Tue, 7 Jul 2020 07:16:47 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-pg1-x543.google.com with SMTP id p3so19582710pgh.3 for ; Tue, 07 Jul 2020 00:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qRmaI7C/4qQRPFDeEAinOx7Yek9H+fsPJBXbjQ0pLos=; b=ZLhGJtXH4cG4DDLcttBXZ5a0NwmYqjYgTF2nSUMNGbLLMME7hwlRONtL0WHmh6oCEc Ku7wbuWdL81Xe6XFQm04OgU07VnmE64SoE2qpR9guAiwCjq4v/PbQc/SoSObhvaeqVTW ACjZsz8I2wmLXqYcgGXre15Nh0gMlGsK5yAUWgPRDI+fZ7OspzyMymR9O+nlKIWeWO3M VlR0rh/Og/ZT1+YEdVp5P1mvZVv0aqIDY8iYtLn7dg+UEBS6IkFURde8ApbwnYJ98AFW nNHLCYB23pvSH8oPUiiwBf947js0X2qbWsp0xmPdnvVSWqhEfcF3+x0jkSFumT3blR+b KJ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qRmaI7C/4qQRPFDeEAinOx7Yek9H+fsPJBXbjQ0pLos=; b=kbSDOqkAtCV+HSez9Ic5JaNiZ/pYE6EQdGvbG3/X+/PM1eEjH2eYVSDgDUjmlG5Rrn 0YiruGnYAg2mCfm4NXCTzLZ3LpWO5gdXh1jMtbqs72WTEaqw2dpB6dlRtsbw9Ql+0v/B aonRm590t6wr5Xm2f0LuRMWDhASBVmmtsnfa9UqaLq490lD9UkY18CfjDPE0QNOZRE/T c5QaTTB393+QfOB/TmLoM++6zqEpHwXqVYXJ/jIcx/DR9rR+7jI07nCIG6Yrlox0l5uY 7DzDShAdzX0Pdu3+fFwisOfI30L8IKgnq/BMZauLHjDY7blcVWx3hZz1esh6svcZFukM o0TQ== X-Gm-Message-State: AOAM531VUcKaBxsFmq3yIQsujOdN+Ii6+ETliuDkFeGft0e108YaDKkj W7YRRvfq/ZNK3YFbOyGlXr60EDEXlCcI+Y2/OFspmgWtyWVRhA== X-Google-Smtp-Source: ABdhPJzXzOvos857kCG6GHEVrM7/2PvO1l5weTdLbT4hm+vSKfiaodjnUDngWds2ZtZ4RxxGsSGNS/hQShaq1vIjWBI= X-Received: by 2002:a62:404:: with SMTP id 4mr49793280pfe.133.1594106205728; Tue, 07 Jul 2020 00:16:45 -0700 (PDT) MIME-Version: 1.0 References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> In-Reply-To: From: Sleep Walker Date: Tue, 7 Jul 2020 10:16:25 +0300 Message-ID: Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) To: Mark Millard Cc: Oleksandr Tymoshenko , Peter Jeremy , freebsd-arm X-Rspamd-Queue-Id: 4B1DJb387Lz49fS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ZLhGJtXH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::543 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.005]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::543:from]; NEURAL_HAM_SHORT(-0.98)[-0.983]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 07:16:48 -0000 Hi! On NanoPC-T4 r361538 nodebug root@freenas:~ # uname -aUK FreeBSD freenas 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361538: Tue May 26 23:53:06 MSK 2020 root@freenas:/usr/obj/usr/src/arm64.aarch64/sys/FREEN= AS arm64 1300096 1300096 root@freenas:~ # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 55179 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 60.4 MBytes 507 Mbits/sec 0 161 KBytes [ 5] 1.00-2.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 2.00-3.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 3.00-4.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 4.00-5.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 5.00-6.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 6.00-7.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 7.00-8.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 8.00-9.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes [ 5] 9.00-10.00 sec 59.9 MBytes 503 Mbits/sec 0 175 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 600 MBytes 503 Mbits/sec 0 sende= r [ 5] 0.00-10.34 sec 599 MBytes 486 Mbits/sec receiver iperf Done. root@freenas:~ # iperf3 -R -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 40284 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 3.11 MBytes 26.0 Mbits/sec [ 5] 1.01-2.01 sec 2.77 MBytes 23.1 Mbits/sec [ 5] 2.01-3.01 sec 3.22 MBytes 27.1 Mbits/sec [ 5] 3.01-4.01 sec 2.34 MBytes 19.7 Mbits/sec [ 5] 4.01-5.00 sec 4.55 MBytes 38.5 Mbits/sec [ 5] 5.00-6.01 sec 4.88 MBytes 40.5 Mbits/sec [ 5] 6.01-7.01 sec 3.72 MBytes 31.3 Mbits/sec [ 5] 7.01-8.01 sec 3.80 MBytes 31.9 Mbits/sec [ 5] 8.01-9.00 sec 1.73 MBytes 14.6 Mbits/sec [ 5] 9.00-10.00 sec 1.18 MBytes 9.97 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.34 sec 31.4 MBytes 25.5 Mbits/sec 1100 sender [ 5] 0.00-10.00 sec 31.3 MBytes 26.3 Mbits/sec receiver iperf Done. root@freenas:~ # iperf3 -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 30151 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.025 ms 0/898 (0%) receiver iperf Done. root@freenas:~ # iperf3 -R -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 13018 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 134 KBytes 1.10 Mbits/sec 0.012 ms 0/94 (0%) [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) [ 5] 2.00-3.00 sec 127 KBytes 1.04 Mbits/sec 0.003 ms 0/89 (0%) [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.007 ms 0/90 (0%) [ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) [ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 0.005 ms 0/89 (0%) [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.009 ms 0/90 (0%) [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.04 sec 1.26 MBytes 1.05 Mbits/sec 0.000 ms 0/902 (0%) sender [ 5] 0.00-10.00 sec 1.26 MBytes 1.05 Mbits/sec 0.008 ms 0/902 (0%) receiver iperf Done. root@freenas:~ # =D0=B2=D1=82, 7 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 09:44, Mark Millard= via freebsd-arm < freebsd-arm@freebsd.org>: > > > On 2020-Jul-6, at 23:22, Mark Millard wrote: > > > On 2020-Jul-6, at 23:03, Mark Millard wrote: > > > > > >> On 2020-Jul-6, at 14:21, Mark Millard wrote: > >> > >>> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko > wrote: > >>> > >>>> Furkan Salman (furkan@fkardame.com) wrote: > >>>>> Hello Peter, > >>>>> > >>>>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ > or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue > then I am happy to help with testing. > >>>> > >>>> > >>>> Hi Furkan, > >>>> > >>>> Yes, RockPi E seems to be a good test target. If you could check the > >>>> GigE interface before and after the patch. Whether it works/doesn't > work > >>>> and if it works in both cases - try testing performance with iperf3, > >>>> just to see if performance was affected in any way. > >>> > >>> For folks not familiar with the general type of activity > >>> or specifically with iperf3 (or other specifics), more > >>> detailed information to "collect and report . . ., collecting > >>> the information via the commands . . ." could help: more > >>> step-by-step. > >>> > >>> Also: Do you care between debug kernels vs. non-debug > >>> kernels? Debug ones of the appropriate vintage for head > >>> are available via artifacts.ci.freebsd.org but there > >>> might be performance consequences to using such. > >> > >> I put a copy of the -r362982 *debug* kernel from > >> artifacts.ci.freebsd.org on the Rock64 V2.0 that > >> I sometimes have access to. There are no hardware > >> mods to the Rock64 V2.0. > >> > >> It did DHCP to pick up an address just fine during > >> the boot. I ssh'd into it just fine after the boot. > >> > >> # uname -apKU > >> FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue > Jul 7 03:41:02 UTC 2020 > root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm= 64.aarch64/sys/GENERIC > arm64 aarch64 1300100 1300092 > >> > >> # ifconfig > >> dwc0: flags=3D8843 metric 0 mt= u > 1500 > >> options=3D80008 > >> ether # > >> hwaddr # > >> inet # netmask # broadcast # > >> media: Ethernet autoselect (1000baseT ) > >> status: active > >> nd6 options=3D29 > >> . . . > >> > >> I'll note that the Rock64 is the only thing running a debug > >> kernel for this note. > >> > >> An rsync copying an approximately 4 GiByte tar file to the Rock64 > >> reported: > >> > >> # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > >> > >> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) > >> > >> I'll note that at times it listed over 32MB/s. The storage media > >> is a USB3 SSD plugged into the USB3 port. It has the Rock64's > >> root filesystem. > >> > >> For reference, locally duplicating the file on the Rock64 via > >> rsync reported: > >> > >> # rsync -axHh --info=3Dprogress2 -r > /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar > >> 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) > >> > >> (from/to: same media). I do not expect that the rsync over the > >> network was limited by the target media on the Rock64. > >> > >> Copying from the same machine to a large, fast machine instead > >> of to the Rock64: > >> > >> # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > >> 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) > >> > >> So that should not be the side constraining the to-Rock64 > >> rate. > >> > >> Copying from the Rock64 to the large, fast machine: > >> > >> rsync -axHh --info=3Dprogress2 --delete -r > /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > >> 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) > >> > >> It did not list figures much higher than above, so slower than > >> the copy to the Rock64 fairly generally. > >> > >> All this activity is over the local network, nothing remote. > >> All machines were running head -r360311 (non-debug), except > >> for the Rock64 having the -r362982 *debug* kernel instead. > >> > >> I hope that the above helps. > >> > >> I see that there are now iperf3 usage instructions so at some > >> point I may get that going and report the results, including > >> doing a non-debug kernel build and install. > >> > > > > Still using the debug kernel, but I figured I'd show > > the results from proving that I can get iperf3 to do > > the requested type of testing: > > > > # iperf3 -c 192.168.1.122 > > Connecting to host 192.168.1.122, port 5201 > > [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port 52= 01 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 KBytes > > > [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 KBytes > > > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 KBytes > > > [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > > [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > > [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 KBytes > > > [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 KBytes > > > [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 KBytes > > > [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > > [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 > sender > > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec > receiver > > > > # iperf3 -R -c 192.168.1.122 > > Connecting to host 192.168.1.122, port 5201 > > Reverse mode, remote host 192.168.1.122 is sending > > [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port 52= 01 > > [ ID] Interval Transfer Bitrate > > [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec > > [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec > > [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec > > [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec > > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec > > [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec > > [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec > > [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec > > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec > > [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 > sender > > [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec > receiver > > > > I'll note that I run with the following in /etc/sysctl.conf : > > > > # The Rock64 does not seem to automatically adjust from 600MHz, > > # so do so manually. (The specifics likely would not be > > # appropriate to the RPi4/3.) > > dev.cpu.0.freq=3D1200 > > > > It is a historical artifact that I've not checked on the > > status of in a very long time: it works so I leave it > > there. > > Looks like it will be some time before I deal with > updating to a more modern kernel/world (non-debug). > > But I switched back to my non-debug head -r360311 > kernel (and dtb) build and here are the iperf3 > results for that context: > > # iperf3 -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > [ 5] local 192.168.1.109 port 39541 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 73.6 MBytes 617 Mbits/sec 0 1.07 MBytes > > [ 5] 1.00-2.00 sec 72.9 MBytes 612 Mbits/sec 0 1.60 MBytes > > [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes > > [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes > > [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes > > [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes > > [ 5] 6.00-7.00 sec 72.7 MBytes 610 Mbits/sec 0 1.60 MBytes > > [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes > > [ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes > > [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 729 MBytes 611 Mbits/sec 0 > sender > [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec > receiver > > # iperf3 -R -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > Reverse mode, remote host 192.168.1.122 is sending > [ 5] local 192.168.1.109 port 50696 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec > [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec > [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec > [ 5] 3.00-4.00 sec 84.4 MBytes 708 Mbits/sec > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 > sender > [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec > receiver > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Tue Jul 7 07:43:23 2020 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 3C184358A0E for ; Tue, 7 Jul 2020 07:43:23 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1DvG3pX0z4C24 for ; Tue, 7 Jul 2020 07:43:22 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-pg1-x532.google.com with SMTP id w2so18813383pgg.10 for ; Tue, 07 Jul 2020 00:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TPukZiSA5gwETHUDX/LaI0hNV+dRcOxrOsst7WTjRZE=; b=HzRv0mHOr5tZoLOTSDbVkhhUPhyurfUieeyO9eJsgZl8sYI0/jDpfbSv4gw7LmQTwn +quAyq8nSe/55GkaFCRLfPuB1cs2Ll1Bkz79LbnUpq7r47et+Isqmz0cAnAyVWBH0GZk v6rUftO5TcY5xUvY4kCZf1p9fjjMR234K0JGsu2imuK08PhVEj0C50WkDoYSAImpTFyP UH/gfZi5MO6/5QVIufi/grtvGpBsL3ItXpwZEmPRiPedFRjUsmLkYmQVMleN+uPXp0Ug Uv/0yNMf657qXpMoM2SHZw1rAt9Bfzlzkv7M5YjZzZevO7cV5uTDi7Zqkgul3xHL4uCB gyrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TPukZiSA5gwETHUDX/LaI0hNV+dRcOxrOsst7WTjRZE=; b=Xc2R/WFyU/krW0+rSFvJf+o1Z4IA7lZrQcWMpDrPioe9OQizLicLMw3BUOHofUuOZJ PrxNHK+qWrgfBddM7315DLwnsjqybeNbKHVREl//LE/CzKPgox61nwHQpsQwercluLNE cxFulnUTCWkbUTO+myl5cG0rUxyeJ7hrewq0ea7Q5Bvrqq4Lc6o5/Xup0hQhe6LZGKUg Rg3UcohT2Pl7vitohqZK32gWrYVZPr2p/jiGpf5uJfvvlloFTUtRFifPGP1lI9iZl8GV GoMnaph5edrz4IpXTBGdyCabPYNbUOOnVWpejAQvwwsQacVlUfIMGEbco3Avhqur084w nwzA== X-Gm-Message-State: AOAM531pTd9so1aBhxbQNptopgI6C78EXd7vNvZvcsEFHKGiRk6nYR2U PCpTtHby7zUQEKAYEIMsQTLPiYgOqvD3pKNDLd8= X-Google-Smtp-Source: ABdhPJzyyqrIwiTpCW2cgXQb/EofYFifYYXDsZEZ1nFhPTZ3v6MdFfxdy0gAAmcDCURX9t6xV/mz46rPugZ9zaG3HHg= X-Received: by 2002:a62:404:: with SMTP id 4mr49868742pfe.133.1594107800126; Tue, 07 Jul 2020 00:43:20 -0700 (PDT) MIME-Version: 1.0 References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> In-Reply-To: From: Sleep Walker Date: Tue, 7 Jul 2020 10:42:59 +0300 Message-ID: Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) To: Mark Millard Cc: Oleksandr Tymoshenko , Peter Jeremy , freebsd-arm X-Rspamd-Queue-Id: 4B1DvG3pX0z4C24 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=HzRv0mHO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.004]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::532:from]; NEURAL_HAM_SHORT(-0.98)[-0.984]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 07:43:23 -0000 Hi! On Khadas-EDGE-V ot@khadas-edge-v:~ # sysctl dev.cpu.0.freq dev.cpu.0.freq: 1416 root@khadas-edge-v:~ # uname -aUK FreeBSD khadas-edge-v 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362798M 0fb6ad5-c996(nanopi): Tue Jun 30 19:44:09 MSK 2020 root@dev.kubsu.ru:/usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/= sys/FREENAS arm64 1300100 1300100 root@khadas-edge-v:~ # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 26993 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 57.4 MBytes 481 Mbits/sec 0 144 KBytes [ 5] 1.00-2.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes [ 5] 2.00-3.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes [ 5] 3.00-4.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes [ 5] 4.00-5.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes [ 5] 5.00-6.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes [ 5] 6.00-7.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes [ 5] 7.00-8.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes [ 5] 8.00-9.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes [ 5] 9.00-10.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 568 MBytes 477 Mbits/sec 0 sende= r [ 5] 0.00-10.34 sec 568 MBytes 461 Mbits/sec receiver iperf Done. root@khadas-edge-v:~ # iperf3 -R -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 45336 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 4.65 MBytes 38.5 Mbits/sec [ 5] 1.01-2.01 sec 9.39 MBytes 79.3 Mbits/sec [ 5] 2.01-3.00 sec 6.15 MBytes 51.8 Mbits/sec [ 5] 3.00-4.01 sec 5.79 MBytes 48.0 Mbits/sec [ 5] 4.01-5.01 sec 2.75 MBytes 23.1 Mbits/sec [ 5] 5.01-6.00 sec 6.84 MBytes 57.7 Mbits/sec [ 5] 6.00-7.00 sec 2.01 MBytes 16.9 Mbits/sec [ 5] 7.00-8.01 sec 1.97 MBytes 16.4 Mbits/sec [ 5] 8.01-9.01 sec 2.06 MBytes 17.3 Mbits/sec [ 5] 9.01-10.00 sec 1.69 MBytes 14.3 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.34 sec 43.4 MBytes 35.2 Mbits/sec 1636 sender [ 5] 0.00-10.00 sec 43.3 MBytes 36.3 Mbits/sec receiver iperf Done. root@khadas-edge-v:~ # iperf3 -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 52129 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.007 ms 0/898 (0%) receiver iperf Done. root@khadas-edge-v:~ # iperf3 -R -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 39861 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 134 KBytes 1.10 Mbits/sec 0.013 ms 0/94 (0%) [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 0.008 ms 0/89 (0%) [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) [ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) [ 5] 5.00-6.00 sec 127 KBytes 1.04 Mbits/sec 0.004 ms 0/89 (0%) [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 0.005 ms 0/90 (0%) [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) [ 5] 9.00-10.00 sec 127 KBytes 1.04 Mbits/sec 0.049 ms 0/89 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/901 (0%) sender [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.049 ms 0/901 (0%) receiver iperf Done. root@khadas-edge-v:~ # =D0=B2=D1=82, 7 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 10:16, Sleep Walker= : > Hi! > > On NanoPC-T4 r361538 nodebug > > root@freenas:~ # uname -aUK > FreeBSD freenas 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361538: Tue May 26 > 23:53:06 MSK 2020 root@freenas:/usr/obj/usr/src/arm64.aarch64/sys/FRE= ENAS > arm64 1300096 1300096 > root@freenas:~ # iperf3 -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > [ 5] local 192.168.1.101 port 55179 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 60.4 MBytes 507 Mbits/sec 0 161 KBytes > > [ 5] 1.00-2.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 2.00-3.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 3.00-4.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 4.00-5.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 5.00-6.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 6.00-7.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 7.00-8.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 8.00-9.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes > > [ 5] 9.00-10.00 sec 59.9 MBytes 503 Mbits/sec 0 175 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 600 MBytes 503 Mbits/sec 0 > sender > [ 5] 0.00-10.34 sec 599 MBytes 486 Mbits/sec > receiver > > iperf Done. > root@freenas:~ # iperf3 -R -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > Reverse mode, remote host 192.168.1.100 is sending > [ 5] local 192.168.1.101 port 40284 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.01 sec 3.11 MBytes 26.0 Mbits/sec > [ 5] 1.01-2.01 sec 2.77 MBytes 23.1 Mbits/sec > [ 5] 2.01-3.01 sec 3.22 MBytes 27.1 Mbits/sec > [ 5] 3.01-4.01 sec 2.34 MBytes 19.7 Mbits/sec > [ 5] 4.01-5.00 sec 4.55 MBytes 38.5 Mbits/sec > [ 5] 5.00-6.01 sec 4.88 MBytes 40.5 Mbits/sec > [ 5] 6.01-7.01 sec 3.72 MBytes 31.3 Mbits/sec > [ 5] 7.01-8.01 sec 3.80 MBytes 31.9 Mbits/sec > [ 5] 8.01-9.00 sec 1.73 MBytes 14.6 Mbits/sec > [ 5] 9.00-10.00 sec 1.18 MBytes 9.97 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.34 sec 31.4 MBytes 25.5 Mbits/sec 1100 > sender > [ 5] 0.00-10.00 sec 31.3 MBytes 26.3 Mbits/sec > receiver > > iperf Done. > root@freenas:~ # iperf3 -u -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > [ 5] local 192.168.1.101 port 30151 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Total Datagrams > [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 > [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 > [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Jitter Lost/Tota= l > Datagrams > [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%= ) > sender > [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.025 ms 0/898 (0%= ) > receiver > > iperf Done. > root@freenas:~ # iperf3 -R -u -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > Reverse mode, remote host 192.168.1.100 is sending > [ 5] local 192.168.1.101 port 13018 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Jitter Lost/Tota= l > Datagrams > [ 5] 0.00-1.00 sec 134 KBytes 1.10 Mbits/sec 0.012 ms 0/94 (0%) > [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) > [ 5] 2.00-3.00 sec 127 KBytes 1.04 Mbits/sec 0.003 ms 0/89 (0%) > [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.007 ms 0/90 (0%) > [ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) > [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) > [ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 0.005 ms 0/89 (0%) > [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.009 ms 0/90 (0%) > [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) > [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Jitter Lost/Tota= l > Datagrams > [ 5] 0.00-10.04 sec 1.26 MBytes 1.05 Mbits/sec 0.000 ms 0/902 (0%= ) > sender > [ 5] 0.00-10.00 sec 1.26 MBytes 1.05 Mbits/sec 0.008 ms 0/902 (0%= ) > receiver > > iperf Done. > root@freenas:~ # > > =D0=B2=D1=82, 7 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 09:44, Mark Milla= rd via freebsd-arm < > freebsd-arm@freebsd.org>: > >> >> >> On 2020-Jul-6, at 23:22, Mark Millard wrote: >> >> > On 2020-Jul-6, at 23:03, Mark Millard wrote: >> > >> > >> >> On 2020-Jul-6, at 14:21, Mark Millard wrote: >> >> >> >>> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko >> wrote: >> >>> >> >>>> Furkan Salman (furkan@fkardame.com) wrote: >> >>>>> Hello Peter, >> >>>>> >> >>>>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r= @ >> or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue >> then I am happy to help with testing. >> >>>> >> >>>> >> >>>> Hi Furkan, >> >>>> >> >>>> Yes, RockPi E seems to be a good test target. If you could check th= e >> >>>> GigE interface before and after the patch. Whether it works/doesn't >> work >> >>>> and if it works in both cases - try testing performance with iperf3= , >> >>>> just to see if performance was affected in any way. >> >>> >> >>> For folks not familiar with the general type of activity >> >>> or specifically with iperf3 (or other specifics), more >> >>> detailed information to "collect and report . . ., collecting >> >>> the information via the commands . . ." could help: more >> >>> step-by-step. >> >>> >> >>> Also: Do you care between debug kernels vs. non-debug >> >>> kernels? Debug ones of the appropriate vintage for head >> >>> are available via artifacts.ci.freebsd.org but there >> >>> might be performance consequences to using such. >> >> >> >> I put a copy of the -r362982 *debug* kernel from >> >> artifacts.ci.freebsd.org on the Rock64 V2.0 that >> >> I sometimes have access to. There are no hardware >> >> mods to the Rock64 V2.0. >> >> >> >> It did DHCP to pick up an address just fine during >> >> the boot. I ssh'd into it just fine after the boot. >> >> >> >> # uname -apKU >> >> FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tu= e >> Jul 7 03:41:02 UTC 2020 >> root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/ar= m64.aarch64/sys/GENERIC >> arm64 aarch64 1300100 1300092 >> >> >> >> # ifconfig >> >> dwc0: flags=3D8843 metric 0 m= tu >> 1500 >> >> options=3D80008 >> >> ether # >> >> hwaddr # >> >> inet # netmask # broadcast # >> >> media: Ethernet autoselect (1000baseT ) >> >> status: active >> >> nd6 options=3D29 >> >> . . . >> >> >> >> I'll note that the Rock64 is the only thing running a debug >> >> kernel for this note. >> >> >> >> An rsync copying an approximately 4 GiByte tar file to the Rock64 >> >> reported: >> >> >> >> # rsync -axHh --info=3Dprogress2 --delete -r >> /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >> >> >> >> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) >> >> >> >> I'll note that at times it listed over 32MB/s. The storage media >> >> is a USB3 SSD plugged into the USB3 port. It has the Rock64's >> >> root filesystem. >> >> >> >> For reference, locally duplicating the file on the Rock64 via >> >> rsync reported: >> >> >> >> # rsync -axHh --info=3Dprogress2 -r >> /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar >> >> 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) >> >> >> >> (from/to: same media). I do not expect that the rsync over the >> >> network was limited by the target media on the Rock64. >> >> >> >> Copying from the same machine to a large, fast machine instead >> >> of to the Rock64: >> >> >> >> # rsync -axHh --info=3Dprogress2 --delete -r >> /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >> >> 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) >> >> >> >> So that should not be the side constraining the to-Rock64 >> >> rate. >> >> >> >> Copying from the Rock64 to the large, fast machine: >> >> >> >> rsync -axHh --info=3Dprogress2 --delete -r >> /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >> >> 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) >> >> >> >> It did not list figures much higher than above, so slower than >> >> the copy to the Rock64 fairly generally. >> >> >> >> All this activity is over the local network, nothing remote. >> >> All machines were running head -r360311 (non-debug), except >> >> for the Rock64 having the -r362982 *debug* kernel instead. >> >> >> >> I hope that the above helps. >> >> >> >> I see that there are now iperf3 usage instructions so at some >> >> point I may get that going and report the results, including >> >> doing a non-debug kernel build and install. >> >> >> > >> > Still using the debug kernel, but I figured I'd show >> > the results from proving that I can get iperf3 to do >> > the requested type of testing: >> > >> > # iperf3 -c 192.168.1.122 >> > Connecting to host 192.168.1.122, port 5201 >> > [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port >> 5201 >> > [ ID] Interval Transfer Bitrate Retr Cwnd >> > [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 >> KBytes >> > [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 >> KBytes >> > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 >> KBytes >> > [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 >> KBytes >> > [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 >> KBytes >> > [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 >> KBytes >> > [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 >> KBytes >> > [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 >> KBytes >> > [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 >> KBytes >> > [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 >> KBytes >> > - - - - - - - - - - - - - - - - - - - - - - - - - >> > [ ID] Interval Transfer Bitrate Retr >> > [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 >> sender >> > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec >> receiver >> > >> > # iperf3 -R -c 192.168.1.122 >> > Connecting to host 192.168.1.122, port 5201 >> > Reverse mode, remote host 192.168.1.122 is sending >> > [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port >> 5201 >> > [ ID] Interval Transfer Bitrate >> > [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec >> > [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec >> > [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec >> > [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec >> > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec >> > [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec >> > [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec >> > [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec >> > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec >> > [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec >> > - - - - - - - - - - - - - - - - - - - - - - - - - >> > [ ID] Interval Transfer Bitrate Retr >> > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 >> sender >> > [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec >> receiver >> > >> > I'll note that I run with the following in /etc/sysctl.conf : >> > >> > # The Rock64 does not seem to automatically adjust from 600MHz, >> > # so do so manually. (The specifics likely would not be >> > # appropriate to the RPi4/3.) >> > dev.cpu.0.freq=3D1200 >> > >> > It is a historical artifact that I've not checked on the >> > status of in a very long time: it works so I leave it >> > there. >> >> Looks like it will be some time before I deal with >> updating to a more modern kernel/world (non-debug). >> >> But I switched back to my non-debug head -r360311 >> kernel (and dtb) build and here are the iperf3 >> results for that context: >> >> # iperf3 -c 192.168.1.122 >> Connecting to host 192.168.1.122, port 5201 >> [ 5] local 192.168.1.109 port 39541 connected to 192.168.1.122 port 520= 1 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 73.6 MBytes 617 Mbits/sec 0 1.07 MBytes >> >> [ 5] 1.00-2.00 sec 72.9 MBytes 612 Mbits/sec 0 1.60 MBytes >> >> [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >> >> [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes >> >> [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >> >> [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >> >> [ 5] 6.00-7.00 sec 72.7 MBytes 610 Mbits/sec 0 1.60 MBytes >> >> [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes >> >> [ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes >> >> [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes >> >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 729 MBytes 611 Mbits/sec 0 >> sender >> [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec >> receiver >> >> # iperf3 -R -c 192.168.1.122 >> Connecting to host 192.168.1.122, port 5201 >> Reverse mode, remote host 192.168.1.122 is sending >> [ 5] local 192.168.1.109 port 50696 connected to 192.168.1.122 port 520= 1 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec >> [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 3.00-4.00 sec 84.4 MBytes 708 Mbits/sec >> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec >> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 >> sender >> [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec >> receiver >> >> >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >> >> _______________________________________________ >> 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" >> > From owner-freebsd-arm@freebsd.org Tue Jul 7 08:20:24 2020 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 60A3635A1B1 for ; Tue, 7 Jul 2020 08:20:24 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (warbird.scd-systems.net [37.120.173.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.scd-systems.net", Issuer "mail.scd-systems.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1Fjy5vxfz4F39 for ; Tue, 7 Jul 2020 08:20:22 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (127.0.1.80 [127.0.1.80]) by mail.scd-systems.net (OpenSMTPD) with ESMTP id ef8942fa for ; Tue, 7 Jul 2020 08:20:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=scd-systems.net; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=B2srCcI4thg19YHY91xekiZeFm5yqZ4iJBrfBmc1vlc=; b=YskLKSlxlkIN 7eTSkL0gFMy8je60Jy+PrjQYJWZAOIyTXATvFEKkR6dml/of5CAxRvaXEUPvlI3p k140AbUXWpUTeA2heNYvwepNAgDb1zOQNCAnTGVAjR7qv3Bd2bS7Cx8KtHxKrkJB Fr6nsiuOmNI92YlW1NMZ32eZ8ooMJyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=scd-systems.net; h=subject :to:references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=default; b=Rs4 XyL1o6cIw54zSwYWCxAlFY4+EZ2PGaY0jnZ1HBlBsly9ycg5oMhfpBmUokiHAeDJ nMAvnSuvP0ZZf4OAymxCg++uSh/WB/UIaX/HTigecOR7+OrULwOQiB5+ZUtob541 XJk0vy+StrWvjgQrHzrZB6oOOZmSMOjwDLqR7uGg= Received: from LT1006.local (127.0.1.254 [127.0.1.254]) by mail.scd-systems.net (OpenSMTPD) with ESMTPSA id 737be4d5 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Tue, 7 Jul 2020 08:20:18 +0000 (UTC) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) To: freebsd-arm@freebsd.org References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> From: Charles Message-ID: <04564059-4df1-65e5-5a2f-ddf2e1513c6f@scd-systems.net> Date: Tue, 7 Jul 2020 10:20:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B1Fjy5vxfz4F39 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=scd-systems.net header.s=default header.b=YskLKSlx; dmarc=none; spf=pass (mx1.freebsd.org: domain of charlesr@scd-systems.net designates 37.120.173.96 as permitted sender) smtp.mailfrom=charlesr@scd-systems.net X-Spamd-Result: default: False [-2.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[scd-systems.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.02)[-1.020]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[scd-systems.net: no valid DMARC record]; NEURAL_SPAM_SHORT(0.30)[0.296]; DKIM_TRACE(0.00)[scd-systems.net:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197540, ipnet:37.120.160.0/19, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 08:20:24 -0000 Hi, I tried kernel r362982 without getting a stable network. With tcpdump I can see, that partially packets do not received on the interface dwc0. Tested with direct paired cable connection to my pc. Do I need to tune or check the regulators ? And what else I can test to see what's wrong ? Best, C. Am 07.07.20 um 09:42 schrieb Sleep Walker: > Hi! > On Khadas-EDGE-V > ot@khadas-edge-v:~ # sysctl dev.cpu.0.freq > dev.cpu.0.freq: 1416 > root@khadas-edge-v:~ # uname -aUK > FreeBSD khadas-edge-v 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362798M > 0fb6ad5-c996(nanopi): Tue Jun 30 19:44:09 MSK 2020 > root@dev.kubsu.ru:/usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/sys/FREENAS > arm64 1300100 1300100 > root@khadas-edge-v:~ # iperf3 -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > [ 5] local 192.168.1.101 port 26993 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 57.4 MBytes 481 Mbits/sec 0 144 KBytes > > [ 5] 1.00-2.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes > > [ 5] 2.00-3.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes > > [ 5] 3.00-4.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes > > [ 5] 4.00-5.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes > > [ 5] 5.00-6.00 sec 56.8 MBytes 476 Mbits/sec 0 161 KBytes > > [ 5] 6.00-7.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes > > [ 5] 7.00-8.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes > > [ 5] 8.00-9.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes > > [ 5] 9.00-10.00 sec 56.8 MBytes 476 Mbits/sec 0 175 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 568 MBytes 477 Mbits/sec 0 sender > [ 5] 0.00-10.34 sec 568 MBytes 461 Mbits/sec > receiver > > iperf Done. > root@khadas-edge-v:~ # iperf3 -R -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > Reverse mode, remote host 192.168.1.100 is sending > [ 5] local 192.168.1.101 port 45336 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.01 sec 4.65 MBytes 38.5 Mbits/sec > [ 5] 1.01-2.01 sec 9.39 MBytes 79.3 Mbits/sec > [ 5] 2.01-3.00 sec 6.15 MBytes 51.8 Mbits/sec > [ 5] 3.00-4.01 sec 5.79 MBytes 48.0 Mbits/sec > [ 5] 4.01-5.01 sec 2.75 MBytes 23.1 Mbits/sec > [ 5] 5.01-6.00 sec 6.84 MBytes 57.7 Mbits/sec > [ 5] 6.00-7.00 sec 2.01 MBytes 16.9 Mbits/sec > [ 5] 7.00-8.01 sec 1.97 MBytes 16.4 Mbits/sec > [ 5] 8.01-9.01 sec 2.06 MBytes 17.3 Mbits/sec > [ 5] 9.01-10.00 sec 1.69 MBytes 14.3 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.34 sec 43.4 MBytes 35.2 Mbits/sec 1636 > sender > [ 5] 0.00-10.00 sec 43.3 MBytes 36.3 Mbits/sec > receiver > > iperf Done. > root@khadas-edge-v:~ # iperf3 -u -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > [ 5] local 192.168.1.101 port 52129 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Total Datagrams > [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 > [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 > [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 > [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Jitter Lost/Total > Datagrams > [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) > sender > [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.007 ms 0/898 (0%) > receiver > > iperf Done. > root@khadas-edge-v:~ # iperf3 -R -u -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > Reverse mode, remote host 192.168.1.100 is sending > [ 5] local 192.168.1.101 port 39861 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Jitter Lost/Total > Datagrams > [ 5] 0.00-1.00 sec 134 KBytes 1.10 Mbits/sec 0.013 ms 0/94 (0%) > [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 0.008 ms 0/89 (0%) > [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) > [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) > [ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) > [ 5] 5.00-6.00 sec 127 KBytes 1.04 Mbits/sec 0.004 ms 0/89 (0%) > [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 0.005 ms 0/90 (0%) > [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) > [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) > [ 5] 9.00-10.00 sec 127 KBytes 1.04 Mbits/sec 0.049 ms 0/89 (0%) > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Jitter Lost/Total > Datagrams > [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/901 (0%) > sender > [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.049 ms 0/901 (0%) > receiver > > iperf Done. > root@khadas-edge-v:~ # > > вт, 7 июл. 2020 г. в 10:16, Sleep Walker : > >> Hi! >> >> On NanoPC-T4 r361538 nodebug >> >> root@freenas:~ # uname -aUK >> FreeBSD freenas 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361538: Tue May 26 >> 23:53:06 MSK 2020 root@freenas:/usr/obj/usr/src/arm64.aarch64/sys/FREENAS >> arm64 1300096 1300096 >> root@freenas:~ # iperf3 -c 192.168.1.100 >> Connecting to host 192.168.1.100, port 5201 >> [ 5] local 192.168.1.101 port 55179 connected to 192.168.1.100 port 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 60.4 MBytes 507 Mbits/sec 0 161 KBytes >> >> [ 5] 1.00-2.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 2.00-3.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 3.00-4.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 4.00-5.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 5.00-6.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 6.00-7.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 7.00-8.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 8.00-9.00 sec 59.9 MBytes 503 Mbits/sec 0 161 KBytes >> >> [ 5] 9.00-10.00 sec 59.9 MBytes 503 Mbits/sec 0 175 KBytes >> >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 600 MBytes 503 Mbits/sec 0 >> sender >> [ 5] 0.00-10.34 sec 599 MBytes 486 Mbits/sec >> receiver >> >> iperf Done. >> root@freenas:~ # iperf3 -R -c 192.168.1.100 >> Connecting to host 192.168.1.100, port 5201 >> Reverse mode, remote host 192.168.1.100 is sending >> [ 5] local 192.168.1.101 port 40284 connected to 192.168.1.100 port 5201 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.01 sec 3.11 MBytes 26.0 Mbits/sec >> [ 5] 1.01-2.01 sec 2.77 MBytes 23.1 Mbits/sec >> [ 5] 2.01-3.01 sec 3.22 MBytes 27.1 Mbits/sec >> [ 5] 3.01-4.01 sec 2.34 MBytes 19.7 Mbits/sec >> [ 5] 4.01-5.00 sec 4.55 MBytes 38.5 Mbits/sec >> [ 5] 5.00-6.01 sec 4.88 MBytes 40.5 Mbits/sec >> [ 5] 6.01-7.01 sec 3.72 MBytes 31.3 Mbits/sec >> [ 5] 7.01-8.01 sec 3.80 MBytes 31.9 Mbits/sec >> [ 5] 8.01-9.00 sec 1.73 MBytes 14.6 Mbits/sec >> [ 5] 9.00-10.00 sec 1.18 MBytes 9.97 Mbits/sec >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.34 sec 31.4 MBytes 25.5 Mbits/sec 1100 >> sender >> [ 5] 0.00-10.00 sec 31.3 MBytes 26.3 Mbits/sec >> receiver >> >> iperf Done. >> root@freenas:~ # iperf3 -u -c 192.168.1.100 >> Connecting to host 192.168.1.100, port 5201 >> [ 5] local 192.168.1.101 port 30151 connected to 192.168.1.100 port 5201 >> [ ID] Interval Transfer Bitrate Total Datagrams >> [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 >> [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 >> [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 >> [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Jitter Lost/Total >> Datagrams >> [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) >> sender >> [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.025 ms 0/898 (0%) >> receiver >> >> iperf Done. >> root@freenas:~ # iperf3 -R -u -c 192.168.1.100 >> Connecting to host 192.168.1.100, port 5201 >> Reverse mode, remote host 192.168.1.100 is sending >> [ 5] local 192.168.1.101 port 13018 connected to 192.168.1.100 port 5201 >> [ ID] Interval Transfer Bitrate Jitter Lost/Total >> Datagrams >> [ 5] 0.00-1.00 sec 134 KBytes 1.10 Mbits/sec 0.012 ms 0/94 (0%) >> [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) >> [ 5] 2.00-3.00 sec 127 KBytes 1.04 Mbits/sec 0.003 ms 0/89 (0%) >> [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.007 ms 0/90 (0%) >> [ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.004 ms 0/90 (0%) >> [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) >> [ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 0.005 ms 0/89 (0%) >> [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.009 ms 0/90 (0%) >> [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.006 ms 0/90 (0%) >> [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0.008 ms 0/90 (0%) >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Jitter Lost/Total >> Datagrams >> [ 5] 0.00-10.04 sec 1.26 MBytes 1.05 Mbits/sec 0.000 ms 0/902 (0%) >> sender >> [ 5] 0.00-10.00 sec 1.26 MBytes 1.05 Mbits/sec 0.008 ms 0/902 (0%) >> receiver >> >> iperf Done. >> root@freenas:~ # >> >> вт, 7 июл. 2020 г. в 09:44, Mark Millard via freebsd-arm < >> freebsd-arm@freebsd.org>: >> >>> >>> >>> On 2020-Jul-6, at 23:22, Mark Millard wrote: >>> >>>> On 2020-Jul-6, at 23:03, Mark Millard wrote: >>>> >>>> >>>>> On 2020-Jul-6, at 14:21, Mark Millard wrote: >>>>> >>>>>> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko >>> wrote: >>>>>> >>>>>>> Furkan Salman (furkan@fkardame.com) wrote: >>>>>>>> Hello Peter, >>>>>>>> >>>>>>>> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ >>> or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue >>> then I am happy to help with testing. >>>>>>> >>>>>>> >>>>>>> Hi Furkan, >>>>>>> >>>>>>> Yes, RockPi E seems to be a good test target. If you could check the >>>>>>> GigE interface before and after the patch. Whether it works/doesn't >>> work >>>>>>> and if it works in both cases - try testing performance with iperf3, >>>>>>> just to see if performance was affected in any way. >>>>>> >>>>>> For folks not familiar with the general type of activity >>>>>> or specifically with iperf3 (or other specifics), more >>>>>> detailed information to "collect and report . . ., collecting >>>>>> the information via the commands . . ." could help: more >>>>>> step-by-step. >>>>>> >>>>>> Also: Do you care between debug kernels vs. non-debug >>>>>> kernels? Debug ones of the appropriate vintage for head >>>>>> are available via artifacts.ci.freebsd.org but there >>>>>> might be performance consequences to using such. >>>>> >>>>> I put a copy of the -r362982 *debug* kernel from >>>>> artifacts.ci.freebsd.org on the Rock64 V2.0 that >>>>> I sometimes have access to. There are no hardware >>>>> mods to the Rock64 V2.0. >>>>> >>>>> It did DHCP to pick up an address just fine during >>>>> the boot. I ssh'd into it just fine after the boot. >>>>> >>>>> # uname -apKU >>>>> FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue >>> Jul 7 03:41:02 UTC 2020 >>> root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC >>> arm64 aarch64 1300100 1300092 >>>>> >>>>> # ifconfig >>>>> dwc0: flags=8843 metric 0 mtu >>> 1500 >>>>> options=80008 >>>>> ether # >>>>> hwaddr # >>>>> inet # netmask # broadcast # >>>>> media: Ethernet autoselect (1000baseT ) >>>>> status: active >>>>> nd6 options=29 >>>>> . . . >>>>> >>>>> I'll note that the Rock64 is the only thing running a debug >>>>> kernel for this note. >>>>> >>>>> An rsync copying an approximately 4 GiByte tar file to the Rock64 >>>>> reported: >>>>> >>>>> # rsync -axHh --info=progress2 --delete -r >>> /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >>>>> >>>>> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=0/1) >>>>> >>>>> I'll note that at times it listed over 32MB/s. The storage media >>>>> is a USB3 SSD plugged into the USB3 port. It has the Rock64's >>>>> root filesystem. >>>>> >>>>> For reference, locally duplicating the file on the Rock64 via >>>>> rsync reported: >>>>> >>>>> # rsync -axHh --info=progress2 -r >>> /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar >>>>> 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=0/1) >>>>> >>>>> (from/to: same media). I do not expect that the rsync over the >>>>> network was limited by the target media on the Rock64. >>>>> >>>>> Copying from the same machine to a large, fast machine instead >>>>> of to the Rock64: >>>>> >>>>> # rsync -axHh --info=progress2 --delete -r >>> /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >>>>> 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=0/1) >>>>> >>>>> So that should not be the side constraining the to-Rock64 >>>>> rate. >>>>> >>>>> Copying from the Rock64 to the large, fast machine: >>>>> >>>>> rsync -axHh --info=progress2 --delete -r >>> /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ >>>>> 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=0/1) >>>>> >>>>> It did not list figures much higher than above, so slower than >>>>> the copy to the Rock64 fairly generally. >>>>> >>>>> All this activity is over the local network, nothing remote. >>>>> All machines were running head -r360311 (non-debug), except >>>>> for the Rock64 having the -r362982 *debug* kernel instead. >>>>> >>>>> I hope that the above helps. >>>>> >>>>> I see that there are now iperf3 usage instructions so at some >>>>> point I may get that going and report the results, including >>>>> doing a non-debug kernel build and install. >>>>> >>>> >>>> Still using the debug kernel, but I figured I'd show >>>> the results from proving that I can get iperf3 to do >>>> the requested type of testing: >>>> >>>> # iperf3 -c 192.168.1.122 >>>> Connecting to host 192.168.1.122, port 5201 >>>> [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port >>> 5201 >>>> [ ID] Interval Transfer Bitrate Retr Cwnd >>>> [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 >>> KBytes >>>> [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 >>> KBytes >>>> - - - - - - - - - - - - - - - - - - - - - - - - - >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 >>> sender >>>> [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec >>> receiver >>>> >>>> # iperf3 -R -c 192.168.1.122 >>>> Connecting to host 192.168.1.122, port 5201 >>>> Reverse mode, remote host 192.168.1.122 is sending >>>> [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port >>> 5201 >>>> [ ID] Interval Transfer Bitrate >>>> [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec >>>> [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec >>>> [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec >>>> [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec >>>> [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec >>>> [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec >>>> [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec >>>> [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec >>>> [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec >>>> [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec >>>> - - - - - - - - - - - - - - - - - - - - - - - - - >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 >>> sender >>>> [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec >>> receiver >>>> >>>> I'll note that I run with the following in /etc/sysctl.conf : >>>> >>>> # The Rock64 does not seem to automatically adjust from 600MHz, >>>> # so do so manually. (The specifics likely would not be >>>> # appropriate to the RPi4/3.) >>>> dev.cpu.0.freq=1200 >>>> >>>> It is a historical artifact that I've not checked on the >>>> status of in a very long time: it works so I leave it >>>> there. >>> >>> Looks like it will be some time before I deal with >>> updating to a more modern kernel/world (non-debug). >>> >>> But I switched back to my non-debug head -r360311 >>> kernel (and dtb) build and here are the iperf3 >>> results for that context: >>> >>> # iperf3 -c 192.168.1.122 >>> Connecting to host 192.168.1.122, port 5201 >>> [ 5] local 192.168.1.109 port 39541 connected to 192.168.1.122 port 5201 >>> [ ID] Interval Transfer Bitrate Retr Cwnd >>> [ 5] 0.00-1.00 sec 73.6 MBytes 617 Mbits/sec 0 1.07 MBytes >>> >>> [ 5] 1.00-2.00 sec 72.9 MBytes 612 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 6.00-7.00 sec 72.7 MBytes 610 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes >>> >>> [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.00 sec 729 MBytes 611 Mbits/sec 0 >>> sender >>> [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec >>> receiver >>> >>> # iperf3 -R -c 192.168.1.122 >>> Connecting to host 192.168.1.122, port 5201 >>> Reverse mode, remote host 192.168.1.122 is sending >>> [ 5] local 192.168.1.109 port 50696 connected to 192.168.1.122 port 5201 >>> [ ID] Interval Transfer Bitrate >>> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec >>> [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 3.00-4.00 sec 84.4 MBytes 708 Mbits/sec >>> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec >>> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec >>> - - - - - - - - - - - - - - - - - - - - - - - - - >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 >>> sender >>> [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec >>> receiver >>> >>> >>> === >>> Mark Millard >>> marklmi at yahoo.com >>> ( dsl-only.net went >>> away in early 2018-Mar) >>> >>> _______________________________________________ >>> 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" >>> >> > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Tue Jul 7 17:54:45 2020 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 28D6634864D for ; Tue, 7 Jul 2020 17:54:45 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1VSh1QJ5z3fbM for ; Tue, 7 Jul 2020 17:54:43 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1594144479; cv=none; d=zohomail.com; s=zohoarc; b=N+bsox8LoDJA3s+88hHt84U8ogSBaEC/rb0VfjvZg3anM9xY8A477sk3ZjyQe0h61srQ+tUYVPm9fWDuAsy6pa3FAAJCuLCeIzgqLKwB5O1gVaewTkZHO9huPknma5fU3qt/ddXjINCtYAt5rR80YTbU6L2FMTw7BOT7+roX0zs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1594144479; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=9cx3m+prXGhIZRrkBiQVVYi94eWV5Nb+Zz9yhEMi1yE=; b=iEMLQBJrAHPUCloE/BD41SBZB7CSTbnKrwg8ukUZMc5Xr4Fid2dGhiu6ysAxjhulSfqejCKFQEGBCaLnhci7AY6BuLXWCqhKNR2jsm8ZbdNLZrKjX+GdtTNkguU2gfCOeLCs77MIPwVa1AGkGr1XQ2XQYLZ+opJAZneyOgxniY4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1594144479; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; bh=9cx3m+prXGhIZRrkBiQVVYi94eWV5Nb+Zz9yhEMi1yE=; b=oT7G10x3h9W8sCMUQQqcTlkUPI2EqHM8lMr0w5bCaPz6MT2pSBO/YSoDieyWNJAH 4N036wSis70kxewTvf764ci1MhTRosdMj/3svcehMmAZ20uBJJFaR4GBQj37AZSxFpL t5R4Q72rMbXVAcPj/VdLQyGQL9LBFVwaOh8dyBrI= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1594144478881896.8439891845621; Tue, 7 Jul 2020 10:54:38 -0700 (PDT) Date: Tue, 07 Jul 2020 20:54:38 +0300 From: Furkan Salman To: "Oleksandr Tymoshenko" Cc: "freebsd-arm" Message-Id: <1732a6a569a.de2d39ae730849.3150039489984939252@fkardame.com> In-Reply-To: <20200706204707.GA94158@bluezbox.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 MIME-Version: 1.0 Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 4B1VSh1QJ5z3fbM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=oT7G10x3; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-4.77 / 15.00]; NEURAL_HAM_MEDIUM(-1.07)[-1.075]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/23]; NEURAL_HAM_LONG(-1.01)[-1.006]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fkardame.com:~]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:54:45 -0000 SGVsbG8sCgoKCkkgYW0gcnVubmluZyBGcmVlQlNEIHVzaW5nIHMxOTlwd2ExazlyQCB0ZXN0IGlt YWdlIG92ZXIgUm9ja1BpRSB3ZSB3ZXJlIG9ubHkgYWJsZSB0byBnZXQgMSBsYW4gY2FyZCBvdXQg b2YgdGhlIDIuIFRoZSBvbmUgd29ya2luZyBpcyAxR2Igd2hpY2ggaXMgb3ZlciBSVEw4MjExRSwg dGhlcmUgaXMgYW5vdGhlciBMYW4gd2hpY2ggaXMgMTAwbWIgb25seSBhbmQgaXQgaXMgb25ib2Fy ZCByazMzMjggbGFuLiBXZSBjYW4gc2VlIHRoZSBsYW4gY2FyZCBidXQgaXQgaXMgbm90IGNvbWlu ZyB1cCBldmVuIGFmdGVyIHRyeWluZyB0byBicmluZyBpdCB1cCBtYW51YWxseS4KCgoKWW91IGNh biBmaW5kIHRoZSBib290bG9nIGF0dGFjaGVkIGhlcmUgPsKgaHR0cHM6Ly9oYXN0ZWJpbi5jb20v Ymlmb3l1d3Viby5jb2ZmZWVzY3JpcHQKCgoKQmVsb3cgaXMgbXkgZmluZGluZy4KCkJvb3Rsb2cg aW5mb3JtYXRpb24gYWJvdXQgdGhlIExhbiBjb25uZWN0aWlvbi4KCgoKZHdjMDogPFJvY2tjaGlw IEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlcj4gbWVtIDB4ZmY1NDAwMDAtMHhmZjU0ZmZmZiBp cnEgNDQgb24gb2Z3YnVzMMKgwqDCoMKgCgptaWlidXMwOiA8TUlJIGJ1cz4gb24gZHdjMMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoAoKcmdlcGh5MDogPFJUTDgxNjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBt ZWRpYSBpbnRlcmZhY2U+IFBIWSAwIG9uIG1paWJ1czDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAKCnJnZXBoeTA6wqAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJh c2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLG8KCnJnZXBo eTE6IDxSVEw4MTY5Uy84MTEwUy84MjExIDEwMDBCQVNFLVQgbWVkaWEgaW50ZXJmYWNlPiBQSFkg MSBvbiBtaWlidXMwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgpyZ2VwaHkx OsKgIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlcixvCgpkd2MwOiBFdGhlcm5ldCBhZGRyZXNzOiBk Mjo1NTozNTo1ZjowYTo2N8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoAoKZHdjMTogPFJvY2tjaGlwIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlcj4gbWVtIDB4 ZmY1NTAwMDAtMHhmZjU1ZmZmZiBpcnEgNDUgb24gb2Z3YnVzMMKgwqDCoMKgCgptaWlidXMxOiA8 TUlJIGJ1cz4gb24gZHdjMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKdWtwaHkwOiA8R2VuZXJpYyBJRUVF IDgwMi4zdSBtZWRpYSBpbnRlcmZhY2U+IFBIWSAwIG9uIG1paWJ1czHCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCnVrcGh5MDrCoCBu b25lLCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRv wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCmR3YzE6 IEV0aGVybmV0IGFkZHJlc3M6IDYyOjczOjY0OjVkOmUyOjIyCgoKCnJvb3RAcm9jay1waS1lOn4g IyBpZmNvbmZpZyAtYcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCmR3YzA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJV Tk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDCoCBvcHRpb25zPTgwMDA4PFZMQU5f TVRVLExJTktTVEFURT7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAKCsKgwqDCoMKgwqDCoMKgIGV0aGVyIGQyOjU1OjM1OjVmOjBhOjY3wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCsKgwqDC oMKgwqDCoMKgIGluZXQgMTkyLjE2OC4xLjE0IG5ldG1hc2sgMHhmZmZmZmYwMCBicm9hZGNhc3Qg MTkyLjE2OC4xLjI1NcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoAoKwqDCoMKgwqDCoMKgwqAgbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNl VCA8ZnVsbC1kdXBsZXg+KcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCsKgwqDCoMKgwqDCoMKgIHN0YXR1czogYWN0aXZlwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCsKgwqDCoMKgwqDCoMKgIG5kNiBvcHRpb25zPTI5PFBF UkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgpkd2MxOiBmbGFncz04 ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUg MTUwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKwqDCoMKgwqDCoMKgwqAg b3B0aW9ucz04MDAwODxWTEFOX01UVSxMSU5LU1RBVEU+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDCoCBldGhlciA2Mjo3Mzo2NDo1ZDpl MjoyMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDCoCBtZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAo bm9uZSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCsKgwqDC oMKgwqDCoMKgIHN0YXR1czogbm8gY2FycmllcsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKwqDCoMKgwqDC oMKgwqAgbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FM PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAKCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4g bWV0cmljIDAgbXR1IDE2Mzg0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDCoCBvcHRpb25zPTY4MDAwMzxSWENTVU0sVFhD U1VNLExJTktTVEFURSxSWENTVU1fSVBWNixUWENTVU1fSVBWNj7CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCsKgwqDCoMKgwqDCoMKgIGluZXQ2IDo6MSBwcmVmaXhs ZW4gMTI4wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAKCsKgwqDCoMKgwqDCoMKgIGluZXQ2IGZlODA6OjElbG8wIHByZWZpeGxl biA2NCBzY29wZWlkIDB4M8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKwqDCoMKgwqDCoMKg wqAgaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAwwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDCoCBncm91cHM6IGxvwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKwqDCoMKgwqDCoMKgwqAgbmQ2IG9wdGlvbnM9 MjE8UEVSRk9STU5VRCxBVVRPX0xJTktMT0NBTD7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oAoKcm9vdEByb2NrLXBpLWU6fiAjCgoKCmlwZXJmMyBzZXJ2ZXIgaXMgcnVubmluZyBvbiBteSBY ODYgTGFwdG9wIG92ZXIgd2lmaSBhcyBJIGhhdmUgYSBzaG9ydGFnZSBvZiBsYW4gY2FibGUgdG9u aWdodC4gSWYgbmVlZGVkIEkgY2FuIGFycmFuZ2UgaXQgdG9tb3Jyb3cgYW5kIHNoYXJlIGFub3Ro ZXIgaXBlcmYgcmVzdWx0IHdpdGggYm90aCBkZXZpY2VzIG9uIDFHYiBsYW4gY29ubmVjdGlvbi4K CgoKcm9vdEByb2NrLXBpLWU6fiAjIGlwZXJmMyAtYyAxOTIuMTY4LjEuMTXCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKCkNvbm5lY3RpbmcgdG8gaG9zdCAxOTIu MTY4LjEuMTUsIHBvcnQgNTIwMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAKClvCoCA1XSBsb2NhbCAxOTIuMTY4LjEuMTQgcG9ydCAyMjM5NiBjb25uZWN0ZWQgdG8g MTkyLjE2OC4xLjE1IHBvcnQgNTIwMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoAoKWyBJRF0gSW50ZXJ2YWzCoMKgwqDCoMKgwqDCoMKgwqDCoCBUcmFuc2ZlcsKgwqDC oMKgIEJpdHJhdGXCoMKgwqDCoMKgwqDCoMKgIFJldHLCoCBDd25kwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClvCoCA1XcKgwqAgMC4wMC0x LjAwwqDCoCBzZWPCoCAxMS4xIE1CeXRlc8KgIDkzLjIgTWJpdHMvc2VjwqDCoMKgIDDCoMKgwqAg NTY3IEtCeXRlc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8Kg IDVdwqDCoCAxLjAwLTIuMDDCoMKgIHNlY8KgIDkuMTUgTUJ5dGVzwqAgNzYuNyBNYml0cy9zZWPC oMKgwqAgMMKgwqDCoCA1NzIgS0J5dGVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgCgpbwqAgNV3CoMKgIDIuMDAtMy4wMMKgwqAgc2VjwqAgNi40OCBNQnl0ZXPCoCA1 NC40IE1iaXRzL3NlY8KgwqDCoCAwwqDCoMKgIDU3NSBLQnl0ZXPCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClvCoCA1XcKgwqAgMy4wMC00LjAwwqDCoCBzZWPCoCA1 LjczIE1CeXRlc8KgIDQ4LjEgTWJpdHMvc2VjwqDCoMKgIDDCoMKgwqAgNTc4IEtCeXRlc8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCA0LjAwLTUu MDDCoMKgIHNlY8KgIDUuOTMgTUJ5dGVzwqAgNDkuNiBNYml0cy9zZWPCoMKgwqAgMMKgwqDCoCA1 ODIgS0J5dGVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgpbwqAg NV3CoMKgIDUuMDAtNi4wMMKgwqAgc2VjwqAgNi4zNSBNQnl0ZXPCoCA1My40IE1iaXRzL3NlY8Kg wqDCoCAwwqDCoMKgIDU4NSBLQnl0ZXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAKClvCoCA1XcKgwqAgNi4wMC03LjAwwqDCoCBzZWPCoCA5LjM1IE1CeXRlc8KgIDc4 LjUgTWJpdHMvc2VjwqDCoMKgIDDCoMKgwqAgNTkxIEtCeXRlc8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCA3LjAwLTguMDDCoMKgIHNlY8KgIDcu MzcgTUJ5dGVzwqAgNjEuOCBNYml0cy9zZWPCoMKgwqAgMMKgwqDCoCA1OTQgS0J5dGVzwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgpbwqAgNV3CoMKgIDguMDAtOS4w MMKgwqAgc2VjwqAgOS42NyBNQnl0ZXPCoCA4MS4yIE1iaXRzL3NlY8KgwqDCoCAwwqDCoMKgIDU5 OCBLQnl0ZXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClvCoCA1 XcKgwqAgOS4wMC0xMC4wMMKgIHNlY8KgIDYuMjYgTUJ5dGVzwqAgNTIuNCBNYml0cy9zZWPCoMKg wqAgMMKgwqDCoCA2MDEgS0J5dGVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgCgotIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClsgSURdIEludGVydmFswqDCoMKgwqDCoMKg wqDCoMKgwqAgVHJhbnNmZXLCoMKgwqDCoCBCaXRyYXRlwqDCoMKgwqDCoMKgwqDCoCBSZXRywqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAKClvCoCA1XcKgwqAgMC4wMC0xMC4wMMKgIHNlY8KgIDc3LjQgTUJ5dGVzwqAgNjQu OSBNYml0cy9zZWPCoMKgwqAgMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzZW5kZXLCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCAwLjAwLTEwLjg1wqAgc2VjwqAg NzYuNiBNQnl0ZXPCoCA1OS4yIE1iaXRzL3NlY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgcmVjZWl2ZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg CgppcGVyZiBEb25lLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg Cgpyb290QHJvY2stcGktZTp+ICMgaXBlcmYzIC1SIC1jIDE5Mi4xNjguMS4xNcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKQ29ubmVjdGluZyB0byBob3N0IDE5Mi4xNjgu MS4xNSwgcG9ydCA1MjAxwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oAoKUmV2ZXJzZSBtb2RlLCByZW1vdGUgaG9zdCAxOTIuMTY4LjEuMTUgaXMgc2VuZGluZ8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgpbwqAgNV0gbG9jYWwgMTkyLjE2OC4xLjE0IHBvcnQg MzA5OTUgY29ubmVjdGVkIHRvIDE5Mi4xNjguMS4xNSBwb3J0IDUyMDHCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClsgSURdIEludGVydmFswqDCoMKgwqDCoMKgwqDC oMKgwqAgVHJhbnNmZXLCoMKgwqDCoCBCaXRyYXRlwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoAoKW8KgIDVdwqDCoCAwLjAwLTEuMDDCoMKgIHNlY8KgIDUuOTIgTUJ5dGVzwqAg NDkuNyBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCAxLjAwLTIu MDDCoMKgIHNlY8KgIDMuMzAgTUJ5dGVzwqAgMjcuNyBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoAoKW8KgIDVdwqDCoCAyLjAwLTMuMDDCoMKgIHNlY8KgIDIuODggTUJ5dGVzwqAgMjQu MiBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCAzLjAwLTQuMDDC oMKgIHNlY8KgIDMuMjcgTUJ5dGVzwqAgMjcuNCBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoAoKW8KgIDVdwqDCoCA0LjAwLTUuMDDCoMKgIHNlY8KgIDQuNTMgTUJ5dGVzwqAgMzguMCBN Yml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCA1LjAwLTYuMDDCoMKg IHNlY8KgIDQuMjIgTUJ5dGVzwqAgMzUuNCBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oAoKW8KgIDVdwqDCoCA2LjAwLTcuMDDCoMKgIHNlY8KgIDIuODIgTUJ5dGVzwqAgMjMuNyBNYml0 cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCA3LjAwLTguMDDCoMKgIHNl Y8KgIDMuNzAgTUJ5dGVzwqAgMzEuMCBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoK W8KgIDVdwqDCoCA4LjAwLTkuMDDCoMKgIHNlY8KgIDMuNTIgTUJ5dGVzwqAgMjkuNSBNYml0cy9z ZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKW8KgIDVdwqDCoCA5LjAwLTEwLjAwwqAgc2VjwqAg My40MyBNQnl0ZXPCoCAyOC44IE1iaXRzL3NlY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgCgotIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAKClsgSURdIEludGVydmFswqDCoMKgwqDCoMKgwqDCoMKgwqAgVHJh bnNmZXLCoMKgwqDCoCBCaXRyYXRlwqDCoMKgwqDCoMKgwqDCoCBSZXRywqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAKClvC oCA1XcKgwqAgMC4wMC0xMC44MMKgIHNlY8KgIDM4LjAgTUJ5dGVzwqAgMjkuNSBNYml0cy9zZWPC oCAyNjjCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2VuZGVywqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAKClvCoCA1XcKgwqAgMC4wMC0xMC4wMMKgIHNlY8KgIDM3LjYgTUJ5dGVzwqAg MzEuNSBNYml0cy9zZWPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlY2VpdmVy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKaXBlcmYgRG9uZS7C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoAoKCgoKCklmIHRoZXJlIGlzIGFueXRoaW5nIGVsc2Ug SSBjYW4gaGVscCB5b3Ugd2l0aCB0aGVuIHBsZWFzZSBsZXQgbWUga25vdy4KCgoKVGhhbmsgeW91 LgoKRnVya2FuLgoKCgoKCgotLS0tIE9uIE1vbiwgMDYgSnVsIDIwMjAgMjM6NDc6MDcgKzAzMDAg T2xla3NhbmRyIFR5bW9zaGVua28gPGdvbnpvQGJsdWV6Ym94LmNvbT4gd3JvdGUgLS0tLQoKCgpG dXJrYW4gU2FsbWFuIChtYWlsdG86ZnVya2FuQGZrYXJkYW1lLmNvbSkgd3JvdGU6IAo+IEhlbGxv IFBldGVyLCAKPiAKPiBJIGhhdmUgcm9ja3BpRSB3aGljaCBpcyBzb21ld2hhdCBzaW1pbGFyIHRv IFJvY2s2NCwgSWYgczEzM3B3YTFrOXJAIG9yIGdvbnpvQCBjYW4gY29uZmlybSBpZiByb2NrcGll IGNhbiBiZSB1c2VkIHRvIHRlc3QgUkszMzI4IExhbiBpc3N1ZSB0aGVuIEkgYW0gaGFwcHkgdG8g aGVscCB3aXRoIHRlc3RpbmcuIAogCiAKSGkgRnVya2FuLCAKIApZZXMsIFJvY2tQaSBFIHNlZW1z IHRvIGJlIGEgZ29vZCB0ZXN0IHRhcmdldC4gSWYgeW91IGNvdWxkIGNoZWNrIHRoZSAKR2lnRSBp bnRlcmZhY2UgYmVmb3JlIGFuZCBhZnRlciB0aGUgcGF0Y2guIFdoZXRoZXIgaXQgd29ya3MvZG9l c24ndCB3b3JrIAphbmQgaWYgaXQgd29ya3MgaW4gYm90aCBjYXNlcyAtIHRyeSB0ZXN0aW5nIHBl cmZvcm1hbmNlIHdpdGggaXBlcmYzLCAKanVzdCB0byBzZWUgaWYgcGVyZm9ybWFuY2Ugd2FzIGFm ZmVjdGVkIGluIGFueSB3YXkuIAogClRoYW5rcyAKIAotLSAKZ29uem8= From owner-freebsd-arm@freebsd.org Wed Jul 8 01:28:09 2020 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 31E353524FE for ; Wed, 8 Jul 2020 01:28:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1hWq6Lpzz4KpH for ; Wed, 8 Jul 2020 01:28:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: T6R8aBMVM1mmDa_k1Zs68XtfD4h1ytnMVrxcQNSH1.ZjEuW65ALguBdL36KdllP heL_BTKWVVmDiTpPucxciMGoxWNhKb8vOqeULKl8mhwkuA8IHb8EuD2LGZRTunp.GIuuuYQR7TWY Fphy7AepSEu5ewlwMNAoB963gzM8m6XxuN9gK9gJlPIZcMpzinJvaVhMAal8zZXh0Po3EVU2_DGG EGXBt4adV8cIwsPWwjFTEYQBnWOWv.vAHdukoa4xVyKlpprhKKlSS8wV7r29IknvMhsoeJwyhYel YIaV0XXmI7_jw0lA49z9FGbObLzG5.4qsV8EsJodcRJ71iLktkj06_GJ6XJvqUKGR397Q_46xdnV aj0gnYJhV62Sx2NEYMTBOWqv6OHAYKlgKRTiXLcghfgsFv58GRcb0wIO5RojOqNeJfcnkg4ZytzC sYKEWr_3INmoxLECB9nN.2mivs7aBWNr_58m07oYME3vosHU91dQ2eSfWDxqFZnOGr8LxCB4tDFh kUpxToNLk.o1pwI0vkupWgTAwp2yUbZ9MlY7mk4edY4VITJnnM7eC9rjHceXquOsWtKQ5N9Typym FSr6zbIM5RITa5mTD3vT.mkRr6qZPGOTlH6PAyea0B0cVZWYSvfPTVa5eWOuoZWrNnaBOaDMhq1f RbFet3f5C1HEKnGReunYeIwX2ybT2G1S9T.n0QiBrpeUzFOLF85wTKjGIQiv8I3D.SPenxAFUANK LwVGRlOG6wVpQ_arSojVGJysVGDVV5cNO8IyPhvrRCNne09egBto0S474LPG2vi0nyOcCytlgbcE EN1fWL.W8mJYKnUCX.18zX7oluepz0SZoCRsdAmibUVg9J2OeqcliS.oLsUF95w0zXxr4uqHyP5Y p6zNGZmuWCEZYClQRI47fCgkogsYdZGyXbUfuSFdwrXyGNfNk.kqX3psHmCSV4CWoeUzZYYKKV4u AWw3dBCogx8wIARCtGo96bdq8mdYZxGAGM5Fh8PdPf0RFhSWch_ig2u4xnWOe1D2qPgvNV4ii1l4 KQJE6Y6hdJ4p9LZqCfGVJbOmskEyBrcb30J8Px4qM5R2vWEH0DWw9IWN.Bhd8oDYzH0Wf20l7hKH sYg8Tpye1XiowY0IsswmDhg1vKDfP8pOwFwTGg9TAdZ21qF7uL1F5QbveZMJBC6EKt3NcW6Q_BZ5 0U2_Ws948tRTNVAusDFU2yec4ksJr2JzMdRqlyWHzLrfIKQ6ppesna5dgKGeZwpvPFz8TbrwGPtI DHfGwz_lh9QrF1NtfW_eglDf5Upi7CQ10imFfs2VHc9M9sRxajpI22mRyIZxI.ly9kIVlxeWxXo7 W5GIT_wyYuUKgIUC3hqan31LAa5K8_Pe95ZFLRTD1WicAWFe4at5B1pBP1GYaXkRuHFKf74Je3i7 tId2B.Y_5SDbDnualnug1Rn1SJWI6Vw_gnfrhur1nL9_GTMUmG4IgKCom51vJO80mT4I- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jul 2020 01:28:06 +0000 Received: by smtp431.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7f4c36dff4f22e02d53141e0627ae18d; Wed, 08 Jul 2020 01:28:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: Date: Tue, 7 Jul 2020 18:27:59 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> To: Oleksandr Tymoshenko , Peter Jeremy X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1hWq6Lpzz4KpH X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.01)[-1.006]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; NEURAL_HAM_SHORT(-0.24)[-0.238]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 01:28:09 -0000 Any chance that the delays (or other parameters) depend on the operating temperature(s) of some parts? If yes, then some of the following about the Rock64 V2 context that I have access to might be relevant to explaining my already reported V2 results (not much for Retr): A) The Rock64 has a "case" that is really just a top and a bottom with posts: open on all 4 sides. B) It has a fan blowing down on the board from the top. C) It has a heat sink on the SOC, which the fan blows on directly. D) It has a heat sink on the RAM, which the fan also blows on directly. (I've not dealt with a more modern non-debug kernel build yet. It still may be some time before I deal with that.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jul 8 02:12:36 2020 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 78B503535A6 for ; Wed, 8 Jul 2020 02:12:36 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 4B1jW71ldtz4MxF for ; Wed, 8 Jul 2020 02:12:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jszZT-000Kpd-7f; Tue, 07 Jul 2020 19:12:28 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 0682CQ79080080; Tue, 7 Jul 2020 19:12:26 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 7 Jul 2020 19:12:26 -0700 From: Oleksandr Tymoshenko To: Mark Millard Cc: Peter Jeremy , freebsd-arm Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) Message-ID: <20200708021226.GA77884@bluezbox.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Mark Millard (marklmi@yahoo.com) wrote: > Any chance that the delays (or other parameters) depend > on the operating temperature(s) of some parts? > > If yes, then some of the following about the Rock [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B1jW71ldtz4MxF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.62 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.928]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.40)[-0.405]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 02:12:36 -0000 Mark Millard (marklmi@yahoo.com) wrote: > Any chance that the delays (or other parameters) depend > on the operating temperature(s) of some parts? > > If yes, then some of the following about the Rock64 V2 > context that I have access to might be relevant to > explaining my already reported V2 results (not much > for Retr): > > A) The Rock64 has a "case" that is really just a top > and a bottom with posts: open on all 4 sides. > > B) It has a fan blowing down on the board from the > top. > > C) It has a heat sink on the SOC, which the fan blows > on directly. > > D) It has a heat sink on the RAM, which the fan also > blows on directly. > > (I've not dealt with a more modern non-debug kernel > build yet. It still may be some time before I deal > with that.) Temperature is not likely to be a factor in the delay values. Rock64 V2 has a known issue with Gigabit ethernet stability: https://forum.pine64.org/showthread.php?tid=7545 https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ Althought judging by description it's more like an almost complete network lock-up and not performance degradation. I received another board with RK3328 today and will investigate the issue further. -- gonzo From owner-freebsd-arm@freebsd.org Wed Jul 8 04:52:22 2020 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 2166F356AC7 for ; Wed, 8 Jul 2020 04:52:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1n3S6Ghgz4VkL for ; Wed, 8 Jul 2020 04:52:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MzORMboVM1mvlLYlILlcyTUw6J.MhT9ZwrgKjomTLKTLv3VgyYB3Bywo32kEUWj nL_NiY27zK9d03LMLKMB7svwqADj418blocA_..eefO3UgpT6h1rvnEj6a2Rv2RZKbQ6pnMDaaCq EPJQOcHQzHEUJyjWVWWMe002.h7yIfiB1ZBxzdn8fcyPlPGK5.BcG4IeELgfHdH9gAG4oPY34t9o ybxCWs3B_mbKOqrtKyvZGdJ59WFOdyrb0y91_zaiAblpbpSjXULgEoRGsWW8gUL1HuX23iIEEwC7 jjVSXmkZq0bGeauiMk4dt8i_QzoIcxho3xsLBSjZPcLIW7EGb6fIF.GG7EzBYg8HNbl.pvkAjuwG 2SnobeGNutRlhyAFTAY.9GFkgFsjMHmJweaNf91Va91SUugkm2xUonpTgglGQvleEZeFigrtn3xA cgy7fUFmoA8V7NtBs2VvM.Lo4qKX0tHEJomVRBbUckE8_Qre1dFl3NQ7kQrvsZXCVG2eXlfKgoeq GtgPxmBpe210Dif78Vm55E1IZTddEF7MUR.wOQoUXooobl33RMN9Xvr0mtEhMl_aOqR1WnV.BHRq Gok36EMuhj5FvZCQyCbXW6CsMaRqV2s7KyoDL4v0q1R0U.mOFnQccgfAKsmjHk32MIBlfLPANtc0 vj0h9QN.yogTWIp7vhS9NqfZ86TsUFGyOVNm58SqzLeSyya8sgvXFMcc98cJ8NYjTjEpwzXqNlyF Gm1PnFfUYQSxcwP8vqfG5KI3b97Pbd_J9XObKY1IrkMomzWpWFOqBrPrph5fPizsINcMgeAMT6FL fQS_5TUnz6b5yoHXCJwb43hpcpfPyGd4c6UoV84JNKDYBnOPFajblOCS5gb2F.aCeLxrgmNLSTBk keMNRN2WE1TTv9sQW1EYX.4vuDeaT3bX8ZTvN4wKlQEbp.bvxHWQaZeFbWlCHnOrdgnyBc8DUAVo WlBUYNLwvkKmMr1pcKzEUZ3goGoNI3qZ1ohCzxo7Wjj6C1T5SDVuqPBic9BaGe7DM3Ajcbz1edkF VE3FadP.D5Cz.CLlRhPiiHsGUgoS_IO9f6OcVi2EiLPiTRrynf4ovFuLS1.0q9M2LV1g2wSnLm6e e1a8ngoZPmz3k2QsPIP0hDeCh0tf9A26FA8XfCjsuJGOaR86euyP.Z.R0lOupakdfTu7R.mSqTop BKREFvS77OjFQyIItiVCw8PuUOygJbmTGc4gRz0X.s5MBHFcMSsNw9jlh7XjjqLYX2mBGoTAmyZH Cdyb5UMogtIjc21WoW2zB5IQtaC._uXdGze8S1eV.K.gmqzlkF67oJIZ_eTVWV3WGdmsa8NPKHCl Id7LapeOYo5_FjDcCSnUhS7veZcpoe4kfhZu3TNoLksVyRDZzjdB6aqfmfPL3k_f_SaKrbiL6zY3 YjAxa6M1KA1wHoK83NjugaGR2gcSQPI.sTrmiLYSzuPpqhfzc3U8uMGCwt9L5iYU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jul 2020 04:52:19 +0000 Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 77406799c0ff0b228de6c20a6da621af; Wed, 08 Jul 2020 04:52:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: <20200708021226.GA77884@bluezbox.com> Date: Tue, 7 Jul 2020 21:52:14 -0700 Cc: Peter Jeremy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> <20200708021226.GA77884@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1n3S6Ghgz4VkL X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.002]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; NEURAL_HAM_SHORT(-0.26)[-0.260]; NEURAL_HAM_MEDIUM(-1.03)[-1.034]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 04:52:22 -0000 On 2020-Jul-7, at 19:12, Oleksandr Tymoshenko = wrote: > Mark Millard (marklmi at yahoo.com) wrote: >> Any chance that the delays (or other parameters) depend >> on the operating temperature(s) of some parts? >>=20 >> If yes, then some of the following about the Rock64 V2 >> context that I have access to might be relevant to >> explaining my already reported V2 results (not much >> for Retr): >>=20 >> A) The Rock64 has a "case" that is really just a top >> and a bottom with posts: open on all 4 sides. >>=20 >> B) It has a fan blowing down on the board from the >> top. >>=20 >> C) It has a heat sink on the SOC, which the fan blows >> on directly. >>=20 >> D) It has a heat sink on the RAM, which the fan also >> blows on directly. >>=20 >> (I've not dealt with a more modern non-debug kernel >> build yet. It still may be some time before I deal >> with that.) >=20 > Temperature is not likely to be a factor in the delay values. > Rock64 V2 has a known issue with Gigabit ethernet stability: >=20 > https://forum.pine64.org/showthread.php?tid=3D7545 > https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ >=20 > Althought judging by description it's more like an almost complete > network lock-up and not performance degradation. >=20 > I received another board with RK3328 today and will investigate > the issue further. Okay. Looks like I should have copied iperf3 output from the server side as well: somewhat different information. The output was still available from the earlier runs so here it is . . . The modern debug-kernel runs: Accepted connection from 192.168.1.109, port 47111 [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 17015 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 17.5 MBytes 147 Mbits/sec =20 [ 5] 1.00-2.00 sec 45.3 MBytes 380 Mbits/sec =20 [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec =20 [ 5] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 5] 4.00-5.00 sec 44.9 MBytes 377 Mbits/sec =20 [ 5] 5.00-6.00 sec 45.1 MBytes 379 Mbits/sec =20 [ 5] 6.00-7.00 sec 44.5 MBytes 373 Mbits/sec =20 [ 5] 7.00-8.00 sec 45.0 MBytes 378 Mbits/sec =20 [ 5] 8.00-9.00 sec 44.9 MBytes 377 Mbits/sec =20 [ 5] 9.00-10.00 sec 44.5 MBytes 373 Mbits/sec =20 [ 5] 10.00-10.62 sec 27.9 MBytes 379 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec = receiver Accepted connection from 192.168.1.109, port 22375 [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 54738 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 24.7 MBytes 207 Mbits/sec 0 265 KBytes = =20 [ 5] 1.00-2.00 sec 61.6 MBytes 517 Mbits/sec 4 211 KBytes = =20 [ 5] 2.00-3.00 sec 61.4 MBytes 515 Mbits/sec 1 352 KBytes = =20 [ 5] 3.00-4.00 sec 61.3 MBytes 514 Mbits/sec 4 269 KBytes = =20 [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec 2 355 KBytes = =20 [ 5] 5.00-6.00 sec 61.3 MBytes 514 Mbits/sec 3 304 KBytes = =20 [ 5] 6.00-7.00 sec 61.3 MBytes 514 Mbits/sec 2 327 KBytes = =20 [ 5] 7.00-8.00 sec 61.4 MBytes 515 Mbits/sec 5 278 KBytes = =20 [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec 2 393 KBytes = =20 [ 5] 9.00-10.00 sec 61.4 MBytes 515 Mbits/sec 3 284 KBytes = =20 [ 5] 10.00-10.61 sec 37.3 MBytes 514 Mbits/sec 2 282 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 = sender (So a fairly consistent Retr rate.) The non-debug head -r360311 kernel runs: Accepted connection from 192.168.1.109, port 46431 [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 39541 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 50.3 MBytes 422 Mbits/sec =20 [ 5] 1.00-2.00 sec 72.7 MBytes 610 Mbits/sec =20 [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec =20 [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec =20 [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec =20 [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec =20 [ 5] 6.00-7.00 sec 72.8 MBytes 611 Mbits/sec =20 [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec =20 [ 5] 8.00-9.00 sec 72.8 MBytes 610 Mbits/sec =20 [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec =20 [ 5] 10.00-10.32 sec 23.4 MBytes 612 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec = receiver Accepted connection from 192.168.1.109, port 40223 [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 50696 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 78.5 MBytes 659 Mbits/sec 0 480 KBytes = =20 [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 747 KBytes = =20 [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 940 KBytes = =20 [ 5] 3.00-4.00 sec 84.5 MBytes 709 Mbits/sec 52 368 KBytes = =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 681 KBytes = =20 [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 889 KBytes = =20 [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 1.03 MBytes = =20 [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 1.17 MBytes = =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 125 KBytes = =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 3 586 KBytes = =20 [ 5] 10.00-10.31 sec 34.7 MBytes 942 Mbits/sec 0 667 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 = sender So: Larger total Retr than the modern debug kernel case but not a fairly consistent rate of Retr values. I've still not dealt with updating to a modern non-debug environment to test it. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jul 8 07:27:26 2020 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 34DC1359B92 for ; Wed, 8 Jul 2020 07:27:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1rVP0tHFz4dxh for ; Wed, 8 Jul 2020 07:27:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gw22JSEVM1kpL9rQ2PsGvzpULrE4FohjFwP.fF_qoO7G7nDOVLYXSd_MPBcgf2L nb4sPEM_CzPis0pZZg3PKAKLF5lGp1XA9.FfsoXuPFS8YEKze1WpTPI9JHzEUbdVArgJhy5jSitW gDkjG.AaXZCggfopJ.kO9afGKPTW_AqHW2a4wF3SYRwz5d2WIboT2mfOTuHiQUOe3xLETG8J7Dt2 bEqpbopc2v2BoSz2ZYrRmEOEN2qJgksx9vvuWy_SfvPgl4Yjuha7RES3slroh7I3aO1QjOd.SjOQ MOm6VrFGYIhgPNqQpLAP2fkaXh0raN6JWAdipJrA4xYIGHSpDzzUYncHEUrBpqHmeYsJFgUpB53x zhmKZ1rfMwIkCs3tE6ysvSYkoYzsrAiyo.AYCvmwRpMlr5u3Z.ZrkwaiUKHGkFvVGm7h17LgU1.s 7heapJPpxVlz6TUvZMMBfYx1JVwmpW6tKMUwC_XRz7vsrcj3sEod7LGtFC3F0JQeYnGA367JUuAE tNca1VUnli37pzdCOMqIcokQRUQZuWQKxY7YzkLj.OMgSspY_x3x2d4ARlUD06TcbWrU4Q5AIvnI Zaytn0TAuw6GuD.l4jmJTLRErDh6DJ60mqOfOv8Up1NiZKasIM1iby9utUH6ak1WgOXVR8iyBoTd vzrQHjAWtmfWBEzXD.ISOpUi96flDcR7ZaPBaTcG_IVmAh49MbZiKprSfMaQ5NIfUjq_NSBE09Q4 CizJkMA8QcPKDWFQoPWyxbYuLYhnFfN.WLSDAG1suBep3FS9Nb_zURQosY1vHDrB4mysmrUAWqnZ aNriP_nMLID255nEZigVOfN6wrIoBCMqV6FblqC2QRLcROJXNsHWqwbr6xoYVEIXuwmswjF2mdqe DD9RqJkqWV3XdIL6WtI2uszXeD8LrBdj0d2x9yN13.DdCkCivgtIjHtXqpVRKCT8yR9Jp_AqKC56 .dstbGKq43DQ8TRw7eDrWQ7_TpU2Y5ZPY7.DdF1pnoPElAWviOFrvJO77VhqPsmj2fdWmyJONzEz yyWPj428bwDX8_4qxsXCejOrGDehgxzAp.JTD6iGcUfqdAl9RIiKr2GnWLgis7Z_cFc9dxSzQt15 3djXCN.FvwT_EKba_._k4Q1jNWsjAijJfPUm5ppm_wqySxcX4tzZqzv4K9rOrfCLKgmXGm7ljXV3 cQLShmbpse5Te4ujF0NthiobhiVe4jf2Uh.YqZ8haV9hFRGG0zX9jtWrKKhEy8OVB4hcl4rSjH5F p0AHIBlnmgTXF4A_DZBbNeqhUzB3kny2mcl46FtHDszZEvcosNkEBZgQrnLSSbAK_bkAalAY3rzQ fpeIvh52N4FHp7w3gy_yWPAi.OEJGPlhV3v9ugUC0tQePwy.cEO.vO1mhwiDhhPxv3u5ogKUXFN1 DeHsBdTXhhCpIhacl2bQRWMAai5vInvuErwbLD3OOvzgXFA6cHIlL.TfGGA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jul 2020 07:27:23 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e832bf499e19fd17610ceb450509e4cd; Wed, 08 Jul 2020 07:27:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: Date: Wed, 8 Jul 2020 00:27:19 -0700 Cc: Peter Jeremy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4AA1D1FD-F9A4-400E-80FA-C1888F399602@yahoo.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> <20200708021226.GA77884@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1rVP0tHFz4dxh X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.002]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; NEURAL_HAM_SHORT(-0.85)[-0.845]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 07:27:26 -0000 On 2020-Jul-7, at 21:52, Mark Millard wrote: > On 2020-Jul-7, at 19:12, Oleksandr Tymoshenko = wrote: >=20 >> Mark Millard (marklmi at yahoo.com) wrote: >>> Any chance that the delays (or other parameters) depend >>> on the operating temperature(s) of some parts? >>>=20 >>> If yes, then some of the following about the Rock64 V2 >>> context that I have access to might be relevant to >>> explaining my already reported V2 results (not much >>> for Retr): >>>=20 >>> A) The Rock64 has a "case" that is really just a top >>> and a bottom with posts: open on all 4 sides. >>>=20 >>> B) It has a fan blowing down on the board from the >>> top. >>>=20 >>> C) It has a heat sink on the SOC, which the fan blows >>> on directly. >>>=20 >>> D) It has a heat sink on the RAM, which the fan also >>> blows on directly. >>>=20 >>> (I've not dealt with a more modern non-debug kernel >>> build yet. It still may be some time before I deal >>> with that.) >>=20 >> Temperature is not likely to be a factor in the delay values. >> Rock64 V2 has a known issue with Gigabit ethernet stability: >>=20 >> https://forum.pine64.org/showthread.php?tid=3D7545 >> https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ >>=20 >> Althought judging by description it's more like an almost complete >> network lock-up and not performance degradation. >>=20 >> I received another board with RK3328 today and will investigate >> the issue further. >=20 > Okay. >=20 > Looks like I should have copied iperf3 output from the server > side as well: somewhat different information. The output was > still available from the earlier runs so here it is . . . >=20 > The modern debug-kernel runs: >=20 > Accepted connection from 192.168.1.109, port 47111 > [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 17015 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 17.5 MBytes 147 Mbits/sec =20= > [ 5] 1.00-2.00 sec 45.3 MBytes 380 Mbits/sec =20= > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec =20= > [ 5] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec =20= > [ 5] 4.00-5.00 sec 44.9 MBytes 377 Mbits/sec =20= > [ 5] 5.00-6.00 sec 45.1 MBytes 379 Mbits/sec =20= > [ 5] 6.00-7.00 sec 44.5 MBytes 373 Mbits/sec =20= > [ 5] 7.00-8.00 sec 45.0 MBytes 378 Mbits/sec =20= > [ 5] 8.00-9.00 sec 44.9 MBytes 377 Mbits/sec =20= > [ 5] 9.00-10.00 sec 44.5 MBytes 373 Mbits/sec =20= > [ 5] 10.00-10.62 sec 27.9 MBytes 379 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec = receiver >=20 > Accepted connection from 192.168.1.109, port 22375 > [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 54738 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 24.7 MBytes 207 Mbits/sec 0 265 = KBytes =20 > [ 5] 1.00-2.00 sec 61.6 MBytes 517 Mbits/sec 4 211 = KBytes =20 > [ 5] 2.00-3.00 sec 61.4 MBytes 515 Mbits/sec 1 352 = KBytes =20 > [ 5] 3.00-4.00 sec 61.3 MBytes 514 Mbits/sec 4 269 = KBytes =20 > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec 2 355 = KBytes =20 > [ 5] 5.00-6.00 sec 61.3 MBytes 514 Mbits/sec 3 304 = KBytes =20 > [ 5] 6.00-7.00 sec 61.3 MBytes 514 Mbits/sec 2 327 = KBytes =20 > [ 5] 7.00-8.00 sec 61.4 MBytes 515 Mbits/sec 5 278 = KBytes =20 > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec 2 393 = KBytes =20 > [ 5] 9.00-10.00 sec 61.4 MBytes 515 Mbits/sec 3 284 = KBytes =20 > [ 5] 10.00-10.61 sec 37.3 MBytes 514 Mbits/sec 2 282 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 = sender >=20 > (So a fairly consistent Retr rate.) >=20 > The non-debug head -r360311 kernel runs: >=20 > Accepted connection from 192.168.1.109, port 46431 > [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 39541 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 50.3 MBytes 422 Mbits/sec =20= > [ 5] 1.00-2.00 sec 72.7 MBytes 610 Mbits/sec =20= > [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec =20= > [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec =20= > [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec =20= > [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec =20= > [ 5] 6.00-7.00 sec 72.8 MBytes 611 Mbits/sec =20= > [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec =20= > [ 5] 8.00-9.00 sec 72.8 MBytes 610 Mbits/sec =20= > [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec =20= > [ 5] 10.00-10.32 sec 23.4 MBytes 612 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec = receiver >=20 > Accepted connection from 192.168.1.109, port 40223 > [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 50696 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 78.5 MBytes 659 Mbits/sec 0 480 = KBytes =20 > [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 747 = KBytes =20 > [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 940 = KBytes =20 > [ 5] 3.00-4.00 sec 84.5 MBytes 709 Mbits/sec 52 368 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 681 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 889 = KBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 1.03 = MBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 1.17 = MBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 125 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 3 586 = KBytes =20 > [ 5] 10.00-10.31 sec 34.7 MBytes 942 Mbits/sec 0 667 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 = sender >=20 > So: Larger total Retr than the modern debug kernel case > but not a fairly consistent rate of Retr values. >=20 >=20 > I've still not dealt with updating to a modern non-debug > environment to test it. >=20 Turns out that I get non-zero Retr values between any two machines that I try, even when both are not arm at all. For example, between a PowerMac G5 (2 sockets, 2 cores each, powerpc64) and a Threadripper 1950X (amd64), Both are Gbps=20 capable . . . FBSDG5L2# iperf3 -c 192.168.1.120 Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.7 port 17239 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 946 Mbits/sec 0 489 KBytes = =20 [ 5] 1.00-2.00 sec 113 MBytes 944 Mbits/sec 0 730 KBytes = =20 [ 5] 2.00-3.00 sec 113 MBytes 945 Mbits/sec 48 1.03 MBytes = =20 [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 95 52.8 KBytes = =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 95 21.4 KBytes = =20 [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 96 1.04 MBytes = =20 [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 91 148 KBytes = =20 [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 92 388 KBytes = =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 99 792 KBytes = =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 93 1.07 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 709 = sender [ 5] 0.00-10.79 sec 1.10 GBytes 874 Mbits/sec = receiver Accepted connection from 192.168.1.120, port 24400 [ 5] local 192.168.1.7 port 5201 connected to 192.168.1.120 port 14839 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 109 MBytes 914 Mbits/sec 84 668 KBytes = =20 [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 102 942 KBytes = =20 [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 101 603 KBytes = =20 [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 95 868 KBytes = =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 92 135 KBytes = =20 [ 5] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 89 989 KBytes = =20 [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 95 28.5 KBytes = =20 [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 100 158 KBytes = =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 102 20.0 KBytes = =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 99 335 KBytes = =20 [ 5] 10.00-10.00 sec 7.50 KBytes 525 Mbits/sec 0 344 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 959 = sender Accepted connection from 192.168.1.7, port 30451 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.7 port 28078 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 38.8 MBytes 326 Mbits/sec 36 1.61 MBytes = =20 [ 5] 1.00-2.01 sec 80.6 MBytes 667 Mbits/sec 471 817 KBytes = =20 [ 5] 2.01-3.00 sec 106 MBytes 901 Mbits/sec 114 688 KBytes = =20 [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 893 KBytes = =20 [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 2 523 KBytes = =20 [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 0 774 KBytes = =20 [ 5] 6.00-7.00 sec 108 MBytes 903 Mbits/sec 361 551 KBytes = =20 [ 5] 7.00-8.00 sec 96.3 MBytes 808 Mbits/sec 180 473 KBytes = =20 [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 740 KBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 934 KBytes = =20 [ 5] 10.00-10.67 sec 74.1 MBytes 933 Mbits/sec 1 456 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.67 sec 1.03 GBytes 833 Mbits/sec 1165 = sender Connecting to host 192.168.1.7, port 5201 [ 5] local 192.168.1.120 port 60431 connected to 192.168.1.7 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 97.8 MBytes 818 Mbits/sec 0 633 KBytes = =20 [ 5] 1.00-2.00 sec 111 MBytes 934 Mbits/sec 128 649 KBytes = =20 [ 5] 2.00-3.00 sec 112 MBytes 937 Mbits/sec 0 863 KBytes = =20 [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 2 394 KBytes = =20 [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 0 693 KBytes = =20 [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 897 KBytes = =20 [ 5] 6.00-7.00 sec 111 MBytes 932 Mbits/sec 2 480 KBytes = =20 [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 0 746 KBytes = =20 [ 5] 8.00-9.00 sec 62.3 MBytes 523 Mbits/sec 320 436 KBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 934 Mbits/sec 0 717 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.03 GBytes 881 Mbits/sec 452 = sender [ 5] 0.00-10.01 sec 1.02 GBytes 880 Mbits/sec = receiver I may need to establish a better context or just may be limited to Bitrate comparisons instead of looking for Retr staying zero. (Still not at a modern non-debug build for the Rock64.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jul 8 09:00:12 2020 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 12D0F35BE5D for ; Wed, 8 Jul 2020 09:00:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1tYP6VR7z3Vg5 for ; Wed, 8 Jul 2020 09:00:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1594198806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=emQKIMtUTQF0VRGVnzqusnUPSIUtV8K0/BVPShLGGXg=; b=I+0okPYtSKzvbQtAB+P00Gq4S6231hMksoqY3UATmhp0u/GlXtK8521qGZEpDwxT6pefUb G8SWWe7AFQvU9mw5JDIwtLQBvVKFmlbULe7ZMvORIgIFRQ3QN5cLYJIV8VfGjCeWZj01C1 WL22nU7t2zvOYS7Prt+UIDmHBmOhyjM= Received: from amy.home (lfbn-idf2-1-686-145.w86-247.abo.wanadoo.fr [86.247.139.145]) by mx.blih.net (OpenSMTPD) with ESMTPSA id b15cfe3f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 8 Jul 2020 09:00:06 +0000 (UTC) Date: Wed, 8 Jul 2020 11:00:06 +0200 From: Emmanuel Vadot To: Furkan Salman Cc: "Oleksandr Tymoshenko" , "freebsd-arm" Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 Message-Id: <20200708110006.5feb2af3d19f72c232b847d6@bidouilliste.com> In-Reply-To: <1732a6a569a.de2d39ae730849.3150039489984939252@fkardame.com> References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <1732a6a569a.de2d39ae730849.3150039489984939252@fkardame.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B1tYP6VR7z3Vg5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=I+0okPYt; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.007]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.66)[-0.660]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 09:00:12 -0000 On Tue, 07 Jul 2020 20:54:38 +0300 Furkan Salman wrote: > Hello, >=20 >=20 >=20 > I am running FreeBSD using s199pwa1k9r@ test image over RockPiE we were o= nly able to get 1 lan card out of the 2. The one working is 1Gb which is ov= er RTL8211E, there is another Lan which is 100mb only and it is onboard rk3= 328 lan. We can see the lan card but it is not coming up even after trying = to bring it up manually. >=20 >=20 > > You can find the bootlog attached here >=A0https://hastebin.com/bifoyuwub= o.coffeescript >=20 >=20 >=20 > Below is my finding. >=20 > Bootlog information about the Lan connectiion. >=20 >=20 >=20 > dwc0: mem 0xff540000-0xff54ffff ir= q 44 on ofwbus0=A0=A0=A0=A0 >=20 > miibus0: on dwc0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 >=20 > rgephy0: PHY 0 on miibus= 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > rgephy0:=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000bas= eT, 1000baseT-master,o >=20 > rgephy1: PHY 1 on miibus= 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > rgephy1:=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000bas= eT, 1000baseT-master,o >=20 > dwc0: Ethernet address: d2:55:35:5f:0a:67=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > dwc1: mem 0xff550000-0xff55ffff ir= q 45 on ofwbus0=A0=A0=A0=A0 >=20 > miibus1: on dwc1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 >=20 > ukphy0: PHY 0 on miibus1=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > ukphy0:=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > dwc1: Ethernet address: 62:73:64:5d:e2:22 >=20 >=20 >=20 > root@rock-pi-e:~ # ifconfig -a=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > dwc0: flags=3D8843 metric 0 mtu 1= 500=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 options=3D80008=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 ether d2:55:35:5f:0a:67=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.14 netmask 0xffffff00 broadcast 192.= 168.1.255=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (1000baseT = )=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 status: active=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 nd6 options=3D29=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 >=20 > dwc1: flags=3D8843 metric 0 mtu 1= 500=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 options=3D80008=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 ether 62:73:64:5d:e2:22=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (none)=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 status: no carrier=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 nd6 options=3D29=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 >=20 > lo0: flags=3D8049 metric 0 mtu 16384=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 options=3D680003=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 inet6 ::1 prefixlen 128=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 inet 127.0.0.1 netmask 0xff000000=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 groups: lo=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0 nd6 options=3D21=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > root@rock-pi-e:~ # >=20 >=20 >=20 > iperf3 server is running on my X86 Laptop over wifi as I have a shortage = of lan cable tonight. If needed I can arrange it tomorrow and share another= iperf result with both devices on 1Gb lan connection. >=20 >=20 >=20 > root@rock-pi-e:~ # iperf3 -c 192.168.1.15=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > Connecting to host 192.168.1.15, port 5201=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5] local 192.168.1.14 port 22396 connected to 192.168.1.15 port 5201= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [ ID] Interval=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bitrate= =A0=A0=A0=A0=A0=A0=A0=A0 Retr=A0 Cwnd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-1.00=A0=A0 sec=A0 11.1 MBytes=A0 93.2 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 567 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 1.00-2.00=A0=A0 sec=A0 9.15 MBytes=A0 76.7 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 572 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 2.00-3.00=A0=A0 sec=A0 6.48 MBytes=A0 54.4 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 575 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 3.00-4.00=A0=A0 sec=A0 5.73 MBytes=A0 48.1 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 578 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 4.00-5.00=A0=A0 sec=A0 5.93 MBytes=A0 49.6 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 582 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 5.00-6.00=A0=A0 sec=A0 6.35 MBytes=A0 53.4 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 585 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 6.00-7.00=A0=A0 sec=A0 9.35 MBytes=A0 78.5 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 591 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 7.00-8.00=A0=A0 sec=A0 7.37 MBytes=A0 61.8 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 594 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 8.00-9.00=A0=A0 sec=A0 9.67 MBytes=A0 81.2 Mbits/sec=A0=A0= =A0 0=A0=A0=A0 598 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 9.00-10.00=A0 sec=A0 6.26 MBytes=A0 52.4 Mbits/sec=A0=A0=A0= 0=A0=A0=A0 601 KBytes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 >=20 > - - - - - - - - - - - - - - - - - - - - - - - - -=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [ ID] Interval=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bitrate= =A0=A0=A0=A0=A0=A0=A0=A0 Retr=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-10.00=A0 sec=A0 77.4 MBytes=A0 64.9 Mbits/sec=A0=A0=A0= 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sender=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-10.85=A0 sec=A0 76.6 MBytes=A0 59.2 Mbits/sec=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 receiver=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > iperf Done.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 >=20 > root@rock-pi-e:~ # iperf3 -R -c 192.168.1.15=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > Connecting to host 192.168.1.15, port 5201=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > Reverse mode, remote host 192.168.1.15 is sending=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5] local 192.168.1.14 port 30995 connected to 192.168.1.15 port 5201= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [ ID] Interval=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bitrate= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-1.00=A0=A0 sec=A0 5.92 MBytes=A0 49.7 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 1.00-2.00=A0=A0 sec=A0 3.30 MBytes=A0 27.7 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 2.00-3.00=A0=A0 sec=A0 2.88 MBytes=A0 24.2 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 3.00-4.00=A0=A0 sec=A0 3.27 MBytes=A0 27.4 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 4.00-5.00=A0=A0 sec=A0 4.53 MBytes=A0 38.0 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 5.00-6.00=A0=A0 sec=A0 4.22 MBytes=A0 35.4 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 6.00-7.00=A0=A0 sec=A0 2.82 MBytes=A0 23.7 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 7.00-8.00=A0=A0 sec=A0 3.70 MBytes=A0 31.0 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 8.00-9.00=A0=A0 sec=A0 3.52 MBytes=A0 29.5 Mbits/sec=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 9.00-10.00=A0 sec=A0 3.43 MBytes=A0 28.8 Mbits/sec=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > - - - - - - - - - - - - - - - - - - - - - - - - -=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [ ID] Interval=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bitrate= =A0=A0=A0=A0=A0=A0=A0=A0 Retr=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-10.80=A0 sec=A0 38.0 MBytes=A0 29.5 Mbits/sec=A0 268= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sender=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 >=20 > [=A0 5]=A0=A0 0.00-10.00=A0 sec=A0 37.6 MBytes=A0 31.5 Mbits/sec=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 receiver=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > iperf Done.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 >=20 >=20 >=20 >=20 > If there is anything else I can help you with then please let me know. >=20 >=20 >=20 > Thank you. >=20 > Furkan. We don't have any clock support for the gmac* so I'm not surprised that it doesn't work. For the first interface u-boot does some setup so it just work for us, the second one isn't setup by u-boot so the module might not be clocked correctly. >=20 >=20 >=20 >=20 >=20 > ---- On Mon, 06 Jul 2020 23:47:07 +0300 Oleksandr Tymoshenko wrote ---- >=20 >=20 >=20 > Furkan Salman (mailto:furkan@fkardame.com) wrote:=20 > > Hello Peter,=20 > >=20 > > I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or = gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue then I a= m happy to help with testing.=20 > =20 > =20 > Hi Furkan,=20 > =20 > Yes, RockPi E seems to be a good test target. If you could check the=20 > GigE interface before and after the patch. Whether it works/doesn't work= =20 > and if it works in both cases - try testing performance with iperf3,=20 > just to see if performance was affected in any way.=20 > =20 > Thanks=20 > =20 > --=20 > gonzo > _______________________________________________ > 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" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Jul 8 11:17:45 2020 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 D630935FA4A for ; Wed, 8 Jul 2020 11:17:45 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1xc85bptz3fv4 for ; Wed, 8 Jul 2020 11:17:44 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 08 Jul 2020 11:17:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1594207062; bh=LGl/Wt5tyOSofF5kM6qW8TbLbnfSqqP79CfXg0ng9Cs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Xn1TczbHGufAvFDsciM6R7SKvv4ARt7k8FU9Nhnep/raSUSE6+zb3PSkdJGf5bb/k FEo3hnPczwIgW9+ER1+IWnjMB90OVrmy6WvuypRlBFMybAVpHXlJ3Oyu8ycXkURHBo 8J9PUR9DAtkUHfwV+p1fFMM0mgTFRQw+2gArVaGQ= To: =?utf-8?Q?Klaus_K=C3=BCchemann?= From: Dan Kotowski Cc: freebsd-arm@freebsd.org Reply-To: Dan Kotowski Subject: Re: Recommended arm hardware (mostly for compilation)? Message-ID: In-Reply-To: <9E10C464-474F-489A-A667-B263A64E78F2@googlemail.com> References: <1b109252-3232-05c4-e1e0-2fea4739583d@spth.de> <47A5AF8A-1EB9-4721-94D5-B0A0A6FFF69B@unrelenting.technology> <9E10C464-474F-489A-A667-B263A64E78F2@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B1xc85bptz3fv4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=Xn1TczbH; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-2.82 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.01)[-1.009]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.69)[-0.690]; FREEMAIL_TO(0.00)[googlemail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.133:from]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.133:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 11:17:45 -0000 > If someone=E2=80=99s looking for horsepower between those options, consid= er the LX2K from SolidRun, > while current support for FreeBSD is unknown to me . Reviving an old thread... -------------------------------------------------------------- >>> World build completed on Wed Jul 8 02:47:59 UTC 2020 >>> World built in 6897 seconds, ncpu: 16, make -j16 -------------------------------------------------------------- Stable enough to buildworld: * AHCI/SATA and USB all seem to work just fine But: * Firmware is still a moving target * No DPAA2-MC and no drivers means no onboard netifs * Still not properly mapping interrupts behind SMMU (PCI and NVMe are no-go= until that's resolved) * No i2c (set that testing aside to focus on interrupts, probably should re= visit) * No on-board uSD+eMMC in OS (works fine for loading firmware, but also set= aside to focus on interrupts) Others using it seem to be running Linux reasonably fine, including a full = Ubuntu 20.04 desktop with Chromium - there's even 1 person working on stabi= lizing a Thunderbolt 3 controller! All of this laden with bugs and instabil= ities, but it's a lot closer today than it was when this thread began :) From owner-freebsd-arm@freebsd.org Wed Jul 8 13:08:24 2020 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 266D3362A0E for ; Wed, 8 Jul 2020 13:08:24 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B203q1cN0z43Zt for ; Wed, 8 Jul 2020 13:08:22 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 08 Jul 2020 13:08:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1594213700; bh=QTyj96jmkEjvuHaJlGL8UBWJHj+P8vjY2QzproiLVr4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=GMB/fVZgh7jF5T9Fr4SzIwmf5XEsCVsTH3WTVjtITFRDDMQm0i+jYTl8Vxi61jtCX OwvcJnKvjIHbnpKgIwSR0ESGLIg48lO8jEhqhhA4iXXl26UGSfBIHER5MmsoK8djOc 54M/sVi7QPvosl1VGa9B7y8JuDfKd9xVQe+/M7i0= To: "greg@unrelenting.technology" From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: =?us-ascii?Q?<82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej=5FPPtiv=5Fps9vROdUI529pKfxp4lbs=3D@a9development.com>__=5F=5F=5F=5F=5F<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_____<8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology>_?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B203q1cN0z43Zt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=GMB/fVZg; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-4.02 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.89)[-0.890]; NEURAL_HAM_MEDIUM(-1.04)[-1.037]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.131:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 13:08:24 -0000 > > > In the old firmware, under the Root Complex Nodes, `Output reference:= 0x30` points to the ITS Node > > > with node offset 0x30. > > > Then in the new firmware, under the Root Copmlex Nodes, `Output refer= ence: 0x48` points to the SMMU > > > with node offset 0x48. > > > Is this what you meant when you said everything is "behind the SMMU"? > > > Yes. > > > What patches are we applying right now? I think some new builds would= be good, including one with > > > all the stuff we've fixed - like AHCI - but with the NXP PCIe code so= I can test on the old > > > firmware. If I'm keeping track correctly, this includes: > > > > > > - D20835: enable tagged pointers > > > - D20974: Port sbsawdt drive from NetBSD > > > - D21017: armv8crypto: add AES-XTS support > > > - D24423: arm/pmu: add ACPI attachment, more FDT names > > > > > > These are not directly related to running on NXP, just random improve= ments :) > > > > > > - D25145: acpi_resource: support multiple IRQs > > > - D25157: ahci_generic: add quirk for NXP0004 > > > - D25179: acpi_iort: fix mapping end calculation > > > > > > Yes, these three. > > > Here's the pci_layerscape patch: > > > https://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b3d= feb105d376.patch > > > If we haven't tried it + acpi_iort fix before, which is quite likely,= maybe that's a combination > > > that would work. > > > (I remember when we tried it only, there was only the same interrupt = problem as usual..) > > > It's honestly kinda weird that "old" FW requires the custom controlle= r access while "new" FW > > > requires not doing it >_< > > > > Any tips on where to add verbosity to dmesg during boot? You had a hand= ful of extras in there to > > print things things from the IORT. > > That thing is here: > https://github.com/freebsd/freebsd/blob/6cee1596c05e8a9ab64812444627b61c5= 84ca6bc/sys/arm64/acpica/acpi_iort.c#L169 > > > Also seeing that NVMe hangs in nvme_ctrlr_start_config_hook, > > maybe we want to add some verbosity to sys/dev/nvme/nvme_ctrlr.c to see= what it's waiting for? > > We know it's an interrupt.. everything is waiting for an interrupt. Well, at least we're stable enough to buildworld and buildkernel on-system!= :partyparrot: Waiting on a new SSD, but building on a USB uSD: -------------------------------------------------------------- >>> World build completed on Wed Jul 8 02:47:59 UTC 2020 >>> World built in 6897 seconds, ncpu: 16, make -j16 -------------------------------------------------------------- Forgot to copy off the buildkernel time, but it was just under 900 seconds. Interestingly, we have real temp readouts from thermal zones, which is new.= Did I add something back in that we had previously removed? From owner-freebsd-arm@freebsd.org Wed Jul 8 15:21:41 2020 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 21D16365601 for ; Wed, 8 Jul 2020 15:21:41 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B231c21Zwz4BnM for ; Wed, 8 Jul 2020 15:21:40 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 08 Jul 2020 15:21:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1594221696; bh=69LvxhHU2WnQd1K0V2CC/pEGmNGucRNs5/GAcuw2idQ=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Z7Esfz3kqjx0W+Estt+yjHO2POl+R0yKlyoBx4MuxKZadnBQpJs4OTlgxoNQV9NRK Xd9HxJYPDNOr5xTzPMDNeQWSIs0GmmA5fRBvu0fB6JfuKF1Hqck4rsNLq3JPeVyNWH DnFzmoCyFZBHz1ED8Fcu5BnU0dAL6nw42zpGXt+Q= To: Dan Kotowski From: Dan Kotowski Cc: "greg@unrelenting.technology" , freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: =?us-ascii?Q?<82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej=5FPPtiv=5Fps9vROdUI529pKfxp4lbs=3D@a9development.com>__=5F=5F=5F=5F=5F<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>____<8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology>__?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B231c21Zwz4BnM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=Z7Esfz3k; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.86 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; NEURAL_HAM_LONG(-0.98)[-0.984]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.76)[-0.757]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.131:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 15:21:41 -0000 > > > > In the old firmware, under the Root Complex Nodes, `Output referenc= e: 0x30` points to the ITS Node > > > > with node offset 0x30. > > > > Then in the new firmware, under the Root Copmlex Nodes, `Output ref= erence: 0x48` points to the SMMU > > > > with node offset 0x48. > > > > Is this what you meant when you said everything is "behind the SMMU= "? > > > > Yes. > > > > What patches are we applying right now? I think some new builds wou= ld be good, including one with > > > > all the stuff we've fixed - like AHCI - but with the NXP PCIe code = so I can test on the old > > > > firmware. If I'm keeping track correctly, this includes: > > > > > > > > - D20835: enable tagged pointers > > > > - D20974: Port sbsawdt drive from NetBSD > > > > - D21017: armv8crypto: add AES-XTS support > > > > - D24423: arm/pmu: add ACPI attachment, more FDT names > > > > > > > > These are not directly related to running on NXP, just random impro= vements :) > > > > > > > > - D25145: acpi_resource: support multiple IRQs > > > > - D25157: ahci_generic: add quirk for NXP0004 > > > > - D25179: acpi_iort: fix mapping end calculation > > > > > > > > Yes, these three. > > > > Here's the pci_layerscape patch: > > > > https://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b= 3dfeb105d376.patch > > > > If we haven't tried it + acpi_iort fix before, which is quite likel= y, maybe that's a combination > > > > that would work. > > > > (I remember when we tried it only, there was only the same interrup= t problem as usual..) > > > > It's honestly kinda weird that "old" FW requires the custom control= ler access while "new" FW > > > > requires not doing it >_< > > > > > > Any tips on where to add verbosity to dmesg during boot? You had a ha= ndful of extras in there to > > > print things things from the IORT. > > > > That thing is here: > > https://github.com/freebsd/freebsd/blob/6cee1596c05e8a9ab64812444627b61= c584ca6bc/sys/arm64/acpica/acpi_iort.c#L169 > > > > > Also seeing that NVMe hangs in nvme_ctrlr_start_config_hook, > > > maybe we want to add some verbosity to sys/dev/nvme/nvme_ctrlr.c to s= ee what it's waiting for? > > > > We know it's an interrupt.. everything is waiting for an interrupt. > > Well, at least we're stable enough to buildworld and buildkernel on-syste= m! :partyparrot: > > Waiting on a new SSD, but building on a USB uSD: > > -------------------------------------------------------------------------= --------------------------------------------------------------------- > > > > > World build completed on Wed Jul 8 02:47:59 UTC 2020 > > > > World built in 6897 seconds, ncpu: 16, make -j16 > > Forgot to copy off the buildkernel time, but it was just under 900 second= s. > > Interestingly, we have real temp readouts from thermal zones, which is ne= w. Did I add something back in that we had previously removed? Here's something: https://gist.github.com/agrajag9/11efe00514513100232999e0= a9ec612c NVMe is working. It mapped an interrupt. I have no idea what changed to mak= e this work other than compiling my own kernel. I applied the 7 patches abo= ve and added a bunch of my own debug printfs (dmesg.boot lines beginning wi= th A9DEBUG), but it's the same POC ECAM firmware we've been using for a whi= le. I'll test with the HBA later this week - it's currently in use elsehwer= e in my homelab doing zfs send|receive things. From owner-freebsd-arm@freebsd.org Thu Jul 9 07:22:46 2020 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 CABCA362E16 for ; Thu, 9 Jul 2020 07:22:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2SLY3Vyrz4d2N for ; Thu, 9 Jul 2020 07:22:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6.efTNAVM1lNUdaiIqPTPaOvI9_TEy2Oa7ruhpwUmZnGPgJCCsbqvvYjEZ9SzZ9 snKWHjSCnB5h4YqHX4sFIuP4IbvDsGA0MdMVh.IYFe0_OxZ0SgC07bGzY1g.6cq8QLwvE7H.FAgC 4JCNf_wtXrmgB70KZUZRmxZ5Us7y1L0mMbU4ou4BfjzMeigMPaow70TSXk_IyrJO2Kh7Bra_1znC C.Cq46DxT_u3k83YVnVO71_jj8ux7J132UkRCoL3gHvv9DQ7UQYrhAXENi6HTxm_9Ng1Uea6VguK KvcSWHXVUNTpJJR7xmTii1in7ISZOr8vdDIkHbYk4zO5KHYrRy1108OIt2SXCUSanmQ92Y0s.V4S QB9g0h2RNCe7gDmI4vi327Z.TLx0oQwN5oFGO68Q6gToPi4OhJy0M7LolRR4dzEik8QU07GEe32q QtnMvN6mEV8ZbzChu4_uy7gHvmEjMjFGW_T09i.FYhCFEj5g0uPOjnw2J6hI58xQ_.TxSvM9T2Xf U6q6V58kaTDewiACrGinLmOADk9sBfI4o6Irf7tIExmepzN3TLVVUJ2V8FX_JvbxCAOYnRvGkWt1 vZv0NgLFROCoqImg8R6PHcjAdNMP2qIL0UTtjd50h.zoD2H5OH.bHA9S.o1ulo6e9T3gt7mg_SiF zuKGR2lE5fzTB.E6fkQsUvwTELRtxnVgWzcYX2bAoN015c7VSqVe43T2UGB050Hl8Mfx2EAbhjCW wHsBtxmpx17bOrgxTmrccnE9W0HUb8LuBZggXKBsH__5v2y3d5pzqa3DxysjUuOk5jpyOoCw4pyd fP5cghWgK1CbFyFBakBgrOExW4NKaksMMJoBsHJjqLiFmMd0hg4R3l_J9ZPu4S4M2UCIaoOOibcs wvdAjhegWMllufUxNq7O38NdGtJVnu2mAjnqbnBMhbPY.5a3E_FbnloNI7qzmCWcLQ1Yjsh4DMR1 CKtDXkBeUZrZS_yWoY6T7tAOdJeS4ZQCogo0L7R30ebW1nvZY2D2Mhlc4Pk3GhzEtC6IbFb9UDSf rddopOJCkWHF1a2H.z3ThTugCSUTgf5lr_iQa2N.YZtbWZHDwOqBnVmYCX_WY0Ir4hU2hczDDOFm ZggXmbU8zvFowBfLkUVKL_13b36YIg9zGKPilIN2SalFx1ApQNA1J03RgHCKilHkkeoRZp5bVMRe MgMqKfk6QCrYSuPxNhwGMEtY3G7qgHFFmEmAaFuNjBE6TV5__9T8inGE8dXUFqyC8Lrk2SP8eeZB tFUcM613Dx1wIADGPvM_xVDOS4_SHKM6UODBX3PVHYbmaIf5P3EUhVuPyiF3h1Ch_3Rw_Ax5RMwT RmejIqgwT2uGJImpuq0JSRf1nrL8.UTihay.tnd1XymDpZnUOKGRWZ9jMxb_zt3LxxHpvUAXVqFX hW15JGTCclWo1QpEwFv4bMrB_vuHnLU6qhnpBfJQ45Cv1s6d5XputR5qnrpc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Jul 2020 07:22:43 +0000 Received: by smtp417.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f5bd290183c1ab6d44f5e3a892919c2b; Thu, 09 Jul 2020 07:22:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) From: Mark Millard In-Reply-To: <4AA1D1FD-F9A4-400E-80FA-C1888F399602@yahoo.com> Date: Thu, 9 Jul 2020 00:22:36 -0700 Cc: Peter Jeremy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> <3289DA3D-03FB-43BD-9A6A-956AC0A03B59@yahoo.com> <20200708021226.GA77884@bluezbox.com> <4AA1D1FD-F9A4-400E-80FA-C1888F399602@yahoo.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B2SLY3Vyrz4d2N X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.12 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.03)[-1.028]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; NEURAL_HAM_SHORT(-0.62)[-0.622]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 07:22:46 -0000 On 2020-Jul-8, at 00:27, Mark Millard wrote: > On 2020-Jul-7, at 21:52, Mark Millard wrote: >=20 >> On 2020-Jul-7, at 19:12, Oleksandr Tymoshenko = wrote: >>=20 >>> Mark Millard (marklmi at yahoo.com) wrote: >>>> Any chance that the delays (or other parameters) depend >>>> on the operating temperature(s) of some parts? >>>>=20 >>>> If yes, then some of the following about the Rock64 V2 >>>> context that I have access to might be relevant to >>>> explaining my already reported V2 results (not much >>>> for Retr): >>>>=20 >>>> A) The Rock64 has a "case" that is really just a top >>>> and a bottom with posts: open on all 4 sides. >>>>=20 >>>> B) It has a fan blowing down on the board from the >>>> top. >>>>=20 >>>> C) It has a heat sink on the SOC, which the fan blows >>>> on directly. >>>>=20 >>>> D) It has a heat sink on the RAM, which the fan also >>>> blows on directly. >>>>=20 >>>> (I've not dealt with a more modern non-debug kernel >>>> build yet. It still may be some time before I deal >>>> with that.) >>>=20 >>> Temperature is not likely to be a factor in the delay values. >>> Rock64 V2 has a known issue with Gigabit ethernet stability: >>>=20 >>> https://forum.pine64.org/showthread.php?tid=3D7545 >>> https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ >>>=20 >>> Althought judging by description it's more like an almost complete >>> network lock-up and not performance degradation. >>>=20 >>> I received another board with RK3328 today and will investigate >>> the issue further. >>=20 >> Okay. >>=20 >> Looks like I should have copied iperf3 output from the server >> side as well: somewhat different information. The output was >> still available from the earlier runs so here it is . . . >>=20 >> The modern debug-kernel runs: >>=20 >> Accepted connection from 192.168.1.109, port 47111 >> [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 17015 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 17.5 MBytes 147 Mbits/sec =20= >> [ 5] 1.00-2.00 sec 45.3 MBytes 380 Mbits/sec =20= >> [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec =20= >> [ 5] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec =20= >> [ 5] 4.00-5.00 sec 44.9 MBytes 377 Mbits/sec =20= >> [ 5] 5.00-6.00 sec 45.1 MBytes 379 Mbits/sec =20= >> [ 5] 6.00-7.00 sec 44.5 MBytes 373 Mbits/sec =20= >> [ 5] 7.00-8.00 sec 45.0 MBytes 378 Mbits/sec =20= >> [ 5] 8.00-9.00 sec 44.9 MBytes 377 Mbits/sec =20= >> [ 5] 9.00-10.00 sec 44.5 MBytes 373 Mbits/sec =20= >> [ 5] 10.00-10.62 sec 27.9 MBytes 379 Mbits/sec =20= >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec = receiver >>=20 >> Accepted connection from 192.168.1.109, port 22375 >> [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 54738 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 24.7 MBytes 207 Mbits/sec 0 265 = KBytes =20 >> [ 5] 1.00-2.00 sec 61.6 MBytes 517 Mbits/sec 4 211 = KBytes =20 >> [ 5] 2.00-3.00 sec 61.4 MBytes 515 Mbits/sec 1 352 = KBytes =20 >> [ 5] 3.00-4.00 sec 61.3 MBytes 514 Mbits/sec 4 269 = KBytes =20 >> [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec 2 355 = KBytes =20 >> [ 5] 5.00-6.00 sec 61.3 MBytes 514 Mbits/sec 3 304 = KBytes =20 >> [ 5] 6.00-7.00 sec 61.3 MBytes 514 Mbits/sec 2 327 = KBytes =20 >> [ 5] 7.00-8.00 sec 61.4 MBytes 515 Mbits/sec 5 278 = KBytes =20 >> [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec 2 393 = KBytes =20 >> [ 5] 9.00-10.00 sec 61.4 MBytes 515 Mbits/sec 3 284 = KBytes =20 >> [ 5] 10.00-10.61 sec 37.3 MBytes 514 Mbits/sec 2 282 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 = sender >>=20 >> (So a fairly consistent Retr rate.) >>=20 >> The non-debug head -r360311 kernel runs: >>=20 >> Accepted connection from 192.168.1.109, port 46431 >> [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 39541 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 50.3 MBytes 422 Mbits/sec =20= >> [ 5] 1.00-2.00 sec 72.7 MBytes 610 Mbits/sec =20= >> [ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec =20= >> [ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec =20= >> [ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec =20= >> [ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec =20= >> [ 5] 6.00-7.00 sec 72.8 MBytes 611 Mbits/sec =20= >> [ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec =20= >> [ 5] 8.00-9.00 sec 72.8 MBytes 610 Mbits/sec =20= >> [ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec =20= >> [ 5] 10.00-10.32 sec 23.4 MBytes 612 Mbits/sec =20= >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-10.32 sec 729 MBytes 593 Mbits/sec = receiver >>=20 >> Accepted connection from 192.168.1.109, port 40223 >> [ 5] local 192.168.1.122 port 5201 connected to 192.168.1.109 port = 50696 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 78.5 MBytes 659 Mbits/sec 0 480 = KBytes =20 >> [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 747 = KBytes =20 >> [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 940 = KBytes =20 >> [ 5] 3.00-4.00 sec 84.5 MBytes 709 Mbits/sec 52 368 = KBytes =20 >> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 681 = KBytes =20 >> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 889 = KBytes =20 >> [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 1.03 = MBytes =20 >> [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 1.17 = MBytes =20 >> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 125 = KBytes =20 >> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 3 586 = KBytes =20 >> [ 5] 10.00-10.31 sec 34.7 MBytes 942 Mbits/sec 0 667 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 = sender >>=20 >> So: Larger total Retr than the modern debug kernel case >> but not a fairly consistent rate of Retr values. >>=20 >>=20 >> I've still not dealt with updating to a modern non-debug >> environment to test it. >>=20 >=20 > Turns out that I get non-zero Retr values between > any two machines that I try, even when both are not > arm at all. >=20 > For example, between a PowerMac G5 (2 sockets, 2 cores each, > powerpc64) and a Threadripper 1950X (amd64), Both are Gbps=20 > capable . . . >=20 > FBSDG5L2# iperf3 -c 192.168.1.120 > Connecting to host 192.168.1.120, port 5201 > [ 5] local 192.168.1.7 port 17239 connected to 192.168.1.120 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 946 Mbits/sec 0 489 = KBytes =20 > [ 5] 1.00-2.00 sec 113 MBytes 944 Mbits/sec 0 730 = KBytes =20 > [ 5] 2.00-3.00 sec 113 MBytes 945 Mbits/sec 48 1.03 = MBytes =20 > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 95 52.8 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 95 21.4 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 96 1.04 = MBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 91 148 = KBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 92 388 = KBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 99 792 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 93 1.07 = MBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 709 = sender > [ 5] 0.00-10.79 sec 1.10 GBytes 874 Mbits/sec = receiver >=20 >=20 > Accepted connection from 192.168.1.120, port 24400 > [ 5] local 192.168.1.7 port 5201 connected to 192.168.1.120 port = 14839 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 109 MBytes 914 Mbits/sec 84 668 = KBytes =20 > [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 102 942 = KBytes =20 > [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 101 603 = KBytes =20 > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 95 868 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 92 135 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 89 989 = KBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 95 28.5 = KBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 100 158 = KBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 102 20.0 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 99 335 = KBytes =20 > [ 5] 10.00-10.00 sec 7.50 KBytes 525 Mbits/sec 0 344 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 959 = sender >=20 > Accepted connection from 192.168.1.7, port 30451 > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.7 port = 28078 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 38.8 MBytes 326 Mbits/sec 36 1.61 = MBytes =20 > [ 5] 1.00-2.01 sec 80.6 MBytes 667 Mbits/sec 471 817 = KBytes =20 > [ 5] 2.01-3.00 sec 106 MBytes 901 Mbits/sec 114 688 = KBytes =20 > [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 893 = KBytes =20 > [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 2 523 = KBytes =20 > [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 0 774 = KBytes =20 > [ 5] 6.00-7.00 sec 108 MBytes 903 Mbits/sec 361 551 = KBytes =20 > [ 5] 7.00-8.00 sec 96.3 MBytes 808 Mbits/sec 180 473 = KBytes =20 > [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 740 = KBytes =20 > [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 934 = KBytes =20 > [ 5] 10.00-10.67 sec 74.1 MBytes 933 Mbits/sec 1 456 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.67 sec 1.03 GBytes 833 Mbits/sec 1165 = sender >=20 > Connecting to host 192.168.1.7, port 5201 > [ 5] local 192.168.1.120 port 60431 connected to 192.168.1.7 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 97.8 MBytes 818 Mbits/sec 0 633 = KBytes =20 > [ 5] 1.00-2.00 sec 111 MBytes 934 Mbits/sec 128 649 = KBytes =20 > [ 5] 2.00-3.00 sec 112 MBytes 937 Mbits/sec 0 863 = KBytes =20 > [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 2 394 = KBytes =20 > [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 0 693 = KBytes =20 > [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 897 = KBytes =20 > [ 5] 6.00-7.00 sec 111 MBytes 932 Mbits/sec 2 480 = KBytes =20 > [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 0 746 = KBytes =20 > [ 5] 8.00-9.00 sec 62.3 MBytes 523 Mbits/sec 320 436 = KBytes =20 > [ 5] 9.00-10.00 sec 111 MBytes 934 Mbits/sec 0 717 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.03 GBytes 881 Mbits/sec 452 = sender > [ 5] 0.00-10.01 sec 1.02 GBytes 880 Mbits/sec = receiver >=20 > I may need to establish a better context or just may be > limited to Bitrate comparisons instead of looking for > Retr staying zero. >=20 > (Still not at a modern non-debug build for the Rock64.) The Rock64 V2 is now running head -r363021 with a non-debug kernel and world: # uname -apKU FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r363021M: Wed = Jul 8 20:30:01 PDT 2020 = markmi@FBSDFHUGE:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 aarch64 1300100 1300100 The patch for extra messages (and a potential bug fix) has not been applied. The iperf3 outputs are below. # iperf3 -c 192.168.1.120 Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.109 port 40422 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 73.3 MBytes 615 Mbits/sec 0 732 KBytes = =20 [ 5] 1.00-2.00 sec 72.7 MBytes 610 Mbits/sec 0 732 KBytes = =20 [ 5] 2.00-3.00 sec 72.9 MBytes 612 Mbits/sec 0 1.07 MBytes = =20 [ 5] 3.00-4.00 sec 72.7 MBytes 610 Mbits/sec 0 1.07 MBytes = =20 [ 5] 4.00-5.00 sec 72.7 MBytes 610 Mbits/sec 0 1.07 MBytes = =20 [ 5] 5.00-6.00 sec 72.7 MBytes 610 Mbits/sec 0 1.07 MBytes = =20 [ 5] 6.00-7.00 sec 72.6 MBytes 609 Mbits/sec 0 1.07 MBytes = =20 [ 5] 7.00-8.00 sec 72.6 MBytes 609 Mbits/sec 0 1.07 MBytes = =20 [ 5] 8.00-9.00 sec 72.7 MBytes 609 Mbits/sec 0 1.07 MBytes = =20 [ 5] 9.00-10.00 sec 72.7 MBytes 610 Mbits/sec 0 1.07 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 727 MBytes 610 Mbits/sec 0 = sender [ 5] 0.00-10.57 sec 727 MBytes 577 Mbits/sec = receiver iperf Done. # iperf3 -R -c 192.168.1.120 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.109 port 10711 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 932 Mbits/sec =20 [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 8.00-9.00 sec 111 MBytes 932 Mbits/sec =20 [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.56 sec 1.09 GBytes 885 Mbits/sec 932 = sender [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec = receiver Where the server-side reported: # iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.109, port 17887 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.109 port = 40422 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 32.1 MBytes 269 Mbits/sec =20 [ 5] 1.00-2.00 sec 72.7 MBytes 610 Mbits/sec =20 [ 5] 2.00-3.00 sec 72.7 MBytes 610 Mbits/sec =20 [ 5] 3.00-4.00 sec 72.5 MBytes 608 Mbits/sec =20 [ 5] 4.00-5.00 sec 72.7 MBytes 610 Mbits/sec =20 [ 5] 5.00-6.00 sec 72.6 MBytes 609 Mbits/sec =20 [ 5] 6.00-7.00 sec 72.6 MBytes 609 Mbits/sec =20 [ 5] 7.00-8.00 sec 72.6 MBytes 609 Mbits/sec =20 [ 5] 8.00-9.00 sec 72.6 MBytes 609 Mbits/sec =20 [ 5] 9.00-10.00 sec 72.7 MBytes 610 Mbits/sec =20 [ 5] 10.00-10.57 sec 41.3 MBytes 610 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.57 sec 727 MBytes 577 Mbits/sec = receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.109, port 45095 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.109 port = 10711 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 50.3 MBytes 422 Mbits/sec 36 375 KBytes = =20 [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 95 1.61 MBytes = =20 [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 92 265 KBytes = =20 [ 5] 3.00-4.00 sec 111 MBytes 932 Mbits/sec 95 342 KBytes = =20 [ 5] 4.00-5.00 sec 111 MBytes 934 Mbits/sec 95 1.01 MBytes = =20 [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 93 471 KBytes = =20 [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 96 1.10 MBytes = =20 [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 100 656 KBytes = =20 [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 86 676 KBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 932 Mbits/sec 91 1.08 MBytes = =20 [ 5] 10.00-10.56 sec 62.6 MBytes 933 Mbits/sec 53 696 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.56 sec 1.09 GBytes 885 Mbits/sec 932 = sender ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Side note for a networking problem one can run into on the Rock64 . . . I'll note that the kernel for the Rock64 still leaks mbuf_clusters during network activity, not freeing most of them: vm.uma.mbuf_cluster.stats.xdomain: 0 vm.uma.mbuf_cluster.stats.fails: 0 vm.uma.mbuf_cluster.stats.frees: 0 vm.uma.mbuf_cluster.stats.allocs: 3302 vm.uma.mbuf_cluster.stats.current: 3302 . . . vm.uma.mbuf_cluster.limit.max_items: 84417 vm.uma.mbuf_cluster.limit.items: 3302 Copying an about 4 GiByte tar to the Rock64 uses up a large portion of the 84417 max_items : vm.uma.mbuf_cluster.stats.current ends up being rather large and vm.uma.mbuf_cluster.stats.frees ends up being rather small. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jul 9 20:35:41 2020 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 521973559A2 for ; Thu, 9 Jul 2020 20:35:41 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 4B2nxS1K67z4bKM for ; Thu, 9 Jul 2020 20:35:39 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jtdGW-0002fP-UM; Thu, 09 Jul 2020 13:35:33 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 069KZWSo010254; Thu, 9 Jul 2020 13:35:32 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 9 Jul 2020 13:35:32 -0700 From: Oleksandr Tymoshenko To: Peter Jeremy Cc: freebsd-arm@freebsd.org Subject: Re: RK3328/Rock64 GigE testers needed. Message-ID: <20200709203532.GA9738@bluezbox.com> References: <20200705000643.GA63127@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200705000643.GA63127@server.rulingia.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Peter Jeremy (peter@rulingia.com) wrote: > Head r362736 has enabled the internal RGMII delay lines in the RK3328 > (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've > modded to use [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B2nxS1K67z4bKM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.18 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.016]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.03)[-1.031]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; NEURAL_SPAM_SHORT(0.17)[0.167]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 20:35:41 -0000 Peter Jeremy (peter@rulingia.com) wrote: > Head r362736 has enabled the internal RGMII delay lines in the RK3328 > (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've > modded to use the higher RGMII bus voltage, as per the v3.0). > > gonzo@ and I would be interested in other people's experiences with > this revision - particularly other people with Rock64 v2 or Rock64 v3 > boards. Thanks to everyone for tests, it looks like only Peter's device networking was completely broken by the commit. As a possible workaround I consider adding a tunable/sysctl that can be used to override the delay in DTB. The change is available in this patch: https://people.freebsd.org/~gonzo/patches/rockchip-gmac-202007009.patch This is WIP on improving if_dwc_rk and contains following changes - Enable and dump gmac clocks frequencies. RK3328 does not have ethernet clocks implemented yet so this part fails on the SoC. - Configure clock according to the sensed media. I was able to switch between 100 and 1000 switches on both Rock64 and on Firefly-RK3399 - Introduces tunable and sysctl dev.dwc.X.delays (where X is a unit number, e.g. 0, 1... etc. The value is (rx_delay << 8) | tx_delay, so adding dev.dwc.0.delays=0x4533 to loader.conf would set rx delay to 69 and tx delay to 51. It's possible to change delays run-time using sysctl too so people can experiment with values fast. - Print delay values and enable flags when changing delays. This should be useful to get the delay values set by U-Boot and that worked before the r362736. The patch does not have any performance improvements, so there is no need to re-run tests. -- gonzo From owner-freebsd-arm@freebsd.org Fri Jul 10 03:39:33 2020 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 C5B8F35DA9A for ; Fri, 10 Jul 2020 03:39:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2zLX59lqz42fg for ; Fri, 10 Jul 2020 03:39:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1wvusYEVM1nUg79MTz883IPjGdZ5XP7ZpUMnnjcUQ1c8u_mMvVjRFjEJO9WbHcL ntJUfTeUdw70INNICJOI6xGuPkykQ6qACvY1CFS4BejehUMoPB8roGQiyNiE3xLgvd4a.4WN33qj mhp4CvtI42LhvyAOx5O6afcvZs2N83qmW2qUbpIk0c8_AiVnxy.Q_RgQWaayCdz_LUee9uiKFboQ bpNjjs.7qg4oV8lvKwjITORJM0F7Kofv2x4oWa_.9QhyW1sLWrszBqc8Zl.8om41qw2bEZlFRTj9 q6Sq_9M.FKJvDD2RRABLQx5A7wQ6WS96qlMylm8kjJC3wllqdASVWzGid3BEUw3hLCJ.TmpOQeJU 7i6W7QdKMDhJdJaB560mqn5j4A.1FQVjiq8B1YPVxbPLql0ScFE6dNvl3gks32gDlO0ZiQwbCLNG 5dYaFatC66GCSU02osDEax8dX7GlY9rabx40NBtgg08aABC4amlvoaF6dwLf4HmodN2F7wfemT9d vzHuAjQWVlyyk7j25.lLADFAgnMfKyuyoOhQXTJtLHKOm9d.NlRxNPBt6i442I.hk21BYdVwwcWl z.jfly0mjVkZkrKuc0zQkw5Ue5hfo.YkBiOOoe1IOT9yzCLo.QDZ4974YHRuv2awhywMVHr5Kv5j Fuy80giU6OamLhEzqSH_D_w3Hpd7UM6RpUuxOl2PiPB08ZHfZiZZmKDPSsQ9AY7.J0f_Q6L07BYq dXJcFWvgUMjcdb3IXAfXgxoEMEVTlifU.njtUX0Knu2.uOr_oaiIYCN2nHkh_PpwO9AakL_CJof4 UiaKPzW9tQ6lkuDWJ1lqfuK7gN2g9VoTgzhga2UY90PXFVxcu5HEEbDsSaWgCx2HWKE_JcV33vWs .VgsrqvXHRChQJeWHE6gH7QgakmQAiAxmNu2v1uhH3x2YlKkVdB6YnRccixhJSfXdr599G.QnHSS wVAODlM8HB7D3TJDbMOFxfRAFaF0OQVz1XLEAXB35feKOwly.bzYsVfcFUJeJE5A7fApnplguxVn Bz9q2jS.pGjje3kapxaW86g8p0MBBGXtYYKXNaJPjraXtX0i4hes84alaIgOZbIbbaJs3Q0uUjZq h5TAnvG9oCu0hpjVebcXuCL9CBzqzl6T6j7hf.AnsAnRCD72aq.qn37vb4PTGIxJn3SlL096Q2zW f2OY5429_PJWPONNZrtjnIKgX5Al9MSYRrS370O0qJ9UGjvBRW8KZm7rRFJPh_UhAzk2cfPeGay5 1JjUbd2FVz7TXDXSe9SycqklYmfFXCYmlmOGycqNzGcB.fOJ1vWu9Djd.zdByeJ9CvjVovzDvP00 Er6HeKqqxlhaagtxntBYkjxTOe0Nv7YN9.xiGW3Dq9u_FrwkpI24B3rwIOMnFrYsTGYuMvNnVCt_ fWeWRfkDY2Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Jul 2020 03:39:30 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d6e44a60df1116869619a9a2d860a8ec; Fri, 10 Jul 2020 03:39:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: RPi4 (8 Gibyte) via UEFI v1.16 and upgrade to head -r363021 : still needs https://reviews.freebsd.org/D25219 materials Message-Id: <85AE0FCE-112F-4778-B040-07894F9FBD73@yahoo.com> Date: Thu, 9 Jul 2020 20:39:23 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <85AE0FCE-112F-4778-B040-07894F9FBD73.ref@yahoo.com> X-Rspamd-Queue-Id: 4B2zLX59lqz42fg X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.08 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.56)[-0.558]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URL_IN_SUBJECT(1.00)[reviews.freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.027]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 03:39:33 -0000 I updated the media that I plug into either a Rock64 or RPi4 from head -r360311 (with 5 relevant patches) to head -r363021 with just https://reviews.freebsd.org/D25219 of the 5 applied: -r363021 already had the material from the other 4 patches. It manages to boot okay. I quickly tested for the "rare bad 4K block content" issue that I've previously reported for the USB3 SSD I/O in my context and it is still there. (The Rock64 does not have such problems.) Note about D25219 use: Trying -r363021 without D25219 applied damaged the UFS file system in its partial boot and the UFS file system needed a couple of fsck's from a working environment. It is important to apply D25219. This is separate from the "rare bad 4K block content" issue. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jul 10 05:58:49 2020 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 6754035FEE9 for ; Fri, 10 Jul 2020 05:58:49 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (warbird.scd-systems.net [37.120.173.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.scd-systems.net", Issuer "mail.scd-systems.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B32RD2FhPz48Yf for ; Fri, 10 Jul 2020 05:58:47 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (127.0.1.80 [127.0.1.80]) by mail.scd-systems.net (OpenSMTPD) with ESMTP id b904643a for ; Fri, 10 Jul 2020 05:58:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=scd-systems.net; h= reply-to:subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=djL8cDITG+A/CQ2LwSYnoBMNRxa7Ucx7kEYIDvLPDpo=; b=TOClbY0nJWZh j9gFMuOnckp/5Ra815fk3uZl9A0Uw30GmR6jvzt+KDEVD7L1OgVaXIv0bcHkyrZ5 4bJKpfnJgHJ6oYobKIV5yttdziQbGUEzVTWjyc9S7hx8ARO8QjsJtf8HSIt9MSLZ vCPj0WivaAwRjcmuijjxk2bZfoZ8ep8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=scd-systems.net; h=reply-to :subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=ZxBN6PyA3H2OPlmW/BpXIzN9BiJ7Tn2cmBbitorFNjroM/elqJIrA KixqpTBcpX9G0wd/wMW3378W+Ea8TU5YVN9DHvCsNTBqFm6N/aJkhYf+5aynBWiO NlfqVVh5Awyz8d8B8t/0/KZ/cKnCFJzdQKpKHdvf+/gZGaqRnJkE3c= Received: from LT1006.fritz.box (127.0.1.254 [127.0.1.254]) by mail.scd-systems.net (OpenSMTPD) with ESMTPSA id 9befa16d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Fri, 10 Jul 2020 05:58:40 +0000 (UTC) Reply-To: charlesr@scd-systems.net Subject: Re: RK3328/Rock64 GigE testers needed. To: freebsd-arm@freebsd.org References: <20200705000643.GA63127@server.rulingia.com> <20200709203532.GA9738@bluezbox.com> From: Charles Message-ID: Date: Fri, 10 Jul 2020 07:58:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200709203532.GA9738@bluezbox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B32RD2FhPz48Yf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=scd-systems.net header.s=default header.b=TOClbY0n; dmarc=none; spf=pass (mx1.freebsd.org: domain of charlesr@scd-systems.net designates 37.120.173.96 as permitted sender) smtp.mailfrom=charlesr@scd-systems.net X-Spamd-Result: default: False [-2.94 / 15.00]; HAS_REPLYTO(0.00)[charlesr@scd-systems.net]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[scd-systems.net:s=default]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.05)[-1.053]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[scd-systems.net:+]; NEURAL_HAM_SHORT(-0.41)[-0.409]; DMARC_NA(0.00)[scd-systems.net: no valid DMARC record]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197540, ipnet:37.120.160.0/19, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 05:58:49 -0000 Hi gonzo, Mark, If this patch and tuning settings are not help, do I have to solder like mentioned in https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ ? Just for the case, I bought some resistors. I would like to know why the interface works stable with linux. Best, C. Am 09.07.20 um 22:35 schrieb Oleksandr Tymoshenko: > Peter Jeremy (peter@rulingia.com) wrote: >> Head r362736 has enabled the internal RGMII delay lines in the RK3328 >> (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've >> modded to use the higher RGMII bus voltage, as per the v3.0). >> >> gonzo@ and I would be interested in other people's experiences with >> this revision - particularly other people with Rock64 v2 or Rock64 v3 >> boards. > > Thanks to everyone for tests, it looks like only Peter's device > networking was completely broken by the commit. As a possible workaround > I consider adding a tunable/sysctl that can be used to override the delay > in DTB. The change is available in this patch: > https://people.freebsd.org/~gonzo/patches/rockchip-gmac-202007009.patch > > This is WIP on improving if_dwc_rk and contains following changes > > - Enable and dump gmac clocks frequencies. RK3328 does not have ethernet > clocks implemented yet so this part fails on the SoC. > > - Configure clock according to the sensed media. I was able to switch > between 100 and 1000 switches on both Rock64 and on Firefly-RK3399 > > - Introduces tunable and sysctl dev.dwc.X.delays (where X is a unit > number, e.g. 0, 1... etc. The value is (rx_delay << 8) | tx_delay, > so adding dev.dwc.0.delays=0x4533 to loader.conf would set rx delay to 69 > and tx delay to 51. It's possible to change delays run-time using > sysctl too so people can experiment with values fast. > > - Print delay values and enable flags when changing delays. This should > be useful to get the delay values set by U-Boot and that worked before > the r362736. > > The patch does not have any performance improvements, so there is no > need to re-run tests. > From owner-freebsd-arm@freebsd.org Fri Jul 10 06:57:49 2020 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 2FD72361070 for ; Fri, 10 Jul 2020 06:57:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-49.consmr.mail.gq1.yahoo.com (sonic317-49.consmr.mail.gq1.yahoo.com [98.137.66.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B33lJ1YLmz4D0t for ; Fri, 10 Jul 2020 06:57:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: N_6BpMEVRDvd.miR6A7lED5GPdAEx7ojsA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Jul 2020 06:57:46 +0000 Received: by smtp427.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 392e08f9a5dd1e33a0d3cc4203f86505; Fri, 10 Jul 2020 06:55:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: RK3328/Rock64 GigE testers needed. From: Mark Millard In-Reply-To: Date: Thu, 9 Jul 2020 23:55:43 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200705000643.GA63127@server.rulingia.com> <20200709203532.GA9738@bluezbox.com> To: charlesr@scd-systems.net X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B33lJ1YLmz4D0t X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.17 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.175:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.024]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.005]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.175:from]; NEURAL_HAM_SHORT(-0.64)[-0.640]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 06:57:49 -0000 On 2020-Jul-9, at 22:58, Charles wrote: > Hi gonzo, Mark, >=20 > If this patch and tuning settings are not help, do I have to solder = like mentioned in = https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ ? >=20 > Just for the case, I bought some resistors. >=20 > I would like to know why the interface works stable with linux. None of my testing was based on using the investigatory patch, just head -r360311 and then updated to -r363021 (for the non-debug buildworld buildkernel based testing). None of my testing was based on my doing any explicit tuning. The Rock64 V2 in use has never been modified. The ~600 Mbps send from the Rock64 and the ~900 Mbps receive by the Rock64 for a non-debug buildworld buildkernel context, both before and after -r362736 , does not seem to show to indicate a problem in my context. One thing that is constant for my tests is that the u-boot in use is unchanged. I've no clue if FreeBSD is depending on some u-boot initialization. The u-boot is from building sysutils/u-boot-rock64 ( -r532703 ), involving sysutils/u-boot-master ( -r532958 at the time ). sysutils/u-boot-master has had updates since then (including to 2020.07) --but I've not installed any such u-boot updates on the Rock64. Various lines from U-Boot and the kernel during an example boot: U-Boot TPL 2020.04 (Apr 25 2020 - 07:18:42) U-Boot SPL 2020.04 (Apr 25 2020 - 07:18:42 +0000) U-Boot 2020.04 (Apr 25 2020 - 07:19:22 +0000) =1B =1B =1BE=1BF=1BI=1B =1Bv=1Be=1Br=1Bs=1Bi=1Bo=1Bn=1B:=1B =1B2=1B.=1B8=1B= 0=1B =1B=1B =1B =1B =1BE=1BF=1BI=1B =1BF=1Bi=1Br=1Bm=1Bw=1Ba=1Br=1Be=1B:=1B = =1BD=1Ba=1Bs=1B =1BU=1B-=1BB=1Bo=1Bo=1Bt=1B =1B(=1Br=1Be=1Bv=1B = =1B8=1B2=1B2=1B4=1B.=1B1=1B0=1B2=1B4=1B)=1B U=1Bs=1Bi=1Bn=1Bg=1B =1BD=1BT=1BB=1B =1Bp=1Br=1Bo=1Bv=1Bi=1Bd=1Be=1Bd=1B = =1Bb=1By=1B =1BE=1BF=1BI=1B =1Ba=1Bt=1B =1B0=1Bx=1B8=1B0=1Bf=1B0=1B0=1B0=1B= 0=1B.=1B =1BL=1Bo=1Ba=1Bd=1Bi=1Bn=1Bg=1B =1BD=1BT=1BB=1B =1Bo=1Bv=1Be=1Br=1Bl=1Ba=1B= y=1Bs=1B:=1B =1B'=1Br=1Bk=1B3=1B3=1B2=1B8=1B-=1Bd=1Bw=1Bc=1B3=1B.=1Bd=1Bt=1B= b=1Bo=1B'=1B =1Ba=1Bp=1Bp=1Bl=1By=1Bi=1Bn=1Bg=1B =1BD=1BT=1BB=1B =1Bo=1Bv=1Be=1Br=1Bl=1B= a=1By=1B = =1B'=1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bd=1Bt=1Bb=1B/=1Bo=1Bv=1Be=1Br=1Bl=1Ba=1By=1B= s=1B/=1Br=1Bk=1B3=1B3=1B2=1B8=1B-=1Bd=1Bw=1Bc=1B3=1B.=1Bd=1Bt=1Bb=1Bo=1B'=1B= =1B I've no clue what u-boot vintage/variation was in use for folks with problems for Rock64 V2 Ethernet. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 04:43:45 2020 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 DA5973554EF for ; Sat, 11 Jul 2020 04:43:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3ck82BDpz4MPJ for ; Sat, 11 Jul 2020 04:43:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: AHFsurIVM1nQaiun5J_oQe3SgI0rXGMv4Wy0BNQflZzRRv8eBOeWS7K3.Et_ReL NHV4L8V9qPs2l4mVLL_v_6kaiuypexxKa7TZHtBhjOuaFADknfr4UoB._JTshIpixgHM.DhFuSz_ 6awtRUH_jf4S5hNkToHZLkuxVmVZW6ToJS59JGSSTiBzgLAwuO_fKRXMjbuaPPGcICdybLNp1Gh5 1Slwu1TfJMZLadP0J_CFD9J4NuXcp771GWLu7_5wuwP35vmAhkxlMF_kRT52JrWSJfrizNaZudhW 9QH9mYhvaEnewPR_REGy7uzrWjA7b5MUmztKra.ggHdLBr5gguJWlsh1IdGp07zkFcOSecZF_Zkf rO37enp0XmeIxnMVRU_.Yj8HiwgcwwXXFVpr19LBdIGIX3.QXdEYd19K9clPzHP3z1pmrqjFzDjZ 8FGfgcpjrEZwyO8yBMOMVwoycQKF2d6ykQSZV_Zssn7kSjmMNmM237HsaEq_mjstisIrnI09zQEv zsf.8K94xM181ujQB2aTHbOkpOqybl9f4wVvAaTbFEjRabNLHjtDHhWz1R.zOeWpevLJUFfZcPjv krUTQ.loIpegVFGowl9hCxpB5ailsOkjrczztLxXb3Oe5A6kbUqV_28JD7oy0c0LehTxAENycwPd yZwUgZb5GoPq1gnQI7mWof9uGUAJb6bwzdmQ1TJGGElTUj8PaBOv56dSweNkjm4KAN7kuCiXGXNL G21RBPQlGfKCzxjImA6hnpL6aecSIxIekUZWmA6tGdmrJqTWBA4hsaedjSoWxnAo2btVA.5tYrW3 URVzqBkHBhAw.W7esNRm5u4G9sArJNQixDOfjUisDDLVvFyl4sBZYYg3sbjx43HfB49D3bPE6KtS RuZgbtWehb_RpxHvvG_aqcPyJJrL8UDuqN9JjBoV_9LJu9MF00kmcp1VlX9Ne7.1lmFDeX7T_yBU CYeB.zY03QYABFdDvNuaqETkKdlrqagA49JztZ7cEc1Eja7g3uF5YhRtsg9ONztwUc7xblnEfRab 94cLW_jL1I.wnoOhmWT993eq7dbWSRWDmU1Kb9hAOa54q74lrQYi7UIaGCjdrM2Z2.qwCMfI9rwv DCS42iookVIU_RW0Gc9l6wu8QR4VlNLxR6wM7rW6DrVNUU5.QngcazHcaAQvj8L.TxFP2PpUJGRq ZrpIBZQH1nY7TeOMHtXmWxRpJIQ7E9.z9vjCvYM930VJt.0GDTo34IogShdrdcivm5_77JZtg0.q bVqVcIa8OaZkR0VPQEhGxElbLnJHrRxi3eQTWK5Twi3eF2bEZphEj.74zmXNvQfOXXAWwl03D2kw fc_8gVxu4aSuJUqUwteWvRg_JzvU4pfNmUI3gkoTJF1wdJQWb1mxxZAXycViJMp2rp2n5HM2Iwfb 6IGV4uifIKAUWycVZ50UCN2iMTxtEzvd89LrwNB1iTcDqOQA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 04:43:42 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7c2fc7028f3b60de943e24c1bd9169dc; Sat, 11 Jul 2020 04:43:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: FYI: An armv7 head -r360311 crash backtrace ( pcpup / vm_radix_lookup_unlocked ) 'Translation Fault (L1)' on read Message-Id: <5A5A2562-6988-4DCB-BE48-67D62378A012@yahoo.com> Date: Fri, 10 Jul 2020 21:43:38 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <5A5A2562-6988-4DCB-BE48-67D62378A012.ref@yahoo.com> X-Rspamd-Queue-Id: 4B3ck82BDpz4MPJ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.26 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.87)[-0.875]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; NEURAL_SPAM_SHORT(0.12)[0.123]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 04:43:45 -0000 For a head -r360311 based armv7 environment (OPi+2e) I got: # svnlite update -r363021 /usr/src/ Updating '/usr/src': Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xe223b718 FSR=00000005, FAR=f79585f8, spsr=60000013 r0 =f79585ee, r1 =c3950000, r2 =00000000, r3 =00000000 r4 =ffffffff, r5 =00000000, r6 =00017afd, r7 =00000000 r8 =00000001, r9 =00000000, r10=e223b7f0, r11=e223b7c0 r12=c0b5cd14, ssp=e223b7a8, slr=c096d9c0, pc =c06614a0 panic: Fatal abort cpuid = 0 time = 1594441895 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0676724 lr = 0xc007f3a4 (db_trace_self_wrapper+0x30) sp = 0xe223b4f0 fp = 0xe223b608 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc007f3a4 lr = 0xc02ea2f0 (vpanic+0x174) sp = 0xe223b610 fp = 0xe223b630 r4 = 0x00000100 r5 = 0xe23143c0 r6 = 0xc07fef39 r7 = 0x00000000 vpanic() at vpanic+0x174 pc = 0xc02ea2f0 lr = 0xc02ea17c (vpanic) sp = 0xe223b638 fp = 0xe223b63c r4 = 0xe223b718 r5 = 0x00000013 r6 = 0xf79585f8 r7 = 0x00000005 r8 = 0x00000005 r9 = 0xe23143c0 r10 = 0xf79585f8 vpanic() at vpanic pc = 0xc02ea17c lr = 0xc069973c (abort_align) sp = 0xe223b644 fp = 0xe223b670 r4 = 0x00000005 r5 = 0x00000005 r6 = 0xe23143c0 r7 = 0xf79585f8 r8 = 0xe223b63c r9 = 0xc02ea17c r10 = 0xe223b644 abort_align() at abort_align pc = 0xc069973c lr = 0xc06992e8 (abort_handler+0x2e8) sp = 0xe223b678 fp = 0xe223b710 r4 = 0x00000013 r5 = 0xf79585f8 abort_handler() at abort_handler+0x2e8 pc = 0xc06992e8 lr = 0xc0679054 (exception_exit) sp = 0xe223b718 fp = 0xe223b7c0 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00017afd r7 = 0x00000000 r8 = 0x00000001 r9 = 0x00000000 r10 = 0xe223b7f0 exception_exit() at exception_exit pc = 0xc0679054 lr = 0xc096d9c0 (pcpup) sp = 0xe223b7a8 fp = 0xe223b7c0 r0 = 0xf79585ee r1 = 0xc3950000 r2 = 0x00000000 r3 = 0x00000000 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00017afd r7 = 0x00000000 r8 = 0x00000001 r9 = 0x00000000 r10 = 0xe223b7f0 r12 = 0xc0b5cd14 vm_radix_lookup_unlocked() at vm_radix_lookup_unlocked+0xb4 pc = 0xc06614a0 lr = 0xc065633c (vm_page_acquire_unlocked+0x78) sp = 0xe223b7c8 fp = 0xe223b810 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0x00000000 vm_page_acquire_unlocked() at vm_page_acquire_unlocked+0x78 pc = 0xc065633c lr = 0xc0657cb0 (vm_page_grab_pages_unlocked+0xa8) sp = 0xe223b818 fp = 0xe223b860 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0xe223b840 r8 = 0x00000000 r9 = 0x00000001 r10 = 0xe4802160 vm_page_grab_pages_unlocked() at vm_page_grab_pages_unlocked+0xa8 pc = 0xc0657cb0 lr = 0xc03b7b40 (allocbuf+0x458) sp = 0xe223b868 fp = 0xe223b8a8 r4 = 0x00000000 r5 = 0xc6fa3848 r6 = 0x00001222 r7 = 0xc6fa3908 r8 = 0x00001000 r9 = 0x00000001 r10 = 0x00001000 allocbuf() at allocbuf+0x458 pc = 0xc03b7b40 lr = 0xc03b5860 (getblkx+0x700) sp = 0xe223b8b0 fp = 0xe223b948 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00008000 r7 = 0xe223b908 r8 = 0x00000000 r9 = 0x00008000 r10 = 0xc6fa3848 getblkx() at getblkx+0x700 pc = 0xc03b5860 lr = 0xc03b4fd8 (breadn_flags+0x50) sp = 0xe223b950 fp = 0xe223b990 r4 = 0x00000000 r5 = 0xe36aa4a0 r6 = 0xe223b9c0 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xdaaf1538 r10 = 0xe23143c0 breadn_flags() at breadn_flags+0x50 pc = 0xc03b4fd8 lr = 0xc0605724 (ffs_blkatoff+0xe4) sp = 0xe223b998 fp = 0xe223b9e0 r4 = 0x00000200 r5 = 0xdaaf1000 r6 = 0xe223b9c0 r7 = 0x00000000 r8 = 0xe223ba7c r9 = 0xdaaf1538 r10 = 0x00000000 ffs_blkatoff() at ffs_blkatoff+0xe4 pc = 0xc0605724 lr = 0xc0616aac (ufs_lookup_ino+0x5a4) sp = 0xe223b9e8 fp = 0xe223bab0 r4 = 0x00000000 r5 = 0x00007fff r6 = 0x00000000 r7 = 0xffffffff r8 = 0xe223bc08 r9 = 0x00000000 r10 = 0x00000000 ufs_lookup_ino() at ufs_lookup_ino+0x5a4 pc = 0xc0616aac lr = 0xc03c2058 (vfs_cache_lookup+0xc8) sp = 0xe223bab8 fp = 0xe223bae0 r4 = 0xe223bc58 r5 = 0xe36aa4a0 r6 = 0xe223bc70 r7 = 0x00000000 r8 = 0xe223bc08 r9 = 0xe223bc78 r10 = 0xe223bc58 vfs_cache_lookup() at vfs_cache_lookup+0xc8 pc = 0xc03c2058 lr = 0xc03cd1f4 (lookup+0x6f4) sp = 0xe223bae8 fp = 0xe223bb38 r4 = 0xe223bc78 r5 = 0xe36aa4a0 r6 = 0xe223bc70 r7 = 0x00200000 lookup() at lookup+0x6f4 pc = 0xc03cd1f4 lr = 0xc03cc520 (namei+0x548) sp = 0xe223bb40 fp = 0xe223bbe8 r4 = 0xe223bc08 r5 = 0xe223bc64 r6 = 0xe23143c0 r7 = 0xc0b581d4 r8 = 0xe223bc98 r9 = 0xe223bc78 r10 = 0x00000000 namei() at namei+0x548 pc = 0xc03cc520 lr = 0xc03ebe08 (kern_statat+0x7c) sp = 0xe223bbf0 fp = 0xe223bcc8 r4 = 0xe23143c0 r5 = 0xe223bc08 r6 = 0x20d2c0d0 r7 = 0x00000000 r8 = 0xbfbfe20c r9 = 0x20d2c018 r10 = 0x00000000 kern_statat() at kern_statat+0x7c pc = 0xc03ebe08 lr = 0xc03ecb20 (sys_fstatat+0x2c) sp = 0xe223bcd0 fp = 0xe223bdc8 r4 = 0xe2314668 r5 = 0x00000000 r6 = 0x00000000 r7 = 0xc53e8880 r8 = 0xbfbfe20c r9 = 0x20d2c018 r10 = 0x00000000 sys_fstatat() at sys_fstatat+0x2c pc = 0xc03ecb20 lr = 0xc06988d8 (swi_handler+0x184) sp = 0xe223bdd0 fp = 0xe223be40 r4 = 0xe23143c0 r10 = 0x00000000 swi_handler() at swi_handler+0x184 pc = 0xc06988d8 lr = 0xc0678fe4 (swi_exit) sp = 0xe223be48 fp = 0xbfbfe070 r4 = 0xbfbfe078 r5 = 0xbfbfe180 r6 = 0x20d2c0d0 r7 = 0x00000228 r8 = 0xbfbfe20c r10 = 0x00000000 swi_exit() at swi_exit pc = 0xc0678fe4 lr = 0xc0678fe4 (swi_exit) sp = 0xe223be48 fp = 0xbfbfe070 KDB: enter: panic [ thread pid 66470 tid 100193 ] Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! db> The system had been sitting idle for a substantial time before I attempted that command. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 07:14:46 2020 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 A05BF358E3D for ; Sat, 11 Jul 2020 07:14:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3h4P2jHQz4Tg5 for ; Sat, 11 Jul 2020 07:14:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: s9PYQFoVM1ntgpHjIOOshX7_Xm0vgDZ93ZdeZuD92.0_INuQxc_fqvoUAWjS9ie OeCvJ9xVhEbm1RqGvEYC3NNreQDlapgMGTB9rsLu0lB29nNgawsVj3qeiwtG00P_vB9xGac16cap uLuUSeAL9Xq1icZ454boKuPP4gxQ4uSkgw6z0HNkU2mTObXlq51vh0__27GKTrDJkANsOUVs6S6I O0P9S6zzu0YG.y.z20EU8JP0UYUlMwHN0MesEypeRpBV_Jmb444PL8LcX2KlR5d99Uhm6yx.7Qww N15R2PUiPCdLHEILHrGSxtdqp2XjV1TZ.Yw5cugiBKCbGsK7cZxgdH3MM5c51UYHhZ20Cp4fdqyV u5NfzU1Eq6CUb7W7fcawBDUqMuqH1bn7y_LQX1FWl4Hg9fR0S4eWSJuCDhY2Pj1PDFh2M_Ldjk9p A4V1VozVnyLlKThlyZiOZ7lNBP_rC4bf_lW1rpXlvsv1rar92fBSSs6v1A7JPWSxeRtTxfToThAG i3oecD5eIfDZWNJGkw6NRsmzishlQSL938YiTYFPrUKZXsJ8oqYEOgWcCvlmltu8QjRf1fNWNJNv 1IRK6DIDkjdoPPa3udsX_JARr8msFpSOF4mOVCIK4GNFB26rKfkPhigaFUioLqe4PSZ.cnCJwZ2t pWE._VNC2cEgbIPhLa6iC9384RXNlzcDUe9tKYo9YtUGZSqa_hGWZGZYkQ87Z8KGK6Jx1MnFc86j RiIW3QhTs0MihJ0vQN14grT.tXFsjFE7fpYkxNlS9UHpISj0ztf6.LGuc4X83z8PjT3XnEZoSMeF 7wmuMTgipgqrPd6U96720YSnPByEwbE7FnRne7oipjHrkXzB3qaS4adnjxNRXJxirL0oTNYdqZGQ bP46v1HbP4TKApxBnnbmRZL_T_Posiugr66XBM9N7KDS4BK.D_io7VIostNw7gVLsZ.2lO15jRfS N_Q8hjaOBkcjreM_p0vPSLMnPmC91U_X7WEizR45xT6uf3xYmEdF9bMI5JydtVH_PJCJR9oRDwXh 18Ogd3_4M4iSY8ofk9GA_OVGdKgKZWGxRooDivp3.OnP0Lt4azTFHgNMJ2wmyX4XYNoEDbW6XOE. kMZjV6fgfEUSuXjndi8K0e4GNm21J8q1uVNeNVz.T73JoFsA6nRXhdQpOuunD90JjXsEVxYAHFw_ Nqppyy88WPAqVUj6q_icONDgdc4xMzCTZi0oEejS2d3KgEI4y.0H6U4IcYRIHzrufi0alZP.O7B. GRPqoo6J4VTyqdG_174lqnolQiUR8pxXXiOVV9bzc3OiTAgNf.Vk1fBog.dIKWVyIFQFDpaZGrTZ 2VL9bwMRHaT09KBlU4.PI7XttgRHu3hv6cPI4YPHN0pT8u_wEQ1oC6idHWs0COOquFklTXhSq7NR z4Cy7FOcRDPwf8wUjieoPNVYTIbtl29Bv1lrlGTTDnDcEri785RsaGdbqGw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 07:14:43 +0000 Received: by smtp413.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8f97a160aadea33e8be0f34d624244f8; Sat, 11 Jul 2020 07:14:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" . . . Message-Id: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> Date: Sat, 11 Jul 2020 00:14:40 -0700 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <6E0B6750-273C-468A-9233-E868B0674F34.ref@yahoo.com> X-Rspamd-Queue-Id: 4B3h4P2jHQz4Tg5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.86)[-0.865]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.03)[-1.033]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 07:14:46 -0000 Anyone else with such Overdrive 1000 problems after upgrading into this range or beyond? boot -v output: ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Type Physical Virtual #Pages Attr Reserved 008000000000 0 00000e80 WC WT WB=20 ConventionalMemory 008000e80000 0 0001ef7d WC WT WB=20 BootServicesData 00801fdfd000 0 00000203 WC WT WB=20 ConventionalMemory 008020000000 0 001d0583 WC WT WB=20 LoaderData 0081f0583000 0 00008000 WC WT WB=20 LoaderCode 0081f8583000 0 0000017d WC WT WB=20 ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB=20 ConventionalMemory 0081f87a0000 0 0000000b WC WT WB=20 LoaderData 0081f87ab000 0 00000001 WC WT WB=20 ConventionalMemory 0081f87ac000 0 000020ab WC WT WB=20 BootServicesData 0081fa857000 0 00000029 WC WT WB=20 ConventionalMemory 0081fa880000 0 0000000b WC WT WB=20 BootServicesData 0081fa88b000 0 0000001f WC WT WB=20 ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB=20 BootServicesData 0081fa8ad000 0 000002f0 WC WT WB=20 ConventionalMemory 0081fab9d000 0 00000001 WC WT WB=20 BootServicesData 0081fab9e000 0 00000012 WC WT WB=20 ConventionalMemory 0081fabb0000 0 00000001 WC WT WB=20 BootServicesData 0081fabb1000 0 00000006 WC WT WB=20 ConventionalMemory 0081fabb7000 0 00000002 WC WT WB=20 BootServicesData 0081fabb9000 0 00000ae7 WC WT WB=20 ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB=20 BootServicesCode 0081fb6e6000 0 0000014a WC WT WB=20 RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB = RUNTIME ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB=20 RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB = RUNTIME ConventionalMemory 0081fc000000 0 0000001f WC WT WB=20 BootServicesData 0081fc01f000 0 00000001 WC WT WB=20 ConventionalMemory 0081fc020000 0 00003732 WC WT WB=20 BootServicesData 0081ff752000 0 0000087a WC WT WB=20 ConventionalMemory 0081fffcc000 0 00000004 WC WT WB=20 RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB = RUNTIME ConventionalMemory 0081ffff0000 0 0000000c WC WT WB=20 BootServicesData 0081ffffc000 0 00000004 WC WT WB=20 Physical memory chunk(s): 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) Excluded memory regions: 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc=20 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc=20 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc=20 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc=20 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc=20 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc=20 Found 4 CPUs in the device tree Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 = markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) VT: init without driver. Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. Preloaded boot_entropy_cache "/boot/entropy" at 0xffff00000116f360. module firmware already present! module_register: cannot register simplebus/gpio from kernel; already = loaded from kernel Module simplebus/gpio failed to register: 17 module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel Module simplebus/pcib failed to register: 17 Starting CPU 1 (101) Starting CPU 2 (200) Starting CPU 3 (201) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: read 4096 bytes from preloaded cache random: unblocking device. VIMAGE (virtualized network stack) enabled hostuuid: using # ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 Table 'FACP' at 0x81f8770000 Table 'APIC' at 0x81f8750000 Table 'GTDT' at 0x81f8740000 Table 'DBG2' at 0x81f8730000 Table 'SPCR' at 0x81f8720000 Table 'MCFG' at 0x81f8710000 Table 'CSRT' at 0x81f8700000 ACPI: No IORT table found snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff = [1024] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 random: entropy device external interface MAP 81fb830000 mode 2 pages 992 MAP 81fbdb0000 mode 2 pages 592 MAP 81fffd0000 mode 2 pages 32 WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD = 13.0. kbd0 at kbdmux0 crypto: mem: null: openfirm: WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. ofwbus0: simplebus0: on ofwbus0 clk_fixed0: on simplebus0 clk_fixed1: on simplebus0 clk_fixed2: on simplebus0 clk_fixed3: on simplebus0 clk_fixed4: on simplebus0 clk_fixed5: on simplebus0 clk_fixed6: on simplebus0 clk_fixed7: on simplebus0 clk_fixed8: on simplebus0 clk_fixed9: on simplebus0 clk_fixed10: on simplebus0 psci0: on ofwbus0 psci0: PSCI version 0.2 compatible gic0: mem = 0xe1110000-0xe1110fff,0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe11600= 00-0xe116ffff irq 4 on ofwbus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 gicv2m0: mem 0x80000-0x80fff = on gic0 gicv2m0: using spi 64 to 319 generic_timer0: irq 5,6,7,8 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality 1000 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s cpulist0: on ofwbus0 cpu0: on cpulist0 cpu0: missing 'clock-frequency' property cpu1: on cpulist0 cpu1: missing 'clock-frequency' property cpu2: on cpulist0 cpu2: missing 'clock-frequency' property cpu3: on cpulist0 cpu3: missing 'clock-frequency' property pmu0: irq 0,1,2,3 on ofwbus0 ahci0: mem 0xe0300000-0xe03effff irq 9 on = simplebus0 ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC 8ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: HPCP ahcich1: at channel 1 on ahci0 ahcich1: Caps: HPCP ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahcich6: not probed (disabled) ahcich7: not probed (disabled) simplebus0: mem 0xe0d00000-0xe0deffff irq 10 disabled = compat snps,dwc-ahci (no driver attached) simplebus0: mem 0xe1000000-0xe1000fff irq 11 compat = snps,designware-i2c (no driver attached) simplebus0: mem 0xe0050000-0xe0050fff irq 12 compat = snps,designware-i2c (no driver attached) uart0: mem 0xe1010000-0xe1010fff irq 13 on = simplebus0 uart0: console (115200,n,8,1) uart0: fast interrupt uart0: PPS capture mode: DCD simplebus0: mem 0xe1020000-0xe1020fff irq 14 compat = arm,pl022 (no driver attached) simplebus0: mem 0xe1030000-0xe1030fff irq 15 compat = arm,pl022 (no driver attached) simplebus0: mem 0xe1050000-0xe1050fff irq 16 compat = arm,pl061 (no driver attached) simplebus0: mem 0xe0020000-0xe0020fff irq 17 compat = arm,pl061 (no driver attached) simplebus0: mem 0xe0030000-0xe0030fff irq 18 compat = arm,pl061 (no driver attached) simplebus0: mem 0xe0080000-0xe0080fff irq 19 compat = arm,pl061 (no driver attached) simplebus0: mem 0xe0100000-0xe010ffff irq 20 compat = amd,ccp-seattle-v1a (no driver attached) simplebus0: mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) simplebus0: mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) simplebus0: mem = 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0bcffff irq 22 compat arm,sbsa-gwdt = (no driver attached) simplebus0: mem 0xe0010000-0xe0010007 irq 23 type ipmi = compat ipmi-kcs (no driver attached) simplebus0: mem = 0xe1240800-0xe1240bff,0xe1250000-0xe125005f,0xe12500f8-0xe12500fb irq 24 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) simplebus0: mem = 0xe1240c00-0xe1240fff,0xe1250080-0xe12500df,0xe12500fc-0xe12500ff irq 25 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) simplebus0: mem = 0xe0700000-0xe077ffff,0xe0780000-0xe07fffff irq 26,27,28,29,30 disabled = compat amd,xgbe-seattle-v1a (no driver attached) simplebus0: mem = 0xe0900000-0xe097ffff,0xe0980000-0xe09fffff irq 31,32,33,34,35 disabled = compat amd,xgbe-seattle-v1a (no driver attached) cryptosoft0: crypto: assign cryptosoft0 driver id 0, flags 0x6000000 Device configuration finished. Found SMCCC version 1.0 procfs registered Timecounters tick every 1.000 msec lo0: bpf attached vlan: initialized, using hash tables with chaining IPsec: Initialized Security Association Processing. tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 usb_needs_explore_all: no devclass Release APs...ahcich0: AHCI reset... Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... done Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> ahcich0: SATA connect timeout time=3D10000us status=3D00000000 Instruction Set Attributes 0 =3D ahcich0: AHCI reset: device not found Instruction Set Attributes 1 =3D <> ahcich1: AHCI reset... Processor Features 0 =3D ahcich1: SATA connect time=3D100us status=3D00000133 Processor Features 1 =3D <> ahcich1: AHCI reset: device found Memory Model Features 0 =3D ahcich1: AHCI reset: device ready after 0ms Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 regulator: shutting down unused regulators Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk ada0 ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number # ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 976762MB (2000409264 512 byte sectors) pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 pass0: ACS-4 ATA SATA 3.x device pass0: Serial Number # pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) pass0: Command Queueing enabled efirtc0: providing initial system time start_init: trying /sbin/init Setting hostuuid: #. Setting hostid: #. Starting file system checks: /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, 23658372 = blocks, 0.1% fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 = /usr/local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 = /usr/local/llvm10/lib /usr/local/llvm80/lib Setting hostname: FBSDCA57. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED Feeding entropy: . lo0: link state changed to UP Starting Network: lo0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 Starting devd. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 08:32:40 2020 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 E599035BBF6 for ; Sat, 11 Jul 2020 08:32:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3jpH3gGBz4d0B for ; Sat, 11 Jul 2020 08:32:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mSpAYbMVM1mqtjwyFtu.SDCi4kdFBEnICGxra0wpJC544WPw_whtkF0hPTq9sew 0TLcNui5Q13wWVNkAxvlmNtXp2fHNQfwhqavMgnXf6fiVBMv07B8tnJQv266KsuipqMw9kXd1uSt kLkNOq3uwn1on7Ypx7y5LBMzgzVKGyc3JgX2FO_jSTrV__QbuCZPzHTRj.OY4ZAW76rUnM12uCsr hturRU1PScwsAWHuA9yN_rv4K80CZkYk54xzvwXQhYgPiap4TwSAKslc45rMWIf6wNGXxBcjkzDx yaqI.VCJ4YMl1Bpm9dVBgBcLVghHYPixcHVS9zVor7b1eEH9Ru9C0tx2KFhNTcH0bLc0Mb0VCf6K CcIC1agGox9AyHzWgaGFbwhLtZemCWxl_kS4XM989rHn0j53CnwOOTX_DswHP5TeATMWPNFZa4k2 N7C9oKNKsv5ge1Wowu_A.EwoV4GeH6Loy0Srx0J0avob5DJdELU1vdeS3ZW5wbYmtW2_ZQLRfFCB LoWwyarAZciksWziVRrwgcLA4zBmNBHEF2fhgKnHyfNeRcujAkOj8N9FPN1F98bIXPC4YmfNfQaC lEVNjjkw.0_qyf6TzCaMZqsi1x5d3EzD0_pPj9CjCiiu0MlKOKpk0CSSd16tVYjsg8B8eqKFjCeI sy1F8M6TBzIl9gyt5EsAk_wCOXt_S6XRrwEvvdQxqvv8es6c61GiTm7ERwE1t8NQ4HFwdXY8QeB_ ECtuC6efz0A4sTGDr88qr_1XdqMk_WevFARM0saB7IkM7LU_yeU4AAvG4Gz2CFQSLe2b46m.XZ9K 4XxkhdlvXUv4VPmNUeDKI4cK6GEBbKCLxe8zwDybgbSnbZAO.Ocq1.3P6hzQJdl2AUEaDPhiJ.eF WyP.Lfd4rakeoOtEuSiG0Vr0rBiSM5c2xBO62m_L8JPBrupEAdVi6TwaDUbradl548yweJB6k_5_ Gpv5dmwqafBrTLWSM1TEtQmaa6voXiK6L7zV4qxksYUNwmh1qYZFtxmwVnrxCEdYq5sQ18Pgr1oh T8aYGk50MC_l.kM59CexL1a1XA9WEo6gY9EGniOn2p3pHYM1BBOkian81KIvkCVeyPBXbzycTCS. TQyCXSDCxP7ByO.Fe5LJTe5K1bB7kOdalpfyIN_5nCeTTuVGB8dLu6NquQpmfwQIqz3Eu6VYLR7t 9Yb3xWDc.7FRoRGKgwQsBt8DCjSWs0zKIZjQGyfIpUtjV41gJxFJqGeqZARa9aIUHkVJAA_GvhVc wdBrZ9Tum_G1p9AwqfUEOIrLLVyYQC7pqOmI9pcWnpMjMetmPN_.AlZnTgEnLS13vhiwGj4dJWo_ u53wwlW_FlXU5teQydcr1Vq0ViivJkO6ogumVtv26hhX1Couz8WcgxrpmApoX6qQzoKe_ilLXBtu 86JXKo6dKDwlbLPmFVmcFkg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 08:32:38 +0000 Received: by smtp412.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d30c39d5acc4bf3487a8a64eec49f2fe; Sat, 11 Jul 2020 08:32:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) Date: Sat, 11 Jul 2020 01:32:35 -0700 References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> To: "hselasky@freebsd.org " , Andrew Turner , Robert Crowston , freebsd-arm , FreeBSD Current In-Reply-To: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> Message-Id: <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B3jpH3gGBz4d0B X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.02 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.87)[-0.867]; FREEMAIL_TO(0.00)[FreeBSD.org,freebsd.org,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.64)[-0.637]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 08:32:41 -0000 On 2020-Jul-11, at 00:14, Mark Millard wrote: > Anyone else with such Overdrive 1000 problems after > upgrading into this range or beyond? >=20 > boot -v output: >=20 > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Type Physical Virtual #Pages Attr > Reserved 008000000000 0 00000e80 WC WT WB=20 > ConventionalMemory 008000e80000 0 0001ef7d WC WT WB=20 > BootServicesData 00801fdfd000 0 00000203 WC WT WB=20 > ConventionalMemory 008020000000 0 001d0583 WC WT WB=20 > LoaderData 0081f0583000 0 00008000 WC WT WB=20 > LoaderCode 0081f8583000 0 0000017d WC WT WB=20 > ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB=20 > ConventionalMemory 0081f87a0000 0 0000000b WC WT WB=20 > LoaderData 0081f87ab000 0 00000001 WC WT WB=20 > ConventionalMemory 0081f87ac000 0 000020ab WC WT WB=20 > BootServicesData 0081fa857000 0 00000029 WC WT WB=20 > ConventionalMemory 0081fa880000 0 0000000b WC WT WB=20 > BootServicesData 0081fa88b000 0 0000001f WC WT WB=20 > ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB=20 > BootServicesData 0081fa8ad000 0 000002f0 WC WT WB=20 > ConventionalMemory 0081fab9d000 0 00000001 WC WT WB=20 > BootServicesData 0081fab9e000 0 00000012 WC WT WB=20 > ConventionalMemory 0081fabb0000 0 00000001 WC WT WB=20 > BootServicesData 0081fabb1000 0 00000006 WC WT WB=20 > ConventionalMemory 0081fabb7000 0 00000002 WC WT WB=20 > BootServicesData 0081fabb9000 0 00000ae7 WC WT WB=20 > ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB=20 > BootServicesCode 0081fb6e6000 0 0000014a WC WT WB=20 > RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB = RUNTIME > ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB=20 > RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB = RUNTIME > ConventionalMemory 0081fc000000 0 0000001f WC WT WB=20 > BootServicesData 0081fc01f000 0 00000001 WC WT WB=20 > ConventionalMemory 0081fc020000 0 00003732 WC WT WB=20 > BootServicesData 0081ff752000 0 0000087a WC WT WB=20 > ConventionalMemory 0081fffcc000 0 00000004 WC WT WB=20 > RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB = RUNTIME > ConventionalMemory 0081ffff0000 0 0000000c WC WT WB=20 > BootServicesData 0081ffffc000 0 00000004 WC WT WB=20 > Physical memory chunk(s): > 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) > 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) > 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) > Excluded memory regions: > 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc=20 > 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc=20 > 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc=20 > 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc=20 > 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc=20 > 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc=20 > Found 4 CPUs in the device tree > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 > = markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 > FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) > VT: init without driver. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. > Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. > Preloaded boot_entropy_cache "/boot/entropy" at 0xffff00000116f360. > module firmware already present! > module_register: cannot register simplebus/gpio from kernel; already = loaded from kernel > Module simplebus/gpio failed to register: 17 > module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel > Module simplebus/pcib failed to register: 17 > Starting CPU 1 (101) > Starting CPU 2 (200) > Starting CPU 3 (201) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: read 4096 bytes from preloaded cache > random: unblocking device. > VIMAGE (virtualized network stack) enabled > hostuuid: using # > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > Table 'FACP' at 0x81f8770000 > Table 'APIC' at 0x81f8750000 > Table 'GTDT' at 0x81f8740000 > Table 'DBG2' at 0x81f8730000 > Table 'SPCR' at 0x81f8720000 > Table 'MCFG' at 0x81f8710000 > Table 'CSRT' at 0x81f8700000 > ACPI: No IORT table found > snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff = [1024] > feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 > random: entropy device external interface > MAP 81fb830000 mode 2 pages 992 > MAP 81fbdb0000 mode 2 pages 592 > MAP 81fffd0000 mode 2 pages 32 > WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. > kbd0 at kbdmux0 > crypto: > mem: > null: > openfirm: > WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. > ofwbus0: > simplebus0: on ofwbus0 > clk_fixed0: on simplebus0 > clk_fixed1: on simplebus0 > clk_fixed2: on simplebus0 > clk_fixed3: on simplebus0 > clk_fixed4: on simplebus0 > clk_fixed5: on simplebus0 > clk_fixed6: on simplebus0 > clk_fixed7: on simplebus0 > clk_fixed8: on simplebus0 > clk_fixed9: on simplebus0 > clk_fixed10: on simplebus0 > psci0: on ofwbus0 > psci0: PSCI version 0.2 compatible > gic0: mem = 0xe1110000-0xe1110fff,0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe11600= 00-0xe116ffff irq 4 on ofwbus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 > gicv2m0: mem = 0x80000-0x80fff on gic0 > gicv2m0: using spi 64 to 319 > generic_timer0: irq 5,6,7,8 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality = 1000 > efirtc0: > efirtc0: registered as a time-of-day clock, resolution 1.000000s > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu0: missing 'clock-frequency' property > cpu1: on cpulist0 > cpu1: missing 'clock-frequency' property > cpu2: on cpulist0 > cpu2: missing 'clock-frequency' property > cpu3: on cpulist0 > cpu3: missing 'clock-frequency' property > pmu0: irq 0,1,2,3 on ofwbus0 > ahci0: mem 0xe0300000-0xe03effff irq 9 on = simplebus0 > ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported > ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC 8ports > ahci0: Caps2: APST > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: HPCP > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: HPCP > ahcich2: not probed (disabled) > ahcich3: not probed (disabled) > ahcich4: not probed (disabled) > ahcich5: not probed (disabled) > ahcich6: not probed (disabled) > ahcich7: not probed (disabled) > simplebus0: mem 0xe0d00000-0xe0deffff irq 10 disabled = compat snps,dwc-ahci (no driver attached) > simplebus0: mem 0xe1000000-0xe1000fff irq 11 compat = snps,designware-i2c (no driver attached) > simplebus0: mem 0xe0050000-0xe0050fff irq 12 compat = snps,designware-i2c (no driver attached) > uart0: mem 0xe1010000-0xe1010fff irq 13 on = simplebus0 > uart0: console (115200,n,8,1) > uart0: fast interrupt > uart0: PPS capture mode: DCD > simplebus0: mem 0xe1020000-0xe1020fff irq 14 compat = arm,pl022 (no driver attached) > simplebus0: mem 0xe1030000-0xe1030fff irq 15 compat = arm,pl022 (no driver attached) > simplebus0: mem 0xe1050000-0xe1050fff irq 16 compat = arm,pl061 (no driver attached) > simplebus0: mem 0xe0020000-0xe0020fff irq 17 compat = arm,pl061 (no driver attached) > simplebus0: mem 0xe0030000-0xe0030fff irq 18 compat = arm,pl061 (no driver attached) > simplebus0: mem 0xe0080000-0xe0080fff irq 19 compat = arm,pl061 (no driver attached) > simplebus0: mem 0xe0100000-0xe010ffff irq 20 compat = amd,ccp-seattle-v1a (no driver attached) > simplebus0: mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) > simplebus0: mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) > simplebus0: mem = 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0bcffff irq 22 compat arm,sbsa-gwdt = (no driver attached) > simplebus0: mem 0xe0010000-0xe0010007 irq 23 type ipmi = compat ipmi-kcs (no driver attached) > simplebus0: mem = 0xe1240800-0xe1240bff,0xe1250000-0xe125005f,0xe12500f8-0xe12500fb irq 24 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) > simplebus0: mem = 0xe1240c00-0xe1240fff,0xe1250080-0xe12500df,0xe12500fc-0xe12500ff irq 25 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) > simplebus0: mem = 0xe0700000-0xe077ffff,0xe0780000-0xe07fffff irq 26,27,28,29,30 disabled = compat amd,xgbe-seattle-v1a (no driver attached) > simplebus0: mem = 0xe0900000-0xe097ffff,0xe0980000-0xe09fffff irq 31,32,33,34,35 disabled = compat amd,xgbe-seattle-v1a (no driver attached) > cryptosoft0: > crypto: assign cryptosoft0 driver id 0, flags 0x6000000 > Device configuration finished. > Found SMCCC version 1.0 > procfs registered > Timecounters tick every 1.000 msec > lo0: bpf attached > vlan: initialized, using hash tables with chaining > IPsec: Initialized Security Association Processing. > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 > Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 > usb_needs_explore_all: no devclass > Release APs...ahcich0: AHCI reset... > Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... > done > Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 0 >=20 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > ahcich0: SATA connect timeout time=3D10000us status=3D00000000 > Instruction Set Attributes 0 =3D > ahcich0: AHCI reset: device not found > Instruction Set Attributes 1 =3D <> > ahcich1: AHCI reset... > Processor Features 0 =3D > ahcich1: SATA connect time=3D100us status=3D00000133 > Processor Features 1 =3D <> > ahcich1: AHCI reset: device found > Memory Model Features 0 =3D > ahcich1: AHCI reset: device ready after 0ms > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 > CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 > CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 > regulator: shutting down unused regulators > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > GEOM: new disk ada0 > ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada0: ACS-4 ATA SATA 3.x device > ada0: Serial Number # > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 976762MB (2000409264 512 byte sectors) > pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 > pass0: ACS-4 ATA SATA 3.x device > pass0: Serial Number # > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > pass0: Command Queueing enabled > efirtc0: providing initial system time > start_init: trying /sbin/init > Setting hostuuid: #. > Setting hostid: #. > Starting file system checks: > /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, 23658372 = blocks, 0.1% fragmentation) > Mounting local filesystems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 = /usr/local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 = /usr/local/llvm10/lib /usr/local/llvm80/lib > Setting hostname: FBSDCA57. > Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED > Feeding entropy: . > lo0: link state changed to UP > Starting Network: lo0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D680003= > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > Starting devd. > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 I used artificat.ci.freebsd.org to do an approximate bisect and the results are: head -r362952 and before work. there was no -r362953 artifact head -r362954 and later fail. The potential failure checkins are -r362953 and -r362954 : Author: hselasky Date: Mon Jul 6 08:50:11 2020 New Revision: 362953 URL:=20 https://svnweb.freebsd.org/changeset/base/362953 Log: Infiniband clients must be attached and detached in a specific order = in ibcore. . . . Differential Revision: https://reviews.freebsd.org/D23973 . . . and: Author: andrew Date: Mon Jul 6 08:51:55 2020 New Revision: 362954 URL:=20 https://svnweb.freebsd.org/changeset/base/362954 Log: Add a driver for bcm2838 PCI express controller . . . Submitted by: Robert Crowston Differential Revision: https://reviews.freebsd.org/D25068 . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 09:26:27 2020 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 BA9BA35C77A for ; Sat, 11 Jul 2020 09:26:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3l0L2746z4gLD for ; Sat, 11 Jul 2020 09:26:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 26aEXugVM1kM9iSn.ozO5BZX63yiM7EwHKpI3xrEfiu8ZSJ7fZe7jjDiLBbFa2F Z2iZaEqsQ2clVSVoYpcMv0r8TtthQIEpbpOj1XE0XUQLXUYBmwXieAwg0gTH2ExI0OphL0qC.lkh JuQ3Z5PK7pmlGo_iabr.r3oTKn.bD3G2y81CbICkmDJFpd341RfRMHU2iWtCsHuOScxMauVKyCme deqZcwJ2km.HRgJuuEbPPtI50ZN7HrC.XXeQoHyzED3kHwknZQ3PP90AT3lFnbu3VAKLulKuPbxO o56pSoz.n4hHGiC7dznBrvTUT_tQu61Eq1m0wFveaWxHidNAsG3taLBHJUJ7iP4soVf3mnV8a31W vNQ1nUyJKo2iDeG0flECWYLje1KzHACRdS8iCb56zPtnV0V5pnQa96XYqsY7utY4pJ20sDRCHBtv GLEqtCMvoqUipO1eEuTJlPxwNngzfCLeiyGMugjvH3d5vH6sZUF4kzysElnxnGYbqgJsiKSKKhsG OUHv2SMZroVEzWxBYe0z82fqZve3lIvb6dcC2iTT7pMUXWrfnsMMqavHG0UFwGz.JIonmR_uqfdo Sn8V9yj6bFPX6kP82TS.rXub1.n8OxVQycRekS50bQKKlFVRHKHDo3EVnIMPpzfw35iw7Ks.2Oje CRItJGt3KlwMyWslmZ1bGGY88w4L5USV0ckgnc7yGHDAPFuZSVQ3ncaPXuAboGLGzHkx9XtyMJq9 YxalYMM4GXuXR0AQgPjdLAASfE16OGgVEXSZTqf40ndaRS_V._rn3CBg730Q1z8hWtHDqXZ4_GPb zsL0_PZi0Pr8k.DUHcwomgSVXzyRbhh4pfWLwQ_sfs4f3_4g5z9WeJdjI4k1kJSUq7CSWt6lmeHR 8ipyP5NYBD8LlbU8aX8w63P4EBTohNF..2G2FBWDPD9z6SPoKu8Jgj0rGqZQb6KxZ535ThvNRwwg NBIMTIHAOl2Yfv9Camw0Q3MKEdcNfuA7I3PT2e5y4faRO.jWbiPtllxwSXtkZTd8ew65mdcuxmU9 0Ip97RByEVMuobuFdek7GABToS11gtQqlrtaYDQvFyWFLDooOEUWuwx2HZYDC3Wjrvu.JG8QDL.X 4W9ZSO7OnrVVR7N5oCagwwCQvM40zPiBfu0PaWaRSfDoHWOSJyP_6nAw1hb5zO2_l3LFGcxdi0PN M7H7ocimSeojNtz_su1qYWn.abiQX5IY7P8P7LENhljtXTVfYEs.veItyMFAZeK9wZLh4vI.2MIC spgvHCPIsGdMPJSR4Z0CocrRZl6F7ej_cYViRo6HwdYZw6HvMl3y11Sl..h.QIFJRbicF8oPu6Aw inwxx3xKAVihIwCuClbnoLkcWJWhRYhctE90epLTC2qjBOe9sT_jaMNMYwWUFDdfSyftQRxlVag_ L4.nxAcC1GWeeF536JSBi Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 09:26:25 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d99fdc51bb692b1452ec5a7082dec412; Sat, 11 Jul 2020 09:26:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) Date: Sat, 11 Jul 2020 02:26:19 -0700 References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> To: Andrew Turner , Robert Crowston , freebsd-arm , FreeBSD Current In-Reply-To: <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> Message-Id: <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B3l0L2746z4gLD X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.90)[-0.902]; FREEMAIL_TO(0.00)[freebsd.org,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 09:26:27 -0000 On 2020-Jul-11, at 01:32, Mark Millard wrote: > On 2020-Jul-11, at 00:14, Mark Millard wrote: >=20 >> Anyone else with such Overdrive 1000 problems after >> upgrading into this range or beyond? >>=20 >> boot -v output: >>=20 >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Type Physical Virtual #Pages Attr >> Reserved 008000000000 0 00000e80 WC WT WB=20 >> ConventionalMemory 008000e80000 0 0001ef7d WC WT WB=20 >> BootServicesData 00801fdfd000 0 00000203 WC WT WB=20 >> ConventionalMemory 008020000000 0 001d0583 WC WT WB=20 >> LoaderData 0081f0583000 0 00008000 WC WT WB=20 >> LoaderCode 0081f8583000 0 0000017d WC WT WB=20 >> ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB=20 >> ConventionalMemory 0081f87a0000 0 0000000b WC WT WB=20 >> LoaderData 0081f87ab000 0 00000001 WC WT WB=20 >> ConventionalMemory 0081f87ac000 0 000020ab WC WT WB=20 >> BootServicesData 0081fa857000 0 00000029 WC WT WB=20 >> ConventionalMemory 0081fa880000 0 0000000b WC WT WB=20 >> BootServicesData 0081fa88b000 0 0000001f WC WT WB=20 >> ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB=20 >> BootServicesData 0081fa8ad000 0 000002f0 WC WT WB=20 >> ConventionalMemory 0081fab9d000 0 00000001 WC WT WB=20 >> BootServicesData 0081fab9e000 0 00000012 WC WT WB=20 >> ConventionalMemory 0081fabb0000 0 00000001 WC WT WB=20 >> BootServicesData 0081fabb1000 0 00000006 WC WT WB=20 >> ConventionalMemory 0081fabb7000 0 00000002 WC WT WB=20 >> BootServicesData 0081fabb9000 0 00000ae7 WC WT WB=20 >> ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB=20 >> BootServicesCode 0081fb6e6000 0 0000014a WC WT WB=20 >> RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB = RUNTIME >> ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB=20 >> RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB = RUNTIME >> ConventionalMemory 0081fc000000 0 0000001f WC WT WB=20 >> BootServicesData 0081fc01f000 0 00000001 WC WT WB=20 >> ConventionalMemory 0081fc020000 0 00003732 WC WT WB=20 >> BootServicesData 0081ff752000 0 0000087a WC WT WB=20 >> ConventionalMemory 0081fffcc000 0 00000004 WC WT WB=20 >> RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB = RUNTIME >> ConventionalMemory 0081ffff0000 0 0000000c WC WT WB=20 >> BootServicesData 0081ffffc000 0 00000004 WC WT WB=20 >> Physical memory chunk(s): >> 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) >> 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) >> 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) >> Excluded memory regions: >> 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc=20 >> 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc=20 >> 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc=20 >> 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc=20 >> 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc=20 >> 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc=20 >> Found 4 CPUs in the device tree >> Copyright (c) 1992-2020 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 >> = markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 >> FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) >> VT: init without driver. >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. >> Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. >> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff00000116f360. >> module firmware already present! >> module_register: cannot register simplebus/gpio from kernel; already = loaded from kernel >> Module simplebus/gpio failed to register: 17 >> module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel >> Module simplebus/pcib failed to register: 17 >> Starting CPU 1 (101) >> Starting CPU 2 (200) >> Starting CPU 3 (201) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: read 4096 bytes from preloaded cache >> random: unblocking device. >> VIMAGE (virtualized network stack) enabled >> hostuuid: using # >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ULE: setup cpu 2 >> ULE: setup cpu 3 >> Table 'FACP' at 0x81f8770000 >> Table 'APIC' at 0x81f8750000 >> Table 'GTDT' at 0x81f8740000 >> Table 'DBG2' at 0x81f8730000 >> Table 'SPCR' at 0x81f8720000 >> Table 'MCFG' at 0x81f8710000 >> Table 'CSRT' at 0x81f8700000 >> ACPI: No IORT table found >> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff= [1024] >> feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 >> random: entropy device external interface >> MAP 81fb830000 mode 2 pages 992 >> MAP 81fbdb0000 mode 2 pages 592 >> MAP 81fffd0000 mode 2 pages 32 >> WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. >> kbd0 at kbdmux0 >> crypto: >> mem: >> null: >> openfirm: >> WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. >> ofwbus0: >> simplebus0: on ofwbus0 >> clk_fixed0: on simplebus0 >> clk_fixed1: on simplebus0 >> clk_fixed2: on simplebus0 >> clk_fixed3: on simplebus0 >> clk_fixed4: on simplebus0 >> clk_fixed5: on simplebus0 >> clk_fixed6: on simplebus0 >> clk_fixed7: on simplebus0 >> clk_fixed8: on simplebus0 >> clk_fixed9: on simplebus0 >> clk_fixed10: on simplebus0 >> psci0: on ofwbus0 >> psci0: PSCI version 0.2 compatible >> gic0: mem = 0xe1110000-0xe1110fff,0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe11600= 00-0xe116ffff irq 4 on ofwbus0 >> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 >> gicv2m0: mem = 0x80000-0x80fff on gic0 >> gicv2m0: using spi 64 to 319 >> generic_timer0: irq 5,6,7,8 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality = 1000 >> efirtc0: >> efirtc0: registered as a time-of-day clock, resolution 1.000000s >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu0: missing 'clock-frequency' property >> cpu1: on cpulist0 >> cpu1: missing 'clock-frequency' property >> cpu2: on cpulist0 >> cpu2: missing 'clock-frequency' property >> cpu3: on cpulist0 >> cpu3: missing 'clock-frequency' property >> pmu0: irq 0,1,2,3 on ofwbus0 >> ahci0: mem 0xe0300000-0xe03effff irq 9 on = simplebus0 >> ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported >> ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC 8ports >> ahci0: Caps2: APST >> ahcich0: at channel 0 on ahci0 >> ahcich0: Caps: HPCP >> ahcich1: at channel 1 on ahci0 >> ahcich1: Caps: HPCP >> ahcich2: not probed (disabled) >> ahcich3: not probed (disabled) >> ahcich4: not probed (disabled) >> ahcich5: not probed (disabled) >> ahcich6: not probed (disabled) >> ahcich7: not probed (disabled) >> simplebus0: mem 0xe0d00000-0xe0deffff irq 10 disabled = compat snps,dwc-ahci (no driver attached) >> simplebus0: mem 0xe1000000-0xe1000fff irq 11 compat = snps,designware-i2c (no driver attached) >> simplebus0: mem 0xe0050000-0xe0050fff irq 12 compat = snps,designware-i2c (no driver attached) >> uart0: mem 0xe1010000-0xe1010fff irq 13 on = simplebus0 >> uart0: console (115200,n,8,1) >> uart0: fast interrupt >> uart0: PPS capture mode: DCD >> simplebus0: mem 0xe1020000-0xe1020fff irq 14 compat = arm,pl022 (no driver attached) >> simplebus0: mem 0xe1030000-0xe1030fff irq 15 compat = arm,pl022 (no driver attached) >> simplebus0: mem 0xe1050000-0xe1050fff irq 16 compat = arm,pl061 (no driver attached) >> simplebus0: mem 0xe0020000-0xe0020fff irq 17 compat = arm,pl061 (no driver attached) >> simplebus0: mem 0xe0030000-0xe0030fff irq 18 compat = arm,pl061 (no driver attached) >> simplebus0: mem 0xe0080000-0xe0080fff irq 19 compat = arm,pl061 (no driver attached) >> simplebus0: mem 0xe0100000-0xe010ffff irq 20 compat = amd,ccp-seattle-v1a (no driver attached) >> simplebus0: mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) >> simplebus0: mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) >> simplebus0: mem = 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0bcffff irq 22 compat arm,sbsa-gwdt = (no driver attached) >> simplebus0: mem 0xe0010000-0xe0010007 irq 23 type ipmi = compat ipmi-kcs (no driver attached) >> simplebus0: mem = 0xe1240800-0xe1240bff,0xe1250000-0xe125005f,0xe12500f8-0xe12500fb irq 24 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >> simplebus0: mem = 0xe1240c00-0xe1240fff,0xe1250080-0xe12500df,0xe12500fc-0xe12500ff irq 25 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >> simplebus0: mem = 0xe0700000-0xe077ffff,0xe0780000-0xe07fffff irq 26,27,28,29,30 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >> simplebus0: mem = 0xe0900000-0xe097ffff,0xe0980000-0xe09fffff irq 31,32,33,34,35 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >> cryptosoft0: >> crypto: assign cryptosoft0 driver id 0, flags 0x6000000 >> Device configuration finished. >> Found SMCCC version 1.0 >> procfs registered >> Timecounters tick every 1.000 msec >> lo0: bpf attached >> vlan: initialized, using hash tables with chaining >> IPsec: Initialized Security Association Processing. >> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 >> Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 >> usb_needs_explore_all: no devclass >> Release APs...ahcich0: AHCI reset... >> Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... >> done >> Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 = 0 >>=20 >> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >> ahcich0: SATA connect timeout time=3D10000us status=3D00000000 >> Instruction Set Attributes 0 =3D >> ahcich0: AHCI reset: device not found >> Instruction Set Attributes 1 =3D <> >> ahcich1: AHCI reset... >> Processor Features 0 =3D >> ahcich1: SATA connect time=3D100us status=3D00000133 >> Processor Features 1 =3D <> >> ahcich1: AHCI reset: device found >> Memory Model Features 0 =3D >> ahcich1: AHCI reset: device ready after 0ms >> Memory Model Features 1 =3D <8bit VMID> >> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> >> Debug Features 1 =3D <> >> Auxiliary Features 0 =3D <> >> Auxiliary Features 1 =3D <> >> CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 >> CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 >> CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 >> regulator: shutting down unused regulators >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> GEOM: new disk ada0 >> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 >> ada0: ACS-4 ATA SATA 3.x device >> ada0: Serial Number # >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >> ada0: Command Queueing enabled >> ada0: 976762MB (2000409264 512 byte sectors) >> pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 >> pass0: ACS-4 ATA SATA 3.x device >> pass0: Serial Number # >> pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >> pass0: Command Queueing enabled >> efirtc0: providing initial system time >> start_init: trying /sbin/init >> Setting hostuuid: #. >> Setting hostid: #. >> Starting file system checks: >> /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, 23658372 = blocks, 0.1% fragmentation) >> Mounting local filesystems:. >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 = /usr/local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 = /usr/local/llvm10/lib /usr/local/llvm80/lib >> Setting hostname: FBSDCA57. >> Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED >> Feeding entropy: . >> lo0: link state changed to UP >> Starting Network: lo0. >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D680003= >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> groups: lo >> nd6 options=3D21 >> Starting devd. >> add host 127.0.0.1: gateway lo0 fib 0: route already in table >> add host ::1: gateway lo0 fib 0: route already in table >> add net fe80::: gateway ::1 >> add net ff02::: gateway ::1 >> add net ::ffff:0.0.0.0: gateway ::1 >> add net ::0.0.0.0: gateway ::1 >=20 > I used artificat.ci.freebsd.org to do an approximate > bisect and the results are: >=20 > head -r362952 and before work. > there was no -r362953 artifact > head -r362954 and later fail. >=20 >=20 > The potential failure checkins are -r362953 and > -r362954 : >=20 > Author: hselasky > Date: Mon Jul 6 08:50:11 2020 > New Revision: 362953 > URL:=20 > https://svnweb.freebsd.org/changeset/base/362953 >=20 >=20 > Log: > Infiniband clients must be attached and detached in a specific order = in ibcore. > . . . > Differential Revision: https://reviews.freebsd.org/D23973 > . . . >=20 > and: >=20 > Author: andrew > Date: Mon Jul 6 08:51:55 2020 > New Revision: 362954 > URL:=20 > https://svnweb.freebsd.org/changeset/base/362954 >=20 >=20 > Log: > Add a driver for bcm2838 PCI express controller > . . . > Submitted by: Robert Crowston > Differential Revision: https://reviews.freebsd.org/D25068 > . . . diff'ing the boot -v material for a good boot vs. a failing one shows that . . . Only the failure example has: +module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel +Module simplebus/pcib failed to register: 17 Only the good example later has: -pcib0: mem 0xf0000000-0xffffffff on = simplebus0 -pcib0: parsing FDT for ECAM0: -pcib0: PCI addr: 0x0, CPU addr: 0xefff0000, Size: 0x10000 -pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x80000000 -pcib0: PCI addr: 0x100000000, CPU addr: 0x100000000, Size: = 0x7f00000000 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 -pcib0: Bus is cache-coherent -pci0: on pcib0 -pci0: domain=3D0, physical bus=3D0 -found-> vendor=3D0x1022, dev=3D0x1a00, revid=3D0x00 - domain=3D0, bus=3D0, slot=3D0, func=3D0 - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 - cmdreg=3D0x0004, statreg=3D0x0000, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) -found-> vendor=3D0x1022, dev=3D0x1a01, revid=3D0x00 - domain=3D0, bus=3D0, slot=3D2, func=3D0 - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 - cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 - domain=3D0, bus=3D0, slot=3D2, func=3D2 - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) - intpin=3Da, irq=3D255 - powerspec 3 supports D0 D3 current D0 - MSI supports 1 message, 64 bit - secbus=3D1, subbus=3D1 -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 - domain=3D0, bus=3D0, slot=3D2, func=3D3 - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) - intpin=3Da, irq=3D255 - powerspec 3 supports D0 D3 current D0 - MSI supports 1 message, 64 bit - secbus=3D2, subbus=3D2 -pcib1: at device 2.2 on pci0 -pcib0: rman_reserve_resource: start=3D0x40100000, end=3D0x401fffff, = count=3D0x100000 -pcib1: domain 0 -pcib1: secondary bus 1 -pcib1: subordinate bus 1 -pcib1: memory decode 0x40100000-0x401fffff -pci1: on pcib1 -pcib1: allocated bus range (1-1) for rid 0 of pci1 -pci1: domain=3D0, physical bus=3D1 -found-> vendor=3D0x1b73, dev=3D0x1009, revid=3D0x02 - domain=3D0, bus=3D1, slot=3D0, func=3D0 - class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) - intpin=3Da, irq=3D255 - powerspec 3 supports D0 D1 D3 current D0 - MSI supports 8 messages, 64 bit - MSI-X supports 8 messages in maps 0x18 and 0x20 - map[10]: type Memory, range 64, base 0x40100000, size 16, = memory disabled -pcib1: allocated memory range (0x40100000-0x4010ffff) for rid 10 of = pci0:1:0:0 - map[18]: type Memory, range 64, base 0x40110000, size 12, = enabled -pcib1: allocated memory range (0x40110000-0x40110fff) for rid 18 of = pci0:1:0:0 - map[20]: type Memory, range 64, base 0x40111000, size 12, = enabled -pcib1: allocated memory range (0x40111000-0x40111fff) for rid 20 of = pci0:1:0:0 -xhci0: mem = 0x40100000-0x4010ffff,0x40110000-0x40110fff,0x40111000-0x40111fff at = device 0.0 on pci1 -xhci0: 32 bytes context size, 64-bit DMA -xhci0: attempting to allocate 1 MSI vectors (8 supported) -xhci0: using IRQ 36 for MSI -xhci0: MSI enabled -usbus0 on xhci0 -xhci0: usbpf: Attached -pcib2: at device 2.3 on pci0 -pcib0: rman_reserve_resource: start=3D0x1000, end=3D0x1fff, = count=3D0x1000 -pcib0: rman_reserve_resource: start=3D0x40000000, end=3D0x400fffff, = count=3D0x100000 -pcib2: domain 0 -pcib2: secondary bus 2 -pcib2: subordinate bus 2 -pcib2: I/O decode 0x1000-0x1fff -pcib2: memory decode 0x40000000-0x400fffff -pci2: on pcib2 -pcib2: allocated bus range (2-2) for rid 0 of pci2 -pci2: domain=3D0, physical bus=3D2 -found-> vendor=3D0x11ab, dev=3D0x4381, revid=3D0x00 - domain=3D0, bus=3D2, slot=3D0, func=3D0 - class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) - intpin=3Da, irq=3D255 - powerspec 3 supports D0 D1 D2 D3 current D0 - MSI supports 1 message, 64 bit - map[10]: type Memory, range 64, base 0x40000000, size 14, = memory disabled -pcib2: allocated memory range (0x40000000-0x40003fff) for rid 10 of = pci0:2:0:0 - map[18]: type I/O Port, range 32, base 0x1000, size 8, port = disabled -pcib2: allocated I/O port range (0x1000-0x10ff) for rid 18 of = pci0:2:0:0 -mskc0: port 0x1000-0x10ff mem = 0x40000000-0x40003fff at device 0.0 on pci2 -mskc0: MSI count : 1 -mskc0: attempting to allocate 1 MSI vectors (1 supported) -mskc0: using IRQ 37 for MSI -mskc0: RAM buffer size : 0KB -msk0: on = mskc0 -msk0: Using defaults for TSO: 65518/35/2048 -msk0: bpf attached -msk0: Ethernet address: e0:ff:f7:00:20:ed -miibus0: on msk0 -e1000phy0: PHY 0 on miibus0 -e1000phy0: OUI 0x000ac2, model 0x0027, rev. 0 -e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, = auto-flow The failure example instead had: +simplebus0: mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) Later there was: -usbus0: 5.0Gbps Super Speed USB v3.0 Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 +usb_needs_explore_all: no devclass I'll stop with that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 09:44:22 2020 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 4641735D16F; Sat, 11 Jul 2020 09:44:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3lP12pL7z3SK7; Sat, 11 Jul 2020 09:44:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E0732260432; Sat, 11 Jul 2020 11:44:18 +0200 (CEST) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) To: Mark Millard , Andrew Turner , Robert Crowston , freebsd-arm , FreeBSD Current References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> From: Hans Petter Selasky Message-ID: <4c4a4a57-167a-167a-2708-532916b253a4@selasky.org> Date: Sat, 11 Jul 2020 11:43:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B3lP12pL7z3SK7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-1.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.97)[-0.967]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-0.62)[-0.617]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.01)[-0.010]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 09:44:22 -0000 On 2020-07-11 10:32, Mark Millard via freebsd-arm wrote: > Author: hselasky > Date: Mon Jul 6 08:50:11 2020 > New Revision: 362953 This revision is likely not involved. --HPS From owner-freebsd-arm@freebsd.org Sat Jul 11 10:48:47 2020 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 CFF6235EB06 for ; Sat, 11 Jul 2020 10:48:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3mqL2hllz3W1R for ; Sat, 11 Jul 2020 10:48:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VgaoOmYVM1lPKo16vc1z8qBgS1hkgauEeyImEkKHppKh1duqsMgzF9HfzHlaQGv uRs4RJoNewUw4OPjG3EZJf2j7n.OoFXKL9LiW3ahqt8GCIA89qnQoYhLNwNm2Fz8zccrBz4As8c7 F_m0GkNclmL7SIJ6NZqqrUOwtWQWRFRjnn45EyfyKn5ESS627qlBPjl0PEWLX3e0bcycV1I1HQXm o4VU0lVqr12fDaBLgUI7MpTHJ72fYehc3UE6slbyyNilh8jadVpSjzhpvDTtsPzhj2GmPSPvtoUt T6ZX0V97BQu6MqW6tieXmEBlCC8oTpCboTY96ilGX7uB8UC9o3iKgOAt.QGObND1Koa9lMIx4aBQ JhHcf472l4uL.oUN7qHqcZH.Bn6infiJTbnIDPs_kDcr5FkNZnNh77jOXpnHJJ2c7M_BoE4DQO.x VmF4mUzeOQUfj0SaFf199V1Y6JCi8FQZR0XRfM_TKOhuOVJlrbnXiQIgXSZzuDMcgxQhR6B0qn_8 MGTjewY4z9PVg_5GsoORGjcHKA2Dz29Q5AWCqYlpD9N_xVinomqmd4wcCovKsm.ZLn1Z4OMsvRiu EQVjijD8Ty3izrZTxBnzjaPsWG0Dwkj58AQ5C0Yofy9T_FSf4jSi.yzwqrYaEX3EPLt9RqNUZtV4 G_NIS21VYuAOfmrq3MbEeDaYf1cECjA1OZseuaIPpRQedmzZcFS0vud_vg0v6m8eqzQdLiRJij75 7QdEMaccep3PGCVY3k1gysRCXkExxd1s0pFbgcCsAEZkAzB8vz7lNDmtVrEqswzkFwC8tOqBhgDS nDXd425zmbbNguFs98bGHLnKQUDYJeLRSAL1ofpntVapIL2d0O0kPVJFhn5qnHBsrmb7DVsZ1q97 bDkUuq3knNhH5rSFjBFMGuxZO1VdkOFUk.T0jPyhdv3y1fdkb6FXppEWbFg3wPNcH2AKkLNiAdh. 5upJ9djVUd1qvCvQKIUnQNWrK9YPE7J0433Yaiy98r91_sb.naFma9LB4v7mxDguavE5FPp1FdL8 A18K4MwFENVEu1Be5hslCo.dQCOcsb2xBl2Thqcb_JhWd.1qeT.UkTpqZlw3mf6LbyI9O2ptSlhX ec_MbLK5qYm3xpY9hQwZaGYBkOdpa948NzFe1Ak.lA0OLilubpO.C8aB76Y3vwflFq1c1v6ziwIn Jssg8Rc6ndfh9xmBSE.FCFdC7r_IwkCxgpA39C0XGIQOBRCpRlKV.IjEF2e2i0hPGcnPmKyQ36vc aprz8WLdfM2k5bfP5c_66emBOupBWlSetbifluK9txF1AFce2bsaGtm2qqKbQ7oOzUCnD0gL6syr HbmWWL.SuSh_tulrmchjof_Srarqi5fbbtC5Gr0nf1.znd0fN2vAiyGTWZaEpO1SLCU6Jj_czTTw Ccc5h0k0l6Xi8iR_8X1l3vncRLsdJtRJOZ2SCd8u5IeLezgU0bSM_wNYEAIYx Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 10:48:44 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 359f25ef8ef8ce59ae07c2bf666461bc; Sat, 11 Jul 2020 10:48:43 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) Date: Sat, 11 Jul 2020 03:48:41 -0700 References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> To: Andrew Turner , Robert Crowston , freebsd-arm , FreeBSD Current In-Reply-To: <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> Message-Id: <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B3mqL2hllz3W1R X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.46 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.92)[-0.924]; FREEMAIL_TO(0.00)[freebsd.org,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 10:48:47 -0000 On 2020-Jul-11, at 02:26, Mark Millard wrote: > On 2020-Jul-11, at 01:32, Mark Millard wrote: >=20 >> On 2020-Jul-11, at 00:14, Mark Millard wrote: >>=20 >>> Anyone else with such Overdrive 1000 problems after >>> upgrading into this range or beyond? >>>=20 >>> boot -v output: >>>=20 >>> ---<>--- >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Type Physical Virtual #Pages Attr >>> Reserved 008000000000 0 00000e80 WC WT WB=20 >>> ConventionalMemory 008000e80000 0 0001ef7d WC WT WB=20 >>> BootServicesData 00801fdfd000 0 00000203 WC WT WB=20 >>> ConventionalMemory 008020000000 0 001d0583 WC WT WB=20 >>> LoaderData 0081f0583000 0 00008000 WC WT WB=20 >>> LoaderCode 0081f8583000 0 0000017d WC WT WB=20 >>> ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB=20 >>> ConventionalMemory 0081f87a0000 0 0000000b WC WT WB=20 >>> LoaderData 0081f87ab000 0 00000001 WC WT WB=20 >>> ConventionalMemory 0081f87ac000 0 000020ab WC WT WB=20 >>> BootServicesData 0081fa857000 0 00000029 WC WT WB=20 >>> ConventionalMemory 0081fa880000 0 0000000b WC WT WB=20 >>> BootServicesData 0081fa88b000 0 0000001f WC WT WB=20 >>> ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB=20 >>> BootServicesData 0081fa8ad000 0 000002f0 WC WT WB=20 >>> ConventionalMemory 0081fab9d000 0 00000001 WC WT WB=20 >>> BootServicesData 0081fab9e000 0 00000012 WC WT WB=20 >>> ConventionalMemory 0081fabb0000 0 00000001 WC WT WB=20 >>> BootServicesData 0081fabb1000 0 00000006 WC WT WB=20 >>> ConventionalMemory 0081fabb7000 0 00000002 WC WT WB=20 >>> BootServicesData 0081fabb9000 0 00000ae7 WC WT WB=20 >>> ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB=20 >>> BootServicesCode 0081fb6e6000 0 0000014a WC WT WB=20 >>> RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB = RUNTIME >>> ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB=20 >>> RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB = RUNTIME >>> ConventionalMemory 0081fc000000 0 0000001f WC WT WB=20 >>> BootServicesData 0081fc01f000 0 00000001 WC WT WB=20 >>> ConventionalMemory 0081fc020000 0 00003732 WC WT WB=20 >>> BootServicesData 0081ff752000 0 0000087a WC WT WB=20 >>> ConventionalMemory 0081fffcc000 0 00000004 WC WT WB=20 >>> RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB = RUNTIME >>> ConventionalMemory 0081ffff0000 0 0000000c WC WT WB=20 >>> BootServicesData 0081ffffc000 0 00000004 WC WT WB=20 >>> Physical memory chunk(s): >>> 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) >>> 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) >>> 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) >>> Excluded memory regions: >>> 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc=20 >>> 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc=20 >>> 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc=20 >>> 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc=20 >>> 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc=20 >>> 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc=20 >>> Found 4 CPUs in the device tree >>> Copyright (c) 1992-2020 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 >>> = markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 >>> FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) >>> VT: init without driver. >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. >>> Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. >>> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff00000116f360. >>> module firmware already present! >>> module_register: cannot register simplebus/gpio from kernel; already = loaded from kernel >>> Module simplebus/gpio failed to register: 17 >>> module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel >>> Module simplebus/pcib failed to register: 17 >>> Starting CPU 1 (101) >>> Starting CPU 2 (200) >>> Starting CPU 3 (201) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> random: read 4096 bytes from preloaded cache >>> random: unblocking device. >>> VIMAGE (virtualized network stack) enabled >>> hostuuid: using # >>> ULE: setup cpu 0 >>> ULE: setup cpu 1 >>> ULE: setup cpu 2 >>> ULE: setup cpu 3 >>> Table 'FACP' at 0x81f8770000 >>> Table 'APIC' at 0x81f8750000 >>> Table 'GTDT' at 0x81f8740000 >>> Table 'DBG2' at 0x81f8730000 >>> Table 'SPCR' at 0x81f8720000 >>> Table 'MCFG' at 0x81f8710000 >>> Table 'CSRT' at 0x81f8700000 >>> ACPI: No IORT table found >>> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] = c=3D0x000003ff [1024] >>> feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 >>> random: entropy device external interface >>> MAP 81fb830000 mode 2 pages 992 >>> MAP 81fbdb0000 mode 2 pages 592 >>> MAP 81fffd0000 mode 2 pages 32 >>> WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. >>> kbd0 at kbdmux0 >>> crypto: >>> mem: >>> null: >>> openfirm: >>> WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. >>> ofwbus0: >>> simplebus0: on ofwbus0 >>> clk_fixed0: on simplebus0 >>> clk_fixed1: on simplebus0 >>> clk_fixed2: on simplebus0 >>> clk_fixed3: on simplebus0 >>> clk_fixed4: on simplebus0 >>> clk_fixed5: on simplebus0 >>> clk_fixed6: on simplebus0 >>> clk_fixed7: on simplebus0 >>> clk_fixed8: on simplebus0 >>> clk_fixed9: on simplebus0 >>> clk_fixed10: on simplebus0 >>> psci0: on ofwbus0 >>> psci0: PSCI version 0.2 compatible >>> gic0: mem = 0xe1110000-0xe1110fff,0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe11600= 00-0xe116ffff irq 4 on ofwbus0 >>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 >>> gicv2m0: mem = 0x80000-0x80fff on gic0 >>> gicv2m0: using spi 64 to 319 >>> generic_timer0: irq 5,6,7,8 on ofwbus0 >>> Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz quality = 1000 >>> Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality = 1000 >>> efirtc0: >>> efirtc0: registered as a time-of-day clock, resolution 1.000000s >>> cpulist0: on ofwbus0 >>> cpu0: on cpulist0 >>> cpu0: missing 'clock-frequency' property >>> cpu1: on cpulist0 >>> cpu1: missing 'clock-frequency' property >>> cpu2: on cpulist0 >>> cpu2: missing 'clock-frequency' property >>> cpu3: on cpulist0 >>> cpu3: missing 'clock-frequency' property >>> pmu0: irq 0,1,2,3 on ofwbus0 >>> ahci0: mem 0xe0300000-0xe03effff irq 9 on = simplebus0 >>> ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported >>> ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC 8ports >>> ahci0: Caps2: APST >>> ahcich0: at channel 0 on ahci0 >>> ahcich0: Caps: HPCP >>> ahcich1: at channel 1 on ahci0 >>> ahcich1: Caps: HPCP >>> ahcich2: not probed (disabled) >>> ahcich3: not probed (disabled) >>> ahcich4: not probed (disabled) >>> ahcich5: not probed (disabled) >>> ahcich6: not probed (disabled) >>> ahcich7: not probed (disabled) >>> simplebus0: mem 0xe0d00000-0xe0deffff irq 10 = disabled compat snps,dwc-ahci (no driver attached) >>> simplebus0: mem 0xe1000000-0xe1000fff irq 11 compat = snps,designware-i2c (no driver attached) >>> simplebus0: mem 0xe0050000-0xe0050fff irq 12 compat = snps,designware-i2c (no driver attached) >>> uart0: mem 0xe1010000-0xe1010fff irq 13 on = simplebus0 >>> uart0: console (115200,n,8,1) >>> uart0: fast interrupt >>> uart0: PPS capture mode: DCD >>> simplebus0: mem 0xe1020000-0xe1020fff irq 14 compat = arm,pl022 (no driver attached) >>> simplebus0: mem 0xe1030000-0xe1030fff irq 15 compat = arm,pl022 (no driver attached) >>> simplebus0: mem 0xe1050000-0xe1050fff irq 16 compat = arm,pl061 (no driver attached) >>> simplebus0: mem 0xe0020000-0xe0020fff irq 17 compat = arm,pl061 (no driver attached) >>> simplebus0: mem 0xe0030000-0xe0030fff irq 18 compat = arm,pl061 (no driver attached) >>> simplebus0: mem 0xe0080000-0xe0080fff irq 19 compat = arm,pl061 (no driver attached) >>> simplebus0: mem 0xe0100000-0xe010ffff irq 20 compat = amd,ccp-seattle-v1a (no driver attached) >>> simplebus0: mem 0xf0000000-0xffffffff type pci = compat pci-host-ecam-generic (no driver attached) >>> simplebus0: mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) >>> simplebus0: mem = 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0bcffff irq 22 compat arm,sbsa-gwdt = (no driver attached) >>> simplebus0: mem 0xe0010000-0xe0010007 irq 23 type = ipmi compat ipmi-kcs (no driver attached) >>> simplebus0: mem = 0xe1240800-0xe1240bff,0xe1250000-0xe125005f,0xe12500f8-0xe12500fb irq 24 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >>> simplebus0: mem = 0xe1240c00-0xe1240fff,0xe1250080-0xe12500df,0xe12500fc-0xe12500ff irq 25 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >>> simplebus0: mem = 0xe0700000-0xe077ffff,0xe0780000-0xe07fffff irq 26,27,28,29,30 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >>> simplebus0: mem = 0xe0900000-0xe097ffff,0xe0980000-0xe09fffff irq 31,32,33,34,35 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >>> cryptosoft0: >>> crypto: assign cryptosoft0 driver id 0, flags 0x6000000 >>> Device configuration finished. >>> Found SMCCC version 1.0 >>> procfs registered >>> Timecounters tick every 1.000 msec >>> lo0: bpf attached >>> vlan: initialized, using hash tables with chaining >>> IPsec: Initialized Security Association Processing. >>> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 >>> Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 >>> usb_needs_explore_all: no devclass >>> Release APs...ahcich0: AHCI reset... >>> Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... >>> done >>> Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 = 0 >>>=20 >>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>> ahcich0: SATA connect timeout time=3D10000us status=3D00000000 >>> Instruction Set Attributes 0 =3D >>> ahcich0: AHCI reset: device not found >>> Instruction Set Attributes 1 =3D <> >>> ahcich1: AHCI reset... >>> Processor Features 0 =3D >>> ahcich1: SATA connect time=3D100us status=3D00000133 >>> Processor Features 1 =3D <> >>> ahcich1: AHCI reset: device found >>> Memory Model Features 0 =3D >>> ahcich1: AHCI reset: device ready after 0ms >>> Memory Model Features 1 =3D <8bit VMID> >>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> >>> Debug Features 1 =3D <> >>> Auxiliary Features 0 =3D <> >>> Auxiliary Features 1 =3D <> >>> CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 >>> CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 >>> CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 >>> regulator: shutting down unused regulators >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> GEOM: new disk ada0 >>> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 >>> ada0: ACS-4 ATA SATA 3.x device >>> ada0: Serial Number # >>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>> ada0: Command Queueing enabled >>> ada0: 976762MB (2000409264 512 byte sectors) >>> pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 >>> pass0: ACS-4 ATA SATA 3.x device >>> pass0: Serial Number # >>> pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>> pass0: Command Queueing enabled >>> efirtc0: providing initial system time >>> start_init: trying /sbin/init >>> Setting hostuuid: #. >>> Setting hostid: #. >>> Starting file system checks: >>> /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS >>> /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, 23658372 = blocks, 0.1% fragmentation) >>> Mounting local filesystems:. >>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 = /usr/local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 = /usr/local/llvm10/lib /usr/local/llvm80/lib >>> Setting hostname: FBSDCA57. >>> Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED >>> Feeding entropy: . >>> lo0: link state changed to UP >>> Starting Network: lo0. >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D680003= >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >>> inet 127.0.0.1 netmask 0xff000000 >>> groups: lo >>> nd6 options=3D21 >>> Starting devd. >>> add host 127.0.0.1: gateway lo0 fib 0: route already in table >>> add host ::1: gateway lo0 fib 0: route already in table >>> add net fe80::: gateway ::1 >>> add net ff02::: gateway ::1 >>> add net ::ffff:0.0.0.0: gateway ::1 >>> add net ::0.0.0.0: gateway ::1 >>=20 >> I used artificat.ci.freebsd.org to do an approximate >> bisect and the results are: >>=20 >> head -r362952 and before work. >> there was no -r362953 artifact >> head -r362954 and later fail. >>=20 >>=20 >> The potential failure checkins are -r362953 and >> -r362954 : >>=20 >> Author: hselasky >> Date: Mon Jul 6 08:50:11 2020 >> New Revision: 362953 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/362953 >>=20 >>=20 >> Log: >> Infiniband clients must be attached and detached in a specific order = in ibcore. >> . . . >> Differential Revision: https://reviews.freebsd.org/D23973 >> . . . >>=20 >> and: >>=20 >> Author: andrew >> Date: Mon Jul 6 08:51:55 2020 >> New Revision: 362954 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/362954 >>=20 >>=20 >> Log: >> Add a driver for bcm2838 PCI express controller >> . . . >> Submitted by: Robert Crowston >> Differential Revision: https://reviews.freebsd.org/D25068 >> . . . >=20 >=20 >=20 > diff'ing the boot -v material for a good boot > vs. a failing one shows that . . . >=20 > Only the failure example has: >=20 > +module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel > +Module simplebus/pcib failed to register: 17 >=20 > Only the good example later has: >=20 > -pcib0: mem 0xf0000000-0xffffffff on = simplebus0 > -pcib0: parsing FDT for ECAM0: > -pcib0: PCI addr: 0x0, CPU addr: 0xefff0000, Size: 0x10000 > -pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x80000000 > -pcib0: PCI addr: 0x100000000, CPU addr: 0x100000000, Size: = 0x7f00000000 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > -pcib0: Bus is cache-coherent > -pci0: on pcib0 > -pci0: domain=3D0, physical bus=3D0 > -found-> vendor=3D0x1022, dev=3D0x1a00, revid=3D0x00 > - domain=3D0, bus=3D0, slot=3D0, func=3D0 > - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > - cmdreg=3D0x0004, statreg=3D0x0000, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > -found-> vendor=3D0x1022, dev=3D0x1a01, revid=3D0x00 > - domain=3D0, bus=3D0, slot=3D2, func=3D0 > - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > - cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 > - domain=3D0, bus=3D0, slot=3D2, func=3D2 > - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > - intpin=3Da, irq=3D255 > - powerspec 3 supports D0 D3 current D0 > - MSI supports 1 message, 64 bit > - secbus=3D1, subbus=3D1 > -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 > - domain=3D0, bus=3D0, slot=3D2, func=3D3 > - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > - intpin=3Da, irq=3D255 > - powerspec 3 supports D0 D3 current D0 > - MSI supports 1 message, 64 bit > - secbus=3D2, subbus=3D2 > -pcib1: at device 2.2 on pci0 > -pcib0: rman_reserve_resource: start=3D0x40100000, end=3D0x401fffff, = count=3D0x100000 > -pcib1: domain 0 > -pcib1: secondary bus 1 > -pcib1: subordinate bus 1 > -pcib1: memory decode 0x40100000-0x401fffff > -pci1: on pcib1 > -pcib1: allocated bus range (1-1) for rid 0 of pci1 > -pci1: domain=3D0, physical bus=3D1 > -found-> vendor=3D0x1b73, dev=3D0x1009, revid=3D0x02 > - domain=3D0, bus=3D1, slot=3D0, func=3D0 > - class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 > - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > - intpin=3Da, irq=3D255 > - powerspec 3 supports D0 D1 D3 current D0 > - MSI supports 8 messages, 64 bit > - MSI-X supports 8 messages in maps 0x18 and 0x20 > - map[10]: type Memory, range 64, base 0x40100000, size 16, = memory disabled > -pcib1: allocated memory range (0x40100000-0x4010ffff) for rid 10 of = pci0:1:0:0 > - map[18]: type Memory, range 64, base 0x40110000, size 12, = enabled > -pcib1: allocated memory range (0x40110000-0x40110fff) for rid 18 of = pci0:1:0:0 > - map[20]: type Memory, range 64, base 0x40111000, size 12, = enabled > -pcib1: allocated memory range (0x40111000-0x40111fff) for rid 20 of = pci0:1:0:0 > -xhci0: mem = 0x40100000-0x4010ffff,0x40110000-0x40110fff,0x40111000-0x40111fff at = device 0.0 on pci1 > -xhci0: 32 bytes context size, 64-bit DMA > -xhci0: attempting to allocate 1 MSI vectors (8 supported) > -xhci0: using IRQ 36 for MSI > -xhci0: MSI enabled > -usbus0 on xhci0 > -xhci0: usbpf: Attached > -pcib2: at device 2.3 on pci0 > -pcib0: rman_reserve_resource: start=3D0x1000, end=3D0x1fff, = count=3D0x1000 > -pcib0: rman_reserve_resource: start=3D0x40000000, end=3D0x400fffff, = count=3D0x100000 > -pcib2: domain 0 > -pcib2: secondary bus 2 > -pcib2: subordinate bus 2 > -pcib2: I/O decode 0x1000-0x1fff > -pcib2: memory decode 0x40000000-0x400fffff > -pci2: on pcib2 > -pcib2: allocated bus range (2-2) for rid 0 of pci2 > -pci2: domain=3D0, physical bus=3D2 > -found-> vendor=3D0x11ab, dev=3D0x4381, revid=3D0x00 > - domain=3D0, bus=3D2, slot=3D0, func=3D0 > - class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > - intpin=3Da, irq=3D255 > - powerspec 3 supports D0 D1 D2 D3 current D0 > - MSI supports 1 message, 64 bit > - map[10]: type Memory, range 64, base 0x40000000, size 14, = memory disabled > -pcib2: allocated memory range (0x40000000-0x40003fff) for rid 10 of = pci0:2:0:0 > - map[18]: type I/O Port, range 32, base 0x1000, size 8, port = disabled > -pcib2: allocated I/O port range (0x1000-0x10ff) for rid 18 of = pci0:2:0:0 > -mskc0: port 0x1000-0x10ff = mem 0x40000000-0x40003fff at device 0.0 on pci2 > -mskc0: MSI count : 1 > -mskc0: attempting to allocate 1 MSI vectors (1 supported) > -mskc0: using IRQ 37 for MSI > -mskc0: RAM buffer size : 0KB > -msk0: = on mskc0 > -msk0: Using defaults for TSO: 65518/35/2048 > -msk0: bpf attached > -msk0: Ethernet address: e0:ff:f7:00:20:ed > -miibus0: on msk0 > -e1000phy0: PHY 0 on miibus0 > -e1000phy0: OUI 0x000ac2, model 0x0027, rev. 0 > -e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, = auto-flow >=20 > The failure example instead had: >=20 > +simplebus0: mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) >=20 > Later there was: >=20 > -usbus0: 5.0Gbps Super Speed USB v3.0 > Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 > +usb_needs_explore_all: no devclass >=20 >=20 > I'll stop with that. >=20 Using nm (and cut and grep) to extract names from a good and bad kernel I find the following, where the "+" lines are from a bad kernel: # diff -u mmjnk.goodnames mmjnk.baddupnames --- mmjnk.goodnames 2020-07-11 03:31:55.360299000 -0700 +++ mmjnk.baddupnames 2020-07-11 03:31:28.483440000 -0700 @@ -1,26 +1,35 @@ __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus = __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus_on_kernel= __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus = __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus_on_kerne= l __set_sysinit_set_sym_alpine_pcib_simplebusmodule_sys_init __set_sysinit_set_sym_pcib_simplebusmodule_sys_init +__set_sysinit_set_sym_pcib_simplebusmodule_sys_init __set_sysinit_set_sym_thunder_pcib_simplebusmodule_sys_init _alpine_pcib_simplebus_depend_on_kernel _mod_metadata_md_alpine_pcib_simplebus _mod_metadata_md_alpine_pcib_simplebus_on_kernel _mod_metadata_md_pcib_simplebus +_mod_metadata_md_pcib_simplebus _mod_metadata_md_pcib_simplebus_on_kernel +_mod_metadata_md_pcib_simplebus_on_kernel _mod_metadata_md_thunder_pcib_simplebus _mod_metadata_md_thunder_pcib_simplebus_on_kernel _pcib_simplebus_depend_on_kernel +_pcib_simplebus_depend_on_kernel _thunder_pcib_simplebus_depend_on_kernel alpine_pcib_simplebus_driver_mod alpine_pcib_simplebus_mod alpine_pcib_simplebusmodule_sys_init pcib_simplebus_driver_mod +pcib_simplebus_driver_mod pcib_simplebus_mod +pcib_simplebus_mod +pcib_simplebusmodule_sys_init pcib_simplebusmodule_sys_init thunder_pcib_simplebus_driver_mod thunder_pcib_simplebus_mod It leaves me wondering if the naming is messing things up via duplicate naming from the likes of: static devclass_t generic_pcie_fdt_devclass; DRIVER_MODULE(pcib, simplebus, generic_pcie_fdt_driver, generic_pcie_fdt_devclass, 0, 0); vs. static devclass_t bcm_pcib_devclass; DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, = 0); (Dual pcib_simplebus based sets of names?) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 21:45:37 2020 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 7435D37241A for ; Sat, 11 Jul 2020 21:45:37 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B43PD0tgCz4fKy; Sat, 11 Jul 2020 21:45:35 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sat, 11 Jul 2020 21:45:28 +0000 To: Mark Millard From: Robert Crowston Cc: Andrew Turner , freebsd-arm , FreeBSD Current Reply-To: Robert Crowston Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) Message-ID: In-Reply-To: <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B43PD0tgCz4fKy X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.18:from]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.10)[-0.103]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.18:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 21:45:37 -0000 So what is the mistake I made here? Should I have given a globally unique name as the first argument to DRIVER_= MODULE()? I didn't see that in the man page, and other examples of pcib dri= vers apparently get away with it. I did notice the weird message about "driver already loaded from kernel". I= wondered if that meant I was dragging in code to the core kernel, that wou= ld otherwise live in an external module? Let me know how I can help fix it! -- RHC. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, 11 July 2020 11:48, Mark Millard wrote: > On 2020-Jul-11, at 02:26, Mark Millard wrote: > > > On 2020-Jul-11, at 01:32, Mark Millard wrote: > > > > > On 2020-Jul-11, at 00:14, Mark Millard wrote: > > > > > > > Anyone else with such Overdrive 1000 problems after > > > > upgrading into this range or beyond? > > > > boot -v output: > > > > ---<>--- > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > Type Physical Virtual #Pages Attr > > > > Reserved 008000000000 0 00000e80 WC WT WB > > > > ConventionalMemory 008000e80000 0 0001ef7d WC WT WB > > > > BootServicesData 00801fdfd000 0 00000203 WC WT WB > > > > ConventionalMemory 008020000000 0 001d0583 WC WT WB > > > > LoaderData 0081f0583000 0 00008000 WC WT WB > > > > LoaderCode 0081f8583000 0 0000017d WC WT WB > > > > ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB > > > > ConventionalMemory 0081f87a0000 0 0000000b WC WT WB > > > > LoaderData 0081f87ab000 0 00000001 WC WT WB > > > > ConventionalMemory 0081f87ac000 0 000020ab WC WT WB > > > > BootServicesData 0081fa857000 0 00000029 WC WT WB > > > > ConventionalMemory 0081fa880000 0 0000000b WC WT WB > > > > BootServicesData 0081fa88b000 0 0000001f WC WT WB > > > > ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB > > > > BootServicesData 0081fa8ad000 0 000002f0 WC WT WB > > > > ConventionalMemory 0081fab9d000 0 00000001 WC WT WB > > > > BootServicesData 0081fab9e000 0 00000012 WC WT WB > > > > ConventionalMemory 0081fabb0000 0 00000001 WC WT WB > > > > BootServicesData 0081fabb1000 0 00000006 WC WT WB > > > > ConventionalMemory 0081fabb7000 0 00000002 WC WT WB > > > > BootServicesData 0081fabb9000 0 00000ae7 WC WT WB > > > > ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB > > > > BootServicesCode 0081fb6e6000 0 0000014a WC WT WB > > > > RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB RUNTI= ME > > > > ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB > > > > RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB RUNTI= ME > > > > ConventionalMemory 0081fc000000 0 0000001f WC WT WB > > > > BootServicesData 0081fc01f000 0 00000001 WC WT WB > > > > ConventionalMemory 0081fc020000 0 00003732 WC WT WB > > > > BootServicesData 0081ff752000 0 0000087a WC WT WB > > > > ConventionalMemory 0081fffcc000 0 00000004 WC WT WB > > > > RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB RUNTI= ME > > > > ConventionalMemory 0081ffff0000 0 0000000c WC WT WB > > > > BootServicesData 0081ffffc000 0 00000004 WC WT WB > > > > Physical memory chunk(s): > > > > 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) > > > > 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) > > > > 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) > > > > Excluded memory regions: > > > > 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc > > > > 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc > > > > 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc > > > > 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc > > > > 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc > > > > 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc > > > > Found 4 CPUs in the device tree > > > > Copyright (c) 1992-2020 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,= 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 > > > > markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm= 64.aarch64/sys/GENERIC-NODBG arm64 > > > > FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) > > > > VT: init without driver. > > > > Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. > > > > Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. > > > > Preloaded boot_entropy_cache "/boot/entropy" at 0xffff00000116f360. > > > > module firmware already present! > > > > module_register: cannot register simplebus/gpio from kernel; alread= y loaded from kernel > > > > Module simplebus/gpio failed to register: 17 > > > > module_register: cannot register simplebus/pcib from kernel; alread= y loaded from kernel > > > > Module simplebus/pcib failed to register: 17 > > > > Starting CPU 1 (101) > > > > Starting CPU 2 (200) > > > > Starting CPU 3 (201) > > > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > > random: read 4096 bytes from preloaded cache > > > > random: unblocking device. > > > > VIMAGE (virtualized network stack) enabled > > > > hostuuid: using # > > > > ULE: setup cpu 0 > > > > ULE: setup cpu 1 > > > > ULE: setup cpu 2 > > > > ULE: setup cpu 3 > > > > Table 'FACP' at 0x81f8770000 > > > > Table 'APIC' at 0x81f8750000 > > > > Table 'GTDT' at 0x81f8740000 > > > > Table 'DBG2' at 0x81f8730000 > > > > Table 'SPCR' at 0x81f8720000 > > > > Table 'MCFG' at 0x81f8710000 > > > > Table 'CSRT' at 0x81f8700000 > > > > ACPI: No IORT table found > > > > snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x0000= 03ff [1024] > > > > feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 f= eeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 > > > > random: entropy device external interface > > > > MAP 81fb830000 mode 2 pages 992 > > > > MAP 81fbdb0000 mode 2 pages 592 > > > > MAP 81fffd0000 mode 2 pages 32 > > > > WARNING: Device "kbd" is Giant locked and may be deleted before Fre= eBSD 13.0. > > > > kbd0 at kbdmux0 > > > > crypto: > > > > mem: > > > > null: > > > > openfirm: > > > > WARNING: Device "openfirm" is Giant locked and may be deleted befor= e FreeBSD 13.0. > > > > ofwbus0: > > > > simplebus0: on ofwbus0 > > > > clk_fixed0: on simplebus0 > > > > clk_fixed1: on simplebus0 > > > > clk_fixed2: on simplebus0 > > > > clk_fixed3: on simplebus0 > > > > clk_fixed4: on simplebus0 > > > > clk_fixed5: on simplebus0 > > > > clk_fixed6: on simplebus0 > > > > clk_fixed7: on simplebus0 > > > > clk_fixed8: on simplebus0 > > > > clk_fixed9: on simplebus0 > > > > clk_fixed10: on simplebus0 > > > > psci0: on ofwbus0 > > > > psci0: PSCI version 0.2 compatible > > > > gic0: mem 0xe1110000-0xe1110fff,= 0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe1160000-0xe116ffff irq 4 on = ofwbus0 > > > > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 > > > > gicv2m0: mem 0x80000-0x= 80fff on gic0 > > > > gicv2m0: using spi 64 to 319 > > > > generic_timer0: irq 5,6,7,8 on ofwbus0 > > > > Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz quality= 1000 > > > > Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality = 1000 > > > > efirtc0: > > > > efirtc0: registered as a time-of-day clock, resolution 1.000000s > > > > cpulist0: on ofwbus0 > > > > cpu0: on cpulist0 > > > > cpu0: missing 'clock-frequency' property > > > > cpu1: on cpulist0 > > > > cpu1: missing 'clock-frequency' property > > > > cpu2: on cpulist0 > > > > cpu2: missing 'clock-frequency' property > > > > cpu3: on cpulist0 > > > > cpu3: missing 'clock-frequency' property > > > > pmu0: irq 0,1,2,3 on ofwbus0 > > > > ahci0: mem 0xe0300000-0xe03effff irq 9 on si= mplebus0 > > > > ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported > > > > ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC 8ports > > > > ahci0: Caps2: APST > > > > ahcich0: at channel 0 on ahci0 > > > > ahcich0: Caps: HPCP > > > > ahcich1: at channel 1 on ahci0 > > > > ahcich1: Caps: HPCP > > > > ahcich2: not probed (disabled) > > > > ahcich3: not probed (disabled) > > > > ahcich4: not probed (disabled) > > > > ahcich5: not probed (disabled) > > > > ahcich6: not probed (disabled) > > > > ahcich7: not probed (disabled) > > > > simplebus0: sata@e0d00000 mem 0xe0d00000-0xe0deffff irq 10 disabled= compat snps,dwc-ahci (no driver attached) > > > > simplebus0: i2c@e1000000 mem 0xe1000000-0xe1000fff irq 11 compat sn= ps,designware-i2c (no driver attached) > > > > simplebus0: i2c@e0050000 mem 0xe0050000-0xe0050fff irq 12 compat sn= ps,designware-i2c (no driver attached) > > > > uart0: mem 0xe1010000-0xe1010fff irq 13 on= simplebus0 > > > > uart0: console (115200,n,8,1) > > > > uart0: fast interrupt > > > > uart0: PPS capture mode: DCD > > > > simplebus0: ssp@e1020000 mem 0xe1020000-0xe1020fff irq 14 compat ar= m,pl022 (no driver attached) > > > > simplebus0: ssp@e1030000 mem 0xe1030000-0xe1030fff irq 15 compat ar= m,pl022 (no driver attached) > > > > simplebus0: gpio@e1050000 mem 0xe1050000-0xe1050fff irq 16 compat a= rm,pl061 (no driver attached) > > > > simplebus0: gpio@e0020000 mem 0xe0020000-0xe0020fff irq 17 compat a= rm,pl061 (no driver attached) > > > > simplebus0: gpio@e0030000 mem 0xe0030000-0xe0030fff irq 18 compat a= rm,pl061 (no driver attached) > > > > simplebus0: gpio@e0080000 mem 0xe0080000-0xe0080fff irq 19 compat a= rm,pl061 (no driver attached) > > > > simplebus0: ccp@e0100000 mem 0xe0100000-0xe010ffff irq 20 compat am= d,ccp-seattle-v1a (no driver attached) > > > > simplebus0: pcie@f0000000 mem 0xf0000000-0xffffffff type pci compat= pci-host-ecam-generic (no driver attached) > > > > simplebus0: ccn@0xe8000000 mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) > > > > simplebus0: gwdt@e0bb0000 mem 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0= bcffff irq 22 compat arm,sbsa-gwdt (no driver attached) > > > > simplebus0: kcs@e0010000 mem 0xe0010000-0xe0010007 irq 23 type ipmi= compat ipmi-kcs (no driver attached) > > > > simplebus0: phy@e1240800 mem 0xe1240800-0xe1240bff,0xe1250000-0xe12= 5005f,0xe12500f8-0xe12500fb irq 24 disabled compat amd,xgbe-phy-seattle-v1a= (no driver attached) > > > > simplebus0: phy@e1240c00 mem 0xe1240c00-0xe1240fff,0xe1250080-0xe12= 500df,0xe12500fc-0xe12500ff irq 25 disabled compat amd,xgbe-phy-seattle-v1a= (no driver attached) > > > > simplebus0: xgmac@e0700000 mem 0xe0700000-0xe077ffff,0xe0780000-0xe= 07fffff irq 26,27,28,29,30 disabled compat amd,xgbe-seattle-v1a (no driver = attached) > > > > simplebus0: xgmac@e0900000 mem 0xe0900000-0xe097ffff,0xe0980000-0xe= 09fffff irq 31,32,33,34,35 disabled compat amd,xgbe-seattle-v1a (no driver = attached) > > > > cryptosoft0: > > > > crypto: assign cryptosoft0 driver id 0, flags 0x6000000 > > > > Device configuration finished. > > > > Found SMCCC version 1.0 > > > > procfs registered > > > > Timecounters tick every 1.000 msec > > > > lo0: bpf attached > > > > vlan: initialized, using hash tables with chaining > > > > IPsec: Initialized Security Association Processing. > > > > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 > > > > Obsolete code will be removed soon: random(9) is the obsolete Park-= Miller LCG from 1988 > > > > usb_needs_explore_all: no devclass > > > > Release APs...ahcich0: AHCI reset... > > > > Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... > > > > done > > > > Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 0 > > > > > > > > Cache Type =3D <64 byte D-cacheline,64 byte I-cache= line,PIPT ICache,64 byte ERG,64 byte CWG> > > > > > > > > > > > > ahcich0: SATA connect timeout time=3D10000us status=3D00000000 > > > > Instruction Set Attributes 0 =3D > > > > ahcich0: AHCI reset: device not found > > > > Instruction Set Attributes 1 =3D <> > > > > ahcich1: AHCI reset... > > > > Processor Features 0 =3D > > > > ahcich1: SATA connect time=3D100us status=3D00000133 > > > > Processor Features 1 =3D <> > > > > ahcich1: AHCI reset: device found > > > > Memory Model Features 0 =3D > > > > ahcich1: AHCI reset: device ready after 0ms > > > > Memory Model Features 1 =3D <8bit VMID> > > > > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > > > > Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3= ,Debugv8> > > > > Debug Features 1 =3D <> > > > > Auxiliary Features 0 =3D <> > > > > Auxiliary Features 1 =3D <> > > > > CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 > > > > CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 > > > > CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 > > > > regulator: shutting down unused regulators > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > Root mount waiting for: CAM > > > > GEOM: new disk ada0 > > > > ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > > ada0: ACS-4 ATA SATA 3.x device > > > > ada0: Serial Number # > > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > > > > ada0: Command Queueing enabled > > > > ada0: 976762MB (2000409264 512 byte sectors) > > > > pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > > pass0: ACS-4 ATA SATA 3.x device > > > > pass0: Serial Number # > > > > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > > > > pass0: Command Queueing enabled > > > > efirtc0: providing initial system time > > > > start_init: trying /sbin/init > > > > Setting hostuuid: #. > > > > Setting hostid: #. > > > > Starting file system checks: > > > > /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS > > > > /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, 2365837= 2 blocks, 0.1% fragmentation) > > > > Mounting local filesystems:. > > > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /us= r/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 /usr/= local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 /usr/local/llvm10/lib /us= r/local/llvm80/lib > > > > Setting hostname: FBSDCA57. > > > > Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_E= THER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > > > > Feeding entropy: . > > > > lo0: link state changed to UP > > > > Starting Network: lo0. > > > > lo0: flags=3D8049 metric 0 mtu 16384 > > > > options=3D680003 > > > > inet6 ::1 prefixlen 128 > > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > > > > inet 127.0.0.1 netmask 0xff000000 > > > > groups: lo > > > > nd6 options=3D21 > > > > Starting devd. > > > > add host 127.0.0.1: gateway lo0 fib 0: route already in table > > > > add host ::1: gateway lo0 fib 0: route already in table > > > > add net fe80::: gateway ::1 > > > > add net ff02::: gateway ::1 > > > > add net ::ffff:0.0.0.0: gateway ::1 > > > > add net ::0.0.0.0: gateway ::1 > > > > > > I used artificat.ci.freebsd.org to do an approximate > > > bisect and the results are: > > > head -r362952 and before work. > > > there was no -r362953 artifact > > > head -r362954 and later fail. > > > The potential failure checkins are -r362953 and > > > -r362954 : > > > Author: hselasky > > > Date: Mon Jul 6 08:50:11 2020 > > > New Revision: 362953 > > > URL: > > > https://svnweb.freebsd.org/changeset/base/362953 > > > Log: > > > Infiniband clients must be attached and detached in a specific order = in ibcore. > > > . . . > > > Differential Revision: https://reviews.freebsd.org/D23973 > > > . . . > > > and: > > > Author: andrew > > > Date: Mon Jul 6 08:51:55 2020 > > > New Revision: 362954 > > > URL: > > > https://svnweb.freebsd.org/changeset/base/362954 > > > Log: > > > Add a driver for bcm2838 PCI express controller > > > . . . > > > Submitted by: Robert Crowston > > > Differential Revision: https://reviews.freebsd.org/D25068 > > > . . . > > > > diff'ing the boot -v material for a good boot > > vs. a failing one shows that . . . > > Only the failure example has: > > +module_register: cannot register simplebus/pcib from kernel; already l= oaded from kernel > > +Module simplebus/pcib failed to register: 17 > > Only the good example later has: > > -pcib0: mem 0xf0000000-0xffffffff on simp= lebus0 > > -pcib0: parsing FDT for ECAM0: > > -pcib0: PCI addr: 0x0, CPU addr: 0xefff0000, Size: 0x10000 > > -pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x80000000 > > -pcib0: PCI addr: 0x100000000, CPU addr: 0x100000000, Size: 0x7f0000000= 0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 > > -pcib0: Bus is cache-coherent > > -pci0: on pcib0 > > -pci0: domain=3D0, physical bus=3D0 > > -found-> vendor=3D0x1022, dev=3D0x1a00, revid=3D0x00 > > > > - domain=3D0, bus=3D0, slot=3D0, func=3D0 > > > > > > - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > > > > > > - cmdreg=3D0x0004, statreg=3D0x0000, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > > > -found-> vendor=3D0x1022, dev=3D0x1a01, revid=3D0x00 > > > > - domain=3D0, bus=3D0, slot=3D2, func=3D0 > > > > > > - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > > > > > > - cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > > > -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 > > > > - domain=3D0, bus=3D0, slot=3D2, func=3D2 > > > > > > - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > > > > > > - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > - intpin=3Da, irq=3D255 > > > > > > - powerspec 3 supports D0 D3 current D0 > > > > > > - MSI supports 1 message, 64 bit > > > > > > - secbus=3D1, subbus=3D1 > > > > > > > > -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 > > > > - domain=3D0, bus=3D0, slot=3D2, func=3D3 > > > > > > - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > > > > > > - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > - intpin=3Da, irq=3D255 > > > > > > - powerspec 3 supports D0 D3 current D0 > > > > > > - MSI supports 1 message, 64 bit > > > > > > - secbus=3D2, subbus=3D2 > > > > > > > > -pcib1: at device 2.2 on pci0 > > -pcib0: rman_reserve_resource: start=3D0x40100000, end=3D0x401fffff, co= unt=3D0x100000 > > -pcib1: domain 0 > > -pcib1: secondary bus 1 > > -pcib1: subordinate bus 1 > > -pcib1: memory decode 0x40100000-0x401fffff > > -pci1: on pcib1 > > -pcib1: allocated bus range (1-1) for rid 0 of pci1 > > -pci1: domain=3D0, physical bus=3D1 > > -found-> vendor=3D0x1b73, dev=3D0x1009, revid=3D0x02 > > > > - domain=3D0, bus=3D1, slot=3D0, func=3D0 > > > > > > - class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 > > > > > > - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > - intpin=3Da, irq=3D255 > > > > > > - powerspec 3 supports D0 D1 D3 current D0 > > > > > > - MSI supports 8 messages, 64 bit > > > > > > - MSI-X supports 8 messages in maps 0x18 and 0x20 > > > > > > - map[10]: type Memory, range 64, base 0x40100000, size 16, me= mory disabled > > > > > > > > -pcib1: allocated memory range (0x40100000-0x4010ffff) for rid 10 of pc= i0:1:0:0 > > > > - map[18]: type Memory, range 64, base 0x40110000, size 12, en= abled > > > > > > > > -pcib1: allocated memory range (0x40110000-0x40110fff) for rid 18 of pc= i0:1:0:0 > > > > - map[20]: type Memory, range 64, base 0x40111000, size 12, en= abled > > > > > > > > -pcib1: allocated memory range (0x40111000-0x40111fff) for rid 20 of pc= i0:1:0:0 > > -xhci0: mem 0x40100000-0x4010ffff,0= x40110000-0x40110fff,0x40111000-0x40111fff at device 0.0 on pci1 > > -xhci0: 32 bytes context size, 64-bit DMA > > -xhci0: attempting to allocate 1 MSI vectors (8 supported) > > -xhci0: using IRQ 36 for MSI > > -xhci0: MSI enabled > > -usbus0 on xhci0 > > -xhci0: usbpf: Attached > > -pcib2: at device 2.3 on pci0 > > -pcib0: rman_reserve_resource: start=3D0x1000, end=3D0x1fff, count=3D0x= 1000 > > -pcib0: rman_reserve_resource: start=3D0x40000000, end=3D0x400fffff, co= unt=3D0x100000 > > -pcib2: domain 0 > > -pcib2: secondary bus 2 > > -pcib2: subordinate bus 2 > > -pcib2: I/O decode 0x1000-0x1fff > > -pcib2: memory decode 0x40000000-0x400fffff > > -pci2: on pcib2 > > -pcib2: allocated bus range (2-2) for rid 0 of pci2 > > -pci2: domain=3D0, physical bus=3D2 > > -found-> vendor=3D0x11ab, dev=3D0x4381, revid=3D0x00 > > > > - domain=3D0, bus=3D2, slot=3D0, func=3D0 > > > > > > - class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > > > > > > - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > > > > > - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) > > > > > > - intpin=3Da, irq=3D255 > > > > > > - powerspec 3 supports D0 D1 D2 D3 current D0 > > > > > > - MSI supports 1 message, 64 bit > > > > > > - map[10]: type Memory, range 64, base 0x40000000, size 14, me= mory disabled > > > > > > > > -pcib2: allocated memory range (0x40000000-0x40003fff) for rid 10 of pc= i0:2:0:0 > > > > - map[18]: type I/O Port, range 32, base 0x1000, size 8, port= disabled > > > > > > > > -pcib2: allocated I/O port range (0x1000-0x10ff) for rid 18 of pci0:2:0= :0 > > -mskc0: port 0x1000-0x10ff mem= 0x40000000-0x40003fff at device 0.0 on pci2 > > -mskc0: MSI count : 1 > > -mskc0: attempting to allocate 1 MSI vectors (1 supported) > > -mskc0: using IRQ 37 for MSI > > -mskc0: RAM buffer size : 0KB > > -msk0: on= mskc0 > > -msk0: Using defaults for TSO: 65518/35/2048 > > -msk0: bpf attached > > -msk0: Ethernet address: e0:ff:f7:00:20:ed > > -miibus0: on msk0 > > -e1000phy0: PHY 0 on miibus0 > > -e1000phy0: OUI 0x000ac2, model 0x0027, rev. 0 > > -e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000b= aseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flo= w > > The failure example instead had: > > +simplebus0: pcie@f0000000 mem 0xf0000000-0xffffffff type pci compat pc= i-host-ecam-generic (no driver attached) > > Later there was: > > -usbus0: 5.0Gbps Super Speed USB v3.0 > > Obsolete code will be removed soon: random(9) is the obsolete Park-Mill= er LCG from 1988 > > +usb_needs_explore_all: no devclass > > I'll stop with that. > > Using nm (and cut and grep) to extract names from a > good and bad kernel I find the following, where the > "+" lines are from a bad kernel: > > diff -u mmjnk.goodnames mmjnk.baddupnames > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- mmjnk.goodnames 2020-07-11 03:31:55.360299000 -0700 > +++ mmjnk.baddupnames 2020-07-11 03:31:28.483440000 -0700 > @@ -1,26 +1,35 @@ > __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus > __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus_on_kerne= l > __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus > +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus > __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel > +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel > __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus > __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus_on_kern= el > __set_sysinit_set_sym_alpine_pcib_simplebusmodule_sys_init > __set_sysinit_set_sym_pcib_simplebusmodule_sys_init > +__set_sysinit_set_sym_pcib_simplebusmodule_sys_init > __set_sysinit_set_sym_thunder_pcib_simplebusmodule_sys_init > _alpine_pcib_simplebus_depend_on_kernel > _mod_metadata_md_alpine_pcib_simplebus > _mod_metadata_md_alpine_pcib_simplebus_on_kernel > _mod_metadata_md_pcib_simplebus > +_mod_metadata_md_pcib_simplebus > _mod_metadata_md_pcib_simplebus_on_kernel > +_mod_metadata_md_pcib_simplebus_on_kernel > _mod_metadata_md_thunder_pcib_simplebus > _mod_metadata_md_thunder_pcib_simplebus_on_kernel > _pcib_simplebus_depend_on_kernel > +_pcib_simplebus_depend_on_kernel > _thunder_pcib_simplebus_depend_on_kernel > alpine_pcib_simplebus_driver_mod > alpine_pcib_simplebus_mod > alpine_pcib_simplebusmodule_sys_init > pcib_simplebus_driver_mod > +pcib_simplebus_driver_mod > pcib_simplebus_mod > +pcib_simplebus_mod > +pcib_simplebusmodule_sys_init > pcib_simplebusmodule_sys_init > thunder_pcib_simplebus_driver_mod > thunder_pcib_simplebus_mod > > It leaves me wondering if the naming is messing things > up via duplicate naming from the likes of: > > static devclass_t generic_pcie_fdt_devclass; > > DRIVER_MODULE(pcib, simplebus, generic_pcie_fdt_driver, > generic_pcie_fdt_devclass, 0, 0); > > vs. > > static devclass_t bcm_pcib_devclass; > DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > > (Dual pcib_simplebus based sets of names?) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 22:13:07 2020 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 E2A1A372C8D for ; Sat, 11 Jul 2020 22:13:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B440y3BR3z3RZH for ; Sat, 11 Jul 2020 22:13:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: TDYvtJYVM1kggQVdMwTlYWQdBLRBGGZXAd2.xTrGmDkHUX3Tkxyd6473E8HKv7j jaejT_7p6jJdgcvTsWW0MdCFDzTOkXA._8r5PRlpWBgdOgMMUs3mXbeYc6Kni9LItzuUoKd304x6 mvrSoVYsJ7n99jUGrCxUW6VNqfApiTmCA5CeRWfQzU68wCKt088rb_0UwLyign3RTJ3kpwbd7bAS 9UIP9Bid_UwRCeoFTt4rvQpTcrSnQM2rflFTJ67h6UasV9sp6LX5jI.AEdOPXIN1O.hzsExVmU8_ _J3gXXpdYeu3XNZopmilmjwVb3UCOV6O3rrI9Vr2CEX_fHKh.ogjSUDgexO6hTY_Y5daTRmRax7K lR_8xBhWMnabqD4Di6Qj9yNKRn..xW2CVpSFlMuiSwdQhQuyEeLoMaXmA1VT9lmwokdERvR1vN0E .8A13ewk7TVfoQpYM0ZpA1d1_6jzXVe23lu0R3uYb3.RrkzZ7EMNTQiQsdhonK5AXY8JAHCYINqS v9enAaKvqDLyPyQrjWr53ZFgmC2y6dFd_GRr8yznD95ZOEFHv6.smkKJ9OyyPIAJJmTtJPCSjMhh sMrkEcEd2SRpLT2ov.UDDFFvHhtumG0F8tqSKx0lok8YXesMJNZY7d7VEpcRWZI8_43gj079eiUp tMxiRslLQMO630ki_hCE7ffTeTyz4E6JHDlwTfCNh6jJboHmM3kk5HN64cxvjNfBxPTYa3eWOaYb zxB9s.nSFrdEieKmvkUVQ2nAQsuWdTHe9e4jPRV2I.uZ1btAiI4bOUixITjm5GhWtisHAIaGOmYJ tmfdskUe0FEzhmlqe_U9iCxT.1TXm3vlX7k10qUnVl0btra6gZMcKXz.xXB13VUW9b3lKpOohW3D BmSHHxBpSVvQmi4uwMkWrkvt.93VcI3BIn_LR7V0eYEVITLcBegittCxH_shBDxXt.2SqKSR2F3c mMGICX5kBEi8HIMB5lr5X31o.5gX77DEzr27iAg8NMhsL0lxUAzSoIEHuuZWMo8ODgIjCCxrR5Iw tfLgdaqpyQg0NISF_icMkxbwEdO113Yr8l0jHYwsiJdv6a_PhGgDOYs46F8sRIpOZPOwMkL8nyIV Q_YHah_KSc8anzpVfQNxFzcRQ72_KHUm0Ab.gqaSdiwVjq9Q1dkuJ6q6AoLIfVfoMHEwLq5PTcWL 6OUaUPGwJB27baffUI2GoGMAeeiP4W1aUBJOzEKgoPSwaISCiVF6lribc0Fhcmq.Xoc8TsS5Lfny 5R6RUilheISSS__K0y5MLxpJx9FCJtVw0u8C5ka_IDF9O6_8F5OD3g7EzTNsC4_TwaEfJADNCTmI 5u3gEJSvuNVfMvi15N_cYZT0xzU0Kjlq25vy3_hr7IalUxeaRdv.snUp_v6HcjUqAtOAkA_rYzLJ tpTkSH1rZHWD8kdsSHFCx13_djFw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jul 2020 22:13:05 +0000 Received: by smtp422.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8069a6c4236d2ffbf0355278345dfebe; Sat, 11 Jul 2020 22:13:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) From: Mark Millard In-Reply-To: Date: Sat, 11 Jul 2020 15:12:58 -0700 Cc: Andrew Turner , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9FBC6DEB-23FA-4FA2-AB10-3D6BDC4CE010@yahoo.com> References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B440y3BR3z3RZH X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.08 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.55)[-0.549]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.0.0.0:email]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[232.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 22:13:07 -0000 >=20 > On 2020-Jul-11, at 14:45, Robert Crowston = wrote: >=20 > So what is the mistake I made here? >=20 > Should I have given a globally unique name as the first argument to = DRIVER_MODULE()? I didn't see that in the man page, and other examples = of pcib drivers apparently get away with it. >=20 > I did notice the weird message about "driver already loaded from = kernel". I wondered if that meant I was dragging in code to the core = kernel, that would otherwise live in an external module? >=20 > Let me know how I can help fix it! >=20 > -- RHC. It is not an area of expertise for me. I've spent hours just getting to the point of sending the notes that I have sent. I did just find the text: QUOTE from = https://www.freebsd.org/cgi/man.cgi?query=3DDRIVER_MODULE&sektion=3D9&n=3D= 1 : The identifier used in DRIVER_MODULE() can be different from the = driver name. Also, the same driver identifier can exist on different = buses, which is a pretty clean way of making front ends for different = cards us- ing the same driver on the same or different buses. For example, = the following is allowed: DRIVER_MODULE(foo, isa, foo_driver, foo_devclass, NULL, NULL); DRIVER_MODULE(foo, pci, foo_driver, foo_devclass, NULL, NULL); END QUOTE But the wording is not explicit about what would be "same bus". I do find two things that suggests to me that "picb" should be a unique name. First: QUOTE from = https://www.freebsd.org/cgi/man.cgi?query=3Ddriver&sektion=3D9&n=3D1 : static int foo_probe(device_t); static int foo_attach(device_t); static int foo_detach(device_t); static int foo_frob(device_t, int, int); static int foo_twiddle(device_t, char *); static device_method_t foo_methods[] =3D { /* Methods from the device interface */ DEVMETHOD(device_probe, foo_probe), DEVMETHOD(device_attach, foo_attach), DEVMETHOD(device_detach, foo_detach), /* Methods from the bogo interface */ DEVMETHOD(bogo_frob, foo_frob), DEVMETHOD(bogo_twiddle, foo_twiddle), /* Terminate method list */ DEVMETHOD_END }; static driver_t foo_driver =3D { "foo", foo_methods, sizeof(struct foo_softc) }; static devclass_t foo_devclass; DRIVER_MODULE(foo, bogo, foo_driver, foo_devclass, NULL, NULL); END QUOTE Note the "foo" in foo_driver. That looks to be something that ends up being globally used (indirectly) and so more likely to have some form of relative-uniqueness criteria. foo is also the prefix on the method routines. I also did the following that produced my second thing making the suggestion: # grep -r "MODULE.*pcib.*simplebus" /usr/src/sys/ | more /usr/src/sys/dev/pci/pci_host_generic_fdt.c:DRIVER_MODULE(pcib, = simplebus, generic_pcie_fdt_driver, /usr/src/sys/dev/xilinx/xlnx_pcib.c:DRIVER_MODULE(xlnx_pcib, simplebus, = xlnx_pcib_fdt_driver, /usr/src/sys/arm64/cavium/thunder_pcie_fdt.c:DRIVER_MODULE(thunder_pcib, = simplebus, thunder_pcie_fdt_driver, /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c:DRIVER_MODULE(pcib, = simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); /usr/src/sys/arm/mv/mv_pci_ctrl.c:DRIVER_MODULE(pcib_ctrl, simplebus, = mv_pcib_ctrl_driver, pcib_ctrl_devclass, 0, 0); /usr/src/sys/arm/nvidia/tegra_pcie.c:DRIVER_MODULE(tegra_pcib, = simplebus, tegra_pcib_driver, pcib_devclass, = /usr/src/sys/arm/annapurna/alpine/alpine_pci.c:DRIVER_MODULE(alpine_pcib, = simplebus, al_pcib_driver, anpa_pcib_devclass, 0, 0); /usr/src/sys/mips/nlm/xlp_pci.c:DRIVER_MODULE(xlp_pcib, simplebus, = xlp_pcib_driver, pcib_devclass, 0, 0); and it looks like in all other cases for pcib and simplebus together, the name in DRIVER_MODULE(name, is unique to the context (one example of plain pcib other than the new one that you added). I hope that the above helps. Mark > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 > On Saturday, 11 July 2020 11:48, Mark Millard = wrote: >=20 >> On 2020-Jul-11, at 02:26, Mark Millard wrote: >>=20 >>> On 2020-Jul-11, at 01:32, Mark Millard wrote: >>>=20 >>>> On 2020-Jul-11, at 00:14, Mark Millard = wrote: >>>>=20 >>>>> Anyone else with such Overdrive 1000 problems after >>>>> upgrading into this range or beyond? >>>>> boot -v output: >>>>> ---<>--- >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> Type Physical Virtual #Pages Attr >>>>> Reserved 008000000000 0 00000e80 WC WT WB >>>>> ConventionalMemory 008000e80000 0 0001ef7d WC WT WB >>>>> BootServicesData 00801fdfd000 0 00000203 WC WT WB >>>>> ConventionalMemory 008020000000 0 001d0583 WC WT WB >>>>> LoaderData 0081f0583000 0 00008000 WC WT WB >>>>> LoaderCode 0081f8583000 0 0000017d WC WT WB >>>>> ACPIReclaimMemory 0081f8700000 0 000000a0 WC WT WB >>>>> ConventionalMemory 0081f87a0000 0 0000000b WC WT WB >>>>> LoaderData 0081f87ab000 0 00000001 WC WT WB >>>>> ConventionalMemory 0081f87ac000 0 000020ab WC WT WB >>>>> BootServicesData 0081fa857000 0 00000029 WC WT WB >>>>> ConventionalMemory 0081fa880000 0 0000000b WC WT WB >>>>> BootServicesData 0081fa88b000 0 0000001f WC WT WB >>>>> ConventionalMemory 0081fa8aa000 0 00000003 WC WT WB >>>>> BootServicesData 0081fa8ad000 0 000002f0 WC WT WB >>>>> ConventionalMemory 0081fab9d000 0 00000001 WC WT WB >>>>> BootServicesData 0081fab9e000 0 00000012 WC WT WB >>>>> ConventionalMemory 0081fabb0000 0 00000001 WC WT WB >>>>> BootServicesData 0081fabb1000 0 00000006 WC WT WB >>>>> ConventionalMemory 0081fabb7000 0 00000002 WC WT WB >>>>> BootServicesData 0081fabb9000 0 00000ae7 WC WT WB >>>>> ConventionalMemory 0081fb6a0000 0 00000046 WC WT WB >>>>> BootServicesCode 0081fb6e6000 0 0000014a WC WT WB >>>>> RuntimeServicesCode 0081fb830000 81fb830000 000003e0 WC WT WB = RUNTIME >>>>> ConventionalMemory 0081fbc10000 0 000001a0 WC WT WB >>>>> RuntimeServicesData 0081fbdb0000 81fbdb0000 00000250 WC WT WB = RUNTIME >>>>> ConventionalMemory 0081fc000000 0 0000001f WC WT WB >>>>> BootServicesData 0081fc01f000 0 00000001 WC WT WB >>>>> ConventionalMemory 0081fc020000 0 00003732 WC WT WB >>>>> BootServicesData 0081ff752000 0 0000087a WC WT WB >>>>> ConventionalMemory 0081fffcc000 0 00000004 WC WT WB >>>>> RuntimeServicesData 0081fffd0000 81fffd0000 00000020 WC WT WB = RUNTIME >>>>> ConventionalMemory 0081ffff0000 0 0000000c WC WT WB >>>>> BootServicesData 0081ffffc000 0 00000004 WC WT WB >>>>> Physical memory chunk(s): >>>>> 0x8000e80000 - 0x81f86fffff, 8056 MB (2062464 pages) >>>>> 0x81f87a0000 - 0x81fb82ffff, 48 MB ( 12432 pages) >>>>> 0x81fbc10000 - 0x81ffffffff, 67 MB ( 17392 pages) >>>>> Excluded memory regions: >>>>> 0x8000000000 - 0x8000e7ffff, 14 MB ( 3712 pages) NoAlloc >>>>> 0x81f0600000 - 0x81f1992fff, 19 MB ( 5011 pages) NoAlloc >>>>> 0x81f8700000 - 0x81f879ffff, 0 MB ( 160 pages) NoAlloc >>>>> 0x81fb830000 - 0x81fbc0ffff, 3 MB ( 992 pages) NoAlloc >>>>> 0x81fbdb0000 - 0x81fbffffff, 2 MB ( 592 pages) NoAlloc >>>>> 0x81fffd0000 - 0x81fffeffff, 0 MB ( 32 pages) NoAlloc >>>>> Found 4 CPUs in the device tree >>>>> Copyright (c) 1992-2020 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, = 1993, 1994 >>>>> The Regents of the University of California. All rights reserved. >>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 13.0-CURRENT #6 r363021M: Thu Jul 9 22:46:01 PDT 2020 >>>>> = markmi@FBSDFHUGE:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 >>>>> FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d) >>>>> VT: init without driver. >>>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001166000. >>>>> Preloaded hostuuid "/etc/hostid" at 0xffff00000116f310. >>>>> Preloaded boot_entropy_cache "/boot/entropy" at = 0xffff00000116f360. >>>>> module firmware already present! >>>>> module_register: cannot register simplebus/gpio from kernel; = already loaded from kernel >>>>> Module simplebus/gpio failed to register: 17 >>>>> module_register: cannot register simplebus/pcib from kernel; = already loaded from kernel >>>>> Module simplebus/pcib failed to register: 17 >>>>> Starting CPU 1 (101) >>>>> Starting CPU 2 (200) >>>>> Starting CPU 3 (201) >>>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>>>> random: read 4096 bytes from preloaded cache >>>>> random: unblocking device. >>>>> VIMAGE (virtualized network stack) enabled >>>>> hostuuid: using # >>>>> ULE: setup cpu 0 >>>>> ULE: setup cpu 1 >>>>> ULE: setup cpu 2 >>>>> ULE: setup cpu 3 >>>>> Table 'FACP' at 0x81f8770000 >>>>> Table 'APIC' at 0x81f8750000 >>>>> Table 'GTDT' at 0x81f8740000 >>>>> Table 'DBG2' at 0x81f8730000 >>>>> Table 'SPCR' at 0x81f8720000 >>>>> Table 'MCFG' at 0x81f8710000 >>>>> Table 'CSRT' at 0x81f8700000 >>>>> ACPI: No IORT table found >>>>> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] = c=3D0x000003ff [1024] >>>>> feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 >>>>> random: entropy device external interface >>>>> MAP 81fb830000 mode 2 pages 992 >>>>> MAP 81fbdb0000 mode 2 pages 592 >>>>> MAP 81fffd0000 mode 2 pages 32 >>>>> WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. >>>>> kbd0 at kbdmux0 >>>>> crypto: >>>>> mem: >>>>> null: >>>>> openfirm: >>>>> WARNING: Device "openfirm" is Giant locked and may be deleted = before FreeBSD 13.0. >>>>> ofwbus0: >>>>> simplebus0: on ofwbus0 >>>>> clk_fixed0: on simplebus0 >>>>> clk_fixed1: on simplebus0 >>>>> clk_fixed2: on simplebus0 >>>>> clk_fixed3: on simplebus0 >>>>> clk_fixed4: on simplebus0 >>>>> clk_fixed5: on simplebus0 >>>>> clk_fixed6: on simplebus0 >>>>> clk_fixed7: on simplebus0 >>>>> clk_fixed8: on simplebus0 >>>>> clk_fixed9: on simplebus0 >>>>> clk_fixed10: on simplebus0 >>>>> psci0: on ofwbus0 >>>>> psci0: PSCI version 0.2 compatible >>>>> gic0: mem = 0xe1110000-0xe1110fff,0xe112f000-0xe1130fff,0xe1140000-0xe114ffff,0xe11600= 00-0xe116ffff irq 4 on ofwbus0 >>>>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 448 >>>>> gicv2m0: mem = 0x80000-0x80fff on gic0 >>>>> gicv2m0: using spi 64 to 319 >>>>> generic_timer0: irq 5,6,7,8 on ofwbus0 >>>>> Timecounter "ARM MPCore Timecounter" frequency 250000000 Hz = quality 1000 >>>>> Event timer "ARM MPCore Eventtimer" frequency 250000000 Hz quality = 1000 >>>>> efirtc0: >>>>> efirtc0: registered as a time-of-day clock, resolution 1.000000s >>>>> cpulist0: on ofwbus0 >>>>> cpu0: on cpulist0 >>>>> cpu0: missing 'clock-frequency' property >>>>> cpu1: on cpulist0 >>>>> cpu1: missing 'clock-frequency' property >>>>> cpu2: on cpulist0 >>>>> cpu2: missing 'clock-frequency' property >>>>> cpu3: on cpulist0 >>>>> cpu3: missing 'clock-frequency' property >>>>> pmu0: irq 0,1,2,3 on ofwbus0 >>>>> ahci0: mem 0xe0300000-0xe03effff irq 9 on = simplebus0 >>>>> ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier supported >>>>> ahci0: Caps: 64bit NCQ SNTF SS AL CLO 6Gbps PM PMD 32cmd CCC = 8ports >>>>> ahci0: Caps2: APST >>>>> ahcich0: at channel 0 on ahci0 >>>>> ahcich0: Caps: HPCP >>>>> ahcich1: at channel 1 on ahci0 >>>>> ahcich1: Caps: HPCP >>>>> ahcich2: not probed (disabled) >>>>> ahcich3: not probed (disabled) >>>>> ahcich4: not probed (disabled) >>>>> ahcich5: not probed (disabled) >>>>> ahcich6: not probed (disabled) >>>>> ahcich7: not probed (disabled) >>>>> simplebus0: sata@e0d00000 mem 0xe0d00000-0xe0deffff irq 10 = disabled compat snps,dwc-ahci (no driver attached) >>>>> simplebus0: i2c@e1000000 mem 0xe1000000-0xe1000fff irq 11 compat = snps,designware-i2c (no driver attached) >>>>> simplebus0: i2c@e0050000 mem 0xe0050000-0xe0050fff irq 12 compat = snps,designware-i2c (no driver attached) >>>>> uart0: mem 0xe1010000-0xe1010fff irq 13 = on simplebus0 >>>>> uart0: console (115200,n,8,1) >>>>> uart0: fast interrupt >>>>> uart0: PPS capture mode: DCD >>>>> simplebus0: ssp@e1020000 mem 0xe1020000-0xe1020fff irq 14 compat = arm,pl022 (no driver attached) >>>>> simplebus0: ssp@e1030000 mem 0xe1030000-0xe1030fff irq 15 compat = arm,pl022 (no driver attached) >>>>> simplebus0: gpio@e1050000 mem 0xe1050000-0xe1050fff irq 16 compat = arm,pl061 (no driver attached) >>>>> simplebus0: gpio@e0020000 mem 0xe0020000-0xe0020fff irq 17 compat = arm,pl061 (no driver attached) >>>>> simplebus0: gpio@e0030000 mem 0xe0030000-0xe0030fff irq 18 compat = arm,pl061 (no driver attached) >>>>> simplebus0: gpio@e0080000 mem 0xe0080000-0xe0080fff irq 19 compat = arm,pl061 (no driver attached) >>>>> simplebus0: ccp@e0100000 mem 0xe0100000-0xe010ffff irq 20 compat = amd,ccp-seattle-v1a (no driver attached) >>>>> simplebus0: pcie@f0000000 mem 0xf0000000-0xffffffff type pci = compat pci-host-ecam-generic (no driver attached) >>>>> simplebus0: ccn@0xe8000000 mem 0xe8000000-0xe8ffffff irq 21 compat = arm,ccn-504 (no driver attached) >>>>> simplebus0: gwdt@e0bb0000 mem = 0xe0bb0000-0xe0bbffff,0xe0bc0000-0xe0bcffff irq 22 compat arm,sbsa-gwdt = (no driver attached) >>>>> simplebus0: kcs@e0010000 mem 0xe0010000-0xe0010007 irq 23 type = ipmi compat ipmi-kcs (no driver attached) >>>>> simplebus0: phy@e1240800 mem = 0xe1240800-0xe1240bff,0xe1250000-0xe125005f,0xe12500f8-0xe12500fb irq 24 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >>>>> simplebus0: phy@e1240c00 mem = 0xe1240c00-0xe1240fff,0xe1250080-0xe12500df,0xe12500fc-0xe12500ff irq 25 = disabled compat amd,xgbe-phy-seattle-v1a (no driver attached) >>>>> simplebus0: xgmac@e0700000 mem = 0xe0700000-0xe077ffff,0xe0780000-0xe07fffff irq 26,27,28,29,30 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >>>>> simplebus0: xgmac@e0900000 mem = 0xe0900000-0xe097ffff,0xe0980000-0xe09fffff irq 31,32,33,34,35 disabled = compat amd,xgbe-seattle-v1a (no driver attached) >>>>> cryptosoft0: >>>>> crypto: assign cryptosoft0 driver id 0, flags 0x6000000 >>>>> Device configuration finished. >>>>> Found SMCCC version 1.0 >>>>> procfs registered >>>>> Timecounters tick every 1.000 msec >>>>> lo0: bpf attached >>>>> vlan: initialized, using hash tables with chaining >>>>> IPsec: Initialized Security Association Processing. >>>>> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 >>>>> Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 >>>>> usb_needs_explore_all: no devclass >>>>> Release APs...ahcich0: AHCI reset... >>>>> Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... >>>>> done >>>>> Root mount waiting for: CAMCPU 0: ARM Cortex-A57 r1p2 affinity: 1 = 0 >>>>>=20 >>>>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>>>>=20 >>>>>=20 >>>>> ahcich0: SATA connect timeout time=3D10000us status=3D00000000 >>>>> Instruction Set Attributes 0 =3D >>>>> ahcich0: AHCI reset: device not found >>>>> Instruction Set Attributes 1 =3D <> >>>>> ahcich1: AHCI reset... >>>>> Processor Features 0 =3D >>>>> ahcich1: SATA connect time=3D100us status=3D00000133 >>>>> Processor Features 1 =3D <> >>>>> ahcich1: AHCI reset: device found >>>>> Memory Model Features 0 =3D >>>>> ahcich1: AHCI reset: device ready after 0ms >>>>> Memory Model Features 1 =3D <8bit VMID> >>>>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>>>> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> >>>>> Debug Features 1 =3D <> >>>>> Auxiliary Features 0 =3D <> >>>>> Auxiliary Features 1 =3D <> >>>>> CPU 1: ARM Cortex-A57 r1p2 affinity: 1 1 >>>>> CPU 2: ARM Cortex-A57 r1p2 affinity: 2 0 >>>>> CPU 3: ARM Cortex-A57 r1p2 affinity: 2 1 >>>>> regulator: shutting down unused regulators >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> GEOM: new disk ada0 >>>>> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0 >>>>> ada0: ACS-4 ATA SATA 3.x device >>>>> ada0: Serial Number # >>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>> ada0: Command Queueing enabled >>>>> ada0: 976762MB (2000409264 512 byte sectors) >>>>> pass0 at ahcich1 bus 0 scbus1 target 0 lun 0 >>>>> pass0: ACS-4 ATA SATA 3.x = device >>>>> pass0: Serial Number # >>>>> pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>> pass0: Command Queueing enabled >>>>> efirtc0: providing initial system time >>>>> start_init: trying /sbin/init >>>>> Setting hostuuid: #. >>>>> Setting hostid: #. >>>>> Starting file system checks: >>>>> /dev/gpt/FBSDCA57root: FILE SYSTEM CLEAN; SKIPPING CHECKS >>>>> /dev/gpt/FBSDCA57root: clean, 189555062 free (288086 frags, = 23658372 blocks, 0.1% fragmentation) >>>>> Mounting local filesystems:. >>>>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc10 = /usr/local/lib/perl5/5.30/mach/CORE /usr/local/lib/qt5 = /usr/local/llvm10/lib /usr/local/llvm80/lib >>>>> Setting hostname: FBSDCA57. >>>>> Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED >>>>> Feeding entropy: . >>>>> lo0: link state changed to UP >>>>> Starting Network: lo0. >>>>> lo0: flags=3D8049 metric 0 mtu = 16384 >>>>> options=3D680003 >>>>> inet6 ::1 prefixlen 128 >>>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >>>>> inet 127.0.0.1 netmask 0xff000000 >>>>> groups: lo >>>>> nd6 options=3D21 >>>>> Starting devd. >>>>> add host 127.0.0.1: gateway lo0 fib 0: route already in table >>>>> add host ::1: gateway lo0 fib 0: route already in table >>>>> add net fe80::: gateway ::1 >>>>> add net ff02::: gateway ::1 >>>>> add net ::ffff:0.0.0.0: gateway ::1 >>>>> add net ::0.0.0.0: gateway ::1 >>>>=20 >>>> I used artificat.ci.freebsd.org to do an approximate >>>> bisect and the results are: >>>> head -r362952 and before work. >>>> there was no -r362953 artifact >>>> head -r362954 and later fail. >>>> The potential failure checkins are -r362953 and >>>> -r362954 : >>>> Author: hselasky >>>> Date: Mon Jul 6 08:50:11 2020 >>>> New Revision: 362953 >>>> URL: >>>> https://svnweb.freebsd.org/changeset/base/362953 >>>> Log: >>>> Infiniband clients must be attached and detached in a specific = order in ibcore. >>>> . . . >>>> Differential Revision: https://reviews.freebsd.org/D23973 >>>> . . . >>>> and: >>>> Author: andrew >>>> Date: Mon Jul 6 08:51:55 2020 >>>> New Revision: 362954 >>>> URL: >>>> https://svnweb.freebsd.org/changeset/base/362954 >>>> Log: >>>> Add a driver for bcm2838 PCI express controller >>>> . . . >>>> Submitted by: Robert Crowston >>>> Differential Revision: https://reviews.freebsd.org/D25068 >>>> . . . >>>=20 >>> diff'ing the boot -v material for a good boot >>> vs. a failing one shows that . . . >>> Only the failure example has: >>> +module_register: cannot register simplebus/pcib from kernel; = already loaded from kernel >>> +Module simplebus/pcib failed to register: 17 >>> Only the good example later has: >>> -pcib0: mem 0xf0000000-0xffffffff on = simplebus0 >>> -pcib0: parsing FDT for ECAM0: >>> -pcib0: PCI addr: 0x0, CPU addr: 0xefff0000, Size: 0x10000 >>> -pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x80000000 >>> -pcib0: PCI addr: 0x100000000, CPU addr: 0x100000000, Size: = 0x7f00000000 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 >>> -pcib0: Bus is cache-coherent >>> -pci0: on pcib0 >>> -pci0: domain=3D0, physical bus=3D0 >>> -found-> vendor=3D0x1022, dev=3D0x1a00, revid=3D0x00 >>>=20 >>> - domain=3D0, bus=3D0, slot=3D0, func=3D0 >>>=20 >>>=20 >>> - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>=20 >>>=20 >>> - cmdreg=3D0x0004, statreg=3D0x0000, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>>=20 >>> -found-> vendor=3D0x1022, dev=3D0x1a01, revid=3D0x00 >>>=20 >>> - domain=3D0, bus=3D0, slot=3D2, func=3D0 >>>=20 >>>=20 >>> - class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>=20 >>>=20 >>> - cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>>=20 >>> -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 >>>=20 >>> - domain=3D0, bus=3D0, slot=3D2, func=3D2 >>>=20 >>>=20 >>> - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>=20 >>>=20 >>> - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>> - intpin=3Da, irq=3D255 >>>=20 >>>=20 >>> - powerspec 3 supports D0 D3 current D0 >>>=20 >>>=20 >>> - MSI supports 1 message, 64 bit >>>=20 >>>=20 >>> - secbus=3D1, subbus=3D1 >>>=20 >>>=20 >>>=20 >>> -found-> vendor=3D0x1022, dev=3D0x1a02, revid=3D0x00 >>>=20 >>> - domain=3D0, bus=3D0, slot=3D2, func=3D3 >>>=20 >>>=20 >>> - class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>=20 >>>=20 >>> - cmdreg=3D0x0507, statreg=3D0x0010, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>> - intpin=3Da, irq=3D255 >>>=20 >>>=20 >>> - powerspec 3 supports D0 D3 current D0 >>>=20 >>>=20 >>> - MSI supports 1 message, 64 bit >>>=20 >>>=20 >>> - secbus=3D2, subbus=3D2 >>>=20 >>>=20 >>>=20 >>> -pcib1: at device 2.2 on pci0 >>> -pcib0: rman_reserve_resource: start=3D0x40100000, end=3D0x401fffff, = count=3D0x100000 >>> -pcib1: domain 0 >>> -pcib1: secondary bus 1 >>> -pcib1: subordinate bus 1 >>> -pcib1: memory decode 0x40100000-0x401fffff >>> -pci1: on pcib1 >>> -pcib1: allocated bus range (1-1) for rid 0 of pci1 >>> -pci1: domain=3D0, physical bus=3D1 >>> -found-> vendor=3D0x1b73, dev=3D0x1009, revid=3D0x02 >>>=20 >>> - domain=3D0, bus=3D1, slot=3D0, func=3D0 >>>=20 >>>=20 >>> - class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 >>>=20 >>>=20 >>> - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>> - intpin=3Da, irq=3D255 >>>=20 >>>=20 >>> - powerspec 3 supports D0 D1 D3 current D0 >>>=20 >>>=20 >>> - MSI supports 8 messages, 64 bit >>>=20 >>>=20 >>> - MSI-X supports 8 messages in maps 0x18 and 0x20 >>>=20 >>>=20 >>> - map[10]: type Memory, range 64, base 0x40100000, size 16, = memory disabled >>>=20 >>>=20 >>>=20 >>> -pcib1: allocated memory range (0x40100000-0x4010ffff) for rid 10 of = pci0:1:0:0 >>>=20 >>> - map[18]: type Memory, range 64, base 0x40110000, size 12, = enabled >>>=20 >>>=20 >>>=20 >>> -pcib1: allocated memory range (0x40110000-0x40110fff) for rid 18 of = pci0:1:0:0 >>>=20 >>> - map[20]: type Memory, range 64, base 0x40111000, size 12, = enabled >>>=20 >>>=20 >>>=20 >>> -pcib1: allocated memory range (0x40111000-0x40111fff) for rid 20 of = pci0:1:0:0 >>> -xhci0: mem = 0x40100000-0x4010ffff,0x40110000-0x40110fff,0x40111000-0x40111fff at = device 0.0 on pci1 >>> -xhci0: 32 bytes context size, 64-bit DMA >>> -xhci0: attempting to allocate 1 MSI vectors (8 supported) >>> -xhci0: using IRQ 36 for MSI >>> -xhci0: MSI enabled >>> -usbus0 on xhci0 >>> -xhci0: usbpf: Attached >>> -pcib2: at device 2.3 on pci0 >>> -pcib0: rman_reserve_resource: start=3D0x1000, end=3D0x1fff, = count=3D0x1000 >>> -pcib0: rman_reserve_resource: start=3D0x40000000, end=3D0x400fffff, = count=3D0x100000 >>> -pcib2: domain 0 >>> -pcib2: secondary bus 2 >>> -pcib2: subordinate bus 2 >>> -pcib2: I/O decode 0x1000-0x1fff >>> -pcib2: memory decode 0x40000000-0x400fffff >>> -pci2: on pcib2 >>> -pcib2: allocated bus range (2-2) for rid 0 of pci2 >>> -pci2: domain=3D0, physical bus=3D2 >>> -found-> vendor=3D0x11ab, dev=3D0x4381, revid=3D0x00 >>>=20 >>> - domain=3D0, bus=3D2, slot=3D0, func=3D0 >>>=20 >>>=20 >>> - class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 >>>=20 >>>=20 >>> - cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) >>>=20 >>>=20 >>> - lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00= (0 ns) >>>=20 >>>=20 >>> - intpin=3Da, irq=3D255 >>>=20 >>>=20 >>> - powerspec 3 supports D0 D1 D2 D3 current D0 >>>=20 >>>=20 >>> - MSI supports 1 message, 64 bit >>>=20 >>>=20 >>> - map[10]: type Memory, range 64, base 0x40000000, size 14, = memory disabled >>>=20 >>>=20 >>>=20 >>> -pcib2: allocated memory range (0x40000000-0x40003fff) for rid 10 of = pci0:2:0:0 >>>=20 >>> - map[18]: type I/O Port, range 32, base 0x1000, size 8, = port disabled >>>=20 >>>=20 >>>=20 >>> -pcib2: allocated I/O port range (0x1000-0x10ff) for rid 18 of = pci0:2:0:0 >>> -mskc0: port 0x1000-0x10ff = mem 0x40000000-0x40003fff at device 0.0 on pci2 >>> -mskc0: MSI count : 1 >>> -mskc0: attempting to allocate 1 MSI vectors (1 supported) >>> -mskc0: using IRQ 37 for MSI >>> -mskc0: RAM buffer size : 0KB >>> -msk0: = on mskc0 >>> -msk0: Using defaults for TSO: 65518/35/2048 >>> -msk0: bpf attached >>> -msk0: Ethernet address: e0:ff:f7:00:20:ed >>> -miibus0: on msk0 >>> -e1000phy0: PHY 0 on miibus0 >>> -e1000phy0: OUI 0x000ac2, model 0x0027, rev. 0 >>> -e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, = auto-flow >>> The failure example instead had: >>> +simplebus0: pcie@f0000000 mem 0xf0000000-0xffffffff type pci compat = pci-host-ecam-generic (no driver attached) >>> Later there was: >>> -usbus0: 5.0Gbps Super Speed USB v3.0 >>> Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 >>> +usb_needs_explore_all: no devclass >>> I'll stop with that. >>=20 >> Using nm (and cut and grep) to extract names from a >> good and bad kernel I find the following, where the >> "+" lines are from a bad kernel: >>=20 >> diff -u mmjnk.goodnames mmjnk.baddupnames >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> --- mmjnk.goodnames 2020-07-11 03:31:55.360299000 -0700 >> +++ mmjnk.baddupnames 2020-07-11 03:31:28.483440000 -0700 >> @@ -1,26 +1,35 @@ >> __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus >> = __set_modmetadata_set_sym__mod_metadata_md_alpine_pcib_simplebus_on_kernel= >> __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus >> +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus >> __set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel >> +__set_modmetadata_set_sym__mod_metadata_md_pcib_simplebus_on_kernel >> __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus >> = __set_modmetadata_set_sym__mod_metadata_md_thunder_pcib_simplebus_on_kerne= l >> __set_sysinit_set_sym_alpine_pcib_simplebusmodule_sys_init >> __set_sysinit_set_sym_pcib_simplebusmodule_sys_init >> +__set_sysinit_set_sym_pcib_simplebusmodule_sys_init >> __set_sysinit_set_sym_thunder_pcib_simplebusmodule_sys_init >> _alpine_pcib_simplebus_depend_on_kernel >> _mod_metadata_md_alpine_pcib_simplebus >> _mod_metadata_md_alpine_pcib_simplebus_on_kernel >> _mod_metadata_md_pcib_simplebus >> +_mod_metadata_md_pcib_simplebus >> _mod_metadata_md_pcib_simplebus_on_kernel >> +_mod_metadata_md_pcib_simplebus_on_kernel >> _mod_metadata_md_thunder_pcib_simplebus >> _mod_metadata_md_thunder_pcib_simplebus_on_kernel >> _pcib_simplebus_depend_on_kernel >> +_pcib_simplebus_depend_on_kernel >> _thunder_pcib_simplebus_depend_on_kernel >> alpine_pcib_simplebus_driver_mod >> alpine_pcib_simplebus_mod >> alpine_pcib_simplebusmodule_sys_init >> pcib_simplebus_driver_mod >> +pcib_simplebus_driver_mod >> pcib_simplebus_mod >> +pcib_simplebus_mod >> +pcib_simplebusmodule_sys_init >> pcib_simplebusmodule_sys_init >> thunder_pcib_simplebus_driver_mod >> thunder_pcib_simplebus_mod >>=20 >> It leaves me wondering if the naming is messing things >> up via duplicate naming from the likes of: >>=20 >> static devclass_t generic_pcie_fdt_devclass; >>=20 >> DRIVER_MODULE(pcib, simplebus, generic_pcie_fdt_driver, >> generic_pcie_fdt_devclass, 0, 0); >>=20 >> vs. >>=20 >> static devclass_t bcm_pcib_devclass; >> DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, = 0); >>=20 >> (Dual pcib_simplebus based sets of names?) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 11 22:49:19 2020 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 082C93734E6 for ; Sat, 11 Jul 2020 22:49:19 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 4B44pk0MYzz3TRT for ; Sat, 11 Jul 2020 22:49:17 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1juOIv-0009oo-UH; Sat, 11 Jul 2020 15:49:10 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 06BMn9fe037745; Sat, 11 Jul 2020 15:49:09 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 11 Jul 2020 15:49:08 -0700 From: Oleksandr Tymoshenko To: Charles Cc: freebsd-arm@freebsd.org Subject: Re: RK3328/Rock64 GigE testers needed. Message-ID: <20200711224908.GA37648@bluezbox.com> References: <20200705000643.GA63127@server.rulingia.com> <20200709203532.GA9738@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Charles (charlesr@scd-systems.net) wrote: > Hi gonzo, Mark, > > If this patch and tuning settings are not help, do I have to solder like > mentioned in > https://sanisimov.com/2019/08/fixing-rock64-v2 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B44pk0MYzz3TRT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.79 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.995]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.497]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 22:49:19 -0000 Charles (charlesr@scd-systems.net) wrote: > Hi gonzo, Mark, > > If this patch and tuning settings are not help, do I have to solder like > mentioned in > https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ ? > > Just for the case, I bought some resistors. > > I would like to know why the interface works stable with linux. Hi Charles, Waht u-boot do you use? At the moment FreeBSD (even with my patch) heavily relies on u-boot to set up clocks and registers for the ethernet adapter. If it's a custom-built u-boot that may explain your issues with network. Also could you boot your board with the kernel with the WIP patch applied and send me the output? Thank you -- gonzo