From nobody Mon Sep 27 06:05:46 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC66917E2C81 for ; Mon, 27 Sep 2021 06:06:01 +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 4HHsZd370Bz4RPj for ; Mon, 27 Sep 2021 06:06:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1632722754; bh=sR1OHu7Ybi6xz8qSAv0qJOMPDma3lwPiazG3/R5R+HE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dDyjOWgzq3+TuRcfuHJWCWnHEVJ3IUuXMx5tJ8XSySzWUi91CIDvd8BzrfBLCMPcQZaCvkBmqOTzM7YF1OzZ3lOXQYiYFd7/66+u+bWTGJZ+UtcizwT22N7+j2b2OvVZwujF88/qz2Mv89P2RnVSVTasDPFppHUPsVkstTNbMLEVyvtFxFtU+IjdHF07A0KGeMAd9rT0mwj2E5TVn3knXQTjbggsnfSx/OPAoaIgU0kesHQR1N6rygkPAmOogHr+MRFh+t4TQe3ys/wy3Nb5rbLzVsCU/Z36UKwBza98Nq+PPCiNPVzt9UgvjiBG3oKefTFJLdDVvD68VfoCRND5Wg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1632722754; bh=8w1Jh5bGTbxKKW4EpOSux+T+xta6ULDiwPmnU65WcT7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PUUfyXxr6NxjcUP5KlvfTYb0vPMBcmKER41HpsGAt6UdMoJU0WUvC4pbrT0s9f+asaRSfgZWPTQeAGp/xln7MRuOk195M/XNFpOp33s2yjlsfyy0hUpkU2VdXPW/4AKhGFVSaNHKVtmEZu/FHpdU1TjQIc3rPytnWGPCd8EeuhXcVUkCuFYLeb8unHPlyYPUMgUQksEtyOsTHe2uTm5q4wt7Ki42Q9dpGAfmPBBIw8caKuWqIwAR/ICO68SMJ4bUapu1ZatwP7XzjVDishzG6z/g96ucHXb0ECgwelQgyE0NPnyILNhHYzQtMAAc+b30/99qd4ige5O3FLgbf3EcsA== X-YMail-OSG: wmVI8EAVM1mFBixHwfuFiAkmBBqra.Ym7Gl8VDxG9DnbQaRG6xUuaCu55TV44aX dcnlmhxp3_xbyf6jGudvasMPakOaY5LdreKr8ba67MRkvyq.F0Pmz0Q0bFasR.OoC3XI4A7HMDCB 7Zt2LXslgub3djJ7mU1ho3GcBdEz7OiuDkSifnCJ48hzIQNLBt7RDouzTGIfcAsyfdmLEEe2pNZl aYp7_HDZU5_zDfKI_QKROJAA.9YjxKr7R4Dr4ZWu9Hr7E1Ht2DWPrwllcEENxu5Eq7BH6VikbBsn 9Ew_U7l418hgEJIDwrTaGL81xYENuYZP7grpkM1PZAz31zy7bZUiTtYvPmr7UWauB0sGVOmBCzw3 cPid82nNKn8MXcaGSCo2gBjJ8kZ.2uIpKU1WXTEci_FxQJOsofSTahGmQF_OkJGtjUVauG3J1EeB W3qkpi9zuTfHOlyFxDeVvcjC8PcmxnRNKLmg98z4jmEodTCwhhgsf9PpaIeXus8nyyLc7VeHFxtc eL9jV0CodYwSghoPNNS7HJ2oTC0ceY9EzV_5DLyTsbEaTsnqokrgy82XLLjA7swqdksPYt2J0G0R _0TYAFscnmkADLmZg_u9rYxVu0IpzvHEQrgM61UNSHsiWCzAWhOwBCWSED8NMXuqdMS5G2xPaO3x 41pJfRrtQQ8L0ZWIYo_gUiLze8xcFsZ0GEmslpy21QUrNgmvK.mXjbWX2r01OO5deoHcj3NY8.dv kbwsA9VQSyAJTgoxB1a832UsbRa2Vif8cGOkaZQrCIqcb3gjtbMWkadpmxcPJHZsW_A_7MbHOVCc 4clHHter4rTGbxi3RNRv7XSxm8_WKe1v_2UYN99KyrZXrL6cDJPKkOUA0RJlmocvbJRLzNBgkjkO CjOy9Imfwe.YhbvHG5knG0TlasNwCevugSbLQGcpPau9NNMO_XrMP4d9kXt9lA_X2lSNz7ps1m9m eppflE.Ts7VSIdSESFhEBp_am3lZuGKcK_w35KE5I5c8XB6PAD9SxPFIuAG4Egb4wsB1Cd7pORgd DKRDUlaMmdQVTWrgIovOf2bukF4c5pMzNxm3mMSs4mt3PjA5HbOUqVGeA8QIg68O_BjDQdqPJnkY qc_VQglKEJ0hOg4MJMVaKwcaRTbQzl5SCFmxhcS7Iep442m_l612s9BKBjMDh1paBj3bISJqnGSq ovR_3DUFVRs.3DqidN.gl_GFim4V2cPlMV3xipf2ThV7mVT1dZCn.R8pexnJMdL3FAnJwOnlonOD XGCgjpeupuiYW45eSm8OuqoWisNesKXign2djADXfS04hEvI.qLGHUCII7CG4dX0EnwWc258UIdF fzom1j4jkXHug6LsWOFDxXpfqXFKg3PBijz3ENwB30UdwEpAyE7LXjwcH_Mwyay_c4ZHTEKueGhV yj93iP2Uk.8KocgXztZNggO98OqrhROSYMwgkNhK5aqqtYifvfdkCZwW0P4h6i1sR5d15CPhJrEd vKNBJkMK3KPoWeh9mlTk3QReKS5hvQkUBPz0iATyb2HYjWbnpNuDE35UN2xUMEuaCJiiSxvrK.Xi lcXAiLXyI1.3FogfOZ6huWQc_rYTosEG0L6OwyO4U5QNwAFfYfaHUGJoVjahUk6a5_RcUh61UYWK L_9zpppMMeUYQRq7A8YdL90fghwOh4L.mm6MnGKAfV3878OSoAEHZMSokD7JKSU4wyxn7rSlJycn wX1Ryx7rz76vGCDHmjHikfdDL15b5k6iFeoq3y4UclWuOUDAtrzOfIvkHjOUK9qCZ5KMRyOFt9Zq WRIHP_V.8ZHFpxDB.MRQXNlrx_.g5SVPGzo6kPI2kJSiqjikDzNSsT9uAlwvZAXXWDcpsZ2gRQnP 6bmaTgtBgxOCaAymPuW.xWM7Yet0m95C58cv3MSTBlpmXgkAo9KvTBUTd0LR7mT1ZtrQVTKe.9cR raPUI0KxqeO7gaB1d90SV9Op3rH0hGWq6W6DKdQS6m3Njg6WRICPgLsHnxpDvZ47Q2dqn1F83Ntb JPQjEj6yi1wXGQ2upLKdbzJkh_iEvTzVu9yclCXrHupBRf0IPajwZWgiM4lLFPwPqePPbrXx78wt v1DbCqm7KnMSZDSo3kwr.AckiHXWMa_IcCJPpBNHLf6t5kHzsXF73W_iiEQcOQeIzWJv8VpWBbWh b6xQHMN_a7wQds2qI3CONcTGT2ZPw.LtwCcXc71SEBcQ8279s6KbDr3ZRPWlwcCFZvc0GLO031Jx Hgz203SsfoiUwTiGezAD_jKrzcntARRW36pH43ynqvvF9ePCcffLUBcnDXiqcb5zGUXIsZoHeiyU v_81nuYUkB_1OG9sTejtnd8fs X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Sep 2021 06:05:54 +0000 Received: by kubenode586.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b4e69c12d193289e757e74478fe0d69; Mon, 27 Sep 2021 06:05:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: I get odd time reports from poudriere on armv7 system, under a (non-debug) main [so: 14] FreeBSD. In-Reply-To: Date: Sun, 26 Sep 2021 23:05:46 -0700 Cc: freebsd-ports@freebsd.org, freebsd-current , Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <0FE65CAD-EDFF-4CE8-8750-BD4F6971CAA0@yahoo.com> References: <187B69AF-9465-41DE-BFD0-A4AA0F7F9068@yahoo.com> To: Ian Lepore , Bryan Drewery X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HHsZd370Bz4RPj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-26, at 10:02, Ian Lepore wrote: > On Sun, 2021-09-26 at 02:27 -0700, Mark Millard via freebsd-current > wrote: >> On 2021-Sep-25, at 23:25, Mark Millard wrote: >>=20 >>=20 >> [...] >> if (argc =3D=3D 3 && strcmp(argv[2], "-nsec") =3D=3D 0) >> printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec); >=20 > There are two problems with this, both the seconds and nanos are > printed incorrectly. The correct incantation would be >=20 > printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec); >=20 Thanks Ian for looking into more than I did last night. Based on the following (up to possible e-mail white space issues), poudriere-devel seems t be working for reporting times: # more /usr/ports/ports-mgmt/poudriere-devel/files/patch-clock=20 --- src/libexec/poudriere/clock/clock.c.orig 2021-09-26 = 22:24:54.735485000 -0700 +++ src/libexec/poudriere/clock/clock.c 2021-09-26 11:46:12.076362000 = -0700 @@ -24,6 +24,7 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ =20 +#include #include #include #include @@ -71,8 +72,8 @@ } else usage(); if (argc =3D=3D 3 && strcmp(argv[2], "-nsec") =3D=3D 0) - printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec); + printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec); else - printf("%ld\n", ts.tv_sec); + printf("%jd\n", (intmax_t)ts.tv_sec); return (EXIT_SUCCESS); } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Sep 28 16:48:08 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 24BB017E650F for ; Tue, 28 Sep 2021 16:48:13 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 4HJln824rjz3wXT for ; Tue, 28 Sep 2021 16:48:12 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 118FC3201FE0 for ; Tue, 28 Sep 2021 12:48:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 28 Sep 2021 12:48:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=aUaVWr/ko7ddVNxPFD1bTR6wfQA OJcjH7GqWe5r/vpE=; b=TM1EQ0jvHdhq9+y67j9HchTFV4RIzVMjsVc2Nt10t0U HVANxwjUteCpD+QbDmKqe0ZDu6FgUFcWoCd+98Ib1BQabzhQDPDc1HAF6zIrVvLe +JADkCCQUpzOT3Fd+951BFqWoMFjTPVsYM4XL8M/tTx8N0QoY4cxZNaSWNSgSA4U UbQN0I5k+qGIntCojqkNYoHzTJj0eulT94D9D/qKEuqLmbNg5vXWLGUTXW1TWLEB Fin1O3HFmUvG1k4/nRx57LtdjkfawQrb3ojA0VACG8ArWexaT9BmsOVwA09+PvKf TiXSvSQHfE4o2HQof5nkcWG9EsScMk+kFXRHm8765/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aUaVWr /ko7ddVNxPFD1bTR6wfQAOJcjH7GqWe5r/vpE=; b=tAjNSkq9hLC+cdsayXms0w 7hPMCYJJqdVIlL1hAgK0AQFejRdbt+h1NONl4HoB1FgCjRvkZyyEPMVl11wSekH4 clgS44vUFDSxEMSsUD6ePy9KEMVmMuvjV4a8TRHldgDQUttxQolgPIBqq+CGq6xG RChLeiLDD5VgCAb9OWpPRzgihDjbUAQq+2NGMHuK/GJ1Eh/Fr7asqkH4u2RU1UK1 y9NzBRFEF0ob6dg+cjrOWf7fCAC+QFjSAuIp8qO20Qe9l27zVx+e5WlJr8r6XZMV vFCpdeh5qPgW0IFqEkLR/AVScm71j5eqsnHAYB9wEVaEEhvr4i53q5LSxWbRoj9g == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvd ettddtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvg ht X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Sep 2021 12:48:10 -0400 (EDT) Date: Tue, 28 Sep 2021 17:48:08 +0100 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: FreeBSD 13 source code using git clone fails Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <597b8064-8acb-4ac4-87ff-8c609a9bc602@www.fastmail.com> <4D7433D2-C1E3-4B89-BDB5-19BCBE2D88AB@kronometrix.org> <7AB539FF-9426-471A-A4B4-90558E82DE32@kronometrix.org> <4A6738B2-719A-43F2-855E-01DE00FBD32B@kronometrix.org> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0DoRTfiSQCgBYDWx" Content-Disposition: inline In-Reply-To: <4A6738B2-719A-43F2-855E-01DE00FBD32B@kronometrix.org> X-Rspamd-Queue-Id: 4HJln824rjz3wXT X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=TM1EQ0jv; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=tAjNSkq9; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.24) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; 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)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --0DoRTfiSQCgBYDWx Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2021 at 09:18:57PM +0300, Stefan Parvu wrote: >> It would probably be faster to do the git clone on a more capable >> machine and then use rsync+ssh (or an nfs mount) to copy everything it >> downloaded to the rpi. > >+1 > >thats right. takes forever. if you're using a microsd for /usr/src you'll get better performance [1] with a usb stick. if swap is needed, format the usb stick to have the swap. [1] microsd is slow media for writing. usb2 is faster, spinning rust might be even faster (it certainly is for rpi4/usb3 spinning rust) [2] anything fast writing small files needs this, or a mfs, on rpi[2,3] like git or svn. The problem never happens on rpi4/usb3-hd/100Mbit. --=20 J. --0DoRTfiSQCgBYDWx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmFTR0AACgkQs8o7QhFz NAWLwg//WZMesFOC6c9VSzZDmRRDdrr09XjH9UkiRDQYHeFFscB4Nn7aRYh8ZjDN bXAR/UMjg0VNdQFznK6C8UDC/cgwlidrzb4Im/a5k8Nt4i1DM2stRMwFu9IwpzQY Jh4Z/xpzcw/fig2CdHo1/OurR9acY8X2SXJjw/OIjjoPBzOKq7hKY9C8oqwX6DxZ L5p0GN2aN27CAWBaxYIYZOTYUxaKT7wUAOJTZSLyUFVO9NkT6uhQ/PDF+fACnJVV M52Twvlcvu4jc36f0RzIlccGPs3wJIoNCzwJd/N2gkS4qvihzeejRgUe5rNMRmxO jUfXtfNV89isRTLzkd3a0MRzHQbx5A2i+PtT8WCaNbq/RF8epuJ8vFgCdAY68arj 6OZhnob88c4WUPOcS00QvSaNLWzFUx0c4GHqtSbnLuEkd9ayRqXEVZLRushQCT7B WTMRM+fhMwmxcdzAYadLx+Ska2TAWbUTfaFD/yJTzVFhF2dLB0TN4/R487t90UUo 109FjTsKUVxeBI747V4gEG5wHrOlwcs5QBbL2y+OxJVyGO+6s+GwpDNGVHFqCI6B iprw2YznWWSZZqsBbLQaTrw9diEY+ZeAqmUoBHb02sn949HAoOxSGj1lmCWMZcIB yfZdqnngCFPTVpFuiFjmBuohQU8NSMbSE6Cab6+wpWdQc+ndqRc= =5kGB -----END PGP SIGNATURE----- --0DoRTfiSQCgBYDWx-- From nobody Tue Sep 28 16:59:24 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 661BC17E7146 for ; Tue, 28 Sep 2021 16:59:28 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HJm273H1Fz4RmM for ; Tue, 28 Sep 2021 16:59:27 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 993873201FE0 for ; Tue, 28 Sep 2021 12:59:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 28 Sep 2021 12:59:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=EJyLPomwR5QTzmZdX1o+MQoMce7 Y39ID5t0D0aiSPv4=; b=LHJrZJolmxJXJW7RpSUA1DAxu7zVOrc9s+hQ1bENkdy JcG1QGi3yOH5tH4H3OCW3ckuucKKqDUlknSPYlO1QskxC3P3J2yhjAyTssTAV6an tBemsXkcGeUdSsobyrP2ThdLjRKBYcCImMSBv/lrcgK0FDr/pkaMDpERv4nNYaTI LLKeAn37UJF0VU4QBjVyIyMprM2CWDc0IfF+rhaOG+QgNY7Y0oT5/TG8Z4XXlGKn oGmoVkMTntdnC+mPNm2r0MiR7D737Hy0wmOuSvZ07ZNLWqNky4saI0zk+oGyIrG4 W5B+0Jom9wBsi2ajQOryRWU0HZNcE0ZMmiXTkn6tBPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EJyLPo mwR5QTzmZdX1o+MQoMce7Y39ID5t0D0aiSPv4=; b=YvvJV53JOmVtY2cBYUweb/ +pBMRbb6ei/bJgOc895LIDkxwT03ojHo/S12rozBLcXttL48FPlDynGMG3QVPwjt TEqNS62s0ZKxZ5baN9Nmz5gVPnh1SdwOkuaUSnRCTgloLGgn/GHrVGNWSejpVJsI UF1hm6tftl42HvTqdjg17Y4PqtBPJwzhpn55PWzTm9Wjtfgd3PX+Y0nH/h5AwpBP nAwe/RFq/tFrd0Ht+5rlK+dxh4DF+UR4DJlcJrncEkX2+ENsHYrsW0YeRALbf9hK UYw6UlGHCG9SIZZsStojinpOh/jQqyVdFJKKt/QVyFKIrmCmaiSnprr4gD2963Aw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvd ettddtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvg ht X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Sep 2021 12:59:25 -0400 (EDT) Date: Tue, 28 Sep 2021 17:59:24 +0100 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: build a custom installation image for ARM RBPI Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f1rZHAfT7UHUdPPp" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HJm273H1Fz4RmM X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=LHJrZJol; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=YvvJV53J; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.24) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; 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)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --f1rZHAfT7UHUdPPp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2021 at 05:18:16PM +0300, Stefan Parvu wrote: >Hi, > > I have a RBPI 3B+ running FreeBSD 13 RELEASE. On top of this I have=20 > added some software and configurations we are developing for FreeBSD=20 > to capture data from different industrial devices. [snip] > Is there anything simpler, to take for example a 32GB FreeBSD 13=20 > vanilla + sfw installation and make it like a generic image for RBPI3B+? From a position of having one pi3 working as you want, I'd take the image there, insert into another machine (in my case a freebsd desktop) and dd the image to the desktop. Then mount the image with mdconfig, and change things which would be pertinent to another installation, like ip address, that sort of thing. Then copy the image to another microsd, and boot up the other pi3. --=20 J. --f1rZHAfT7UHUdPPp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmFTSeQACgkQs8o7QhFz NAWmyA//SfYX0Yc59IThjMsDy1HDQ3FqlAB8n7mH0M+awvoUu/xRPtOGmdWvnunc VmfcIK2H4wm3SaqANRbebxZHxlOfPIdRO9w1/9e1YlkLAWq6KJVWW1vXeg3EmIdc bUQDpkf8ddRw1XzEPBmGWTR31wzwtqSSIMZ6Y54Sc0517h28HV1ivWhpRM0ltB8t XcCz1YXGJ+xljRxGgVJoV8qjefzOf0ItkL50fTONZSj0dC3NsrMBfubae8Pf440U JishEDki5iyawPrwsbDhWjAYruOzJrl2+g92cix/T4qpN72up73XuKh2Ys7Lx+sK diw4BhCK6VKja8nqxG9hFLUzNIWxCsMKl6DKTBMDXeFYgjWui8CLK06vj6p+eKfM IeVPh6da6ig0iPAqtiCoMxs9Xii7+hB69OSPWSBnDPaRLpIsKtCAuzA5KCzEIkco 0NE/z86Vy1J+fkI04DKp6BXLHlZRwJAou3HvwxHscw+TUo5Esi7FsIzgziIhlkvE sFEYZsk8Udwvt2EOOIiMcZqqRP2Oma6D5a2kVl3wsZ4aCXW5uoh3+EBPWco7QWpM nHXx7hxIXvK0CFtoxafyVteuecAS4G/7jwv7ePMMuq5W+preADEEqGXbT9g/rDQy 6Au+g5m0iPmT2OytUC5Rxcb1+LzRQt9W44uN/n4Dlhu2YsCCVgs= =oz9v -----END PGP SIGNATURE----- --f1rZHAfT7UHUdPPp-- From nobody Tue Sep 28 19:08:09 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2498F17CB7BA; Tue, 28 Sep 2021 19:08:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HJptj00jjz4gnP; Tue, 28 Sep 2021 19:08:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632856093; 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: in-reply-to:in-reply-to:references:references; bh=wZLg+E6l+h1wpdB41WKf0iR2T/NaX5cnRq0KZ2MnNl4=; b=ISFbTzGw383wDbXwQ0IkBbXhz5py5xiQpnj6Bn9D0JCodG6OpPc95YjhFXbLirG2pLnZ8l fr0P50lo8Ys4nhB1YAs6xU/KeyR1HWCGqKeUAvbcHA6gnf2i5EIpH0/BVrQ5Dp/XK6ljfA Pft54cKm3SM71hrgth2c4R0iyFL7LYcJU+wcJjeWAx+VwjfjPJqG8IehB81MRR8e7gwJ4q /0Ra72+MKQdD6Rzc1MsMDq7TSoZ0tlW4sZTv661Ay63ey8jIOE/lsvC+0h7mE1d9X73+Jh 7eHht6mN9xPaxrxBenbkw125Kc9q8hWgWHYaJMkR97Z2jHTmj2xoaVJ3glu5QQ== Received: from mail.xzibition.com (unknown [127.0.1.132]) (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 freefall.freebsd.org (Postfix) with ESMTPS id B5575E718; Tue, 28 Sep 2021 19:08:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C629AF9A; Tue, 28 Sep 2021 12:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 65SQQPzdXWq8; Tue, 28 Sep 2021 12:08:09 -0700 (PDT) To: Mark Millard , Ian Lepore DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com F2184F89 Cc: freebsd-ports@freebsd.org, freebsd-current , Free BSD References: <187B69AF-9465-41DE-BFD0-A4AA0F7F9068@yahoo.com> <0FE65CAD-EDFF-4CE8-8750-BD4F6971CAA0@yahoo.com> From: Bryan Drewery Organization: FreeBSD Subject: Re: I get odd time reports from poudriere on armv7 system, under a (non-debug) main [so: 14] FreeBSD. Message-ID: <5fe9294c-aabb-57ff-73e0-d9ad2d8efcf5@FreeBSD.org> Date: Tue, 28 Sep 2021 12:08:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <0FE65CAD-EDFF-4CE8-8750-BD4F6971CAA0@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4PUY2Owcn9dc6SBJCFPer7297t2JnOLNg" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632856093; 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: in-reply-to:in-reply-to:references:references; bh=wZLg+E6l+h1wpdB41WKf0iR2T/NaX5cnRq0KZ2MnNl4=; b=ZaAog1V3dq6omVLasewmf5iWGG0gSOd/i7KOg9jD9+APzEfHe7Bd0EhsKVqzly63AAecXk 6xT+PL+8YzL9stbxBlELIGfp3mdki93cuSa4a6yDVXSy91szR1ZvjuORtpma9nBBfz+2C7 2X1lS/CR/oxQrmsmRz6OaR23LG8LtHpp6zeku8t5D/ZApo9V3CuNxFvEMJdCVVwezFlZ3J 6m+oG5CvUBUcc3FcAtJ0l2LlbbWuyXjSmKZ3b0Yyty5U+TdNV7waMiZAx6Bt2KLMpw71IT zDnruaOftlnzH5mdexeQd+RYvA/szqfaW560kJSNYz+2RylLKm2TlWPCpDPRBA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1632856093; a=rsa-sha256; cv=none; b=jtl0yIsghlmwDetHR2NYIYdgB5Y55m0iJ21HW0+qqXxc4zmwa34qoVYocifitNUbl4qOBA WrIzavU4SR9kOpA79GvHxD5JosJ+43mNrP+Z0kZoFV9ArpeRYGRTZcIn3glmKc2yXf6PkR Zfd8ax5IoXfxKxLd6yO7v6bdd8kf3qcZQdLW6cG9lFvzpPpv+w6M5OfstJglZk5qPw0w1D 7M/22ERoi8z8jXEuqS15psNVOnwyeQgiKEIj8cd8tmOqeM7A2ZX1BEjDiJG0dpGkIboRxq RndZQxZVLNQngkW9MZ65ILh9V4/EgQ9hKuyNlgSeM2BjFwk8Rk/BLWjs9SEnNQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4PUY2Owcn9dc6SBJCFPer7297t2JnOLNg Content-Type: multipart/mixed; boundary="s2lqJLBhwxirULgNtF0GmsE6sRTJO2DTm"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , Ian Lepore Cc: freebsd-ports@freebsd.org, freebsd-current , Free BSD Message-ID: <5fe9294c-aabb-57ff-73e0-d9ad2d8efcf5@FreeBSD.org> Subject: Re: I get odd time reports from poudriere on armv7 system, under a (non-debug) main [so: 14] FreeBSD. References: <187B69AF-9465-41DE-BFD0-A4AA0F7F9068@yahoo.com> <0FE65CAD-EDFF-4CE8-8750-BD4F6971CAA0@yahoo.com> In-Reply-To: <0FE65CAD-EDFF-4CE8-8750-BD4F6971CAA0@yahoo.com> --s2lqJLBhwxirULgNtF0GmsE6sRTJO2DTm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/26/2021 11:05 PM, Mark Millard wrote: > On 2021-Sep-26, at 10:02, Ian Lepore wrote: >=20 >> On Sun, 2021-09-26 at 02:27 -0700, Mark Millard via freebsd-current >> wrote: >>> On 2021-Sep-25, at 23:25, Mark Millard wrote: >>> >>> >>> [...] >>> if (argc =3D=3D 3 && strcmp(argv[2], "-nsec") =3D=3D 0) >>> printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec); >> >> There are two problems with this, both the seconds and nanos are >> printed incorrectly. The correct incantation would be >> >> printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec); >> >=20 > Thanks Ian for looking into more than I did last night. >=20 > Based on the following (up to possible e-mail white space issues), > poudriere-devel seems t be working for reporting times: >=20 > # more /usr/ports/ports-mgmt/poudriere-devel/files/patch-clock=20 > --- src/libexec/poudriere/clock/clock.c.orig 2021-09-26 22:24:54.735= 485000 -0700 > +++ src/libexec/poudriere/clock/clock.c 2021-09-26 11:46:12.076362000 -= 0700 > @@ -24,6 +24,7 @@ > * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > =20 > +#include > #include > #include > #include > @@ -71,8 +72,8 @@ > } else > usage(); > if (argc =3D=3D 3 && strcmp(argv[2], "-nsec") =3D=3D 0) > - printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec); > + printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec);= > else > - printf("%ld\n", ts.tv_sec); > + printf("%jd\n", (intmax_t)ts.tv_sec); > return (EXIT_SUCCESS); > } Thanks, I've committed it in my local git. Will push out later. --=20 Bryan Drewery --s2lqJLBhwxirULgNtF0GmsE6sRTJO2DTm-- --4PUY2Owcn9dc6SBJCFPer7297t2JnOLNg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAmFTaBkFAwAAAAAACgkQNddxu25Gl8/W SwgAjhDhlXXll8wRF30GUWY7TZYYW8Gg079tNVnPksEVKk+XxI0FfzQSpYH+vA2igpFVLEiP2tvN DJHzJwiwZiKC32IsmkHledL79uU45jL/6jlGRbM061p+w0aRpKcYRBTmSNjZJXrGoVAdZBWOqyH1 bNPVtA2Yn0Zs3VhTBof0SJHsAEh/OqtVj3b5dMc6aB7RYvbYlcImacg3oktUp4zKgWl1MSw7/ZBF MU87AKZqtPJFVo6d9wVFI6gdbod0ODmorepZxABn2NRss1NLBVY1pRoj8OLi89FuSc36qHQwmprK wtmroOyJSXD5WsQxsjuwt+4bLL1sNjNeChh8R3qsvQ== =VXtP -----END PGP SIGNATURE----- --4PUY2Owcn9dc6SBJCFPer7297t2JnOLNg-- From nobody Wed Sep 29 17:07:25 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4710017D1D0C for ; Wed, 29 Sep 2021 17:07:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKN8x1cJnz4X9y; Wed, 29 Sep 2021 17:07:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B64402B72A; Wed, 29 Sep 2021 17:07:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <20210920190213.5839f18816daf1f6e4289b94@bidouilliste.com> Subject: Re: rock64 verbose boot hangs Message-ID: <4d24bb8a-0ffe-9073-7863-e83025ffc4fa@FreeBSD.org> Date: Wed, 29 Sep 2021 20:07:25 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 23/09/2021 20:46, Andriy Gapon wrote: > On 20/09/2021 20:02, Emmanuel Vadot wrote: >> >>   Hi Andriy, >> >> On Sat, 18 Sep 2021 15:58:00 +0300 >> Andriy Gapon wrote: >> >>> >>> Normal boot works every time, but with boot_verbose="YES" it hanged on all >>> attempts so far. >>> >>> Last messages on the console: >>> cpulist0: on ofwbus0 >>> cpu0: on cpulist0 >>> cpu0: Nominal frequency 600Mhz >>> cpufreq_dt0: on cpu0 >>> cpufreq_dt0: 408.000 Mhz (950000 uV) >>> cpufreq_dt0: 600.000 Mhz (950000 uV) >>> cpufreq_dt0: 816.000 Mhz (1000000 uV) >>> cpufreq_dt0: 1008.000 Mhz (1100000 uV) >>> cpufreq_dt0: 1200.000 Mhz (1225000 uV) >>> cpufreq_dt0: 1296.000 Mhz (1300000 uV) >>> cpu1: on cpulist0 >>> cpu1: Nominal frequency 600Mhz >>> cpufreq_dt1: on cpu1 >>> >>> The kernel is totally unresponsive after that. >> >>   Can't reproduce here, I'm running 548a706608d with latest DTB and >> latest u-boot/atf >> >>> Any suggestions on how to debug this? >> >>   Not really sure how to start, that seems weird that the kernel will >> hang at the cpufreq attach but maybe try modifying the DTB to remove >> this node ? >>   Also did that happens with my recent commit on clock or was this the >> same before ? An update relevant to the question above. Actually, after upgrading to a version that includes your clock changes the problem went away! I don't know what to make out of this fact, but it looks like the problem was a clock plus timing issue. > Thank you and every one else who responded with information and suggestions. > > Some extra details. > I've been having this problem since I've got this board 9 months ago. > It's been through several FreeBSD and U-Boot and stuff in the ESP partition > upgrades.  And the problem was always present. > > Now I've done more extensive testing with a couple of dozen reboots in a row and > some additional debug prints (like, for example, DEBUG in subr_bus.c). > > I actually see several variations of the problem. > Sometimes it's a hang, but sometimes it's a crash. > A hang can happen in different places and a crash can happen in different places > too. > Some crashes happens during AP startup and the information I am getting is not > very usable. > Some crashes happen during a driver probing when the bus code searches the hints > memory space.  Those crashes look like a memory corruption happens there at random. > > Given those variations plus some other differences that I have comparing to > other Rock64 users (like needing special setup for eMMC and for the watchdog), I > am inclined to think that the board I have has something special either in the > hardware (like a different configuration via some fuses) or in the BootROM. > Even though the PCB has the standard markings. > > And I would not be surprised about that (that it could be a customized > production) as I got my Rock64-s via a special / unusual deal on Amazon. > Iconikal and Recon Sentinal are keywords to search for, for those interested. > Some news articles from the time: > https://liliputing.com/2020/09/this-10-single-board-computer-is-faster-than-a-raspberry-pi-3.html > > https://www.tomshardware.com/news/raspberry-pi-sized-iconikal-rockchip-sbc-only-dollar8-on-amazon > > > So, in the end, I still do not know what causes the verbose boot to hang / crash. > Maybe there is some (not fully working) watchdog that gets armed and disarmed by > some hardware accesses and the verbose boot is too slow to complete in time. > > Here is a small subset of panics and hangs that I saw: > https://people.freebsd.org/~avg/rock64-verbose-boot-panic.txt > -- Andriy Gapon From nobody Wed Sep 29 17:27:53 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C29C17D3FE8 for ; Wed, 29 Sep 2021 17:27:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKNcW6djCz4ZH8; Wed, 29 Sep 2021 17:27:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1632936474; 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=GzqLcKg7M1FbWoUYpdA8+aZHh2yIq+H9mMZQ3yw/N3k=; b=PCGUTBVlByZ2g2WsBIyNcEK8ewzwUwSY7yDWPrjuMAGDdmjE3JHSkY7qLGUa1Zg7ZFD6D2 BqH0Qfi7epGApG9iY1BtijglykJ26Tg014aJndzh9tpXklqAYTZ6zSSDJxhoAkPffsTTvO ND+4XjbuQx7Rxs80UTekqdIVYec+peM= Received: from amy (lfbn-idf2-1-644-191.w86-247.abo.wanadoo.fr [86.247.100.191]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 9cbc1c38 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 29 Sep 2021 17:27:53 +0000 (UTC) Date: Wed, 29 Sep 2021 19:27:53 +0200 From: Emmanuel Vadot To: Andriy Gapon Cc: "freebsd-arm@freebsd.org" Subject: Re: rock64 verbose boot hangs Message-Id: <20210929192753.449ad9a061366ea5e19d735e@bidouilliste.com> In-Reply-To: <4d24bb8a-0ffe-9073-7863-e83025ffc4fa@FreeBSD.org> References: <20210920190213.5839f18816daf1f6e4289b94@bidouilliste.com> <4d24bb8a-0ffe-9073-7863-e83025ffc4fa@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HKNcW6djCz4ZH8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 29 Sep 2021 20:07:25 +0300 Andriy Gapon wrote: > On 23/09/2021 20:46, Andriy Gapon wrote: > > On 20/09/2021 20:02, Emmanuel Vadot wrote: > >> > >> =A0 Hi Andriy, > >> > >> On Sat, 18 Sep 2021 15:58:00 +0300 > >> Andriy Gapon wrote: > >> > >>> > >>> Normal boot works every time, but with boot_verbose=3D"YES" it hanged= on all > >>> attempts so far. > >>> > >>> Last messages on the console: > >>> cpulist0: on ofwbus0 > >>> cpu0: on cpulist0 > >>> cpu0: Nominal frequency 600Mhz > >>> cpufreq_dt0: on cpu0 > >>> cpufreq_dt0: 408.000 Mhz (950000 uV) > >>> cpufreq_dt0: 600.000 Mhz (950000 uV) > >>> cpufreq_dt0: 816.000 Mhz (1000000 uV) > >>> cpufreq_dt0: 1008.000 Mhz (1100000 uV) > >>> cpufreq_dt0: 1200.000 Mhz (1225000 uV) > >>> cpufreq_dt0: 1296.000 Mhz (1300000 uV) > >>> cpu1: on cpulist0 > >>> cpu1: Nominal frequency 600Mhz > >>> cpufreq_dt1: on cpu1 > >>> > >>> The kernel is totally unresponsive after that. > >> > >> =A0 Can't reproduce here, I'm running 548a706608d with latest DTB and > >> latest u-boot/atf > >> > >>> Any suggestions on how to debug this? > >> > >> =A0 Not really sure how to start, that seems weird that the kernel will > >> hang at the cpufreq attach but maybe try modifying the DTB to remove > >> this node ? > >> =A0 Also did that happens with my recent commit on clock or was this t= he > >> same before ? >=20 > An update relevant to the question above. > Actually, after upgrading to a version that includes your clock changes t= he=20 > problem went away! > I don't know what to make out of this fact, but it looks like the problem= was a=20 > clock plus timing issue. I'm not that surprised. Before my clock changes netboot always failed in a really weird way where AP couldn't be started and the serial output was switching chars around (Like "cuolt'd rsart AP"). So I'm glad that it fixed your problems because I had really no idea how to debug that :P > > Thank you and every one else who responded with information and suggest= ions. > >=20 > > Some extra details. > > I've been having this problem since I've got this board 9 months ago. > > It's been through several FreeBSD and U-Boot and stuff in the ESP parti= tion=20 > > upgrades.=A0 And the problem was always present. > >=20 > > Now I've done more extensive testing with a couple of dozen reboots in = a row and=20 > > some additional debug prints (like, for example, DEBUG in subr_bus.c). > >=20 > > I actually see several variations of the problem. > > Sometimes it's a hang, but sometimes it's a crash. > > A hang can happen in different places and a crash can happen in differe= nt places=20 > > too. > > Some crashes happens during AP startup and the information I am getting= is not=20 > > very usable. > > Some crashes happen during a driver probing when the bus code searches = the hints=20 > > memory space.=A0 Those crashes look like a memory corruption happens th= ere at random. > >=20 > > Given those variations plus some other differences that I have comparin= g to=20 > > other Rock64 users (like needing special setup for eMMC and for the wat= chdog), I=20 > > am inclined to think that the board I have has something special either= in the=20 > > hardware (like a different configuration via some fuses) or in the Boot= ROM. > > Even though the PCB has the standard markings. > >=20 > > And I would not be surprised about that (that it could be a customized= =20 > > production) as I got my Rock64-s via a special / unusual deal on Amazon= .=20 > > Iconikal and Recon Sentinal are keywords to search for, for those inter= ested. > > Some news articles from the time: > > https://liliputing.com/2020/09/this-10-single-board-computer-is-faster-= than-a-raspberry-pi-3.html=20 > >=20 > > https://www.tomshardware.com/news/raspberry-pi-sized-iconikal-rockchip-= sbc-only-dollar8-on-amazon=20 > >=20 > >=20 > > So, in the end, I still do not know what causes the verbose boot to han= g / crash. > > Maybe there is some (not fully working) watchdog that gets armed and di= sarmed by=20 > > some hardware accesses and the verbose boot is too slow to complete in = time. > >=20 > > Here is a small subset of panics and hangs that I saw: > > https://people.freebsd.org/~avg/rock64-verbose-boot-panic.txt > >=20 >=20 >=20 > --=20 > Andriy Gapon >=20 --=20 Emmanuel Vadot From nobody Thu Sep 30 16:28:09 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E4D0217D5899 for ; Thu, 30 Sep 2021 16:28:34 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKzFZ61sLz4SVv; Thu, 30 Sep 2021 16:28:34 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from freebsd2.freebsd.lan (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 6171C7827; Thu, 30 Sep 2021 16:28:34 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Subject: Re: Pinebook pro IOMMU enabled crashes From: Jesper Schmitz Mouridsen To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org References: <5434fca8-4f88-2e76-6977-2de150536915@FreeBSD.org> <20210923091921.563b4621a1801975ad52adc7@bidouilliste.com> <307185e1-a02b-9a1f-155b-e5e7bcac818c@FreeBSD.org> Message-ID: <6d578a7e-bb0a-ac5c-96ce-160aeeb74cce@FreeBSD.org> Date: Thu, 30 Sep 2021 18:28:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <307185e1-a02b-9a1f-155b-e5e7bcac818c@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 23.09.2021 19.58, Jesper Schmitz Mouridsen wrote: > Hi > > I just rebuild a generic arm64 with only this change: > > diff --git a/sys/arm64/conf/GENERIC b/sys/arm64/conf/GENERIC > index c716183aae61..7a609db412ca 100644 > --- a/sys/arm64/conf/GENERIC > +++ b/sys/arm64/conf/GENERIC > @@ -19,7 +19,7 @@ > >  cpu            ARM64 >  ident          GENERIC > - > +options                IOMMU >  include                "std.arm64" >  include                "std.dev" > > FreeBSD 14.0-CURRENT #6 main-n249584-fd69939e79a6-dirty > > It does not happen without the nvme attached. > > pcib0: mem > 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 > pci0: on pcib0 > pcib1: at device 0.0 on pci0 > pcib0: failed to reserve resource for pcib1 > pcib1: failed to allocate initial memory window: 0-0xfffff > pci1: on pcib1 > nvme0: at device 0.0 on pci1 > Fatal data abort: >   x0:                0 >   x1:             1000 >   x2:            10040 >   x3:             2000 >   x4:                1 >   x5: ffff00009a7e0168 >   x6: 1400000000000000 >   x7:   10000000000000 >   x8:             1168 >   x9:                1 >  x10:                0 >  x11: ffff000000e8c8c0 >  x12: ffff000000e8c840 >  x13:                1 >  x14:            10000 >  x15:                1 >  x16:            10000 >  x17: ffff000000e8c85c >  x18: ffff000001064180 >  x19: ffff000001064248 >  x20:                0 >  x21: ffff00009a7df000 >  x22: ffffa0000102ea00 >  x23: ffffa00000bb6b80 >  x24: ffffa00001086200 >  x25: ffff000000aa8478 >  x26: ffffa00001086300 >  x27: ffff000000dda000 >  x28:                7 >  x29: ffff000001064190 >   sp: ffff000001064180 >   lr: ffff00000075f20c >  elr: ffff00000078a654 > spsr:         200000c5 >  far:                0 >  esr:         96000004 > panic: vm_fault failed: ffff00000078a654 error 1 > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x184 > panic() at panic+0x44 > data_abort() at data_abort+0x23c > handle_el1h_sync() at handle_el1h_sync+0x78 > --- exception, esr 0x96000004 > iommu_map_msi() at iommu_map_msi+0x20 > gicv3_iommu_init() at gicv3_iommu_init+0x4c > intr_alloc_msix() at intr_alloc_msix+0x13c > rk_pcie_alloc_msix() at rk_pcie_alloc_msix+0xfc > pci_alloc_msix_method() at pci_alloc_msix_method+0x1a8 > nvme_pci_attach() at nvme_pci_attach+0x378 > device_attach() at device_attach+0x400 > device_probe_and_attach() at device_probe_and_attach+0x7c > bus_generic_attach() at bus_generic_attach+0x18 > pci_attach() at pci_attach+0xe8 > device_attach() at device_attach+0x400 > device_probe_and_attach() at device_probe_and_attach+0x7c > bus_generic_attach() at bus_generic_attach+0x18 > device_attach() at device_attach+0x400 > device_probe_and_attach() at device_probe_and_attach+0x7c > bus_generic_attach() at bus_generic_attach+0x18 > pci_attach() at pci_attach+0xe8 > device_attach() at device_attach+0x400 > device_probe_and_attach() at device_probe_and_attach+0x7c > bus_generic_attach() at bus_generic_attach+0x18 > rk_pcie_attach() at rk_pcie_attach+0x14cc > device_attach() at device_attach+0x400 > device_probe_and_attach() at device_probe_and_attach+0x7c > bus_generic_new_pass() at bus_generic_new_pass+0xf8 > bus_generic_new_pass() at bus_generic_new_pass+0xa8 > bus_generic_new_pass() at bus_generic_new_pass+0xa8 > bus_set_pass() at bus_set_pass+0x4c > mi_startup() at mi_startup+0x12c > virtdone() at virtdone+0x6c > > /jsm > > > On 23.09.2021 09.19, Emmanuel Vadot wrote: >> On Sat, 18 Sep 2021 13:15:45 +0200 >> Jesper Schmitz Mouridsen wrote: >> >>> Hi >>> >>> Perhaps this one >>> https://www.mail-archive.com/svn-src-head@freebsd.org/msg126068.html is >>> giving troubles? >>> >>> main-n249225-f673cc5edac3-dirty >>> nvme0: at device 0.0 on pci1 >>> Fatal data abort: >>>     x0:                0 >>>     x1:             1000 >>>     x2:            10040 >>>     x3:             2000 >>>     x4:                1 >>>     x5: ffff00009a7a0168 >>>     x6: 1d00000000000000 >>>     x7:   10000000000000 >>>     x8:             1168 >>>     x9:                1 >>>    x10:                0 >>>    x11: ffff000000f35140 >>>    x12: ffff000000f350c0 >>>    x13:                1 >>>    x14:            10000 >>>    x15:                1 >>>    x16:            10000 >>>    x17: ffff000000f350dc >>>    x18: ffff00000110d180 >>>    x19: ffff00000110d248 >>>    x20:                0 >>>    x21: ffff00009a79f000 >>>    x22: ffffa000010b0a00 >>>    x23: ffffa000010a2880 >>>    x24: ffffa0000116da00 >>>    x25: ffff000000b4fd78 >>>    x26: ffffa0000116db00 >>>    x27: ffff000000e83000 >>>    x28:                7 >>>    x29: ffff00000110d190 >>>     sp: ffff00000110d180 >>>     lr: ffff00000077520c >>>    elr: ffff0000007a03ac >>> spsr:         200000c5 >>>    far:                0 >>>    esr:         96000004 >>> panic: vm_fault failed: ffff0000007a03ac error 1 >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> vpanic() at vpanic+0x184 >>> panic() at panic+0x44 >>> data_abort() at data_abort+0x23c >>> handle_el1h_sync() at handle_el1h_sync+0x78 >>> --- exception, esr 0x96000004 >>> iommu_map_msi() at iommu_map_msi+0x20 >>> gicv3_iommu_init() at gicv3_iommu_init+0x4c >>> intr_alloc_msix() at intr_alloc_msix+0x13c >>> rk_pcie_alloc_msix() at rk_pcie_alloc_msix+0xfc >>> pci_alloc_msix_method() at pci_alloc_msix_method+0x1a8 >>> nvme_pci_attach() at nvme_pci_attach+0x378 >>> device_attach() at device_attach+0x400 >>> device_probe_and_attach() at device_probe_and_attach+0x7c >>> bus_generic_attach() at bus_generic_attach+0x18 >>> pci_attach() at pci_attach+0xe8 >>> device_attach() at device_attach+0x400 >>> device_probe_and_attach() at device_probe_and_attach+0x7c >>> bus_generic_attach() at bus_generic_attach+0x18 >>> device_attach() at device_attach+0x400 >>> device_probe_and_attach() at device_probe_and_attach+0x7c >>> bus_generic_attach() at bus_generic_attach+0x18 >>> pci_attach() at pci_attach+0xe8 >>> device_attach() at device_attach+0x400 >>> device_probe_and_attach() at device_probe_and_attach+0x7c >>> bus_generic_attach() at bus_generic_attach+0x18 >>> rk_pcie_attach() at rk_pcie_attach+0x14cc >>> device_attach() at device_attach+0x400 >>> device_probe_and_attach() at device_probe_and_attach+0x7c >>> bus_generic_new_pass() at bus_generic_new_pass+0xf8 >>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>> bus_set_pass() at bus_set_pass+0x4c >>> mi_startup() at mi_startup+0x12c >>> virtdone() at virtdone+0x6c >>> >>   That's an old commit. Did you see this panic only recently or ? >> > Even on stable/13-n247374-9faebc1e664d-dirty I get the same backtrace when IOMMU is enabled and the nvme is attached. pcib1: at device 0.0 on pci0 pcib0: failed to reserve resource for pcib1 pcib1: failed to allocate initial memory window: 0-0xfffff pci1: on pcib1 nvme0: at device 0.0 on pci1 Fatal data abort: x0: 0 x1: 1000 x2: 10040 x3: 2000 x4: 1 x5: ffff00009a99e160 x6: 1400000000000000 x7: 10000000000000 x8: 1160 x9: ffff000000cd7cc0 x10: 0 x11: ffff000000d89540 x12: ffff000000d894c0 x13: 1 x14: 10000 x15: 1 x16: 10000 x17: 0 x18: ffff000000f5c250 x19: ffff000000f5c318 x20: 0 x21: ffff00009a99d000 x22: ffffa00000f06200 x23: ffffa00000f49700 x24: ffffa00000f8f500 x25: ffff0000009b85f8 x26: ffffa00000f8f600 x27: ffff000000cd7000 x28: 7 x29: ffff000000f5c260 sp: ffff000000f5c250 lr: ffff0000006bf3dc elr: ffff0000006e15d0 spsr: 600001c5 far: 0 esr: 96000004 panic: vm_fault failed: ffff0000006e15d0 cpuid = 0 time = 1 KDB: stack backtrace: #0 0xffff00000047c304 at kdb_backtrace+0x60 #1 0xffff000000437fd8 at vpanic+0x184 #2 0xffff000000437e50 at panic+0x44 #3 0xffff0000006d692c at data_abort+0x204 #4 0xffff0000006bb874 at handle_el1h_sync+0x74 #5 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c #6 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c #7 0xffff0000006b1940 at intr_alloc_msix+0x110 #8 0xffff0000007860c0 at rk_pcie_alloc_msix+0xfc #9 0xffff000000219bbc at pci_alloc_msix_method+0x1a8 #10 0xffff00000020ba64 at nvme_pci_attach+0x378 #11 0xffff00000046bd80 at device_attach+0x400 #12 0xffff00000046d14c at bus_generic_attach+0x4c #13 0xffff000000221f30 at pci_attach+0xe0 #14 0xffff00000046bd80 at device_attach+0x400 #15 0xffff00000046d14c at bus_generic_attach+0x4c #16 0xffff00000046bd80 at device_attach+0x400 #17 0xffff00000046d14c at bus_generic_attach+0x4c Uptime: 1s From nobody Thu Sep 30 16:39:43 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2749D17D6A66 for ; Thu, 30 Sep 2021 16:39:45 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKzVT0RSQz4Tgq; Thu, 30 Sep 2021 16:39:45 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from freebsd2.freebsd.lan (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 91036782D; Thu, 30 Sep 2021 16:39:44 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Subject: Re: Pinebook pro IOMMU enabled crashes From: Jesper Schmitz Mouridsen To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org References: <5434fca8-4f88-2e76-6977-2de150536915@FreeBSD.org> <20210923091921.563b4621a1801975ad52adc7@bidouilliste.com> <307185e1-a02b-9a1f-155b-e5e7bcac818c@FreeBSD.org> <6d578a7e-bb0a-ac5c-96ce-160aeeb74cce@FreeBSD.org> Message-ID: <5e537303-0807-7902-c90f-f9fab5120548@FreeBSD.org> Date: Thu, 30 Sep 2021 18:39:43 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <6d578a7e-bb0a-ac5c-96ce-160aeeb74cce@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 30.09.2021 18.28, Jesper Schmitz Mouridsen wrote: > On 23.09.2021 19.58, Jesper Schmitz Mouridsen wrote: >> Hi >> >> I just rebuild a generic arm64 with only this change: >> >> diff --git a/sys/arm64/conf/GENERIC b/sys/arm64/conf/GENERIC >> index c716183aae61..7a609db412ca 100644 >> --- a/sys/arm64/conf/GENERIC >> +++ b/sys/arm64/conf/GENERIC >> @@ -19,7 +19,7 @@ >> >>   cpu            ARM64 >>   ident          GENERIC >> - >> +options                IOMMU >>   include                "std.arm64" >>   include                "std.dev" >> >> FreeBSD 14.0-CURRENT #6 main-n249584-fd69939e79a6-dirty >> >> It does not happen without the nvme attached. >> >> pcib0: mem >> 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 >> pci0: on pcib0 >> pcib1: at device 0.0 on pci0 >> pcib0: failed to reserve resource for pcib1 >> pcib1: failed to allocate initial memory window: 0-0xfffff >> pci1: on pcib1 >> nvme0: at device 0.0 on pci1 >> Fatal data abort: >>    x0:                0 >>    x1:             1000 >>    x2:            10040 >>    x3:             2000 >>    x4:                1 >>    x5: ffff00009a7e0168 >>    x6: 1400000000000000 >>    x7:   10000000000000 >>    x8:             1168 >>    x9:                1 >>   x10:                0 >>   x11: ffff000000e8c8c0 >>   x12: ffff000000e8c840 >>   x13:                1 >>   x14:            10000 >>   x15:                1 >>   x16:            10000 >>   x17: ffff000000e8c85c >>   x18: ffff000001064180 >>   x19: ffff000001064248 >>   x20:                0 >>   x21: ffff00009a7df000 >>   x22: ffffa0000102ea00 >>   x23: ffffa00000bb6b80 >>   x24: ffffa00001086200 >>   x25: ffff000000aa8478 >>   x26: ffffa00001086300 >>   x27: ffff000000dda000 >>   x28:                7 >>   x29: ffff000001064190 >>    sp: ffff000001064180 >>    lr: ffff00000075f20c >>   elr: ffff00000078a654 >> spsr:         200000c5 >>   far:                0 >>   esr:         96000004 >> panic: vm_fault failed: ffff00000078a654 error 1 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> vpanic() at vpanic+0x184 >> panic() at panic+0x44 >> data_abort() at data_abort+0x23c >> handle_el1h_sync() at handle_el1h_sync+0x78 >> --- exception, esr 0x96000004 >> iommu_map_msi() at iommu_map_msi+0x20 >> gicv3_iommu_init() at gicv3_iommu_init+0x4c >> intr_alloc_msix() at intr_alloc_msix+0x13c >> rk_pcie_alloc_msix() at rk_pcie_alloc_msix+0xfc >> pci_alloc_msix_method() at pci_alloc_msix_method+0x1a8 >> nvme_pci_attach() at nvme_pci_attach+0x378 >> device_attach() at device_attach+0x400 >> device_probe_and_attach() at device_probe_and_attach+0x7c >> bus_generic_attach() at bus_generic_attach+0x18 >> pci_attach() at pci_attach+0xe8 >> device_attach() at device_attach+0x400 >> device_probe_and_attach() at device_probe_and_attach+0x7c >> bus_generic_attach() at bus_generic_attach+0x18 >> device_attach() at device_attach+0x400 >> device_probe_and_attach() at device_probe_and_attach+0x7c >> bus_generic_attach() at bus_generic_attach+0x18 >> pci_attach() at pci_attach+0xe8 >> device_attach() at device_attach+0x400 >> device_probe_and_attach() at device_probe_and_attach+0x7c >> bus_generic_attach() at bus_generic_attach+0x18 >> rk_pcie_attach() at rk_pcie_attach+0x14cc >> device_attach() at device_attach+0x400 >> device_probe_and_attach() at device_probe_and_attach+0x7c >> bus_generic_new_pass() at bus_generic_new_pass+0xf8 >> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >> bus_set_pass() at bus_set_pass+0x4c >> mi_startup() at mi_startup+0x12c >> virtdone() at virtdone+0x6c >> >> /jsm >> >> >> On 23.09.2021 09.19, Emmanuel Vadot wrote: >>> On Sat, 18 Sep 2021 13:15:45 +0200 >>> Jesper Schmitz Mouridsen wrote: >>> >>>> Hi >>>> >>>> Perhaps this one >>>> https://www.mail-archive.com/svn-src-head@freebsd.org/msg126068.html is >>>> giving troubles? >>>> >>>> main-n249225-f673cc5edac3-dirty >>>> nvme0: at device 0.0 on pci1 >>>> Fatal data abort: >>>>     x0:                0 >>>>     x1:             1000 >>>>     x2:            10040 >>>>     x3:             2000 >>>>     x4:                1 >>>>     x5: ffff00009a7a0168 >>>>     x6: 1d00000000000000 >>>>     x7:   10000000000000 >>>>     x8:             1168 >>>>     x9:                1 >>>>    x10:                0 >>>>    x11: ffff000000f35140 >>>>    x12: ffff000000f350c0 >>>>    x13:                1 >>>>    x14:            10000 >>>>    x15:                1 >>>>    x16:            10000 >>>>    x17: ffff000000f350dc >>>>    x18: ffff00000110d180 >>>>    x19: ffff00000110d248 >>>>    x20:                0 >>>>    x21: ffff00009a79f000 >>>>    x22: ffffa000010b0a00 >>>>    x23: ffffa000010a2880 >>>>    x24: ffffa0000116da00 >>>>    x25: ffff000000b4fd78 >>>>    x26: ffffa0000116db00 >>>>    x27: ffff000000e83000 >>>>    x28:                7 >>>>    x29: ffff00000110d190 >>>>     sp: ffff00000110d180 >>>>     lr: ffff00000077520c >>>>    elr: ffff0000007a03ac >>>> spsr:         200000c5 >>>>    far:                0 >>>>    esr:         96000004 >>>> panic: vm_fault failed: ffff0000007a03ac error 1 >>>> cpuid = 0 >>>> time = 1 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>> vpanic() at vpanic+0x184 >>>> panic() at panic+0x44 >>>> data_abort() at data_abort+0x23c >>>> handle_el1h_sync() at handle_el1h_sync+0x78 >>>> --- exception, esr 0x96000004 >>>> iommu_map_msi() at iommu_map_msi+0x20 >>>> gicv3_iommu_init() at gicv3_iommu_init+0x4c >>>> intr_alloc_msix() at intr_alloc_msix+0x13c >>>> rk_pcie_alloc_msix() at rk_pcie_alloc_msix+0xfc >>>> pci_alloc_msix_method() at pci_alloc_msix_method+0x1a8 >>>> nvme_pci_attach() at nvme_pci_attach+0x378 >>>> device_attach() at device_attach+0x400 >>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>> bus_generic_attach() at bus_generic_attach+0x18 >>>> pci_attach() at pci_attach+0xe8 >>>> device_attach() at device_attach+0x400 >>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>> bus_generic_attach() at bus_generic_attach+0x18 >>>> device_attach() at device_attach+0x400 >>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>> bus_generic_attach() at bus_generic_attach+0x18 >>>> pci_attach() at pci_attach+0xe8 >>>> device_attach() at device_attach+0x400 >>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>> bus_generic_attach() at bus_generic_attach+0x18 >>>> rk_pcie_attach() at rk_pcie_attach+0x14cc >>>> device_attach() at device_attach+0x400 >>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>> bus_generic_new_pass() at bus_generic_new_pass+0xf8 >>>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>>> bus_set_pass() at bus_set_pass+0x4c >>>> mi_startup() at mi_startup+0x12c >>>> virtdone() at virtdone+0x6c >>>> >>>   That's an old commit. Did you see this panic only recently or ? >>> >> > > > Even on stable/13-n247374-9faebc1e664d-dirty > > I get the same backtrace when IOMMU is enabled and the nvme is attached. > > pcib1: at device 0.0 on pci0 > pcib0: failed to reserve resource for pcib1 > pcib1: failed to allocate initial memory window: 0-0xfffff > pci1: on pcib1 > nvme0: at device 0.0 on pci1 > Fatal data abort: >   x0:                0 >   x1:             1000 >   x2:            10040 >   x3:             2000 >   x4:                1 >   x5: ffff00009a99e160 >   x6: 1400000000000000 >   x7:   10000000000000 >   x8:             1160 >   x9: ffff000000cd7cc0 >  x10:                0 >  x11: ffff000000d89540 >  x12: ffff000000d894c0 >  x13:                1 >  x14:            10000 >  x15:                1 >  x16:            10000 >  x17:                0 >  x18: ffff000000f5c250 >  x19: ffff000000f5c318 >  x20:                0 >  x21: ffff00009a99d000 >  x22: ffffa00000f06200 >  x23: ffffa00000f49700 >  x24: ffffa00000f8f500 >  x25: ffff0000009b85f8 >  x26: ffffa00000f8f600 >  x27: ffff000000cd7000 >  x28:                7 >  x29: ffff000000f5c260 >   sp: ffff000000f5c250 >   lr: ffff0000006bf3dc >  elr: ffff0000006e15d0 > spsr:         600001c5 >  far:                0 >  esr:         96000004 > panic: vm_fault failed: ffff0000006e15d0 > cpuid = 0 > time = 1 > KDB: stack backtrace: > #0 0xffff00000047c304 at kdb_backtrace+0x60 > #1 0xffff000000437fd8 at vpanic+0x184 > #2 0xffff000000437e50 at panic+0x44 > #3 0xffff0000006d692c at data_abort+0x204 > #4 0xffff0000006bb874 at handle_el1h_sync+0x74 > #5 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c > #6 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c > #7 0xffff0000006b1940 at intr_alloc_msix+0x110 > #8 0xffff0000007860c0 at rk_pcie_alloc_msix+0xfc > #9 0xffff000000219bbc at pci_alloc_msix_method+0x1a8 > #10 0xffff00000020ba64 at nvme_pci_attach+0x378 > #11 0xffff00000046bd80 at device_attach+0x400 > #12 0xffff00000046d14c at bus_generic_attach+0x4c > #13 0xffff000000221f30 at pci_attach+0xe0 > #14 0xffff00000046bd80 at device_attach+0x400 > #15 0xffff00000046d14c at bus_generic_attach+0x4c > #16 0xffff00000046bd80 at device_attach+0x400 > #17 0xffff00000046d14c at bus_generic_attach+0x4c > Uptime: 1s > > git checkout 50cedfede3d21824ec6023324b3ad41a435e1815 sys/arm64/arm64/gicv3_its.c and the problem goes away. The commit is one before Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver. (ba196aec7dad1b73a9a3b86a06259d5e81f16fad) From nobody Fri Oct 1 06:35:13 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 91E6717E5DD5 for ; Fri, 1 Oct 2021 06:35:13 +0000 (UTC) (envelope-from ari@stonepile.fi) Received: from dmx.stonepile.fi (dmx.stonepile.fi [84.22.101.171]) (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 4HLL2S4fygz4dwm for ; Fri, 1 Oct 2021 06:35:12 +0000 (UTC) (envelope-from ari@stonepile.fi) Received: from dmx.stonepile.fi (localhost [127.0.0.1]) by dmx.stonepile.fi (Postfix) with ESMTP id BD272273EEF for ; Fri, 1 Oct 2021 09:35:05 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=stonepile.fi; h= content-language:content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from:received:received; s=k2; t= 1633070103; bh=y4PEsJ7UFQcbzxxbhn/OUp79kgPu3XjVRnzaoW9u4FI=; b=A d7r6ORAjkExe/utThIWyDXq6E+tO0SMmvqvUMgoDO3c6tHVQnPnhOIAXk2m1G0HI Rm5uGQyPvnI3agWn1pTdqslrgC7vb/2SOcdECqQyEc3N6Y6e2chxp3o25+fafn81 L4bYRzebFz614Xuq8r9Ci0ujn9W61vApvEYNqzk9QE= Received: from dmx.stonepile.fi ([127.0.0.1]) by dmx.stonepile.fi (dmx.stonepile.fi [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rvh0Pb0j93fh for ; Fri, 1 Oct 2021 09:35:03 +0300 (EEST) Received: from [192.168.2.221] (unknown [194.136.144.131]) by dmx.stonepile.fi (Postfix) with ESMTPSA id DAF10273030 for ; Fri, 1 Oct 2021 09:35:03 +0300 (EEST) Subject: Problems with 4G Huawei stick & RPi3 after upgrading to 13.0 To: freebsd-arm@freebsd.org Message-ID: <4918ed59-dfe4-2669-dc0e-d768fedef157@stonepile.fi> Date: Fri, 1 Oct 2021 09:35:13 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4HLL2S4fygz4dwm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stonepile.fi header.s=k2 header.b="A d7r6OR"; dmarc=pass (policy=quarantine) header.from=stonepile.fi; spf=pass (mx1.freebsd.org: domain of ari@stonepile.fi designates 84.22.101.171 as permitted sender) smtp.mailfrom=ari@stonepile.fi X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[stonepile.fi:s=k2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[stonepile.fi:+]; DMARC_POLICY_ALLOW(-0.50)[stonepile.fi,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:196752, ipnet:84.22.100.0/23, country:NL]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: ari@stonepile.fi From: Ari Suutari via freebsd-arm X-Original-From: Ari Suutari X-ThisMailContainsUnwantedMimeParts: N Hi, I have a remote system on RPi3 which has been running FreeBSD 12.x for about two years. It has a Huawei 4G usb stick/dongle for internet connection: Bus /dev/usb Device /dev/ugen1.6: ID 12d1:1f01 Huawei Technologies Co., Ltd. E353/E3131 (Mass storage mode) Huawei stick requires usb_modeswitch to change it from mass storage mode to ethernet interface (it's seen as ue1 after switch), so I have devd setup so that it performs this when stick is detected: Bus /dev/usb Device /dev/ugen0.6: ID 12d1:14dc Huawei Technologies Co., Ltd. E3372 LTE/UMTS/GSM HiLink Modem/Networkcard This all has been working very nicely, no problems at all. Yesterday I upgraded the system to FreeBSD 13.0. To my great surprise, Huawei stick didn't work. It is detected OK in mass storage mode, but usb_modeswitch fails with error -7 like this: ------ Look for default devices ...  Found devices in default mode (1) Access device 006 on bus 001 Get the current device configuration ... Current configuration number is 1 Use interface number 0  with class 8 Use endpoints 0x01 (out) and 0x81 (in) Using standard Huawei switching message Looking for active drivers ... Set up interface 0 Use endpoint 0x01 for message sending ... Trying to send message 1 to endpoint 0x01 ...  Sending the message returned error -7. Try to continue Read the response to message 1 (CSW) ...  Response reading failed (error -7)  Device is gone, skip any further commands ---- I tried this maybe dozen times and usb_modeswitch succeeded once, without any changes in anything, so it looks highly unreliable. No difference if I power off completely, just reboot or reinsert the stick. As this is at remote location, I couldn't leave it like this. I inserted my backup SD card with FreeBSD 12.2  and everything works again. The version of usb_modeswitch is the same (2.6.0). What might be the problem here ?     Ari S. From nobody Fri Oct 1 07:01:04 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E418117EB2A2 for ; Fri, 1 Oct 2021 07:01:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4HLLch5fcPz4rB7 for ; Fri, 1 Oct 2021 07:01:24 +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 D489C2600F2; Fri, 1 Oct 2021 09:01:16 +0200 (CEST) Subject: Re: Problems with 4G Huawei stick & RPi3 after upgrading to 13.0 To: ari@stonepile.fi, freebsd-arm@freebsd.org References: <4918ed59-dfe4-2669-dc0e-d768fedef157@stonepile.fi> From: Hans Petter Selasky Message-ID: Date: Fri, 1 Oct 2021 09:01:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <4918ed59-dfe4-2669-dc0e-d768fedef157@stonepile.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HLLch5fcPz4rB7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, First of all make sure the kernel is 13-stable, and not 13.0 release. On 10/1/21 8:35 AM, Ari Suutari via freebsd-arm wrote: > What might be the problem here ? Can you show the output from "usbconfig" run as root. Also, what is printed in "dmesg" when you run usb_modeswitch? --HPS From nobody Fri Oct 1 07:23:33 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6DDF517EF778 for ; Fri, 1 Oct 2021 07:23:27 +0000 (UTC) (envelope-from ari@stonepile.fi) Received: from dmx.stonepile.fi (dmx.stonepile.fi [84.22.101.171]) (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 4HLM664cJwz3F7m for ; Fri, 1 Oct 2021 07:23:26 +0000 (UTC) (envelope-from ari@stonepile.fi) Received: from dmx.stonepile.fi (localhost [127.0.0.1]) by dmx.stonepile.fi (Postfix) with ESMTP id C7DF927316E for ; Fri, 1 Oct 2021 10:23:25 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=stonepile.fi; h= content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=k2; t=1633073004; bh=+OPxgMKfbfdL+ZesOlqGRxAMZk5SYL LlBIC1XM3IDsI=; b=xqkjhxqkoMk9IcIYY36vCJ/uHfZ4XI4AjeFY5G4bLmxtm0 rBxBAPWgDUeyBOshdYf1DZswM9p1wpfQkXZgj9fNZftgg1rSAfw163Uu43MTQAvb +uFzFVEALPUu8T7yMbHQ3blp7T+urrAFNBm/Oam7v1UEB3vJdA8ryiDTZPHRo= Received: from dmx.stonepile.fi ([127.0.0.1]) by dmx.stonepile.fi (dmx.stonepile.fi [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jOuf51uYc0WH for ; Fri, 1 Oct 2021 10:23:24 +0300 (EEST) Received: from [192.168.2.221] (unknown [194.136.144.131]) by dmx.stonepile.fi (Postfix) with ESMTPSA id ECFE8273030 for ; Fri, 1 Oct 2021 10:23:23 +0300 (EEST) Subject: Re: Problems with 4G Huawei stick & RPi3 after upgrading to 13.0 To: freebsd-arm@freebsd.org References: <4918ed59-dfe4-2669-dc0e-d768fedef157@stonepile.fi> Message-ID: Date: Fri, 1 Oct 2021 10:23:33 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4HLM664cJwz3F7m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stonepile.fi header.s=k2 header.b=xqkjhxqk; dmarc=pass (policy=quarantine) header.from=stonepile.fi; spf=pass (mx1.freebsd.org: domain of ari@stonepile.fi designates 84.22.101.171 as permitted sender) smtp.mailfrom=ari@stonepile.fi X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[stonepile.fi:s=k2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[stonepile.fi:+]; DMARC_POLICY_ALLOW(-0.50)[stonepile.fi,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:196752, ipnet:84.22.100.0/23, country:NL]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: ari@stonepile.fi From: Ari Suutari via freebsd-arm X-Original-From: Ari Suutari X-ThisMailContainsUnwantedMimeParts: N Hi, I tend to run only release kernels on non-development systems, but maybe I could try -stable as waiting for 13.1 might not be an option. Here is usbconfig output (but it is from FreeBSD 12.2): ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) I can probably get same output with 13.0 during weekend if I visit the site (it's 100 km away). Unfortunately, I don't have same hardware available locally. If I remember correctly there was no output on dmesg when modeswitch failed, but I'll have to check that.     Ari S. On 1.10.2021 10.01, Hans Petter Selasky wrote: > Hi, > > First of all make sure the kernel is 13-stable, and not 13.0 release. > > On 10/1/21 8:35 AM, Ari Suutari via freebsd-arm wrote: >> What might be the problem here ? > > Can you show the output from "usbconfig" run as root. > > Also, what is printed in "dmesg" when you run usb_modeswitch? > > --HPS > From nobody Fri Oct 1 07:40:30 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09AD117D0CDB for ; Fri, 1 Oct 2021 07:40:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4HLMV36JX3z3G9C for ; Fri, 1 Oct 2021 07:40:43 +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 BE81A2600D5; Fri, 1 Oct 2021 09:40:42 +0200 (CEST) Subject: Re: Problems with 4G Huawei stick & RPi3 after upgrading to 13.0 To: ari@stonepile.fi, freebsd-arm@freebsd.org References: <4918ed59-dfe4-2669-dc0e-d768fedef157@stonepile.fi> From: Hans Petter Selasky Message-ID: <6715f614-2ee1-a576-242d-0996103baa06@selasky.org> Date: Fri, 1 Oct 2021 09:40:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HLMV36JX3z3G9C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 10/1/21 9:23 AM, Ari Suutari via freebsd-arm wrote: > Hi, > > I tend to run only release kernels on non-development systems, but maybe > I could > try -stable as waiting for 13.1 might not be an option. > > Here is usbconfig output (but it is from FreeBSD 12.2): > ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=SAVE (0mA) > ugen0.2: at usbus0, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.3: at usbus0, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.4: at usbus0, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON (2mA) > ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON (98mA) > ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (2mA) > > I can probably get same output with 13.0 during weekend if I visit the > site (it's 100 km away). > Unfortunately, I don't have same hardware available locally. > > If I remember correctly there was no output on dmesg when modeswitch > failed, but I'll have to check > that. > Hi, Running "usbdump -i usbus1 -f 6" may also be an option to see all traffic on the device before and after the upgrade. --HPS From nobody Sun Oct 3 19:36:28 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 886E117A5CA4 for ; Sun, 3 Oct 2021 19:36:33 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HMvH53JWzz4R6S for ; Sun, 3 Oct 2021 19:36:33 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from freebsd2.freebsd.lan (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 169D4C434 for ; Sun, 3 Oct 2021 19:36:32 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Subject: Re: Pinebook pro IOMMU enabled crashes To: freebsd-arm@freebsd.org References: <5434fca8-4f88-2e76-6977-2de150536915@FreeBSD.org> <20210923091921.563b4621a1801975ad52adc7@bidouilliste.com> <307185e1-a02b-9a1f-155b-e5e7bcac818c@FreeBSD.org> <6d578a7e-bb0a-ac5c-96ce-160aeeb74cce@FreeBSD.org> <5e537303-0807-7902-c90f-f9fab5120548@FreeBSD.org> From: Jesper Schmitz Mouridsen Message-ID: Date: Sun, 3 Oct 2021 21:36:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <5e537303-0807-7902-c90f-f9fab5120548@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 30.09.2021 18.39, Jesper Schmitz Mouridsen wrote: >>>>> main-n249225-f673cc5edac3-dirty >>>>> nvme0: at device 0.0 on pci1 >>>>> Fatal data abort: >>>>>     x0:                0 >>>>>     x1:             1000 >>>>>     x2:            10040 >>>>>     x3:             2000 >>>>>     x4:                1 >>>>>     x5: ffff00009a7a0168 >>>>>     x6: 1d00000000000000 >>>>>     x7:   10000000000000 >>>>>     x8:             1168 >>>>>     x9:                1 >>>>>    x10:                0 >>>>>    x11: ffff000000f35140 >>>>>    x12: ffff000000f350c0 >>>>>    x13:                1 >>>>>    x14:            10000 >>>>>    x15:                1 >>>>>    x16:            10000 >>>>>    x17: ffff000000f350dc >>>>>    x18: ffff00000110d180 >>>>>    x19: ffff00000110d248 >>>>>    x20:                0 >>>>>    x21: ffff00009a79f000 >>>>>    x22: ffffa000010b0a00 >>>>>    x23: ffffa000010a2880 >>>>>    x24: ffffa0000116da00 >>>>>    x25: ffff000000b4fd78 >>>>>    x26: ffffa0000116db00 >>>>>    x27: ffff000000e83000 >>>>>    x28:                7 >>>>>    x29: ffff00000110d190 >>>>>     sp: ffff00000110d180 >>>>>     lr: ffff00000077520c >>>>>    elr: ffff0000007a03ac >>>>> spsr:         200000c5 >>>>>    far:                0 >>>>>    esr:         96000004 >>>>> panic: vm_fault failed: ffff0000007a03ac error 1 >>>>> cpuid = 0 >>>>> time = 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self() at db_trace_self >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>>> vpanic() at vpanic+0x184 >>>>> panic() at panic+0x44 >>>>> data_abort() at data_abort+0x23c >>>>> handle_el1h_sync() at handle_el1h_sync+0x78 >>>>> --- exception, esr 0x96000004 >>>>> iommu_map_msi() at iommu_map_msi+0x20 >>>>> gicv3_iommu_init() at gicv3_iommu_init+0x4c >>>>> intr_alloc_msix() at intr_alloc_msix+0x13c >>>>> rk_pcie_alloc_msix() at rk_pcie_alloc_msix+0xfc >>>>> pci_alloc_msix_method() at pci_alloc_msix_method+0x1a8 >>>>> nvme_pci_attach() at nvme_pci_attach+0x378 >>>>> device_attach() at device_attach+0x400 >>>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>>> bus_generic_attach() at bus_generic_attach+0x18 >>>>> pci_attach() at pci_attach+0xe8 >>>>> device_attach() at device_attach+0x400 >>>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>>> bus_generic_attach() at bus_generic_attach+0x18 >>>>> device_attach() at device_attach+0x400 >>>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>>> bus_generic_attach() at bus_generic_attach+0x18 >>>>> pci_attach() at pci_attach+0xe8 >>>>> device_attach() at device_attach+0x400 >>>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>>> bus_generic_attach() at bus_generic_attach+0x18 >>>>> rk_pcie_attach() at rk_pcie_attach+0x14cc >>>>> device_attach() at device_attach+0x400 >>>>> device_probe_and_attach() at device_probe_and_attach+0x7c >>>>> bus_generic_new_pass() at bus_generic_new_pass+0xf8 >>>>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>>>> bus_generic_new_pass() at bus_generic_new_pass+0xa8 >>>>> bus_set_pass() at bus_set_pass+0x4c >>>>> mi_startup() at mi_startup+0x12c >>>>> virtdone() at virtdone+0x6c >>>>> >>>>   That's an old commit. Did you see this panic only recently or ? >>>> >>> >> >> >> Even on stable/13-n247374-9faebc1e664d-dirty >> >> I get the same backtrace when IOMMU is enabled and the nvme is attached. >> >> pcib1: at device 0.0 on pci0 >> pcib0: failed to reserve resource for pcib1 >> pcib1: failed to allocate initial memory window: 0-0xfffff >> pci1: on pcib1 >> nvme0: at device 0.0 on pci1 >> Fatal data abort: >>    x0:                0 >>    x1:             1000 >>    x2:            10040 >>    x3:             2000 >>    x4:                1 >>    x5: ffff00009a99e160 >>    x6: 1400000000000000 >>    x7:   10000000000000 >>    x8:             1160 >>    x9: ffff000000cd7cc0 >>   x10:                0 >>   x11: ffff000000d89540 >>   x12: ffff000000d894c0 >>   x13:                1 >>   x14:            10000 >>   x15:                1 >>   x16:            10000 >>   x17:                0 >>   x18: ffff000000f5c250 >>   x19: ffff000000f5c318 >>   x20:                0 >>   x21: ffff00009a99d000 >>   x22: ffffa00000f06200 >>   x23: ffffa00000f49700 >>   x24: ffffa00000f8f500 >>   x25: ffff0000009b85f8 >>   x26: ffffa00000f8f600 >>   x27: ffff000000cd7000 >>   x28:                7 >>   x29: ffff000000f5c260 >>    sp: ffff000000f5c250 >>    lr: ffff0000006bf3dc >>   elr: ffff0000006e15d0 >> spsr:         600001c5 >>   far:                0 >>   esr:         96000004 >> panic: vm_fault failed: ffff0000006e15d0 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> #0 0xffff00000047c304 at kdb_backtrace+0x60 >> #1 0xffff000000437fd8 at vpanic+0x184 >> #2 0xffff000000437e50 at panic+0x44 >> #3 0xffff0000006d692c at data_abort+0x204 >> #4 0xffff0000006bb874 at handle_el1h_sync+0x74 >> #5 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c >> #6 0xffff0000006bf3d8 at gicv3_iommu_init+0x4c >> #7 0xffff0000006b1940 at intr_alloc_msix+0x110 >> #8 0xffff0000007860c0 at rk_pcie_alloc_msix+0xfc >> #9 0xffff000000219bbc at pci_alloc_msix_method+0x1a8 >> #10 0xffff00000020ba64 at nvme_pci_attach+0x378 >> #11 0xffff00000046bd80 at device_attach+0x400 >> #12 0xffff00000046d14c at bus_generic_attach+0x4c >> #13 0xffff000000221f30 at pci_attach+0xe0 >> #14 0xffff00000046bd80 at device_attach+0x400 >> #15 0xffff00000046d14c at bus_generic_attach+0x4c >> #16 0xffff00000046bd80 at device_attach+0x400 >> #17 0xffff00000046d14c at bus_generic_attach+0x4c >> Uptime: 1s >> >> > git checkout  50cedfede3d21824ec6023324b3ad41a435e1815 > sys/arm64/arm64/gicv3_its.c and the problem goes away. The commit is one > before > Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver. > (ba196aec7dad1b73a9a3b86a06259d5e81f16fad) > It turns out iommu_get_dev_ctx returns NULL for at least my nvme device. (Kingston A2000 M.2 NVMe SSD) So the below patch "fixes" it.. diff --git a/sys/arm64/arm64/gicv3_its.c b/sys/arm64/arm64/gicv3_its.c index 1a0e7a79e76b..28e2bcf70a5d 100644 --- a/sys/arm64/arm64/gicv3_its.c +++ b/sys/arm64/arm64/gicv3_its.c @@ -316,7 +316,7 @@ static const struct { static device_attach_t gicv3_its_attach; static device_detach_t gicv3_its_detach; -static pic_disable_intr_t gicv3_its_disable_intr; +tatic pic_disable_intr_t gicv3_its_disable_intr; static pic_enable_intr_t gicv3_its_enable_intr; static pic_map_intr_t gicv3_its_map_intr; static pic_setup_intr_t gicv3_its_setup_intr; @@ -1473,6 +1473,10 @@ gicv3_iommu_init(device_t dev, device_t child, struct iommu_domain **domain) sc = device_get_softc(dev); ctx = iommu_get_dev_ctx(child); + + if(ctx == NULL) + return (ENXIO); + error = iommu_map_msi(ctx, PAGE_SIZE, GITS_TRANSLATER, IOMMU_MAP_ENTRY_WRITE, IOMMU_MF_CANWAIT, &sc->ma); *domain = iommu_get_ctx_domain(ctx); $ From nobody Sun Oct 3 21:00:33 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 84EF517C553A for ; Sun, 3 Oct 2021 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HMx8241F4z4Wjj for ; Sun, 3 Oct 2021 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0A9724E3B for ; Sun, 3 Oct 2021 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 193L0XJK041289 for ; Sun, 3 Oct 2021 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 193L0XAo041288 for freebsd-arm@FreeBSD.org; Sun, 3 Oct 2021 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202110032100.193L0XAo041288@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 3 Oct 2021 21:00:33 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16332948336.5ac1Bae0.40234" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16332948336.5ac1Bae0.40234 Date: Sun, 3 Oct 2021 21:00:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 3 problems total for which you should take action. --16332948336.5ac1Bae0.40234--