From nobody Mon Nov 15 18:14:39 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 DA0FF1892CAD for ; Mon, 15 Nov 2021 18:14:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4HtHR21mhLz3hSk for ; Mon, 15 Nov 2021 18:14:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637000085; bh=C2icfc7aKDYXON8YieUnvcy1faVtAkd3BnU16MgSNdc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=hmxW6lXTw5hb97MiTGhTXc1UdA+NE1ykFIPjmZei+qDKVl8b9w/CB7dVnedG9ZRpz4kvURi8SRbKRTmUQAwSYz/0ZuH/cVko2HgQaTKh+RselMbC2woiYq7lAvKVppCgK6Hyg0bjJ45EF2dki5ho0dDCed+Et3WCswCIMUOvyrAt4bE7RDWoAnS0XAjEFLMrNEoyR34sBqqR6pL+Uh37DtVucqzCY9dwobVWnQohjerxHPy7Dx86OiEpdt9DKS7PWk7+VkFIxA5UBEQ1edNYY2nrHMg8tidjGDU/LVnj0lVGk8CRhA9OKEtBQBv/qGkJkqw9xyjJbI0mt8klL7OyGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637000085; bh=X/Mik6OZMLbwG2czLS2/itDJjd0cFP6JanHnZ42Da0e=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QdUed6W5gGfVPoI51C14DB8v2MStpvevd2wYW0gz6iUV/61F2/VRbpNAVaBvC9qeJwJU/5LTyoOe+QnIuj2woC/XNgG+T56GtneSp03hT47XE9l0o0X2rJx3j2LoF2SpXt2IM4VGe3sl5wh1WWa7IHxsKV26N9O2kJ8L6mgMmGy0ohwzT/xyK+v+ndj0viSChHV21zJ5WW/JGiykSKqrD5bPvHfD9y4VrEjtuLlfX/5/D3UlVYg1mNSZLCOl+qKkJUQ9uY+MzrEtPOfKDPFs/dnqgKqlK6ykO1Nw3SH+PFWxQDw8tKyHfQ2r9oylM+tYQ6adkmHxY7xB9MG8rZ2t7A== X-YMail-OSG: UytF20kVM1nhbx4zyo8Xyll7v8xTjffuhLe._1z2rEHfWWebjGHzkaehMrrDpvf MDfgD1N4w7_iadJyCvIYZ37ZnDlWcS7ofC0eZxRZ2eUGz6D9D00sDE1300M0ly4_KTjmRWfODWhr 8wTcO0BLOqB7cXFm7WHossMq9DLJ6XTvun3rgCj85DjOJJpwhC0OU8iUB6PglS2v5GbZAJlxd6Ki T9ghuBJ6MHHqCITq9L3xkho1uuAMV0pgUzTe8zPrf0mjrUFiZcIvH6xdRZ6lKxMHF6Btui.kH27C DIJdhNKTaerb6YvWJqQKY0Osjkrd4opCVFrro_rTet.Eag4W_eNNGPguVA1j6xktd30WLWB1bovG gAY_nD8iF_IZgfFDIkuVrkqxBHA5kbAGR517HkO3PxXUopAa0PNYeuP.CYeNa5QC5Bj12spDSXeN O3ldDqWXiE.hIriKW6U5f5RHAHc6D8JuZBqrnqF4CXsSKWmeBiNYjz.AzxOMAoGTFD.Chc_vE7cq HUmO__nQFya41XiiZkarKegCrjISkQ755TDzeiwOIx0Fph6kH6W9EtX4W8IGIDRYZhpLhCiKa1EK pmzEMiTMnQUdj1eFlA_7QMyxMYZBZ5Kle3zr4ss_mfEIoVIDYUNmydBQZjNsKS1q_2Cg4LgqKPtn X5BvQFXY7tnkXOjnuWloAbBfRhPEA1WVEU9b0EnMcbT93wLy684EnWENxUDrdcrHYe42rrVBzbaZ zblBvLOyvrw_lJP5wzKM9xdni4_3pI5cr8787JXyddlY7VikfYz07mu85hh4ViF9_gR5Hc.i3NlL 1sc6jDp5oJ6yTPS06WzwH_zqacBYEgQxivfWokvscNTMKHMVNCQ487exM7VcLtKqtW5Xr30SEh9i wMWdupMpo20brLqgcfgYkIdvP7bJsjMLf7N5OkYE6.f3FuvhioGH5MHHWosXrWSxJmTanU5tshlH zj.1LIEQ377qwP1LuVKNu2xZsW3qFxYH6FkOrh8Dtia07ftCd6f9r6FxnNaXwX22ThRceFebF21p P9xLMTk7mLtkJHB_tiy.Ghmcgl8UGZdg9GBVPOnNBdvr72PZpRvhG_iyIcD8UD96RyYgs87dE8L9 QlAR6MdMx7fCd.4jIOzbXqJmHgpwbvZCDyoFiv1J0DfskdEFhZzuFT3YMs9br0D1kZLgLxDYkzx0 A.X6p1ZVlZTa9dJxzIKhhQueWot.JZ.OzG6UFdAxJm.ijMjx5_xTJb26oQyya4DFGslK5eZ1MDOr sl_zZq3iDHYpccZlsddTU_XGJEOUI1Jk9BoA5U0f17RWksgtvyjo.mmMmzZiGGk.ux.kdNhbBtXk z_rP40IGWqoYybzLOytdMyZPLGpoD0n8F4fKLbGWvSuExg.GbRboKmw4xIT1xVbrbTQWKIXu_n6W T5xSHOZaet8vYpMePAJ8D6esFs_xMGx83syeXktEHWYu0gu7HZ8K2HGG7cHorwRuZFVAjnAQTm5g UgE9sjAJ2EmbvHd6btCFtl6fQVCXXPxYZaLFWqNhRsNwkMXmeJ3KvqP7BGHxNZ1cGpNYMndNsu.k 09YNuotkmkUtPiBw2VFQ6_BKL9VybWS88OXkOfR.kU7gIS4FFh7hiacusmT.gRf7Jz584u4WqNL8 .H5iqDIYoq0bco4rUnDvM2MoMaARYbyxglfIyFBq0.YhgCJd9gL5Nb8VOvqIV7sVTtqNP92btkBV JwwUYFNA.gVr_uOMfT3mVxDFzKZs35rDwjArDRBjleeHgJT1NIaZK581xYuwcFN5pw_fx3cGW5pJ sFJg0zWkG2dqvbCZ8T2d6mpmNpc0t3EbElqJeRGfPtjD63kSn4wc4IACneq8tGRhYfR4Ko4bMc3O XfW_TystsFSYPyuvK3OMgSMBmw6SDgrX0LIYn93JVXNtldAbiB8XwFBWQ1IelX7A4TtM2Il23RtN cR6Ml2rLqznFB0.lMyJYCOSgs0vzgBN44uge1MNX5qj8OAe7DsF1WRmaxfYacL2SD1RoBltAkDf6 urjPw5OAzfWE9nn5ka2_TszIX6ubFrFDIfeleLr3fer3WZTP04RSIDRjbIqRCtYqajhHJQcqdUWm 5_9x7dWA.A_De_nKMnHlFCzkaURw0Yi7domYHyzPKvdTYzTqhJ_kPVnhVLMFU1la20r9Gm2AG7mL nUCmJfeTyCQTai4UEPIdtQ11RdE3BeBm8gOIDEtNQMqKYp4JDHlC9rFiUNk1AkZmyHjApi6fhvU7 DRD7WkylsHFx_qMbYvZYcGZtEIIcMogN7nGrgwRivM0H.vt.v X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 18:14:45 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0202f115a5e78cbabb0b738dbf0e9075; Mon, 15 Nov 2021 18:14:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 Message-Id: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> Date: Mon, 15 Nov 2021 10:14:39 -0800 Cc: "freebsd-arm@freebsd.org" To: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> X-Rspamd-Queue-Id: 4HtHR21mhLz3hSk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hmxW6lXT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 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.96)[-0.965]; 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/20, 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]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N There error was: error: non-constant-expression cannot be narrowed from type 'long long' = to 'std::size_t' (aka 'unsi gned int') in initializer list [-Wc++11-narrowing] std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ static_cast( ) More context: =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. /usr/bin/c++ -D_FILE_OFFSET_BITS=3D64 -D_LARGEFILE_SOURCE = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -I/wrkdirs/usr/ports/devel/llvm13/work/.build/tools/flang/runtime = -I/wrkdi rs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime = -I/wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/inclu= de -I/wrkdirs/usr/ports/devel/llvm13/work/.build/tools/fl ang/include -I/wrkdirs/usr/ports/devel/llvm13/work/.build/include = -I/wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/llvm/includ= e -isystem /wrkdirs/usr/ports/devel/llvm13/work/llvm-project -13.0.0.src/llvm/../mlir/include -isystem = /wrkdirs/usr/ports/devel/llvm13/work/.build/tools/mlir/include -isystem = /wrkdirs/usr/ports/devel/llvm13/work/.build/tools/clang/include -isystem = /wrkdirs/usr/ ports/devel/llvm13/work/llvm-project-13.0.0.src/llvm/../clang/include = -O2 -pipe -mcpu=3Dcortex-a7 -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -mcpu=3Dcortex-a7 -DND EBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden = -Werror=3Ddate-time -Werror=3Dunguarded-availability-new -Wall -Wextra = -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field- initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi = -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type = -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstr ing-conversion -Wmisleading-indentation -fdiagnostics-color = -ffunction-sections -fdata-sections -Wno-deprecated-copy = -Wno-string-conversion -Wno-unused-command-line-argument = -Wstring-conversion =20 -Wcovered-switch-default -Wno-nested-anon-types -O2 -pipe = -mcpu=3Dcortex-a7 -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -mcpu=3Dcortex-a7 -DNDEBUG = -isystem /usr /local/include -std=3Dc++17 -fno-exceptions -MD -MT = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.cpp.o= -MF = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.c pp.o.d -o = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.cpp.o= -c = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: error: non-constant-expression cannot be = narrowed from type 'long long' to 'std::size_t' (aka 'unsi gned int') in initializer list [-Wc++11-narrowing] std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ static_cast( ) 1 error generated. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 18:40:58 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 065551850EF3; Mon, 15 Nov 2021 18:41:06 +0000 (UTC) (envelope-from dim@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 4HtJ1F6dG8z3vPC; Mon, 15 Nov 2021 18:41:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id A724C270E2; Mon, 15 Nov 2021 18:41:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BECB05A022; Mon, 15 Nov 2021 19:41:03 +0100 (CET) From: Dimitry Andric Message-Id: <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B"; protocol="application/pgp-signature"; micalg=pgp-sha1 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: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 Date: Mon, 15 Nov 2021 19:40:58 +0100 In-Reply-To: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" To: Mark Millard References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Nov 2021, at 19:14, Mark Millard via arm wrote: >=20 > There error was: >=20 > error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi > gned int') in initializer list [-Wc++11-narrowing] > std::size_t resultBytes{size * elementBytes}; > ^~~~~~~~~~~~~~~~~~~ > = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue > std::size_t resultBytes{size * elementBytes}; > ^~~~~~~~~~~~~~~~~~~ > static_cast( ) The flang subproject does quite a lot of mixing of size_t and uint64_t, = assuming in various places that they are the same. You will also = encounter similar errors when attempting to build it for e.g. i386, or = other 32 bit architectures. I think it is quite a lot of work to get all = of these right, and it should really be discussed upstream. So for now, I would advise to only turn on the flang option for amd64 by = default. -Dimitry --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYZKpugAKCRCwXqMKLiCW o68qAKDP8WfByS2UovTvl8L2lHFYdYuBFwCgqi2aK0EdPp2/jZ8CuDTUGX2s+Bg= =xxGf -----END PGP SIGNATURE----- --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B-- From nobody Mon Nov 15 19:31:59 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 DD7B918999C3 for ; Mon, 15 Nov 2021 19:32:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4HtK8B3sfxz4jR6 for ; Mon, 15 Nov 2021 19:32:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004722; bh=9UbXsEFxD9z1AHRM3nZZBANcQQjBlM3t7In0FvDOtHI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Y5EFdRi3kBBWp37vjV7z1ElMSLzeQiyidhJw4yBBmvejSGOCrEf5OFfFQK1INPqLa4M5NUMbWq/VxC9n+NsThVIZu4n1LU3pJ+aBG81Tyn4W0dvNRgkfZDl8t59kPAFGCWKys9TA4hAIJqquCVQF75Ir5sCyo2TwWE+6pkxp0SxheN/3KzbB+ORJOmIXtX+A1I4rIBZa6aSw8aIYBoQdydDTUwn/S3XMxGNqqjUE3pqRQbpu6SIOk9Aj85IgV+tABfF4eG5xRm3jmj9Wgk1XM33afE7p2HrPCId5+4KQSJ65lacN/H0evdnp++PJD/C6h+0MV0pZkqnAJbVGy99cVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004722; bh=cV+u/ZrE+q+Te3gC5lkluzg3zNO4yTzIvj5Tssh2uGX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=T7w1OhSmNuYDafuG/OhY0wdI1marKLuZxdq++gHsqtra/xSmwGE5+UcMbzda1oOB1/Rbujixvvg3/TWHits7dHWAbXp5A6c3Ulm3RESyG0ANs+CVOMH8KDhP/k/J9FMfcyqeTthyyYX/NyYsFb1UOPgmzy3xIsfLOX2tlpwDWt5igeETYCxlhtkU93OJMVjhgDWQMDAPhOztQHznl89ckhbTLaJ7NFu6KG7knSmtjED5Oi0FaRPQlR52uwLhmnvwYlIGHJz7zZOHZHsJGfIWY9wRqXstkfa6acssAnOVy9CajW7WqJwAdopqR9Q4S6JsVqZq39zCGtGFyuBoBUgGeA== X-YMail-OSG: eVX1xQUVM1mhbp88hegfI3FLxDJYLulSQoKMt2bhAfWA47_ByjMIwEb5NU8_0ZJ 72KC.7F3DxdgDZY9Gs9X9y0xe6gwxADDYSbg3KrHsCRNAHx1nYQDMGC6P9sp_nSkooAZpM665XCG pgZzeH0DhFDXgb6uZkg_jy9uSHJR6_kf_7NNYeoJZTnXwwhdesB7IA5zPLxUMB0fktid.qi3JRK4 cm7ZMke7VBbSwEN4rqTiiIJE.6e._yaAzh1DHjNkP9LCKkFuV2o_FPsT4or6SJOmdFpEsCXIudIU VWGTaA5RbPWr3VT6LZqghnmoSWZkIlytGxMCD2k5VV36X0vRKbRM4A3hB2kgI8ITWv6jwqVkZZhA ERiilSDyxYnHG1rTv8kPNCD2x6gGumd3BZiGlY56jYJie94SVaf8aM_sNZrtkUk.WF1VCo6SfJlF O2pRyHyJgFYErfRTWo1eep8x4Vgq.r_OesxVUHHWKD0qpdIHHt6C9H060WNiuv1zuPnPabGZokbQ RrRExibnprXCcZJBkQfIl9N9Qy0bUnP2io6t.C410zccsqNZgtVrZbp9Xof6mWGk0Cm9v1BZgvud AfgpPwHn9w.hnId.wu9RfT57Hsqzyi.WKtztxST09wGgPnlTv7rFmguJ9smlnTlBYTY8XbVbm2.7 0Wx_HiB4X5QlZdkxpI3QVWKs.06A1IbdblZRABQXBgddNA_SMqAZ76_0Dsbrh1coA2dXApwOXsC_ eNXyCew8eghtbMedT5iUo5Fv9A928DSN4nEqybKbfwoygnTT9znqsBG0K9wDtd0CMTkq.wvjdmXr hEWWCLVh91Hu1XBqE3vUZWrOv6wFiPBeSThLWRBDznBTyMcUa89wpaMIg_PW45AgJzxBB5w_yULM ndgnufNprwJoKJl5eAjWmDrVaoWwB0egen18lJ_tWPFpjlnO_Xm0wjPj6MFADZp4lufHTZ0tngxi cE_jPfKDWk1USJcbIWrUEDR7Yfp7NoeVeoEIpTngV1dD8MTOjgmWi9i0TZ4631cshvehvL6v1.XT tdreJLlc_EwsIxThOEJsYPojkzxtiEVyEbeneVWny6GYJkxfvfe7VuxnLRkNtl0g3QiUhx_W0XkO vG6ZmHhiPEjnXdjA1I7mcJQ4O7qBb7FRKkZG_POsGCw3.FPuMETUlwytyluOZ1RW.qO232c3BUhk 4tC5QHh8Juu5.kHPk7gpv4Vfs_cO1.YdTSK9_S_Za2yUfQOHrAJ4zJIZ0yXcqUJQCrOHi1Svdpf6 nFrXBoAxc0ql43CSB.FdL9OyfUf38z3Jpj7DB1rVtMmBhh6zYBtEBAXNo9UCuWMITMCx1TPDlH8T 4SLXAYTw7lkhctPjQNM68xZSfHxdIXkmDI3wl_zDT7nNLcGh7MarnPDczdK_yLjaA68J.G.tA00s uC9Oo9kcwDI1mwWBLksRnZ0x2ECb8xiafP8fobdjFGpGhX.BBF_CfFei.E4kdz7H5iTBJue8tIWF mXpFrpfsi5Cd81mwlSoHKKJUffunPDD0VNjkkn3OQTL42ei0nCpVxWU4CW7r_dh.DNvTlfy5itaR _uD7LNmKZC7MElsT1Y9VKluOYTzV7HJCYrne_Hj1vpkePO_JvGYGrYbLjPlkmujzompH2pnZd70L 5cQEC3L3jYE2Wyt.CfJPCtYpxKI58tnLuWbL3CAA9rMCZzU99Ik9XCdQPhHbtWpiocHQOd_BnUVU jwpUIOMtawGhRTuecqoFciVO0uoyVOR4OMGsGK4Ede877kUDxseN.lwLyOzWtOcwg_AKaKMsC4Bj ZXP9oKYeuMP6HLvWB3Oe_Yl6Vr7NCoTALOfyQgDCixjLnn08LgzKgyD4aKsrHThAm3xiX0Dcowe2 n7QAiCEangpL6LhBuCGC5cAOvkN7S37l6PrwZaATpkOdE4exG5WZtpRNWwCdLg.dqvKuKs2Jp3aB Nc6ZDejbljxqj0sKIFOz8k98GrLTw65a6xvG381yQg2umhFJHiiCjaX2mzqLd6VJdYtNz0dOQZ9k huIY3F_MAfpT48snrE5SwNL_NY0PsuT54NbsSynrqfAtSXLjLUmtzBnlEVMCef8vzf1IUwA0Oo60 bSMJzpvzh2lv.73GfQEY5ZvO7ymBD6ie3RaVekwKoA1U3i39pbJn9y5LSiLqMtrV2m8UQ85u.Y1E y460uZ_aUj7m8fbCm1H8MOS_rdP6uy4UC4sChL0FNmIhMFJ4rFtRU8_TJbZb52kZnqZfE0nks7H1 SJXre2A4Ttli.eiXqVZS7nZnhVf6VSV148wnD4Fo9rNQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:32:02 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bce6b983586d0e5f783906e330aabfd2; Mon, 15 Nov 2021 19:32:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Message-Id: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> Date: Mon, 15 Nov 2021 11:31:59 -0800 To: freebsd-current , "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <2CA61249-321C-45AA-9755-597146AB8E9F.ref@yahoo.com> X-Rspamd-Queue-Id: 4HtK8B3sfxz4jR6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y5EFdRi3; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I updated from (shown a system that I've not updated yet): # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 1400040 1400040 to: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 and then updated /usr/ports/ and started poudriere-devel based builds of the ports I's set up to use. However my last round of port builds from a general update of /usr/ports/ were on 2021-10-23 before either of the above. I've had at least two files that seem to be corrupted, where a later = part of the build hits problematical file(s) from earlier build activity. For example: /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] =20 ^ /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] =20 ^ =20 /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] ^ . . . Removing the xorgproto-2021.4 package and rebuilding via poudiere-devel did not get a failure of any ports dependent on it. This was from a use of: # poudriere jail -j13_0R-CA7 -i Jail name: 13_0R-CA7 Jail version: 13.0-RELEASE-p5 Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud Jail fs: =20 Jail updated: 2021-11-04 01:48:49 Jail pkgbase: disabled but another not-investigated example was from: # poudriere jail -j13_0R-CA72 -i Jail name: 13_0R-CA72 Jail version: 13.0-RELEASE-p5 Jail arch: arm64.aarch64 Jail method: null Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud Jail fs: =20 Jail updated: 2021-11-04 01:48:01 Jail pkgbase: disabled (so no 32-bit COMPAT involved). The apparent corruption was in a different port (autoconfig, noticed by the build of automake failing via config reporting /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f being rejected). /usr/obj/DESTDIRs/13_0R-CA7-poud/ and /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the system versions. The media is an Optane 960 in the PCIe slot of a HoneyComb (16 Cortex-A72's). The context is a root on ZFS one, ZFS used in order to have bectl, not redundancy. The ThreadRipper 1950X (so amd64) port builds did not give evidence of such problems based on the updated system. (Also Optane media in a PCIe slot, also root on ZFS.) But the errors seem rare enough to not be able to conclude much. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 19:35:30 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 17CCD189BEB0 for ; Mon, 15 Nov 2021 19:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (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 4HtKDD1dfBz4lYc for ; Mon, 15 Nov 2021 19:35:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004938; bh=W4gFthozDO6PSjo0AW+gqAsC8sdi8ZAH8sKjCYiWZ0o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ldYoifUOkXtIIoGJjxeDRam0QbiKltfjLh7y/qou3yUsB03uUhYBVnJzmkQqQTQsfZI+KInjNbb30yWrSBftr4HV9UMjjjU0XI6j5yXzlC2mQeDTHJrMAU1cYeJyjWTexNGh8DV+3U7kfI/WkUzC3b+cvztY2XxrQPnWxUFGqAaRqJFv+/aCfrwVgw8B5UfKuvGdkq2NfGYcgj+yx4HZ5maGeOmkyIMu4BatEetAuombrCNIBP2Qp8XTKmce4VW6Hyy/+jADfGi8dGgYFnn8zAV6R8MYsR4xxXy4oLhTa7h7yTRN1pBB3J7VsEfyDCTGy0z9qg1h0sXjwKOEsa9chg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004938; bh=hTmbZwqv+gtE1wmSoGoXntG0nPzFlW8153rtnMZqPXJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Koo5SNEcPr9L+2g0CeLxGBMY1L7EpsDBnZPd3qB8nEBKtP64ThZnMvruGjhrzkfcbd/QqpthAUIvZyCCauKpt/5NTvZSfkemQXJXlswQLbrWqcyw4ipYZ+QOf7o4fePqNalfM36nCLOsKbIVcu0BP/gvx8qNyAEBRGpkvrQxzJ+X+4Q6WB5pxRdP2kcmRd9gmrwopWaafRRsIYGPVuYNM8BY2A0UPPSwHgk+6A6ijSHl4ixEXjqxL3cTZz67RLvhoFyuxBznHphh6HuQowyTsFNRnIyE9Za18trWkVvuJViJgWyt5hgpe/DA7NKpaLE5/DW32f4TlVJIBOWk7tVSfA== X-YMail-OSG: zPr6DUAVM1lzdnPqwf3EXCraVyv6OL.zHIqX5DKeDfElYKTbXXGYe13fleUeK0B fJdVSksQqIFubCn1oJaSDBl1vJkBDchgmV6fr3ZBEi5nWQxpn.QCLd87U_OiSDuNNFqvL.6O02Lk uvZkcQTsTNKBhRfpQiTxnXmKRUYMhZYQ1NmLbKMMDd2SjQqqzkI99nsAQ7S.kcwu06koTsYx4rxA eB33lynjgcWVjGBNLXttzssc3NPWuXjd3GW.vgKb3SIfRI9Kg5DwXEwBfF4nuxft93wVAVDtmslz PI1gaCOBNMKZpc4bGUtsy6Upl9emIEOG6llob0uqrsC.mukfUmge.WODWbjtIagCXtQnscaFR06b QrCkfUdgcyVfXHtygKYNCRZfoKT_hXlVpKZ1xjackwS5579eiDmWKOd7lCfRDOeykVHCnbQFdg7Q HN1Z7.wLSxu8dfhbBVdLcygCfT3xy81sWDf5Cy3Qwc59w_3jQJFyLatTmbXu78hCpHfB_y5uLrir .oOD_vcINmHze6xmJF6140tn5UcaauYbfLNAo7VK28uVF4bb1VwO5ec41yJrnHzRZw9jLHxpcog7 CshSWQu2VnGs7PVjWz5BZpDDoiN5rJeAXDwus5FcCsfp8sS1adkNCA26IV2Awd6Q8RblkAgdsaqK ZF2zwTndOaKV4GJLAq71SFl317OYUXRseSiltydkm43_K4FUUCtEX5MTNRkwsrKYpI_5uIwdqaJW zyXEJcRP1kaRE8OVCyXCyrHY_JKeHN0EbrTxp_2F7m53klJXDx.UGVvbT9lLJr3FRy3iKXF2mSQG HGrcp2NH4i65Hu2tk11PNq7TpitupKLBBtE3qCsJJFX9cJwVIXnQ991gFP9FzX56GTfxu5taxLfQ r_CWZwsS7IIFVq8oNBflUHnnJR_NQkqrCnaGZq1nkOvrF4J0jd6uJT8qxMwz2m6RKBLy60xKPizE bCVRom8hNvuVNWdd6N8AVG8VfiZGFEKyqnRAhgf5b.NtFauZTpGjlRmBsNNVNNHo3SR9s4mZdW_s 5TFzeR7htDO3zf9GeRVuekqE0Egba1.DELwdMW4NSq0sDd36ftUPGtvDp5MD5lIWBLR6btICgtwh kHvz2CFBEWGSTI7JoagctOXnwokTrtdqPz.2RsiVm8nJCinDr.ugWe4HyFkn.HXr8jy_tg.OpGap aDzPZumj.NGMQUL74.m64py70DVdVlih1kAb7hzYFxUuOdCT2AgSlX5VNnlTe.h4USlBDg8YPUIt gQCMjoba39QCZCFtSHnGItb2NyVWzJNc_1vjX.cBIwDjHV0MdE_Mgv8HUaYE6eBm6NN37sOalKnz bJe468bRHbaFVi3mIUbIwM5R7F06hBMjb4Is8A9oOpKRA8fhMfWc1g.OEoWpeAbK3XqYb8GgaN7B BUOoxTfWtJ.D6idhp9CkhIYRkGsKPdZi.LvBiIAe5mlVK_nvvBcEEK8A8B30ZNjNog9NBBDNHfa8 sxBVDpBpogKPGq7ERIi32KhqtnKw9OHEPvteY9OuNlcgYczfkzsxLE2OF9bMM4VlIMo8.IfjCR26 3vOXH49.r8fwkFIY8MkJXIVAVw8XQ08NZx4KJcpJ2rsTqBcmaW2SArylwYMjzkBF1z_EprbAu7Zp aloMx20fb_VSu5s2y6Hl2sbAhzyOVptLGjWVOY.UtmFVoK.C3BMYhuxxmP2aw6ltaUInolZszGYt .EWwsPcvtjp4ePRE15_csqtb05y9CxQG2SCgPAV.sN06aopWuM4FtA7eqrx9T4606C2G64AzcuPh YEL1AyMUW.8WvdgQBPBP.2.i_DmzL0kKIH_64in74AIch35ToDuRTa9bubcT3jSg0AzQWgveL53a fRiBwuI.fsal0NCGZmSGeJa_ESEDkZK8kdJvuz3OkSp6HFWOKzLOI2cwMj0N9OgonSMu4iLrkscV qtvX.DpkJ5g5NHk1tjJpBYd12lGMKf7LK0_pFER0On71D1I9w6tmMLrw6QcrQPRMm3Kf_x459Gvd 23thTk0.oDZXCegN3iHIxh95QrakqlAKhmLEurNJhhxo4TTHlYAA5j3.6Co8P9A57PuP_N8TRsLd 3tbgfXPh01jeHZR5WBhtlQe1quF2bRpuwrO37AQ2NMLVqk7jww2vUwsrDFkXu1m495wEsZZrog9Q yJ5RB5Bf_aBc5t_aAJFtG5sEnMEPjUO_nZvn.lD0MhB9oBhnS7.AqKzsUbMijKN2KOb56FM8LU6K MjMXlgc3conqOUAejMPcDjEHl6ungw_AuugmgsPbyMJrOxthN X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:35:38 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 83fe48e92d87a725de8beeca5848aea2; Mon, 15 Nov 2021 19:35:31 +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: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 In-Reply-To: <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> Date: Mon, 15 Nov 2021 11:35:30 -0800 Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtKDD1dfBz4lYc 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-toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 10:40, Dimitry Andric wrote: > On 15 Nov 2021, at 19:14, Mark Millard via arm = wrote: >>=20 >> There error was: >>=20 >> error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi >> gned int') in initializer list [-Wc++11-narrowing] >> std::size_t resultBytes{size * elementBytes}; >> ^~~~~~~~~~~~~~~~~~~ >> = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue >> std::size_t resultBytes{size * elementBytes}; >> ^~~~~~~~~~~~~~~~~~~ >> static_cast( ) >=20 > The flang subproject does quite a lot of mixing of size_t and = uint64_t, assuming in various places that they are the same. You will = also encounter similar errors when attempting to build it for e.g. i386, = or other 32 bit architectures. I think it is quite a lot of work to get = all of these right, and it should really be discussed upstream. >=20 > So for now, I would advise to only turn on the flang option for amd64 = by default. flang was not being built: # more /usr/local/etc/poudriere.d/options/devel_llvm13/options=20 # This file is auto-generated by 'make config'. # Options for llvm13-13.0.0 _OPTIONS_READ=3Dllvm13-13.0.0 _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS FLANG LIT LLD = LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=3DBE_AMDGPU OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_UNSET+=3DFLANG OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB OPTIONS_FILE_SET+=3DMLIR OPTIONS_FILE_UNSET+=3DOPENMP OPTIONS_FILE_UNSET+=3DPYCLANG OPTIONS_FILE_UNSET+=3DBE_FREEBSD OPTIONS_FILE_SET+=3DBE_NATIVE OPTIONS_FILE_UNSET+=3DBE_STANDARD =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 19:40:49 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 BDCC7189ECB6 for ; Mon, 15 Nov 2021 19:40:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4HtKLC5dgGz4pTf for ; Mon, 15 Nov 2021 19:40:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637005250; bh=+p2DghXewEsz34Ggp03Hl7+aPLMgnqmo5G2xRC2m2vc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ijCk5eDfDZwZbSII8rPf3AJdQ1GkAy3YZ9MX+2Ix12fjpMPUWtgz6o6e6dYiRQA2QrigLkrKjmRZpXLnRFUH7nwSeNpNUG2X0bPmtNMBFTWimE/ifQyyZe7yaUl7b+aArxuLBN3n7rjo4qdo0z+n7Etrk8Bt97rZ5Qdlh2f6uK2n0o/d7BKtbKhWbnbDvLvU6ptXQLGD9pHJo+idBi/Wrs0T5QsXnn6MvXY8GQDBKhpcjz4BpHN0qNdGhmiKG+58zGQoRHvrTEpLm9RK5UhYXy0PcgoSc4Cmk7fiqxfcVQNvDYhBGNdApBBMPrbvYyehpzselNVHbU+rclrrXtfWsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637005250; bh=4mf6UxGYgvbdjmhW6+3l+S1mIpkobCA3ZcdB0ZqPvWB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W50hYnXup8BVWIcifbt/iWNUfrD232X1EGQWyB1N0yN9+vRLwVj/kUWieAa6gSvRR6goRor5JOknUkKtVDtI9NO9zlnr6vJXctj0kRjYVPWj3C3srMoZyhmzJlYHfvQ9MsKO0g52xThqZGmREC2kFGurYo2+LcE2gGeDFmlRNMDVTlYaGRBLJK7RJvJ5JhhLW3KnLLhqFQ7FyZf0rBu2gSL8Q0sUleq8gkIrNuOBSxlwLphZA0qhxXLS0sdMPVmTnYif8usvOucx7+C8A8YJhodQb0hI8QUi+tnsit7k2HUH616bNbYqKezeHBku8cXkj0qgPX+TmbuTqK9qxfXg5A== X-YMail-OSG: lTkiFAoVM1mnQ7WUNVhGGXnYpwgTMd6LoZmILn3gd.kClCCnIPSwoJNnLuNSiOw mSFjezMW5v_ZUnwkTvIHeOPRX_.1iX0BEHRVGK18h6tN7TawmkSFQl7lhEELxX8Fv4mjy0Dptxqr xtwz3K1.KQshmSiVrLvUggsKDGa_jsdrinRaAv5fHLkUy.9w3i5w7EomYByiJ.DwNiJNPTaGLyxP dmwbWl7IjLmEVwIdjQZCjCMEM0W5GTkWlgubL0LFninWYAue_AF7AFZGSIDJ8oKaZzRy_7AnBbZS aICYjtANx_tfMO2nR5e_RlvbItFhSBn8R8OjUxrPqJLmUsqq42zu00VCM_ALi8iuyvksmoE04zb_ 6oXQsfOCgKXDriU_TpxBw9mp5ZNd111r2NhWskgFV1v23CSvVn9zQGB4_b8BzqVUu37gdaHEKzTj K4v6yIxfU.OMNc0JUYN2B3vrtzZEdz.NdB8VIEFEsvb0yegS0M3e1hAn2nj32oCFXBQqBL10s3EX 4g8oIWE_n3jjtaPxbLD2EvJbeX4TKWVzPFPy7fcoT.UNihNhSkO14q7jcT8SOL1zL1o7xWmmRlhc hgE2gLhUBUNglatmKYZJc_ovz5ydJx4MqhL4cUsJDYHZKtONg2N2PJfuDsRpJekmq.6vB2ODrSE7 JZXTxooFnOYxGr4_tYp58PpR8Xh1Vc4oYUbx0i93OSg775u8axARJy_Wgi4zmdAybMuYzGFX8SXB 0prXHkI.UWlrvluGYQqiQ97w3MOis8kluulcafQGbsIi6BqqFnYclzz0dL7_BvJKle9g9CRqYBke 0benIYGU5RvTN8iShUWS5WN6qt16iXdM7Mb2Fh_AJzl1oajnsHmNz7v5w65uAOTUW.9gXkbQijv_ fumLcZya6B.pWHfFubkcVjxm5165NQxeZZsPbelWAh.ItWVq58BjQYsyZXtSR.bycB9lnTSseXu0 x3JW3I16PuxxgTbLhoiONdr2hilE6plPh0APY2smjsNODguA6EjXZ_2j8Yoge5_IjO.euDe_cCt0 MFAjILS9c19_66ZiCDkJX6w6JnPGYZDJVy2PVR_dWiMzdHjJdn1rkstY.My4aNRei.Zth0FoJlQk Rhz8kvhMfsas_A_VVp3.DXVuWS1xaXd8t_Sa6t_yoKgk3MYCYB9z6BBz0vthAmJ8dAs5RfQ5fW2N N29sRBPKOpqaccfXDg.IGHZUQ813VoA6p25bZdH57COrG7.zoG4plFVRQpMwd0Nn_oYCT3zr6SJ7 wwkFddvCH5408w9Kq0SNgCMAjl0FdUFpwGxPFadL7XSAAlgihkPp6U6_7C6NsObQBO6lL0ISy9DW zj4pv.fqJjDwe_AKW5ZLzA0cRvCJJ8AwaBOm.CO90UHSSp5WA6Kfgvo5x7K97cLUrQxiUSkMqS3x UA5OSRsOeu1kv2ILT1rSMPtlvZYxpeHwzNWbz38IeQO8EHHHEpf2TS8m.sMk394XBCdmFTabwBZj rIBnJt0jiUtx.4KtMR1ukyiKXo3VqpeC84vnmjcWimeOnfZSDg0OCAmu8p5WJh0.6gtTJRIsZLiK 9UuAULanTNFwlWMxoy.bJ0hEqOclkOm9XtlMYoCHBrOQhl2mxBu_48bF8nftsSEXdUsiNm6j74_R L.pYBA5reaKOW60.ccn.CY1ChY.pcGMawIX.WEepkWc0XurC6R7pANsmKUv3Poa8R74U81jahR7r otGAV42ohGIkdcQoYrUtbGIXK_iaIHlJXZsnWWsNkrmmoxsFkYuyoHVt4N7HU8H7hHGTOz_O9kIz S7MY7_6uTqiA4EIcAcZNIy01Z7BCjghlzPWHBwNHNiO7kreWmndUJ0DKEJ1gbfRJaG9W3sWMdDkU ZdZZRI74uJyrUWrSCm7TjeAk4UwOu2blRX2jGJbl7jQtEgJtuCTQoDh.LxmCSd3U38LasEBVUErM DCLp6pLjCYVFiNnfzMa1l3a0YDecpBpBZJyXn1tJP5FHeTE08PMzfZaS99HBXLt3jbe0ODg6rft_ WIIo6EJ50imok4T7ZILA39en7FuWBwl9UZs71ILaJCtrqdLjW0ysXzTvlf48MI.s1RNK.YWjCsUw nWX7N_mWyu7gNhNK78a.dKKafJdjmcN8o1MQ02pXCiGYjL_ffug_.UZgrdRdT3s15W1bzEVtZ0tD eudeuw9AsZwcWty08PjIyDLDtvBtDoe5W.kPYnUXZm4TaD1TKedqTC5kz6hRZR771ZQ1tF8iEu_5 CA0G_RippaQrqkltFa90OsjXI76zbV3Fob5UGt2L463nho2scPgT2gmMHNgBt2Inznc2HBjjLhNr bi1.qqirmVwAnAKQJWH56BHhDzC0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:40:50 +0000 Received: by kubenode548.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d01971386b38a54d52fdea58f2d7e88f; Mon, 15 Nov 2021 19:40:50 +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: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 In-Reply-To: <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> Date: Mon, 15 Nov 2021 11:40:49 -0800 Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> To: Dimitry Andric X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtKLC5dgGz4pTf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ijCk5eDf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 11:35, Mark Millard wrote: > On 2021-Nov-15, at 10:40, Dimitry Andric wrote: >=20 >> On 15 Nov 2021, at 19:14, Mark Millard via arm = wrote: >>>=20 >>> There error was: >>>=20 >>> error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi >>> gned int') in initializer list [-Wc++11-narrowing] >>> std::size_t resultBytes{size * elementBytes}; >>> ^~~~~~~~~~~~~~~~~~~ >>> = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue >>> std::size_t resultBytes{size * elementBytes}; >>> ^~~~~~~~~~~~~~~~~~~ >>> static_cast( ) >>=20 >> The flang subproject does quite a lot of mixing of size_t and = uint64_t, assuming in various places that they are the same. You will = also encounter similar errors when attempting to build it for e.g. i386, = or other 32 bit architectures. I think it is quite a lot of work to get = all of these right, and it should really be discussed upstream. >>=20 >> So for now, I would advise to only turn on the flang option for amd64 = by default. >=20 > flang was not being built: >=20 > # more /usr/local/etc/poudriere.d/options/devel_llvm13/options=20 > # This file is auto-generated by 'make config'. > # Options for llvm13-13.0.0 > _OPTIONS_READ=3Dllvm13-13.0.0 > _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS FLANG LIT = LLD LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=3DBE_AMDGPU > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_UNSET+=3DFLANG > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB > OPTIONS_FILE_SET+=3DMLIR > OPTIONS_FILE_UNSET+=3DOPENMP > OPTIONS_FILE_UNSET+=3DPYCLANG > OPTIONS_FILE_UNSET+=3DBE_FREEBSD > OPTIONS_FILE_SET+=3DBE_NATIVE > OPTIONS_FILE_UNSET+=3DBE_STANDARD >=20 Hmm. I got that wrong, somehow the above was not used. =46rom the log file: ---Begin OPTIONS List--- =3D=3D=3D> The following configuration options are available for = llvm13-13.0.0_2: BE_AMDGPU=3Don: AMD GPU backend (required by mesa) CLANG=3Don: Build clang DOCS=3Don: Build and/or install documentation EXTRAS=3Don: Extra clang tools FLANG=3Don: Flang FORTRAN compiler LIT=3Don: Install lit and FileCheck test tools LLD=3Don: Install lld, the LLVM linker LLDB=3Don: Install lldb, the LLVM debugger MLIR=3Don: Multi-Level Intermediate Representation PYCLANG=3Don: Install python bindings to libclang =3D=3D=3D=3D> Options available for the single BACKENDS: you have to = select exactly one of them BE_FREEBSD=3Doff: Backends for FreeBSD architectures BE_NATIVE=3Doff: Backend(s) for this architecture (ARM) BE_STANDARD=3Don: All non-experimental backends =3D=3D=3D> Use 'make config' to modify these settings =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 20:51:17 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 1E0291850D27 for ; Mon, 15 Nov 2021 20:51:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4HtLvd64yBz3mMf for ; Mon, 15 Nov 2021 20:51:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637009484; bh=Spm5zBqzDdI49OOdqyyFzFNbB7IVhuxmSRlEcKj+wvQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=bnXnXa1kpKI+G88XFk8U2r7+nOgeA526Jv3US3He6UfzmOhA56NqCtd8hiPGmnB3U16zQ4tDjqITEzb2+k3C8g5dPI2l3aZ1FQmn/kAlx3W7CSrECS5xQolGDMbnhcitX+eKc2L4egbugdRteBg+2U6r9pYr8tacayHXKmdDX6LmrSyq00XEJNArCGL7sY2YmIEb+XzpyyuVUdPcLiK8FZw8CwsIwZ7mYHrAwlkfNJjRkQKs3l0Oz7eWXNURiNwi1VQe9DEugkI0+e9+s40BVyktaGTYEwvgkmJpsICpkQC+6TTIixCeG5pUiaVU4u6y98XO+GZdJVu6wLH9BCODhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637009484; bh=xmDrfuewT2wSebTM3BuXZNf+1nsEfROa/QdpprXCq1a=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G4wJ3F5wAEJcVXzFvmOsLvZBiY4TBYOvv0G/tMh7aew8TuZAtCNaM4uki4N9iAQD01jVJm9yr3QAsNhWySUPdCrgeh8Bjta1KJ2Qu2ltjnQ/Pqp8T894Xoa0cvDdWY0yQjTY5bbX73MVJcmA+zm4BRf99nb61WFMe7Hr22AYUk875Hhx254CnRxN3RF6a2ho4HoCdc6Hg+OhQhDTREvPYIm+b7PHHbqqyOgDNbASAauDO+k5zV10H+nzie/zS1jNG6/JYpEX4HEV7hYOaVL+DI/1705cL1x1MvQ1V09GukMzdwMb9UzK84d1604M52iPCnsNalVmGzAMrN8Yz3EK0g== X-YMail-OSG: sFkpQJUVM1kZUNOAMY2Y2y6WZr8EvO1._TPV3zo3RR.jic88cnTgHiVrYlF5JAn DI1FDwJu0muuB0aIj54c7d7MUocIOEBqIoUDbt7ksK6OhKmLNfHB2SYqcFSQ.eQcZEN5g95oTIlU HOl2Wleu_YG1hCa7LgodVPz4B_VkmDA5f9Ml6tvz0nfynCUzj9W5eMeftBYPXV1Py_z3.llISHyb M9QT5aAUPq25edHrLccaS1caflJPo5M5xsm6MKLZHZkZb5FuBoXp6zuTq6ONsp4mN8KzXX_t.YL5 3_7fJ7LhvI2dRpm8SDEJJnMMOrTRLMRqNWsI8QvpoP74Kszq3EiXn93tntdL4DP45QMh39R2waLN HMIC3etJ51sjBNpTKyfgI9Nekgi5J_PfPotsL1H4a7pnzouoF6bimMRBql1nkf8.qdehaQ7qZmYt FFZ6C5WYm0b5Jw_Z7ygXdnUFqg69YaUWd9VoY1NA1ZPQNXOtIVlr4ln1NqCzvuSGWkyuSlkBjgiC RpDNc_O1w_NuO4tgcG2QVYot20L2.zjrJKvYN4Qqzns27a9JVxVIgfhqtiV00YqzO6DcH3sp.tZC fyDAGDSyOX9WdaKrPg0c3v_L2dTV948VuGS5RaA3W4I7kZqaVaZ5CvqzaVTgU1D_AVLEjC14SoAk c2WcVnpexsZedUAJOwjlbkjkj60oIjSbDQ007u7XRXXvpAqq8j5gxEiNEGAjA0uLDf50KuQ9dzaU 9efAu7yPEQiEvlDbIKslxVGBSz6rhtWxtQ9i7why2qqTTwpdYsB5mWDNzTHaFAWZ88aYLNZU5vrX R39Ym3KPVMvDf0pSfRmreMNusi6rCxtqZyNNkZjn_tqgZ_3zlQUM9Wg2R0VWJa6bO5l0G1ZFiePx D1HzTRc4bj8eN1617hI_XMWk7b3PUEwhrleBBz334bIhmCUeEZSyJEIy9_1M30ffckYQBJBHRoLr Z1SsRQ.JfGxCA1zO44hZCPykoZGomlBSlBtRe3.eyA1q70apQyNqUE5_LXNHEGu.Fpeiva9Xs4Eh jowol15C1mvQiF8ZJcC5XRY3QZhhJ0duAsR2ALHITB.RYsxtSV6f0xjB7RUqVK4O8d.j4e3zLxb1 M1mutDu.SD_Tss9RLEO.bhBhq_aPX9IL3tYo7TVDntnYgxiGUtk0xCVb1hI8mRUWSiAKAw.q2LND xYvT4enPq8hYvpTR3zI6Xmg9kd1PgSLJvdtr8SgtGZSU1WxSyniYH_dAYHKrYLXgl_WfZvg9S3Xb zJ51pRpTpzgPsH_V0BSueFALnqFiipQ4v91318LB1fRi1Kgiy2f14M_cNt3jBXqKqvQWzzptRKdC ubbIoSOdJzdWZp9vHUMHtHkONt4UUfmOSYbjKKqEBRTZ9c_mNQ2ygasZxOzQwAbl6xcAbB9S6s75 5HUb6b04JVFNjTolTxOx0b29QgyFhE1WkmN8qSpMpHDe2jdK6VU.0opEL3VQQYaHgZMWGPbR1MS5 dFOtpDTd2thG8ysQVtUzKNvpebSCGHgBBxD4Y3HNtfc03H5fbYSYPuI9S.XBgTQ_feCmDoVa3RHX 7M0T2cOY6fEvHETiBZ6Nw3c3qn69GBHIsRPal67.MlDbJAH0oGL8ubxKWjHBqxunPMRBiuaq8a.k b3s5nOsd88NfQUQfoqVNvOeMTUsQ.xf6jtPg69DqEkozZLeNvxCHaFAMdgzaPbHYep3Mq8N1pHc3 EXvWB_aRXUJUVhlgmjqYoMHkOqZ1LnUk4bgJiJR_db99jlxBv8FxnV15lzSDEW4Wxo_N6zyMnsXU eH1R2awyuDaNtj6jTYicDCSn6Qx.b9d4koEYJ8_w95_sN80OXg5PzAy4EqWyFi4ebNcwPnOvLSZw l5fVaa.rSNGOgTJZNm43.lht4vMh0DMKo33Qa3UTOrctO_DNbXn6dgTUDXd5eYS_HCK82.FOKr8z 1zUSAFzOa5Mv89UBtsX7SS0wiQ6h37Ql.k5FTkoyphDbVyJT8KcQTpQgMI5IXRcvqHZ1O2XyCt9J y0VN.S5OpNeOmcUz0mhjpia5jn3NPgxlF9Dhxp5NFpEeW4mkvcXNk36jdLu7y6apXIFtT4oeukLG CGwHnjQTJxxt6J71RsRB6gIWkWK588Y9qO74dZiSaqJFpXtqLK9MMo82y4KaaP7i3p79vTerEIZz OnSOHDhGCMZtf7Pz_Ocq5Kh4Nax5aMsN1YV9wwsm9wRXL.xaBJIsCGBzduqAF.a7InLtsUvwBY9z DmV1qh02kX7J1FeT22JhlypeyTSsFM.9mgqxGmQPDtYPcJFsn X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 20:51:24 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b76ae83e72eaf007efbf393290b269c9; Mon, 15 Nov 2021 20:51:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 12:51:17 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> Message-Id: <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtLvd64yBz3mMf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bnXnXa1k; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 11:31, Mark Millard wrote: > I updated from (shown a system that I've not updated yet): >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 > 1400040 1400040 >=20 > to: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > and then updated /usr/ports/ and started poudriere-devel based builds = of > the ports I's set up to use. However my last round of port builds from > a general update of /usr/ports/ were on 2021-10-23 before either of = the > above. >=20 > I've had at least two files that seem to be corrupted, where a later = part > of the build hits problematical file(s) from earlier build activity. = For > example: >=20 > /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] > =20 > ^ > /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] > =20 > ^ =20 > /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] > > ^ > . . . >=20 > Removing the xorgproto-2021.4 package and rebuilding via > poudiere-devel did not get a failure of any ports dependent > on it. >=20 > This was from a use of: >=20 > # poudriere jail -j13_0R-CA7 -i > Jail name: 13_0R-CA7 > Jail version: 13.0-RELEASE-p5 > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud > Jail fs: =20 > Jail updated: 2021-11-04 01:48:49 > Jail pkgbase: disabled >=20 > but another not-investigated example was from: >=20 > # poudriere jail -j13_0R-CA72 -i > Jail name: 13_0R-CA72 > Jail version: 13.0-RELEASE-p5 > Jail arch: arm64.aarch64 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud > Jail fs: =20 > Jail updated: 2021-11-04 01:48:01 > Jail pkgbase: disabled >=20 > (so no 32-bit COMPAT involved). The apparent corruption > was in a different port (autoconfig, noticed by the > build of automake failing via config reporting > /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f > being rejected). >=20 > /usr/obj/DESTDIRs/13_0R-CA7-poud/ and > /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the > system versions. >=20 > The media is an Optane 960 in the PCIe slot of a HoneyComb > (16 Cortex-A72's). The context is a root on ZFS one, ZFS > used in order to have bectl, not redundancy. >=20 > The ThreadRipper 1950X (so amd64) port builds did not give > evidence of such problems based on the updated system. (Also > Optane media in a PCIe slot, also root on ZFS.) But the > errors seem rare enough to not be able to conclude much. For aarch64 targeting aarch64 there was also this explicit corruption notice during the poudriere(-devel) bulk build: . . . [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e I'm not yet to the point of retrying after removing arm-none-eabi-gcc-8.4.0_3 : other things are being built. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 21:13:44 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 40091188C0B9 for ; Mon, 15 Nov 2021 21:13:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4HtMPT6TVzz3vpv for ; Mon, 15 Nov 2021 21:13:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637010828; bh=CmwgQHz7NnMM/ThG+x6GRmKKqofAwcKTvAeWZKZR8DQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=JINM9iSG2CoBT0G496LS2a1pPhEqn8UHD47zv3EBlGSU+kIEy7iK6TMKkMr7WITacb5VvHDykLqoYy8BHJZYTahVJF8VZg+JKn5UuMdkh/PaPOgR/TaJY33cGAdHsq1Uwk4vbrb2kmM2EVDOX0P2ze5sXBpTLfnvaZOriS8YtHRK69m8Tmxd7w2X/FV9EsyQ6x3JAwh6p+++9zQAHr6jgOOsdiVskbY1lIc81zR/D+hzSUnMS9SCWl1bQMduZ8nT7+8GTDF1t0RXqmZL0/Yf7RQy/2XtkTNQaqzRVAryt0xxrl3sblZe7/jUOLQ0zcLy0tvgWG6is9RHKPUAiAvsoA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637010828; bh=J2ASv8VyIBM6J0VIor99/TyaSTI30nldzGFP2WZvAoD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=d/lG6ZOCFerqR3oetjR4PO099VA2EwFEWG3D0cI2AZoWo3lc0vccCv4nH9ANhnqDp8FgK1K2DAGXyEX8aVR9HmqWukrTE8HsSCiUAzEuN5lf8sC8b5AGFXs3AJsNomDWBBY7i1p5tjnvNWs62bS9tRh5b7NwLjr/maz/9C+LvElnDA1hRUJPVGlQmsNtPQxFSQxz+yp99AJJr3WiKQ2TFWh0Q6pzx1kSw/de45NTzaT5Me6IAKX3gllJ2vBfOtJ+06OV+OPq7V6295ebQHcALA+pFtLWrfYpqA3iLWmjhAASv/alevaN4ZNaQq5iA8QJJ6gTdhrcHqPFNKtg/7RGNA== X-YMail-OSG: CYWpBIsVM1nmdSqM2HzRLdrTIIiTZe10cM6Z9lRhhuwlYtomDDUr2UCHJs3cuX7 6VhkHYlgsAWViZaFYtkRwRCvufEPR1pCpuJKQB9Z4qMi7YJU35AR7pn9yeH1u_2f951OInMVh3XH b.zueBdr71TPkjQKGQu4Gt4xXNiy4nZbsiJCb0BBLeSrRxBRWzKSxv1HcEVeAaaTze0Jw6bR7dQi 2lm61h3LaZ74jr3upFKqc3zSdOtloAylDMFSquIakn8wFbsDxfT9q4pehu0cYCBnKgu4.qkPEWhQ AQe2ygibXLTowW0IqgweYyBskUWCzgvaDUpYyCQl3crU1mvzDRMvQgVTiNcBTen.goC8meuirAal BNdnH6HIplua.9kcdCQzVLUGsGhHEl_kodNn6pE.hymlnnx24JfNdVzWmBALGWlssv5quKBEP6FB mELbREBB3sntlw5L.iHuVjWBBQJhNjiohuOsVQgF.DQtUzHstDDrnOq0.zOUuLKOggipR62FROMC YrnmOkrnGUW1GyoXkk5Wbuvr0HErXYc5ICzYE2aKSbah6GAFiFNIH01slKBri2DY6kq5HN5KgZ5N KGOgT3PWMBc9I3FDWhyOKhLf.4EUvZMv8KMSB4k_jj8jGZdFy7_etF.jea16d2DJHQUEkHk38jqJ hMlHu60rBXSEoAAA2DUQnuEDpGUF1YnAQKJYrSrFkL1ZejRVSnNmiXDssSdLu_tWil2LxZucZ._x ALEfOLTyNdWvBeeExSGkKwihhnM_2y9yU6UMJyUWIoax_WXXD5Leih9V4jCLSTBBymdxi6kbGhlj 8iW502ZXx27z05v949uNC6vnJWEyEuQQfN.zBOA0bgi_SQ5fP7jSOuXbCeNJ8jm6GFv9cfaEcA66 z6N__QulyiWMBnIva8dV2R7hgcc9FFPheofj3.H2YZgH3IPkDbIL7oRp_4aS09RKUn.Y3rSduZnK WKn5HvMnhkqS.C5_RQOSlxvKWpmwU6SUhBUw40RuvcsuvSe8muFupoBibRM6vjlxKXt5b1v.2tuo 6fkDNF6k0wuGWkB0R6wJB6Ag8BSlsGhEcIGGleDPz4rLLLwuxfJnxwbBD36dSVjI_6VNSP08EkfJ 81ZnYO3lU5PXW0B.81Btp8mDhuowaLSBP46pmsSTRYCz3aqUJvIt5cBk0AU1.4245OOulzDZjH7j mPmo3h4Qs5d_Zf9rGwqRmlV3baZ2rjmJw_9zfRxBD1lUFHzLdKMlFCh9JIm1Ir_A7g3khXNDrznT V5jS6sGlonlNeq.fxckFMHVMBavxeLdKk60dArkT8cYvMHVK60LgEeNqPpIP8sieg41fnUyo_6MZ 0f3z6uoQUu7SJY5dCcdKqnruzg2PyDgaqCB7UalVfe2AQa.O0h0DVV_LoeXpPE00IJpoxBjvsajm Wz6L2dJvGGp.xz_xIM6diDnQ0Tg9ZuIXCb.o2KI1C7TZG9cwF0pvLztfc9rJ__lwkmMrVJbtD6KO FqKDwAx2O6DFZi3NeuuSZtjMjBDsrp2kYhdXHsOHVX7bA_oM_vmAeOysjKesP1Y_pSOQrfCRkWIA AkblgpLdQFjb2O6Fm0jAXCVsxwo3hEhEvWwFn7nWofgxH7eKdwkRESzyYayWU_qoMvDtOykCEFme ieesBBniB9U9mhWFcozBHEhYlc9V59WbdUkTZVt2V8w.hcKP3I3.pRzs..cveXEJ3gCa9YQLATRk ahJDppj85W1HILRsk_WrH5.pB2Ps.EBc.7pRGsVQsIqEOwfEjfUyZDzLa4IOpiRi4O3IeRWeyFq2 oyvuP11plHAgnlszvvLfI9AFvYQ8YGqoGUIcM.wRfSvGVW6P.pLccpXn_YUIGRELACwRB3fyhqoK 40lWr47LSOVmZCcnRRHDMUwX0ZYCuu8F8_KNog_5ttbrkDRfPMsWleDRcPnlBLP71GQloF2Dyagp jF7Qzo7f6Ffen5JZp_7xKwwgWjmtQdafvCDGEgWo1Wsj8lPnZCtgfjszMC9EVq3mRxNyJufqLAq1 JP2vYNjc4M5XIkm241fNLKB5v5tRgKdBglbw3Ehzsf.iN2w.LwTbZyRAIwHXu.Uh5rk8RdBXit9O xjldbphEQuGIcbjEYWRGzcOa5THZgio2ZWgt8E_3cf91XTBMH.QvP9MagSizgrArreYMwu8hjkey WBqs0P.HRL2J.rvNSB.h_hD1F0zu8_Uj__0Ya1cvuLWffuuV17g7R2DoTdtCFmMR6DpetZuf2K1o a_Sl.u8e.ZaXNeSRN_OroiPD2eTUst4N6RwcYlt_SPzNB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 21:13:48 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5b652c571f08a0174d9c1f6407fbef9d; Mon, 15 Nov 2021 21:13:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 13:13:44 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtMPT6TVzz3vpv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JINM9iSG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 12:51, Mark Millard wrote: > On 2021-Nov-15, at 11:31, Mark Millard wrote: >=20 >> I updated from (shown a system that I've not updated yet): >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >> 1400040 1400040 >>=20 >> to: >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>=20 >> and then updated /usr/ports/ and started poudriere-devel based builds = of >> the ports I's set up to use. However my last round of port builds = from >> a general update of /usr/ports/ were on 2021-10-23 before either of = the >> above. >>=20 >> I've had at least two files that seem to be corrupted, where a later = part >> of the build hits problematical file(s) from earlier build activity. = For >> example: >>=20 >> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] >> =20 >> ^ >> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] >> =20 >> ^ =20 >> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] >> >> ^ >> . . . >>=20 >> Removing the xorgproto-2021.4 package and rebuilding via >> poudiere-devel did not get a failure of any ports dependent >> on it. >>=20 >> This was from a use of: >>=20 >> # poudriere jail -j13_0R-CA7 -i >> Jail name: 13_0R-CA7 >> Jail version: 13.0-RELEASE-p5 >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >> Jail fs: =20 >> Jail updated: 2021-11-04 01:48:49 >> Jail pkgbase: disabled >>=20 >> but another not-investigated example was from: >>=20 >> # poudriere jail -j13_0R-CA72 -i >> Jail name: 13_0R-CA72 >> Jail version: 13.0-RELEASE-p5 >> Jail arch: arm64.aarch64 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >> Jail fs: =20 >> Jail updated: 2021-11-04 01:48:01 >> Jail pkgbase: disabled >>=20 >> (so no 32-bit COMPAT involved). The apparent corruption >> was in a different port (autoconfig, noticed by the >> build of automake failing via config reporting >> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >> being rejected). >>=20 >> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >> system versions. >>=20 >> The media is an Optane 960 in the PCIe slot of a HoneyComb >> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >> used in order to have bectl, not redundancy. >>=20 >> The ThreadRipper 1950X (so amd64) port builds did not give >> evidence of such problems based on the updated system. (Also >> Optane media in a PCIe slot, also root on ZFS.) But the >> errors seem rare enough to not be able to conclude much. >=20 > For aarch64 targeting aarch64 there was also this > explicit corruption notice during the poudriere(-devel) > bulk build: >=20 > . . . > [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... > pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data > [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >=20 > Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg > *** Error code 1 > Stop. > make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >=20 > I'm not yet to the point of retrying after removing > arm-none-eabi-gcc-8.4.0_3 : other things are being built. Another context with my prior general update of /usr/ports/ and the matching port builds: Back then I used USE_TMPFS=3Dall but the failure is based on USE_TMPFS-"data" instead. So: lots more I/O. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 23:43:49 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 29DFF188A37D for ; Mon, 15 Nov 2021 23:44:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4HtQkr3L6Qz3jl1 for ; Mon, 15 Nov 2021 23:44:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637019836; bh=mUekWikUU+iYpvEwo2oz/STVl6wxnakZiVqY5M8itsI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jhhQp9UBKnJiHtdSbCuagjmtt2PbTZegHAuxN4SRrz54w6NiX8uYyynqJqwYHUWhirqOlW6hm3bCJNiVIMEELJyNv2bxZ3x4G1GbGVRkYNk/MeVVT0+2e7uZs5uswuxNfv8MA1Z6b9I81+gi3r+cXJzC6SIQEreyzo/k3LEB9Lgvzg0EVL8wdUIMWsWlU2fvlkeF7apGCOOwQ7C4AO+EoDirMtF3KTCXIdwF8h24k55/PJhDOJvShGnzFte3edDF0ST8F6TvoweKs1KbXTHZ2dVnhbDB7Smk5L/jLrO0DIGM+FRqUQgE/rSTOsw+2GrYyaeBVoZUFU7Ys5LEQEeM9Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637019836; bh=l4BMh9v281S3hHZhq/V4EYcqBA85ot9pqRJkc78XVfH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ja5mZYtLsNhn2luy091FxJ8ugMTx5uv++tZvH2M9cKXAxNSV+GaFWwtLSwW4700nO3zB/N28AuvINvjb5pkslo+CyeyCVtNjJEYKWljvK1QV26AObQ2J1I0bnc7ieKWusYfR//lHeXVaQ3GDK4vet/l8Vuux8WBXxQMuUkdj68B+cC6rxS4Sle7/A3oShMEh1iMVprreaFwVaDBKccDxUbwmd3ctVxKDf/40icNS9cW069g/cVY2UF8aY33plKvS7ODKUODNQWjXs+1+tpV5/Mm1Wct/OuOBG9A3kVFE/eF35XXSFwMXdyKf+8T853oJxIwNN9z/9VWYGrNQd4n0JA== X-YMail-OSG: hjiTR8wVM1mkXN1f6bza0r3_CTVT86vcM0xSb3SNVnast2BnX4r6k8Rz8GoM5Ps qLKI2NPCjpRNg4AIbs3xycKO_1OkdO5ObHaPvH.C1waQxzfXFE0u_FRjzuaPTgh3TXoth5oksRNo _UvQVZ7GAMWP0weEx2_7wp8a5xvmFj.hS_tDh_j23fdKK.ZELSV.FXSHuynYJgakL4N2q2.COfXH AL5VCKFETJ4Y8AgxvQcmi2EjankWs_eifDUWY8pElfFWJgVdKxYfjjOWH.ELSEszxuPNqdbfmDAC Ol.3ls1T9HO0KCRcjexJJvuHLiYfd3IhTwl6u5s5Bw524nD4sHVv5EOVcUqeLO0apuS1.b.lBB6Y zEegDCZOp25lQiymIaMpSTQPWrMAm7HhVNMq17nvpo2AHis4eyJ23ZJtwtJJo25gkLYuuuw7mnfE l4YmAFpaGHjC42JTKijHDOIdxm2.Q7i0_9h7RbEro0f05e1UYl6LjbO_S38fECYSy7zHdWTnrJ6W AJJwsGocpfAl.DLgcu1gH77fLTyEf7ZbwKcMJrdCLswVq0.6x_pCUqDL8TVKmSqzeBCLxUDGHOe0 1xgpG6xkooxiNKrEQjf8kIpBEqGIFBIkQctXjDkCzZlfv54QJsZ1_hhP0AL.T4FbLPcrVc_pbWdf C.ig8TGbLqntAyMbwbZV_rWFdiNwB6JYjZNU9HZrqufZ.2uL2COzFDdsqRvP5k8pWbmLy7xoP7hm DLoqmW2Bppr57.fEFEVnD2Mn4mbXQkG9VA1rYDI2kqopXlWT0vfP4ydDvbDuW3_3ZYYIwnunNuP5 7DFbN5OtXSBPz4b8Zbsf0guJCM8NuHqghJvq.uWmhf12bA0moHKJrlnSp4pAHBnQJ3v_A7iiWUWp pC70JvWuSzIJRGCJuzh0uPEV168D20fhgcqINij8B2zhLSSFeOHe_SIxAbQpOuUuAaYjnce_QBAC VZQQSZEQpWWLhHsEeVkFeZyAmB0KnoIeg4RfHiJ8Q4oGDYbX2vmagoMc14c2uT8GTB8T5epPTZoB hcDLxLdGfQCLr0gEopZtJTFA8Zi89YD1D1Vqh1ZGZBUuxg1sCesyQBiu3klzgE34sFda8IcbmsG2 .k9Njx5Pshko2y74AAt3yBdnpkB3Hbv8TjH77Dob2mMb.4ajHrmJfv2k34OstnPoJCajbzyAjga1 ZxEH8fzBEX.TPsKXFDI0moWoKqguT6knrABF0UkHJqmXrcuEfNcWAwMJ5368x4xNr.YRE1tV04JZ BZcNXTzYXwVWq1pw1bSSsdX6PnHf1CL7XdxI2m6puk4yBLRws5PGCkxlXWCoxLZWGV14QVUENebm DDIQBP5jHEyyf7ZCAWzOFNhQNjRqVqWmh7wGN9Q6H2FhTPES6LFxGUUngPw19sGp_27uaHtEjs.v vEmrV7BEeLvNOvhljUvL9Mm0rGXLbdwpBIQAc4U8eAPCPxCe6GXpaY2dFpwhrORCaJ0rLrewY0lF oirbcY0llXkSwhm7Oo5U5TekDf4Uy.QxMwH1bcJF_rAXmr3eWjqR8eS1JbJ1OQT7toDdc65d.fX8 ZxDt.VTqxBpKbHyN7flqDHLuFilWz8ATqjGLolIL_qSPMvVXVOeq1DVsQ_wrzDoINAoozAIbz1Xh IGdWJhG8F1eCmMTQmfZLQR1jlVehEW3pZc045T1I_v843AF0f2em.2u1vwFFYtA0tFt3f0K5QpGM 1SCoFyKHK27ABZ03m5rFia4CoO6mBP4L36ROnEZkxtmLU3IEtJc9hUFThXQuzO0rX4CBnVOaL3l3 AGdFsEvxKelHgMmiTgtaqkLMMl0t7IDp2AkxiQ2wxzv8rZBJYUOsseKFXiH30BAYCgYYY1BC1BmL Q7p2QEgC7zzAVFscOSNc8MjVEmWZpTn.XFHaUfCKEJrcZTv4XW8OKa6TDxKp27aLKwPhNZqOY.e. 0RBJ9lHyi7f1QRgWpZp48lIg5W.SfvnTqi3o5aM8Erl7v1Kbgr4qiZ7ZXb8UlX6p4osayuEPxYC_ 00ZjFG4DWZktrOz65O3dPbOzf7rNVErUwDWNa9n.EogO3SYwW3zfIxi7E7Cr4yd9mJnQps3dH33P J2yTTteeCdOBjwShEPwYPFEFL.hxm_i.mtN_O4Wja7fok_gSghrP9PVaDnji9JOAQA_vWZueq.eY BtgH8O8gNdgRpMNNrfYpygBWWzKt8rDdbxZ6RaEG96_zd1OFXWGHKnV2ZAxKqpFJKxAsxAekD2Wu 3_HvqJQKEAsfzuYXYHphmvg8sYCkT72AxZUM7ev0bhSsL5Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 23:43:56 +0000 Received: by kubenode522.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ed2e5dd9852d9e679eca91269152e810; Mon, 15 Nov 2021 23:43:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 15:43:49 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtQkr3L6Qz3jl1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jhhQp9UB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 13:13, Mark Millard wrote: > On 2021-Nov-15, at 12:51, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>=20 >>> I updated from (shown a system that I've not updated yet): >>>=20 >>> # uname -apKU >>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>> 1400040 1400040 >>>=20 >>> to: >>>=20 >>> # uname -apKU >>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>=20 >>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>> the ports I's set up to use. However my last round of port builds = from >>> a general update of /usr/ports/ were on 2021-10-23 before either of = the >>> above. >>>=20 >>> I've had at least two files that seem to be corrupted, where a later = part >>> of the build hits problematical file(s) from earlier build activity. = For >>> example: >>>=20 >>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>> =20 >>> ^ >>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>> =20 >>> ^ =20 >>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>> >>> ^ >>> . . . >>>=20 >>> Removing the xorgproto-2021.4 package and rebuilding via >>> poudiere-devel did not get a failure of any ports dependent >>> on it. >>>=20 >>> This was from a use of: >>>=20 >>> # poudriere jail -j13_0R-CA7 -i >>> Jail name: 13_0R-CA7 >>> Jail version: 13.0-RELEASE-p5 >>> Jail arch: arm.armv7 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>> Jail fs: =20 >>> Jail updated: 2021-11-04 01:48:49 >>> Jail pkgbase: disabled >>>=20 >>> but another not-investigated example was from: >>>=20 >>> # poudriere jail -j13_0R-CA72 -i >>> Jail name: 13_0R-CA72 >>> Jail version: 13.0-RELEASE-p5 >>> Jail arch: arm64.aarch64 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>> Jail fs: =20 >>> Jail updated: 2021-11-04 01:48:01 >>> Jail pkgbase: disabled >>>=20 >>> (so no 32-bit COMPAT involved). The apparent corruption >>> was in a different port (autoconfig, noticed by the >>> build of automake failing via config reporting >>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>> being rejected). >>>=20 >>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>> system versions. >>>=20 >>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>> used in order to have bectl, not redundancy. >>>=20 >>> The ThreadRipper 1950X (so amd64) port builds did not give >>> evidence of such problems based on the updated system. (Also >>> Optane media in a PCIe slot, also root on ZFS.) But the >>> errors seem rare enough to not be able to conclude much. >>=20 >> For aarch64 targeting aarch64 there was also this >> explicit corruption notice during the poudriere(-devel) >> bulk build: >>=20 >> . . . >> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>=20 >> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >> *** Error code 1 >> Stop. >> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>=20 >> I'm not yet to the point of retrying after removing >> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >=20 >=20 > Another context with my prior general update of /usr/ports/ > and the matching port builds: Back then I used USE_TMPFS=3Dall > but the failure is based on USE_TMPFS-"data" instead. So: > lots more I/O. >=20 None of the 3 corruptions repeated during bulk builds that retried the builds that generated the files. All of the ports that failed by hitting the corruptions in what they depended on, built fine in teh retries. For reference: I'll note that, back when I was using USE_TMPFS=3Dall , I also did some separate bulk -a test runs, both aarch64 (Cortex-A72) native and Cortext-A72 targeting Cortex-A7 (armv7). None of those showed evidence of file corruptions. In general I've not had previous file corruptions with this system. (There was a little more than 245 GiBytes swap, which covered the tmpfs needs when they were large.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 17 16:40:36 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 2754C1854E9E for ; Wed, 17 Nov 2021 16:40:50 +0000 (UTC) (envelope-from m.efe@mailbox.org) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (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 4HvTFW5xmzz4ZBf for ; Wed, 17 Nov 2021 16:40:47 +0000 (UTC) (envelope-from m.efe@mailbox.org) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4HvTFN1XNSzQkBd for ; Wed, 17 Nov 2021 17:40:40 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1637167238; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jqnOj6qaB2J9m1vpBqvKix3kASrYttMR8UdspFi7HuA=; b=LpZJc5s9mGlXkhU/Ihh124JpHv9O6NTjPncpvA/XDJ9e2YinDYWA15h88zW6ylLHr7VZ9y MEMecrmOn6y/L9YzXGWJFwZyiCj3Muj3UcvqHCRAAnkvLW5J3lOF0WAK6hiZb1MWVdbyvg IfF6KiOi/+OOr3sKJSo0EiorLekGSTv/JPHx/KVNode5Q1Xfl0hhbFtusvlSak8oVRrP2m onys4UF4BXUIZ5nabU7pW8MWJpiyuvtPGH3FSq0VVqHT243bkxPfBEU1l1nq53Ggn9Tghj HeottpyXWSw0gW2ROnk5blBcq2q3Dhf0/mtYAcrc61a00iEHc0q6+oTABdBCMA== Date: Wed, 17 Nov 2021 17:40:36 +0100 (CET) To: "freebsd-arm@freebsd.org" Message-ID: <136528742.227697.1637167236577@office.mailbox.org> Subject: Re: RPI CM4 boot kernel panic 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 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Rspamd-Queue-Id: 4HvTFW5xmzz4ZBf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=LpZJc5s9; dmarc=pass (policy=reject) header.from=mailbox.org; spf=pass (mx1.freebsd.org: domain of m.efe@mailbox.org designates 80.241.56.152 as permitted sender) smtp.mailfrom=m.efe@mailbox.org X-Spamd-Result: default: False [-3.08 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[mailbox.org:s=mail20150812]; RCVD_IN_DNSWL_LOW(-0.10)[80.241.56.152:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:80.241.56.0/21]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.241.56.152:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[mailbox.org:+]; DMARC_POLICY_ALLOW(-0.50)[mailbox.org,reject]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.98)[-0.981]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:199118, ipnet:80.241.56.0/21, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[mailbox.org:dkim] Reply-To: m.efe@mailbox.org From: M. Efe via freebsd-arm X-Original-From: M. Efe X-ThisMailContainsUnwantedMimeParts: N I don't see the patch or dmesg log here, but can confirm that the issue still persists with the latest FreeBSD 13-STABLE snapshot. devmatch_enable="NO" in /etc/rc.conf indeed allows you to boot the device, but only as long as no PCIe device is connected. I tested with different cards (I350-T4 with a Riser 1x to 16x cable, VL805 USB 3.0 Card) and ran into kernel panics every time I tried to boot. Just calling devmatch also results in a kernel panic. Nevertheless, my device was running quite stable for 2 days building world, kernel and ports without any brake :) --- original message --- There's something wrong with rman and libdevinfo, see attached patch and dmesg. --- end of original message --- Do you mind sharing the patch? Btw., I assume you're using the standard IO board, right? From nobody Wed Nov 17 19:17:27 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 6253E188B708 for ; Wed, 17 Nov 2021 19:17:39 +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 4HvXkV2d1cz4RPZ for ; Wed, 17 Nov 2021 19:17:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637176651; bh=dDfbYH4xavsLHtllidO2NoN+PYuhji5v958VppA2i5Y=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=cxt1dJrcTe6LitCgMM1KvENW0FgE8H7SLJjUHkz63pXwK9NafxiVC0adypj23wh7EyCJGBI/guEeRApV+Ril98nAZ35pipTW1mkaKoQeZL8lkSyMPPh/JN9vgwHPrtEMZ7DLxwESHEJa2N0kT7Ib2iDoPieSWm1EFlRv4MUOojIfx+NxsLC5R6rDyX8zCl251GCbjousgTlelaYYEPZXSkA4frWGr5/eEc69Mh7DvenaQZTDNdtj5rJBH7YOWLh6oKqxHCeRhWIjVWBrSPHLEyeB8nY3hQ+iRUod3L8PdCsa14aB1GeQQAn484FSpWAADRcWpJYt2Fp3mvu08CUM2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637176651; bh=X9/4FTtrNoOph1HdFKGO+XMeT4PD3urrSr4exYPkRtf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SReXMGkG+hmF7/iJo337KTsay3D2p91cWRNNN3nra/LXd4r8DDWUjqPDU0NK6p2JzmTZkChPcPkA6QNZ4SC1npF9E18n+PhOr4foN80+cznqyuMYQZ6IkXAq6jcoluKNQUFFKiwEeI6KarkpM/NqOdrBTfUD7V2eheLPcbY/vHlNlhzNA64doldjFGq4P+vru4XFfA/O71TUUkaSBBgGlAF9QqWEp3gwXw6zSRr7veHfHGDg9pzjpm8SuMJsZ7TCNznK8A6JGKLCrNCukZLIl1QSxJRnpZvt79cVeYspVM2PYB8k0wOnK01vQg46PEL8oVQrKDBpl/zcIOXL5oUaWg== X-YMail-OSG: oJPqCE8VM1k3U8YNDXMkc0tyUNjp0HqxiPP05x_2sU41sFzQgJrcQLenP_Tps3k coksqHFXCdd46sR36y3CVTU9kzBRoFA2ud4KR.PEXvpM0RIMXs_2d_5g6f9CPvoDF2HwIfwr3fol blNW4hHYW6iRZQC56YsNyexIJ1fe.I6RN.TNcU8pIp530rzV8CRMWlz5WDCxJPjKOMaxuc0o92iu lb.d8CMj1auG1icxM72UugWTtG9zzyHE3cS__EaVkDNX627HkWpEMec4RVAj1I4tj4IQZCrgM.t1 gNJEQq6.Ntes0w_d5hx8n53MugnPQQ.QoXHHwF_PEcOPSCcOkk8eChQvqMbRBPouXhl_xufqzmbG X.s5CPO8v53KF09i6BmdqvcQUXW1mOdUf7lAkfxsonlKCzLNv8IZTFh59VJyGisLCMzkyeY96qZR pRMw_qKE_WkjV10Bhb8gRZhodLmDejxS4gqbxr0fzcAgivjaw_5X04rwjGaqh8948pGV732Avj9p tSpdY7mX4MmxTugO2EFY1t6uUr56Cff2.mA.xkmQx1ceDE83Z_ob6ZMf5IC26XhlCVJEAbtDU0AF P7rtRmQ9jshVBeSNZT_jPE6Efd5UcjdiRceKeXfDB4z6HZO1BFnv_x2ADDFjtM4dyASCK20NjYej 6Co9MYk1DwbhdIfXLClyMuZ0AzwkoSwL9zWDBN1LaCreicLm8MzGRmxme1vCLEP.JtEqdd4ALIcG BoYh4528OWWPvhANW4hElKor5NzG9vjesR4jFx5fg9_BgpIjdLdGRPp7xv6Rgedw4nSOIJrpCDIK IO5lMp6uESVMYqS4yuytEdaK16C4M.SlLIi2p2KMixqhxlAAdeteNeyncPhalIGOW9KHJMS97DuH 34Spz42HwXcOojjkiRwuIssn8rgNl4LAlHy1vAwPf8i99_JBZFcYRZDmIR4YCCu4wXNXp7d.gWWU 3WEru.fCWjAMoMzBWTpgT6GTjal0KSc4bTDYz9uQ3fSnMzjKDU5hP5QrxSA61ZD3hCVR1dhWuXzP UUWtaZvk5rSYjn_CtSmVpLpsdsKD8hvuiBhtjfWrXBH_mEX2wDXnrJKy0qEiU7XGZFjboTL8TzpN GLL5tuNjKYh2gLi.L9_pizGbXS.8d0wMBLtuxqYFG_CEZ8fdx3WKYPWRRWRQZg6e40Iv96NPnOEI ZCHwS8exTK1zPI6LolDNcpomIVeaWUE3tkuefOC8FECvYWgKYOyqONaNjCQATkART4VmWCW06mmo QI5IZbLDorecaM1Tz8ullLwgubHK8Ek9cG8tIoxE7JK7Uvk4M1ZL8svHuMvPdmJmGoLyXsgh.kLj csgaHwgEQxs6N6PR2ImIEW87eLd40aph5xDqvWMJcbWk2wgynUeyUhYuNmrKvh76VotqZv2NYqpk JGDqWto7iBtQugCjdonG1gwjqoWzJev2VSc1WTplZ91G5brIBki6KR8KJnTjRAS_kmAHLXdfqgIh 8lx498rIyUjsB4XxuZywzIHXXg7mtJBN0du9VOunEZMQM6R.IcomKg2mahhAJmnZfC4guUqABC6q Z7wTMiR0TfPOUeGlJxryUYpyAmaAsdTQE4VcEbGOc2SO.OT.8vdH.RgahdX63Pe1m1oE4I3_F7BJ LqHpRCudxxOwTc3yvi_WzCvcY05XKB7.qQt4FtH1ZeO2JxyAALCkq5bhnaLGvTxOkWmSEChiBVNH RvwNKqfhpGrHTpVvGKSVj2al2qnA9RfTz.eCu7SaIYu9NTRJfaoHrWdAokq1RRKqjYBI.XUaTk.V gdqO9oA00kDoghwDmSDg0onGTpVsQdyXEb_yrkNVDa4jEgTgkIwRJEkRBDOutJYkRgzASSfCEZGe pwF3ibCELHeq6r9BebLuNLvQ0fGtXKFSCsffmVYt1xROZ6Xerrxw_X7QqTmq8nXA7wrzIyweI0kY 9G4dXSEbVaqN0c2pMb9VqWqgigCOS.TECW.ThFc0QC0X8b1PxE9rgMX2GwEfDndwOewM_SwAExK7 HO_4LrW8VJgKt6S8aYPtMSiy5wsM8Boks447uwI5Rvb2MVd6J93QWPdo8PziY5t49MId6_k_57ui LsC38mlGT9SBmeo.8Buwd38orNyYRjhcfMNzbaAAewpnBoVhyMJLw2kpSQ_OHFN.E1GLyb6hFxzw 3wnB.9DC.rHx8rtZ.JRw1fc7uRA0GXr1P17WSswTgHHEu97rP1WoBA0tKkaQS5oSY..1Jt9sGjAC GxUwVTHIgQycZVP7TFgW6i2ufAZRv9NWpPijP_1VxeMUp8Fm0.s2_o0rs.1SAoqnfizZQ8tBStP2 5cHgFLUrXFf3YIYgWAgN7rA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Nov 2021 19:17:31 +0000 Received: by kubenode517.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 64521ccdb33749a612aab2229e750149; Wed, 17 Nov 2021 19:17:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Wed, 17 Nov 2021 11:17:27 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HvXkV2d1cz4RPZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cxt1dJrc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; 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] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 15:43, Mark Millard wrote: > On 2021-Nov-15, at 13:13, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>=20 >>>> I updated from (shown a system that I've not updated yet): >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>> 1400040 1400040 >>>>=20 >>>> to: >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>=20 >>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>> the ports I's set up to use. However my last round of port builds = from >>>> a general update of /usr/ports/ were on 2021-10-23 before either of = the >>>> above. >>>>=20 >>>> I've had at least two files that seem to be corrupted, where a = later part >>>> of the build hits problematical file(s) from earlier build = activity. For >>>> example: >>>>=20 >>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>> =20 >>>> ^ >>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>> >>>> ^ >>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>> =20 >>>> ^ =20 >>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>> >>>> ^ >>>> . . . >>>>=20 >>>> Removing the xorgproto-2021.4 package and rebuilding via >>>> poudiere-devel did not get a failure of any ports dependent >>>> on it. >>>>=20 >>>> This was from a use of: >>>>=20 >>>> # poudriere jail -j13_0R-CA7 -i >>>> Jail name: 13_0R-CA7 >>>> Jail version: 13.0-RELEASE-p5 >>>> Jail arch: arm.armv7 >>>> Jail method: null >>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>> Jail fs: =20 >>>> Jail updated: 2021-11-04 01:48:49 >>>> Jail pkgbase: disabled >>>>=20 >>>> but another not-investigated example was from: >>>>=20 >>>> # poudriere jail -j13_0R-CA72 -i >>>> Jail name: 13_0R-CA72 >>>> Jail version: 13.0-RELEASE-p5 >>>> Jail arch: arm64.aarch64 >>>> Jail method: null >>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>> Jail fs: =20 >>>> Jail updated: 2021-11-04 01:48:01 >>>> Jail pkgbase: disabled >>>>=20 >>>> (so no 32-bit COMPAT involved). The apparent corruption >>>> was in a different port (autoconfig, noticed by the >>>> build of automake failing via config reporting >>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>> being rejected). >>>>=20 >>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>> system versions. >>>>=20 >>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>> used in order to have bectl, not redundancy. >>>>=20 >>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>> evidence of such problems based on the updated system. (Also >>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>> errors seem rare enough to not be able to conclude much. >>>=20 >>> For aarch64 targeting aarch64 there was also this >>> explicit corruption notice during the poudriere(-devel) >>> bulk build: >>>=20 >>> . . . >>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>=20 >>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>> *** Error code 1 >>> Stop. >>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>=20 >>> I'm not yet to the point of retrying after removing >>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>=20 >>=20 >> Another context with my prior general update of /usr/ports/ >> and the matching port builds: Back then I used USE_TMPFS=3Dall >> but the failure is based on USE_TMPFS-"data" instead. So: >> lots more I/O. >>=20 >=20 > None of the 3 corruptions repeated during bulk builds that > retried the builds that generated the files. All of the > ports that failed by hitting the corruptions in what they > depended on, built fine in teh retries. >=20 > For reference: >=20 > I'll note that, back when I was using USE_TMPFS=3Dall , I also > did some separate bulk -a test runs, both aarch64 (Cortex-A72) > native and Cortext-A72 targeting Cortex-A7 (armv7). None of > those showed evidence of file corruptions. In general I've > not had previous file corruptions with this system. (There > was a little more than 245 GiBytes swap, which covered the > tmpfs needs when they were large.) I set up a contrasting test context and got no evidence of corruptions in that context. (Note: the 3 bulk builds total to around 24 hrs of activity for the 3 examples of 460+ ports building.) So, for the Cortex-A72 system, root on UFS on portable USB3 SSD: no evidence of corruptions vs.: root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions Both had USE_TMPFS=3D"data" in use. The same system build had been installed and booted for both tests. The evidence of corruptions is rare enough for this not to be determinative, but it is suggestive. Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are not differentiated by this test result. There is also the result that I've not seen evidence of corruptions on the ThreadRipper 1950 X (amd64) system. Again, not determinative, but suggestive, given how rare the corruptions seem to be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 18 19:32:25 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 0A965189576C for ; Thu, 18 Nov 2021 19:32:39 +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 4Hw91K48f7z4RVw for ; Thu, 18 Nov 2021 19:32:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637263950; bh=d/RsYBSbT/durKvRCe8sqhVGNqZXxFAzedGkfKpcrqQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CH5lfUHP/C1Vp4Z/H7sAI8kFy9fUtc1mQUdKbXL07mL5FCsgPp7laJvUJJik6eOwgzhCYxfo9EWcFDfWQCKGNDBtiU4Aek8IfMent+4lWwa5x2/zEjGIc9vWZ6r/Lh46ySPJSYOs39dmpL8xUnqRxCWg2wujydnjyAuRNnNOSbeI5iR1LXXFtYNYmLcc528auee+Dn/N3DAh7mGBPJ3HDO465lkHeCcBKnxUggiCz0reIDkUn2SX7AsPwyEZ6AHDPOSeYirFpCkEnJJw4ieHZmfmc3tkKQ9TL9EAd9WgSUwskE1D9mUO0ZQfQTujTfjUcx1vYWfY44qA5bMv4j2Jjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637263950; bh=j8Z57J/6nqae63DrGumaH5GkrtqW4c5/INpAVBzt0/J=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gZ1nh4SRQq2V6tKR/TRGPAiAcl517Vsn0gUV14KVmsmnMqWi0mGol2U0PTm7uF2C8CMdHd41kXxMbnC81BxhDM0XkKMxntwq2g7f6EL08cb+2wx06ziXS6rUL3qjSRjFvyJngyDccLUv5l9PLnRdaXTxBgOyFZmyAjk+em7zKh0oNiweNoJdOmW7SDYYIbzE7KSV1EFet53LHJ6Ml3k9+unUxus0WEgkOy4K99zJ5UD5nnZGpqv1A9GyzrnwEY4At/E8cgj4XHu9eBV4CKmCrCu2IBRg66xB5Ff4cYn+dWqCwC9M42qpBKhTB0xOvbK9pNKDPgamoz3QAELTNESdvA== X-YMail-OSG: tU7BZVMVM1n01Th6En2Tx2LDn_nzzPeT4kW9FwdyD.McSSD5tk29K5_fB.tffFl AGkKDxv5dev0vbqyBzb1dvhEyOZMduAu_85eQJaJX196r.d_nOQLhOgHB.iZFZcR4XxSal2kTjMf qzByTqk75U6VGYJ9ZT79.a5QnvqvtMdV4fDaGRAMPVMjuW3xP9YS5arBu_3m4JCX8Dnl3JxE8u1Z OVMJZisvZsTz7Ui2sdJ9CAn9YNuNFfmFPU0cgvcagg5OZcXLMpnWjm_CZ1kE2TdtJXTfE6aAV6L0 iyd8U12MJR88JieG5yUnerbipCUpcvEp8ZlMJgQwg7gNj2fVk5tJNk6iZ1hTOOSm7scZvUnNZxF3 V4vKRFBM6G7JPVBHtOwMUon1TXuB1WoS2NOtbuG04..gOWQWJ.1qKQGX9FT_cFPOcS3SZnLnQBTW NcwmaJBUk4C_Z1KxhzRJN91FoJPY19y1qyzAFA9f7Em1fVi8lq3kZXEpQY_QAozIeDLf6RAdBvLy mmkLC954Q_PBcOVD3sCanzxJW5w6IeA0nDjUsg4cH5x9zFCLq_v1nvod9uZStSz5N9982qLLf1j8 H5kTae15uvsPSleiOlDhP.2rLKrHr030fs0AMnb_WoW.3DMqDcMCSuaJFkUyL7DKH_BDOMB0wNZ1 O.F9zY8PM3PW5jDJ_1oteywGy1vQxmFICrVEjoYhXbqhc3fsrvvxw_baZVD_J7.JY5AYG1Q1_ABV J2agly9CpH4JALNBQy0ucaq_oE7eC4kXQt94Y._rluqbzCfcQrtEYKkUuBqIJbbUP4q2O_KLA.sE fquNVKDv16qxhX9W4.0qAoWHcMVwsb7fnLV5TdDAxzc1BMsOaRIvQd8ovnEjvVlvrsQ62EKug45e sEGxWNEFOPFE1bvAlsaNnTGAuWmsRqSxuPpEefAqQlx1G9LXmIIsEJNrstQi24btlDL0ZoO81GXG NyAbKIptJgog2QtlGYCnJ_PPtrUG8bCLI4YWTQL1MtXmdIlvsDCcJfPlRUWtuQ3ra_OeGmbUKap9 PH39aBFBq4PeKrMeGDaTpdvEuqsLY6Pc9HbeTYiQ6JN5t7p77noJx52_h7ZjfgbgGpv2_txpM814 h0M_aRc9sxh_2xDkbaq75DKKrdn1kh02l9pkUNU_lF4uxw6bCupcYttbgPkhbTgFQDt41thqBOne Pod5qIP6Z0jXXy8.DAAgtaH27NGIAe4231EDn5.1hBS5ex_RC.oLIsW969KaigVh.J._Q1W0F2nt vZOCDfJ1BtfYpnWY1u2doDYS59ay6.bT_40KhixLjpyUaElYOWihZaMpaApHtMYA9gXrJILnIIXc RQAn5kjz0KUkkxE4iqEHfkK1fra..R_1qaLbZ291A2vvidxPQ41aEw0LwrzJY_sAL7QnNdduoOIM RPy.IVbKbbmnjj0Ty9reVoGkBLMKqqsYlP6Y_2ye_rADJCMkKuV070he4puTTsKgp3yiap85U_wp slgNLc532390JYWH1.rfV1lcz8juhhypw8vNdd.UmeiEl9i8l8mbq9.h7LAXyYlv6PRS4P1R1Xxl h6zUuIqBhhfsgnqWJBn9q17IhjzCXJ9UBjFtd8oXRtT_pavszSF3oW5QiGTM0BVAZEG_obkDMLF0 ZDVa9szizyFhx6a85VKutvv3EE1xkwBgcyYyPcr09IH250awUi4vj9qEVZ7bAvEH4jHIzKcACg8G xTTzrx_orxqtRC64iobSKSq8amuDMLKpBuaZ8jDj6un.iCCd7Hp_FxkNafc6puTtrbuj1mXVci2H PTIwQjH3RhFw35C7VrFtkZYC8tEpUyXgzReVTdpnIjw6_EOmlAjikG_MFpFRoj8D9_z_vqg8qY0K bIQyOvOHLBfL1wQJL6KBEDI.Dwir0i2bWceoN3mcZq8dIdk16WaGovviQ3wIs4.Wc3n_pK8JQHG2 3vIlEnKeX8dtRjPcr9zQhPxx.Y0gUm1jPk3zFDTnA_E78XK8hGxomfwDisu.KJCq.2iX8H2ysLMb fHlEurjubyalGjnqZhK_rrm9JHWd8Qvbl4KFmEd8syVuQfa47ttRtqmJDsxQIsn.9Xq0eLPgn_Os yzOQ4rtJFFAV2iNsKq.vzA.cjH8B0RxH5.ZtPPUB_V9uW2hisLnWDyA_vbzRpQRdmw0Pq2kUS6vj vg19F2o8Fci.q6B_get._rzf.5w_UHpQJBNg477SY_0dtqypwbxFsgftBVB8jPLOxGlB7qICiOys Rca.WKwYXq4kUgoGWork9mjKqrwQ2fSsakXuMI41dUF_Ft2POb5nwvRiQysCmlpMaiOAc3IvicIj OZDFyfPz0Bog- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 19:32:30 +0000 Received: by kubenode528.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c925c5342a5fbc652514950bb46c0fe; Thu, 18 Nov 2021 19:32:27 +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: FreeBSD 14: Poll armv6 deprecated or removed In-Reply-To: <341A49EC-241C-43E7-8380-D2EE2F8C59F4@yahoo.com> Date: Thu, 18 Nov 2021 11:32:25 -0800 Cc: Free BSD , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: References: <341A49EC-241C-43E7-8380-D2EE2F8C59F4@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hw91K48f7z4RVw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CH5lfUHP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.205: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.000]; 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.205:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-4, at 14:18, Mark Millard wrote: > On 2021-Nov-4, at 13:39, tech-lists wrote: >=20 >> On Thu, Nov 04, 2021 at 11:53:18AM -0700, Mark Millard via = freebsd-arch wrote: >>=20 >>> Without one or more developers willing to keep ARM11 based RPi* = FreeBSD >>> working as FreeBSD updates, the code will break. Other architectures >>> have been removed for such. Folks that do not want to work on such = code >>> do not want to have to work on it to keep FreeBSD building and = operating >>> for other architectures that have active developmers/maintainers. >>>=20 >>> If there were active FreeBSD developers for ARM11 RPi*'s, the = removal >>> would have been unlikely to be proposed at all, even if the use was >>> minor. FreeBSD is driven by the developer context directly, not the >>> usage context directly.=20 >>=20 >> OK. I can understand that. No developers want to work on it so no >> interest. That's straightforward, logical, bad for me but I can >> understand it and work around it. But that was not mentioned by the = OP. >>=20 >> On Thu, Oct 28, 2021 at 09:44:20AM -0600, Warner Losh wrote: >>=20 >>>> Given that the number of available and useful armv6 boards has = fallen >>>> to almost zero, the time has come to look hard at armv6. >>=20 >> I'm objecting to this because "available and useful" is impossible to = measure. "Available" is going to be a very large number, because of >> the number of sales and popularity of these boards, and that they are >> durable. So stuff made years ago can logically be presumed to be = still >> in working order. Even if 0.1% of rpi1b users used freebsd on their >> boards, it'll still be a big number. FreeBSD does not record anywhere = the context in which it is used. And "useful" depends on who is using it = for what and is an opinion. >>=20 >>> NetBSD supports a lot of systems that FreeBSD does not. That fact = has >>> never justified having support for those systems in FreeBSD.=20 >>=20 >> I'm not saying that. What I'm asking is the reasoning. >>=20 >> "we don't want to support it anymore" is a reason >> "no devs are interested" is a reason >>=20 >> "the number of available and useful armv6 boards has fallen to almost >> zero" is objectively false and so therefore is not a reason. And = because >> it is not a reason then justifications following it will also be >> incorrect. >=20 > I'll note that: >=20 > https://www.netbsd.org/releases/formal-9/NetBSD-9.2.html >=20 > indicates: ARMv6 (Raspberry Pi 1 only) >=20 > so NetBSD does not have general armv6 support, just support for > the RPi*'s that are ARM11 based. (Another page mentions RPi0 and > RPi0w examples as "expected to work", although needing FDT files. > See: https://wiki.netbsd.org/ports/evbarm/raspberry_pi/ and its > earmv6hf material.) >=20 > The lack of a variety of sources of armv6 or ARM11 that NetBSD > supports is likely a kind of property being referenced: even for > NetBSD no other ARM11's are targeted. >=20 > Basically, even for NetBSD, one has to be interested in supporting > (some) RPi*'s in order to be interested in supporting ARM11. There > is not much of any other ARM11 market for NetBSD (or FreeBSD). >=20 >>=20 >> I'm interested to know what NetBSD's reasons are in having tier-1 >> support for armv6, but I'll ask that on their lists. I'll also note that Fedora is at the proposal stage for removal of armv7 (yes: 7) in fc37. From: https://fedoraproject.org/wiki/Changes/RetireARMv7 is (in part): QUOTE Detailed Description The ARMv7 arm architecture was the second variant of the arm = architecture that Fedora has supported, the first was ARMv5, the third = is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37 = release. This will allow ARMv7/armhfp to be supported until the Fedora = 36 end of life in around June 2023. Overall arm32 is generally waning with generally few new ARMv7 devices = added to Fedora in recent releases. To add to that a number of newer = Fedora features designed to improve speed and security of the Fedora = release are causing 32 bit architectures in general primarily due to the = process memory limit when linking large applications. The ARMv7/armhfp = is the last fully supported 32 bit architecture, we still currently = build i686 packages, but it's not shipped as artefacts. Benefit to Fedora The primary benefit is to maintainers of the ARM architecture, the = various toolchain teams and package maintainers in general. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 18 20:15:24 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 E4AD0188C49B for ; Thu, 18 Nov 2021 20:15:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4Hw9yt3206z4gls for ; Thu, 18 Nov 2021 20:15:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637266527; bh=J5jTDIaTnEZkZoigEBqXE+AgCkZprZHN4kz4vMa+nd0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jPQ+PN9rOwtoNQdj8UK47+zCMS3Xq+pIIIQJzafw4K+cVI0pR0CqAc7gGXMDEvp5VYsU+D2UFkayiiMmWt+G+LdBmU8EkzqNGsN+9GJTBrmkL52mTUvQmQKHTx8sMRYkKNVaimclqqr1hYxN2v2YA3Reh4pKplmlH0iq9iaB7qI/4X8drFaQv31f5dFguj/oBnTP87oG3XZy+RSQYSqw8zGm0gOP6RXEqJiU1+N0iPPZGi6E9yjsubjgfn9RQJYX2apo33fO8tj/vdFQtyWpgXNbEOZtSofuFXKaJX5Ea3F/DYCj3gsz5pu1K2l5Rpn7KrGZ+o10ExgaHsih7oig+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637266527; bh=22TNxPffxf7O4ZS25ulyT9IpWTp0oSxF8C2IRXdmggt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OtPgkFlsYOZo0ueOEput32mGu4zEz0lY1jhF00IOYf96dHozTDt+aOzrbW4paCu3qy10YDheDpM+awhcmpZMA4BpAdBQ+DPplpaUok5tDF5kIrW1ZhbGqwLXWgmHHv3ckNI/UQ+ItEs7aSdE5CeS0dMW35+F8O5wum/XGvS/jsfAIC4k1TSOna+RP0Ke+O6yyQ1ncgTkmF/ALLp/z9TULlD3hQ/SFNd9O3k15JtPpMdsfoCbsOr6ow8ur65eRWPJK6Ltdn2r3aAuU/62cvIjUuB0Xdft8vF9TFuEX86Dw4U0qs9gidY/4GGiMmaiTV27jQ+x+R4b0bT0v4xgFZoNNQ== X-YMail-OSG: iJQVXacVM1lNwdySzIF0T1h4BvJBeaVlYFk7da7Wlyef06G2QJsNQPWp4YmSNX_ CZsWrJYYV73UWrvCzb9B8zbrNNjAgXpI45qklwTp5LMgnwJnc9ho32DKcYH79p8Yz7ksPNwFaPpk Dg9NKKoPGL0XjhLWf6zLA.okwH4h1cwzYglZ3GoSkArxGPJ.E2nm8Unn5epmBzU08zfN3Crt_z2a VXxaJ9DWorh1NqCgfAvYqLFumnKzS9E3gYsyY2ioT7kWKAbDdlgBrIcZG18vqMPIvx.HdVB3B033 1srElwg_9Jqp0V.ksFYgg6FMh.a2FB.cxq5lyByc3ikDNAMl3bxq3ZwHulnZNb_iXq2hJiLyqrXH m65lXZ_ts6knfXPwdNqQzqY6dmCZ.iqD5cka7rkc8e3Ld5SuLRrVRUDR8kVwY24h3W7iouculGmR Cq_pNws01zBEp0WkPEzu5oPsGrl5KlqUE1gLbVbNKtCTUoC05735.5dQuHkVh1KblyBtUw9cQrwf YJCFZoNuV9haSeEaWwFb5MrL5s7Y.2l.5fX6_TKq_Qq5XayK7oh.wXMxoycJTHlr0WgHQG8Ax._W nAIs_8cHrSZWL3xIOf2c0Y9CfxbyLo0TFnLNXAItShL1DfNzwuWfH7KK7rWL_OS7Nsap7CO7YVkE XLHHAiz8PF0pVaIYknGNb4Ml67Pn.loYpsrMe51ON_6KhBIQN79m9I8kjYF0AI.ve31JVenWEo9v UDnot1sYmASroxfvjwlnpX3VIvsmL1gmvq4WLPcpSGo7FEp.HPjZmJJBQ5_9Bc0wSu81mPZKbtOq s52b5NVTija.hMVmyMPUIlGxawoSTXFThc5n6BWmCB0g6VPyxwzJIGZXagnqtCvbRt3kbXAIgCIQ fW7v7leydEDEIyf.eX7FrJ6mrsM6JDXOld409Gf3hE8cR7.4HX_D9hVrc_7okfLoku4qLrYwADZB Wqn_pDjVwbHsKjX1.J1M3_NLts4qDdHbcfZIFYRXh4Mu6xT7Wd4fg0KcFt9lKaOm5VK7y4AdQiDv mzwYE1U50lajNorcvRUbmX91rtvFeXD3snrgHJZ7Xc.NZBe2fYWs2G0ar1Zo8LDBuh5aYr56N37H c26QLoDveSAmcKr6hek1WUcUqTrPZlzgfuN9wDfxHQozmw4BRw5eiCAXObHKcEctagoS2z9_KnQ9 yLs8oaqNoK8Zx40866_CefYGOVP3jXddPt5TB5smy7yO2ScNNenfpQX.rPZRTQmLJduwt9Yx5nEI ce0Y_uEZFjFJ3XtZDAS3aYPB_TWRxHn1PlpbZdNvYrfsnkgzG2XqU0wsE1DYp8dHWfwZ9LdyudOZ OPLq7AbQdB5PTZIL5kONxfqe_whxBRgH3n8_eyL3J44zhOpJJgc6vQH3MEFxBW6wUMslAwfreES_ RD6fYvXwUJ5dLBl9btC1aszAMilSJIxNnTSey8YuQ.wgRcS_iN46UNUZj793i0pGwhkUvl9WCasy ieShb__19pguVvZ7QwiG4eZhA_T0ThkwjpDo_3sGVPSEJfhWBDzDYHKRgLrg9O_YWakpHNTBmusc dc4j_oi7xWl.glPbGtLv8y33aRvMXNHdx_4Hs54NIboo2kWYg4qzsXEmiycWTDG8yhXDZFSKVuF2 eRHdHL7CYaW_QNeNRthGRUWVHBEuduMa2UNThOVT2xDYecmQZlXa5PDx3TLK.wZTYWd0UVHXqSO5 U3hcFDPUfJ69eb2iNrGmDVjie3ggejxzEG_R2.TaN92P2If143nLEfypUPvO4.JU8SSLlyHOKiNl uTwXbOMUVgWERuMxFzAie4KSHM5eoYhYIYZub6oCqJ2F_SHW59smPb9daoOuk0BjF0vop0CV7ry9 DLSVb_6eIfdATNiCX_kdEK5zO5qHmFWr6WpBeeE8x2LuN_99pRQS76_zfcXI4_Kg_jCjzZais2E3 IDIF8wlg8YlriN3CBSsu4Y8Pi1k5OVVd2DKbNwwWz9QBKoNP9mSrDmNSfHPY8YYP762sQnpHvR53 CSATrluBi.bneRbwX97o7aIMUobVMWHEuISSDKlmDTeEoDcX.XkPhCP_JvcdFhQSu5U.Y8UU9iYh RJj46enm.juku.UMc_3bvgk82NT39UKd5bv0HOnhcN6dnLppnM.mxyfTsmv2tNiQos0C4Z2EZ7yv LFjAxMlRxuY3D1ytbyj_TN4whiSo3aqnDjOci7VgD5gI5LBDOaSO6UQ.u10MumC1LMQk.rOs1wji VTlJeObJpjsPYm_XjrRU7._c3PczcRfXskLuU6Qff.HfRNA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 20:15:27 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 587cd65cf2b323b8c51e3fe72ea561ae; Thu, 18 Nov 2021 20:15:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Thu, 18 Nov 2021 12:15:24 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hw9yt3206z4gls X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jPQ+PN9r; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-17, at 11:17, Mark Millard wrote: > On 2021-Nov-15, at 15:43, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>=20 >>>>> I updated from (shown a system that I've not updated yet): >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>> 1400040 1400040 >>>>>=20 >>>>> to: >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>=20 >>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>> the ports I's set up to use. However my last round of port builds = from >>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>> above. >>>>>=20 >>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>> example: >>>>>=20 >>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>> =20 >>>>> ^ >>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>> >>>>> ^ >>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>> =20 >>>>> ^ =20 >>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>> >>>>> ^ >>>>> . . . >>>>>=20 >>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>> poudiere-devel did not get a failure of any ports dependent >>>>> on it. >>>>>=20 >>>>> This was from a use of: >>>>>=20 >>>>> # poudriere jail -j13_0R-CA7 -i >>>>> Jail name: 13_0R-CA7 >>>>> Jail version: 13.0-RELEASE-p5 >>>>> Jail arch: arm.armv7 >>>>> Jail method: null >>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>> Jail fs: =20 >>>>> Jail updated: 2021-11-04 01:48:49 >>>>> Jail pkgbase: disabled >>>>>=20 >>>>> but another not-investigated example was from: >>>>>=20 >>>>> # poudriere jail -j13_0R-CA72 -i >>>>> Jail name: 13_0R-CA72 >>>>> Jail version: 13.0-RELEASE-p5 >>>>> Jail arch: arm64.aarch64 >>>>> Jail method: null >>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>> Jail fs: =20 >>>>> Jail updated: 2021-11-04 01:48:01 >>>>> Jail pkgbase: disabled >>>>>=20 >>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>> was in a different port (autoconfig, noticed by the >>>>> build of automake failing via config reporting >>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>> being rejected). >>>>>=20 >>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>> system versions. >>>>>=20 >>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>> used in order to have bectl, not redundancy. >>>>>=20 >>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>> evidence of such problems based on the updated system. (Also >>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>> errors seem rare enough to not be able to conclude much. >>>>=20 >>>> For aarch64 targeting aarch64 there was also this >>>> explicit corruption notice during the poudriere(-devel) >>>> bulk build: >>>>=20 >>>> . . . >>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>=20 >>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>> *** Error code 1 >>>> Stop. >>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>=20 >>>> I'm not yet to the point of retrying after removing >>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>=20 >>>=20 >>> Another context with my prior general update of /usr/ports/ >>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>> but the failure is based on USE_TMPFS-"data" instead. So: >>> lots more I/O. >>>=20 >>=20 >> None of the 3 corruptions repeated during bulk builds that >> retried the builds that generated the files. All of the >> ports that failed by hitting the corruptions in what they >> depended on, built fine in teh retries. >>=20 >> For reference: >>=20 >> I'll note that, back when I was using USE_TMPFS=3Dall , I also >> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >> those showed evidence of file corruptions. In general I've >> not had previous file corruptions with this system. (There >> was a little more than 245 GiBytes swap, which covered the >> tmpfs needs when they were large.) >=20 >=20 > I set up a contrasting test context and got no evidence of > corruptions in that context. (Note: the 3 bulk builds > total to around 24 hrs of activity for the 3 examples > of 460+ ports building.) So, for the Cortex-A72 system, I set up a UFS on Optane (U.2 via M.2 adapter) context and also got no evidence of corruptions in that context (same hardware and a copy of the USB3 SSD based system). The sequence of 3 bulks took somewhat over 18 hrs using the Optane. > root on UFS on portable USB3 SSD: no evidence of corruptions Also: root on UFS on Optane U.2 via M.2: no evidence of corruptions > vs.: > root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >=20 > Both had USE_TMPFS=3D"data" in use. The same system build > had been installed and booted for both tests. >=20 > The evidence of corruptions is rare enough for this not to > be determinative, but it is suggestive. >=20 > Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are > not differentiated by this test result. >=20 > There is also the result that I've not seen evidence of > corruptions on the ThreadRipper 1950 X (amd64) system. > Again, not determinative, but suggestive, given how rare > the corruptions seem to be. So far the only things unique to the observed corruptions are: root on ZFS context (vs. root on UFS) and: Optane in a PCIe slot (but no contrasting ZFS case tested) The PCIe slot does not seem to me to be likely to be contributing. So this seem to be suggestive of a ZFS problem. A contributing point might be that the main [so: 14] system was built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. [I previously ran into a USB subsystem mishandling of keeping things coherent for the week memory ordering in this sort of context. That issue was fixed. But back then I was lucky enough to be able to demonstrate fails vs. works by adding an appropriate instruction to FreeBSD in a few specific places (more than necessary as it turned out). Someone else determined where the actual mishandling was that covered all required places. My generating that much information in this context seems unlikely.] =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 19 15:04:50 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 29592188F464 for ; Fri, 19 Nov 2021 15:04:50 +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 4Hwg1t0XrCz3LZ8 for ; Fri, 19 Nov 2021 15:04:50 +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 E6C3426E2 for ; Fri, 19 Nov 2021 15:04:49 +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 1AJF4nlO064996 for ; Fri, 19 Nov 2021 15:04:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AJF4nHc064995 for freebsd-arm@FreeBSD.org; Fri, 19 Nov 2021 15:04:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 259937] OpenSSL is 20x slower at AES-GCM than on Linux Date: Fri, 19 Nov 2021 15:04:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: allanjude@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259937 Bug ID: 259937 Summary: OpenSSL is 20x slower at AES-GCM than on Linux Product: Base System Version: 13.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: allanjude@FreeBSD.org FreeBSD 14-current: # openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: 19608265 aes-256-gcm's in 3.19s Doing aes-256-gcm for 3s on 64 size blocks: 5182139 aes-256-gcm's in 3.07s Doing aes-256-gcm for 3s on 256 size blocks: 1328395 aes-256-gcm's in 3.09s Doing aes-256-gcm for 3s on 1024 size blocks: 345918 aes-256-gcm's in 3.18s Doing aes-256-gcm for 3s on 8192 size blocks: 43314 aes-256-gcm's in 3.18s Doing aes-256-gcm for 3s on 16384 size blocks: 21688 aes-256-gcm's in 3.18s OpenSSL 1.1.1l-freebsd 24 Aug 2021 built on: reproducible build, date unspecified options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byt= es=20 16384 bytes aes-256-gcm 98425.80k 108020.57k 110199.61k 111400.89k 111592.= 19k=20 111751.92k Same machine with Ubuntu 20.04: $ openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: 83708856 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 64 size blocks: 55912628 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 256 size blocks: 20800967 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 5873794 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 8192 size blocks: 768122 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 16384 size blocks: 386083 aes-256-gcm's in 3.00s OpenSSL 1.1.1f 31 Mar 2020 built on: Mon Aug 23 17:02:39 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -= O2 -fdebug-prefix-map=3D/build/openssl-OpXo8E/openssl-1.1.1f=3D. -fstack-protector-strong -Wformat -Werror=3Dformat-security -DOPENSSL_TLS_SECURITY_LEVEL=3D2 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_= ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=3D2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byt= es=20 16384 bytes aes-256-gcm 446447.23k 1192802.73k 1775015.85k 2004921.69k 2097485.= 14k=20 2108527.96k --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Nov 19 19:08:58 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 670A8189B46C for ; Fri, 19 Nov 2021 19:09:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4HwmRq2hvZz4TY6 for ; Fri, 19 Nov 2021 19:09:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637348944; bh=ZX56WDd7s6jeiBDTC+SliUAk7IvT7xrwfdKnybIRJJM=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=cAWfoKRE8Z6sFEP/lZ5Gf97BbuLxx2xMiClPiNSa1OGoEWttI3lvfKQMxAIzvaHVpIgdt59vkIWQfY7405jMz9p4BEXCCrp5HpXm7/vYO8DEgOLoVAev+9RogBxDhM5u3OdXGZg4sdqkaYF1ooD6FOo6qpNimNQ0tgGH24ONEmQX8dCL94X7rSfAxsHQWIv56vpAfRyImw91DK4sPGxaBRMHnDvjh6SMoGjl7I0o+lao/emA2C1n7HS4J0yvpIQ/FdLml308RV28FuziXq5VCn61lsmaXmy8JZjHNoDgvUvq5pCuBtlDmqyFmCuo4N/udwJr9w89TRNnY/u/EhHy/A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637348944; bh=dyWk6NdDPc3jNa5AzTAfQ8bwePOING0VJMZxFJSAzY4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Oey1fsHlF1V8Kkpwjyw7+gtxlvC3OOspUKjuy0+LWWlZXkcPs0kk5yZ0uGhDPqUsd4PbCAcMrwZM6KN2zEgXtXuTApQAyD8gKL8eAjyAInYBPWTUNcjaZujoh9BQb0/+IXzScSrhDGaWbSLyDlMUuwpyzk6ixaR9F7pheWU3PaqRFgZ0QS9RP97WK+Y6Gpbw6FqrpSfa2a3MISJJ1O+5CVPo+voOXRNj8OFgmkgDiKR+0wbHqeTVExY1k1Z8/qfKtmWb155qM52MsFEE0n8rwy77pb5NxKkS4vwwUSZwtGmw1reGPaWnvEq1sNCVyDw4iWgQz86+HU+Xl/NVSa1wVw== X-YMail-OSG: XBkgwVoVM1lMn8vgaRH3TZMrb1LHNgnYC1FN3sfqrz2mG_6UQ3Caxpue.C4byoz WxHUxhPaJgw05UPp9CoAgTKQqap543hxy3Y8wj6FZF.yucxyb_SWaExhYNbTwg1jK2ImqBWD2jVy 341lp5uIjsoKMDt5S6Et.hbpVhKrhnEUmZrg4Rult2JABu3jKaDfnJllkx862GPLfdw2Lv2AjwG_ dzmhJcXbTsqo0Wzi3KEpGWVsCsliokC0dP38I.swNLuAtnBiaIDm1J7Z3d.fglAkRD1VrHuwH7hV O_0vNi0z38WN1vrAgXZFZWrdnZEZ7teqY3GlfoLT7xxLilv_V1G1Ez9hmleEJnN7r6RvuAOL177w 2BDdEuluJhxKNj8T0mNRJitaijBbQzTO5Sd0lkqV0tWFAQU8HVMGQ8mlgkEmuylAvibL5g.FTf2j ltiAJa72bsW.1B0oUQwKmeL9mO12EUxVjyDHIKWdz2.LRSghci52PzmOXevP8zswAEO1HRx3T7R5 WvPsY0dysroUJcGtomvLFZskZd4HVpXZ8Doffm0r4SIoNSG5sZBjaAhHMd6mfpdS4RDQdkehVRk0 S7SBRk.86DCUtlBjAoOp1hacrBlWnNnNcTWV4sD0nG0YNs4.CNoi4OsGBjNA1rIEXFuuTKFN1jFp 1juJpbwkjRjbdM7U7Hv6SRiHHcKdBYX01EjtHra0_.kQytMTda6fVeJ0BBrBRXbLnutgIFM1glQe eOyPleCQxcXM4nrhb2oDrPEiDtwV9Je6.mexAIFvUWiVTXKx5FirpQyNPHpiAdJa_9u1tGAxf3D5 TpPp24uj12N77V375wQrLm6ETnPk.jBaRsc4sMkvaoRFP8dEJl9Npq20zMNgeu9yY4r3m0Ha2l0U 54jVWlBHG1o5dhk9P_U_CUY6lud7P33GsbtSyxvAm_nTqwlTg_c9u0f_J_iJXjYOoDicu5Tzpk51 E.GL6TTfSXSwY17Waudzbl8hwKq7flOVy6MsO6mg7y5vm4QaO2Ig.caiSnoEh.ZenWeIDwXb3G0S 2f5LIDPEC2_j_u0Ia0SQBH__7ljMslpdQydphT0hcPQ0IAoue9jXtZmn1O23KEuAu9MwtMQEt9cJ FACH1Tv6hbcfwezh2G7G3CuGIR1.F5eLiTtOTzJFhoU1.AzP4WtxYkqRlesBNLdJkiqYCL2Bsksa 8DCIgtB2wxaHwK0FiUjoJtFveKlzWOA7z7KAs2A2CwoYq4lA5nTOy1va7rqUB_pGyaoGrRVroydA 4LfnxBgj2bAs2uBjPtm7ptDBvAkVm5ItlNhpLuON7g_dWmjweMGx6TNKWxgeHKMXM3rmQox5KyM. K3OCgu_dp96E2_P5mLeXRuMpuRUPi9wzsexOYuR3FJp5sTv1R.YTEPdtkanxVRT7c8usF4x1hfv9 8w4TB5PB8wtXbPYb_vzQwmSKVhYvwJ2vAlEBA5IcrDqaTrbgm6wqIwTJAZh6uBsJ22UapTUhmU2j AXcwuT.FcBrf.CCpaHVYzT.jSD3KyyHqrIfQ04bfCFF7FTHqu6Mw5xvTN0ZokSiP2zpK8b7_Ok8_ WqUBfOaBM_EOj9cZnV4SqkR1e6.dtMituHzdtjEUwzBLtbZOjKgxrRuzjal5HE03pwOmbkMzPheU oGUOD.w8fxm3.kwwOEPSLpfVeTJb0XkXmD.qQBLaLXK51NPTl47emMZR8dk8a_s79A1y_HOxBhtE 6F0zsAxhVrniB6TPoZG.j_ohas7ZnGlGe5X5EoouyzziJBVPHgYdPVUEJW62zGr.ztHDaNrRXohm Am4vPc5SdcpBfPpBXdFqqQ4xW675uwetY4MlmBLF5HzhlU0vpOJCf.HdyVz7PmT1GzNWq9dDdQqE 17lumISEcM_NNpQ5sc3R7Lol9oPvadR702I8EKr_tMK.ta37Q4RTdmu1KbYIDyptagkLRtmpAxd_ ZPGBJYALVPLQFHHpmV0k6rPjNPEIHumSNu1NdSePDuEwa_bZmNT2mC6zrzIpswJqjXKrLg80tDqe QLOYGfO.mcO4IU3eEaWDpwNIeTQ5480KTienNKpBX2xS11rf54m8oolF0o6cDTG6y0Eqxu2FoMqT JJDFeG9Y8jzIHa_SPvnaYQLAQUipBX8NFnToNHSqF6x9anSAK11KQNzPHxSs4wBZ0M6jL4dZ4cFz HB_Yf1K0ozT9rJvlvjiavZvTWdWr_2OcfdeNSgJOoC1vq4dt.nYZDM9K5w40i2j1MThbm7it9Q1d IwlESmrRgpNaB8EIbt71S7E3oRntLp_Ype.PozeKojn52Xl0oiCy3Q8j01WYv1m1bMc4xeLxEyFc X.sRKJv6YpaU6mjbuKVJg5VM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Nov 2021 19:09:04 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 90d826abde6eeb10822a09d541675b1a; Fri, 19 Nov 2021 19:09:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 main [so: 14] system hung up with a large amount of memory in use (given the RAM+SWAP configuration) but lots of swap left Date: Fri, 19 Nov 2021 11:08:58 -0800 References: <50D9DD1F-6949-412B-AE86-46E6F0129E8B@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <50D9DD1F-6949-412B-AE86-46E6F0129E8B@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HwmRq2hvZz4TY6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cAWfoKRE; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.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.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.64.206:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-13, at 03:40, Mark Millard wrote: > On 2021-Nov-13, at 03:20, Mark Millard wrote: >=20 >=20 >> While attempting to see if I could repeat a bugzilla report in a >> somewhat different context, I has the system hang up to the >> point that ^C and ^Z did not work and ^T did not echo out what >> would be expected for poudriere (or even the kernel backtrace). >> I was able to escape to ddb. >>=20 >> The context was Cortex-A72 based aarch64 system using: >>=20 >> # poudriere jail -jmain-CA7 -i >> Jail name: main-CA7 >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud >> Jail fs: =20 >> Jail updated: 2021-06-27 17:58:33 >> Jail pkgbase: disabled >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400040 1400040 >>=20 >> It is a non-debug build (but with symbols). >>=20 >> 16 cortex-A72 cores, 64 GiBytes RAM, root on ZFS, 251904Mi swap, >> USE_TMPFS=3Dall in use. ALLOW_PARALLEL_JOBS=3D in use too. >> (Mentioned only for context: I've no specific evidence if other >> contexts would also have failed, say, USE+TMPFS=3D"data" or UFS.) Of course not a "+": USE_TMPFS=3D"data" >> When I looked around at the db> prompts I noticed one >> oddity (I'm no expert at such inspections): >>=20 >> db> show allchains >> . . . >> chain 92: >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> . . . (thousands of more instances of that line content, >> I never found the last) . . . >>=20 >> My patched top (that reports some "maximum observed" (MaxObs???) >> figures) was showing (having hung up with the system): >>=20 >> last pid: 18816; load averages: 10.11, 16.76, 18.73 MaxObs: 115.65, = 103.13, 96.36 = up 8+06:52:04 20:30:57 >> 324 threads: 17 running, 305 sleeping, 2 waiting, 147 MaxObsRunning >> CPU: 2.8% user, 0.0% nice, 97.1% system, 0.0% interrupt, 0.0% = idle >> Mem: 19044Ki Active, 331776B Inact, 73728B Laundry, 6950Mi Wired, = 69632B Buf, 558860Ki Free, 47709Mi MaxObsActive, 12556Mi MaxObsWired, = 59622Mi MaxObs(Act+Wir+Lndry) >> ARC: 2005Mi Total, 623319Ki MFU, 654020Ki MRU, 2048Ki Anon, 27462Ki = Header, 745685Ki Other >> 783741Ki Compressed, 3981Mi Uncompressed, 5.20:1 Ratio >> Swap: 251904Mi Total, 101719Mi Used, 150185Mi Free, 40% Inuse, 3432Ki = In, 3064Ki Out, 101719Mi MaxObsUsed, 101737Mi = MaxObs(Act+Lndry+SwapUsed), 109816Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >> (Based on the 20:30:57 time shown, it had been hung up for over >> 2 hours when I got to it.) >>=20 >> There were no console messages. /var/log/messages had its >> last message at 18:57:52. No out-of-swap or such >> messages. >>=20 >>=20 >> I did get a dump via the db> prompt. >>=20 >=20 > In retrying the poudriere-devel run expiriment I'm > getting various builds that are generating > multi-GiByte log files (and growing) that have > lines like: >=20 > thread 'rustc' panicked at 'capacity overflow', = library/alloc/src/raw_vec.rs:559:5 > stack backtrace: > note: Some details are omitted, run with `RUST_BACKTRACE=3Dfull` for a = verbose backtrace. >=20 > error: internal compiler error: unexpected panic >=20 > note: the compiler unexpectedly panicked. this is a bug. >=20 > note: we would appreciate a bug report:=20 > = https://github.com/rust-lang/rust/issues/new?labels=3DC-bug%2C+I-ICE%2C+T-= compiler&template=3Dice.md >=20 >=20 > note: rustc 1.55.0 running on armv7-unknown-freebsd >=20 > note: compiler flags: -C embed-bitcode=3Dno -C debuginfo=3D2 -C = linker=3Dcc --crate-type lib >=20 > note: some of the compiler flags provided by cargo are hidden >=20 > query stack during panic: > #0 [trimmed_def_paths] calculating trimmed def paths > #1 [lint_mod] linting module `transitions` > #2 [analysis] running analysis passes on this crate > end of query stack > thread 'rustc' panicked at 'cannot panic during the backtrace = function', library/std/src/../../backtrace/src/lib.rs:147:13 > stack backtrace: > 0: 0x4710076c - = ::fmt::h4428caffcb182c5b > 1: 0x471c9d00 - core::fmt::write::h91f4a7678561fd61 > 2: 0x470e2180 - > 3: 0x470ebd40 - > 4: 0x470eb824 - > 5: 0x41ed4848 - > 6: 0x470ec690 - = std::panicking::rust_panic_with_hook::h6bc4b7e83060df25 > 7: 0x47100f0c - > 8: 0x47100900 - > 9: 0x470ec374 - > . . . > 65: 0x470ee71c - > 66: 0x401361bc - > 67: 0x40135cd8 - pthread_create > 68: 0x40138b9c - pthread_peekjoin_np > 69: 0x40138b9c - pthread_peekjoin_np > 70: 0x40138b9c - pthread_peekjoin_np > 71: 0x40138b9c - pthread_peekjoin_np > 72: 0x40138b9c - pthread_peekjoin_np > 73: 0x40138b9c - pthread_peekjoin_np > . . . massive repitition of pthread_peekjoin_np lines . . . >=20 > (I used USE_TMPFS=3D"data" to avoid tmpfs memory usage this > time.) >=20 In trying stress tests such as: # stress --vm 16 --vm-bytes 16G --vm-stride 4096 --vm-hang 30 I've not reproduced a hang under root-on-ZFS (or root-on-UFS). Using USE_TMPFS=3D"data" in poudriere has not produced the hangup in any bulk rebuild runs. (I eventually have to stop such bulk run because of the indefinitely growing files.) These, with the earlier, suggest that the tmpfs use via USE_TMPFS=3Dall in poudriere contributes to the hangup condition involved, as does the indefinitely growing files in various tmpfs instances for various builders. Side notes: Luckily, with the Optane PCIe orOptane U.2-via-M.2-adapter based media, USE_TMPFS=3Dall is only a little faster than USE_TMPFS=3D"data" for the bulk builds. Example from UFS context test results that happen to be handy: # poudriere status -a =3D>> Warning: Looking up all matching builds. This may take a while. SET PORTS JAIL BUILD STATUS QUEUE BUILT FAIL SKIP = IGNORE FETCH REMAIN TIME LOGS . . . - default 13_0R-CA72 2021-11-17_17h29m50s done 485 481 4 0 = 0 0 0 06:07:05 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-17_17h29m50= s - default 13_0R-CA72 2021-11-18_12h42m09s done 485 481 4 0 = 0 0 0 06:02:27 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-18_12h42m09= s . . . Using a portable USB3 SSD media with USE_TMPFS=3D"data" took noticeably = longer: - default 13_0R-CA72 2021-11-16_02h28m29s done 485 481 4 0 = 0 0 0 07:55:25 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-16_02h28m29= s These bulk runs do not involve the indefinitely growing files. Much of the time goes into gcc11, llvm12, llvm13, and rust builds, for = example. The builds use ALLOW_PARALLEL_JOBS=3D and had 16 builders, so maximum = observed load averages (via my personal variation of top): USB3 SSD USE_TMPFS=3D"data" test: last pid: . . .; load averages: . . . MaxObs: 124.65, 106.26, 90.03 Optane USE_TMPFS=3D"data" test: last pid: . . .; load averages: . . . MaxObs: 99.60, 84.64, 78.15 Optane USE_TMPFS=3Dall test: last pid: . . .; load averages: . . . MaxObs: 113.79, 97.04, 84.88 The context is a 16 Cortex-A72 HoneyComb system, 64 GiBytes of RAM. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 20 06:20:40 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 285C1189D385 for ; Sat, 20 Nov 2021 06:20:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4Hx3Lv6gjYz4mZr for ; Sat, 20 Nov 2021 06:20:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637389247; bh=BiOpSI/RYBIeQyNVjZkH281xPU5T8DTLYytOiqeQhXE=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=I3LOupmo6Djz/1FyDarOuDFXKJJI4M5dhpjaGoIUbW+Vq67iYw5G6Nnmy0mRSUD5RehSh3fT6EusFcLvC8BTWyLQivHMgH7tvsq1tj5QMljBhp/gwkAe8qb1JHnaqbE44jHiYgMM91zxovXEhVdGmJmoHi4ir1PT76H5v9wrwximO8yNE/7x1yobYp33jpDliYgl1rbk20zr4t/dzfPCoCfIgyWLwnAhrDJDEoHGMqkqZXvrc8xqhLcBtfwcUcxGJROtFUOCSP1+iu8oUAoFb5ICpz6k7lgnz93y9+pIsWgtCCj1Sr+1zkoWqBSXh7fn8V3k5Q+9CBEORjrg2szhTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637389247; bh=mKULppDzdKQMNbpIqplmxLlYFcFgUhqnqZNTijRw71G=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SfhmoHVIdiXtrPVj1sX+u9HfM/n1U/PFfVjbjt06ZpebGTOOb0UZV95uZyOqdfQC29iKBWrZ3+Tx3xFiLizII+hucY/aJGX8m5tCIN63Yjp3XJ1WOgeFx847Kfc0FfIunnqgBQc4IK+geXAF2KNI5WXHAWbBVBE48hN0E24skSUw+q4vLFohvj9/EsnZLcBw3MxoDlTl9d5mGGJBjmxST2UGopqkzvaM9FAUyuopLIJEH44agkBfG7tyt/+IyAHQ6BXLSZX4uKexo7UZ3AviVCdvJGZokBXFr2RVbD5Jw6cpTIGd/p71GHelTvSn9y56ffL67WNiVhNQKt4NeonqtA== X-YMail-OSG: 1ZcKlJEVM1mbIp3JGxAsImzdTS4TCdmv2jlx2dHShQ5z0FHmyM36k9Cz7Yp2yTq P0C8G_izhGn6YY1m7eMhP6Qi2mc8HI10IYUz5iHiTsz1_m7x3Doe.C32Z56tNvKPUIbg9u5JmrpW zV9il9Gz2mbx9IKrPbdfbjCrlmqQcjDjzWVs0SpXVYd5B8L3eT5ui53_nwgAQr7w4jM923Qz0YcR zHOlS0DG7BLNQdXbzHOuOQuYoTErg5W9SeWoQ8_k7EG89HsRAqYfKu4Lqi6FEcCGISU19HGi4Uhe OmfcCX_oix1tD7i0DggFV6Qj4ZBiSSrenkh4Hjp.3dJ6hDoKT_ncCL3xjBqDxjWol0mcMNJ_JIDJ bvW2dcv2244kopmTJg615xXoggHBweqJO_9eKlkdZWDe8JfZNa4kI1oY6Wtufel7YYIyg1C4qDgb 6N9r4b7dqeJQiVjzY15ev2_LFnXPSGRH9TNSvvLVzHb3F1Gaer7Cj8OMFvj.8xMprRWDsU7l5Ai0 EoTRGyoRJwdkMbSbf1W8FaFMOy5H.faz.MzyCj1kYqyfOsSidVwbBwYphHToQfUocoO5H2z.iAWF FJHAAtcJzHt0t1Qm7OGhfNQ1_llUIl8CRm5hdAbLPeeNZTe18WrbyKh7HSioIxB_Oxwx3A0PaT6m uKRAczgaEq4uIDtASEUoB7uyEI5w7aNDztdDs_ZUBT5wWLG5lXZjLsqm59csqGLboDzwZdNM7gsy Aebt08FeyBUMbbopb58li.3eV4h8sAGMesPfot2Xe6ideCzK.xN4E2YmA0nul1bku9tyYV1lP8h_ HeCfcUm_JW6GQXk5Hkmb4vCvmdm1C63pnSBgkSZgICM9DCChPzhbhFjvnICnYnfuKhQzGIVnPofC y6ZEo9Ayo5zEznRPobc2noRwBk5TGy0H1ZqskR3uKw8VPmMA0y.eQ6fO8tvWpdP6O82FVCJBOhYt ROwskg5wBeCOW_GO37xWlsBkADpBkrsAtwIVYbbkLqpsXtWl8c17ihgD1tTP8AyX8bUjq1U7.uiO uEYWLj5IFhz1zrYzKtmAEiExvGh4lzDPlo6EBF0al9bEGJ2PNlP3UtAucmbJE8Cf.0BGYop6kP8n t5TA7HLt95kPqqtLSKpEfAWkty6ycqsW.FLW6n2J3pi.Vrq.RrqwJcNVru9Py.xpkDNDcg1bwKf8 UcCZuc79nyrL_UJSiR5NKmz6oRr2z1bMaGIwHb7L3PqVPq8SI7lqJ7EXOGCpS3yqjrROQT8aYiv_ ybeMn7HATAYnA22HfItb9iFS4I94LYe8EgqJzB3CYtPWUaLpYa6ES17kHbOdEHAg0dAXeMV_OITn Qspw.5kWB2lt1kOGEw84S.3O72KVmq_Xd2bVnJbhKBCFtnX3vyCQJni8UdRNZ6fmXXm6fSUwNLLf F4gLl0WVcqZWamDtHBF0EFKZZSFgdJ8Wztgc_tOG6Sw1i1oo6nUxZRmC5G4oCJSaUJTjiAjZ9JEh Elr12a7aQk3bFq8RchKPPyYSnpMiGV2dIFR44RTg8bPJ7vRda7jUbgt4zWTC.gRUP1d_g81V5k4D Norl8QrEH8pB69dDo9BdYv6hVPT8Y4AezgBPQOdA7FrlkZm231P6v6ZqUvNXi5npRcIzAEpI8ZiY atglNxo5h3HXctT75EVzLWEKOnqb8irFFM5rDQugP7yC6F9d3Hkz1km58oed0uyGnfu1kVFIBri8 oCjS35PfrQOvHAf_bEmbg9wt60xYDTwsk7oGy_VgQSYI1XS0h2h8Zf_Hk9emXe1OrsjG7A45kCRl USQ72z_fmGBo__nzOKfZUZL2vzJBlfTHd3_FUjaKUMc.lhd9n5wLc.7oMG0JpUwxUgdySsWLX2h0 UtQ49DNmj_wmKTP2Lj8OfXWJGfamIPq43VeqlX_dshOarQe6v35_aD85QfTnyb9IJDnCOu0o0keZ utCJivRX6SNTKZIsglZYZnzudKqmlgOCHAk_VEk3VxDnPuTH6AwaTydFlLdmQXN6hMtpZly2mNMD bydbh5msDxQNmpg00MP8hc3qqSEuz1jG_6xsUMNPBtZZXo7LoD.ZeuY9mDOjgOC0EFyLLntwStz1 eU_j8cXgzTbHnuMeo.8szF64UG8hq0jvrL5JwBEzUmeZELKBYhSHSUt8gRVg_UMc7M3fS3rc_iYB .7u8c5zYe.diBToRPSwWwgOdUTEDrOSSuKYq4U9ZX4I6Sp2.wO9bnlNTM_2VLVkRQRzUs2Wt5zWE rZ9Dgq9r0Ds6YVoFt5dCs9OJMLBq2B0ruTTPjm4U4Da77Vbw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Nov 2021 06:20:47 +0000 Received: by kubenode528.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID feee28c9cabcb0fca281a6ed60859c67; Sat, 20 Nov 2021 06:20:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Fri, 19 Nov 2021 22:20:40 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> Message-Id: <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hx3Lv6gjYz4mZr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I3LOupmo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-18, at 12:15, Mark Millard wrote: > On 2021-Nov-17, at 11:17, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>>=20 >>>>>> I updated from (shown a system that I've not updated yet): >>>>>>=20 >>>>>> # uname -apKU >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>> 1400040 1400040 >>>>>>=20 >>>>>> to: >>>>>>=20 >>>>>> # uname -apKU >>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>=20 >>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>> the ports I's set up to use. However my last round of port builds = from >>>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>>> above. >>>>>>=20 >>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>> example: >>>>>>=20 >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>> =20 >>>>>> ^ >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>> >>>>>> ^ >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>> =20 >>>>>> ^ =20 >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>> >>>>>> ^ >>>>>> . . . >>>>>>=20 >>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>> on it. >>>>>>=20 >>>>>> This was from a use of: >>>>>>=20 >>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>> Jail name: 13_0R-CA7 >>>>>> Jail version: 13.0-RELEASE-p5 >>>>>> Jail arch: arm.armv7 >>>>>> Jail method: null >>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>> Jail fs: =20 >>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>> Jail pkgbase: disabled >>>>>>=20 >>>>>> but another not-investigated example was from: >>>>>>=20 >>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>> Jail name: 13_0R-CA72 >>>>>> Jail version: 13.0-RELEASE-p5 >>>>>> Jail arch: arm64.aarch64 >>>>>> Jail method: null >>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>> Jail fs: =20 >>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>> Jail pkgbase: disabled >>>>>>=20 >>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>> was in a different port (autoconfig, noticed by the >>>>>> build of automake failing via config reporting >>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>> being rejected). >>>>>>=20 >>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>> system versions. >>>>>>=20 >>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>> used in order to have bectl, not redundancy. >>>>>>=20 >>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>> evidence of such problems based on the updated system. (Also >>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>> errors seem rare enough to not be able to conclude much. >>>>>=20 >>>>> For aarch64 targeting aarch64 there was also this >>>>> explicit corruption notice during the poudriere(-devel) >>>>> bulk build: >>>>>=20 >>>>> . . . >>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>=20 >>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>> *** Error code 1 >>>>> Stop. >>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>=20 >>>>> I'm not yet to the point of retrying after removing >>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>=20 >>>>=20 >>>> Another context with my prior general update of /usr/ports/ >>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>> lots more I/O. >>>>=20 >>>=20 >>> None of the 3 corruptions repeated during bulk builds that >>> retried the builds that generated the files. All of the >>> ports that failed by hitting the corruptions in what they >>> depended on, built fine in teh retries. >>>=20 >>> For reference: >>>=20 >>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>> those showed evidence of file corruptions. In general I've >>> not had previous file corruptions with this system. (There >>> was a little more than 245 GiBytes swap, which covered the >>> tmpfs needs when they were large.) >>=20 >>=20 >> I set up a contrasting test context and got no evidence of >> corruptions in that context. (Note: the 3 bulk builds >> total to around 24 hrs of activity for the 3 examples >> of 460+ ports building.) So, for the Cortex-A72 system, >=20 > I set up a UFS on Optane (U.2 via M.2 adapter) context and > also got no evidence of corruptions in that context (same > hardware and a copy of the USB3 SSD based system). The > sequence of 3 bulks took somewhat over 18 hrs using the > Optane. >=20 >> root on UFS on portable USB3 SSD: no evidence of corruptions > Also: > root on UFS on Optane U.2 via M.2: no evidence of corruptions >> vs.: >> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>=20 >> Both had USE_TMPFS=3D"data" in use. The same system build >> had been installed and booted for both tests. >>=20 >> The evidence of corruptions is rare enough for this not to >> be determinative, but it is suggestive. >>=20 >> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >> not differentiated by this test result. >>=20 >> There is also the result that I've not seen evidence of >> corruptions on the ThreadRipper 1950 X (amd64) system. >> Again, not determinative, but suggestive, given how rare >> the corruptions seem to be. >=20 > So far the only things unique to the observed corruptions are: >=20 > root on ZFS context (vs. root on UFS) > and: > Optane in a PCIe slot (but no contrasting ZFS case tested) >=20 > The PCIe slot does not seem to me to be likely to be contributing. > So this seem to be suggestive of a ZFS problem. >=20 > A contributing point might be that the main [so: 14] system was > built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >=20 > [I previously ran into a USB subsystem mishandling of keeping > things coherent for the week memory ordering in this sort of > context. That issue was fixed. But back then I was lucky enough > to be able to demonstrate fails vs. works by adding an > appropriate instruction to FreeBSD in a few specific places > (more than necessary as it turned out). Someone else determined > where the actual mishandling was that covered all required > places. My generating that much information in this context > seems unlikely.] I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media and it got its first corruption (in a different place, 2nd bulk build this time). The use of the corrupted file reports: configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 In file included from conftest.c:27: In file included from /usr/local/include/ogg/ogg.h:24: In file included from /usr/local/include/ogg/os_types.h:154: /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] ^ . . . /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] . . . (nulls) . . . So: 538 such null bytes. Thus, another example of something like a page of nulls being written out when ZFS is in use. audio/gstreamer1-plugins-ogg also failed via referencing the file during its build. (The bulk run is still going and there is one more bulk run to go.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 20 19:54:09 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 6B53E188F1CD for ; Sat, 20 Nov 2021 19:54:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4HxPPV0cmxz3k90 for ; Sat, 20 Nov 2021 19:54:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637438053; bh=cYcKVeA8+06t3AFainxt+18bdXJU9Njlit5Ir6W06W0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=O0XEz6/WBkJyU7csQ6ABwayX+R6J46Otje6GlZ35UUni5p6rPdTyF5ZaEQm+VgMl7Vvh1dvT7C6DH83YK+h0hdaZt8aC6dGHSTloWOnbOFcnHtCKsvIx691y9K7XNmOGUOLLzaNT9jwPzEzHyZfnUsIh86UP9rOnPEaPlupLeb1MyvKwGapH1c1jFghWQr8iRYLwnMEHsDCpFJO2Iv/YeEkdBLBxmU64TbyVgAnnoETl5WDLcPVguarn25K/pTFgpVKdDnKnJ+HgCnQdFqF6tzuvCgX/ebBPGyk1ao9TjGgQVOke2eEBrVnc/DMN1wAnCLhgZ06oKpEhf2MIPqS4Dw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637438053; bh=7Yv/3tTt6GcbfAGgh5kvrhu3m6fRn3q8m4fwwzleaqM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tqkZDZM4IJuXHV6rjrrLEB5/7ZJJOF6kfw0Qzc0nGRq95osz6/Tvgm7kBmTcf4TcX5qy98U4GgG4DLgbRIeZCB2wvVtNEa77Vvn0o6uTjqwLkNwgVte+b14b6zYUONaRUaSvvM7JO2//Oc2oOqI5aK/eKRxn8MIZQEL8HeEBwZjqfnLAlj7ZWVtGq5Sl1AloA6cMwrjG5uiF6BvzQt44WTWcBD8FBtG0OhEqA422k0MfgbUSyzepLO8UtY+NfvlpQKxfsNEAH0VVZiv3wMshVOdIECbf6MTok/CDhacyU9oWKA/PXYXW3RW4SiNfoGnAVEc+jmEukQliuQk4OWWvbQ== X-YMail-OSG: KAF.tNQVM1lxJEOe981imz_mHXsdmEQEwWrjn497ze6soeJwkuKKd1EPOiENzka Kakc7uLv2j8Go9Cq1hWuuCPoWs3IbRP_vZQbGgHOnUB4z.VlEWGjLwEr7Xcihd16_txv34jzYJ.9 .WX0yFB74GYyRy9K.C6ksoiT0XVmnU.eVswbMac4Xcz.mljbHplZcq0JA0fODed_Rq9NL4T.ISDU flEX9QuiiTznjv_M8OlMGXHRK6JWWIgti5mcR2GUPN6ynNqbMuzLeYFUq2pHCTFLm0wDgl8h2ILg Z2WQfRQICwCYR0ReC966qFEELBpeNlJiqvDj27vlVOPy5LPvak_l660wBsuZPQJHh7lF.ZAbWfD5 nIVwI9jQULxx7Vb_F19le0XRbarcTyNgZntAEfS3YBAVTme4r_XHejBIlI12ztKuIC605C7eslh6 0S9nAJQ4gFHVDNGD2QbY4RvU8AFpZ.toDdrIrrXgxuWnc4.U03Q1ijaJ7xxjFY.Zio.iPZVJTXZd FkyyLtg_DmVZY..ixcsBypwOFlSCA8gUlPP_E7OSbv36sJzFfABRT7Ebu.hFb1o4vjxkImBujm9E qJCE8P5e1H8kMNz8jB3HVvLzHcEz.HYO2YXmhtwtOkaM9RpaUcrQ_ztajgHGuunzu_apiVfLd.XK I_O8NlUMj1zZzfEcLsQTeuAuHJnML0sagcZMq6_D7IFYrc8s2a_hicfPIHzlBPqQGlpvME1STbCC glfSHgTXLahingYgld4zoWiyI4Tvm.65rY5.dHGpji56B4E9nQD1P4eQ8CWIGKhwLBNDA7Cxtvr8 tw1NsAKRtw4.WzN4j2gbn_UeQ2nQ8JM_kWo1oeJu7m5pi6UH8I1H5j8knYMN06.NgJIdQWQBAB_e 2SoiOmy3UVrYGh0Fus6hwHlyIGk.wQiljijU8jG1N1khM.r16DBs6GNALQx8_L4Y2eQ4xlHe0Ylw CaDVyQm_9Rn8ZfNHctjEg7Ke6.JXsez95q0_vh1BaRGqHqDq4jLdzF7bIKGvwnF4zyaIO64HSMkH spOssem7pNVH.H6J7U1P0Jife5Jr0YJYDEmMFxmjteaVxGwyFWuMYcFewPs.6a4JWGWeHGNP4L8l JwqEWpcRL5yYgYdvAmfISaU_C6DevPflPALnBR6jUbmM5WXMl2SJngbJWb1xfDqSqVkoez8W8_MW WQXCdg3D7aCHebhI2x6fsLEb.GxHPgjmR5V3pbEHv07.w.Mi_CsLk_BoRnPIhmPdEQoauGPUmHdU k4Trajq.1yGpx74ZCWIeM_0DIRit8t4IKimdOF2nxGuEggYEap.05vovuGdj47IlLjJpcmyWblw2 A1x8R_k28wTr59VyIiqU4r7x8Hsxnb77XzFdxp2alrJIkyUJa5EaozaZ3LP2Sdh6GUh4f6E2G1nz PeexgoixxqqkoMafg_28uvKgKubHXSMKhSr5jhcS9wZZ2DbOAafVHvjF6SwPefUDqfK7aMUjp.fC y0Z232.fcj5BbBgcpz3chZH5Ga5a0TqGHCwbD2BYhsYcAjDuSdGdtu9aMacdAZfpZgr2VxW6A0yd KTXnbbRzpL17RELCF0PDMK9aFEV80r18c9siRg6eF..vDKaKKOXpvnxsmwt5gTfc.s5G.Mm4QZZj dZ4cVHkYNEpp05BjDEw6_pI8y7c6qFSSYQLZYP1KUyx.iY.X6UmIFi5_E76Kp0GvUcAd4Y4pWz0n KZ_QYl1vOTZRNIAtZRLcHwvE2gJm4PYdNFjcLHH70qp4RTxSU.gwJQN4QodOpgScgDVqAXDEF38g NLUJAE2slA89YbDoCRpoz4vjhzCNUK7O3FxcF7LJFt.Hxu6xiJ2GUPd2Tdix5KWtVabQpyQZL4pJ ENdgf7YcLS_.uKX_88c4JzyiLcuVSegUSZKJZe8UhsnTjzAkGLPCfvBRy2yjSTFCt7kokV5ho3ta kW_YyagubyD1bhNWV5EZlUJkE3ddA.Q2g5idyXjruHptlIxamk0n0xNaT0Sor_nhz6PT1vWD4AUO UpVsfMffUhhd4jC7DFHhcxdb0obJhp1N1RPz.ghlTWFmjSFkP.IsAHp78nYg.HOw64ppcJiX4S_h s7GV3BR2z5FWShdoxLpaEemnigFqAmXGIT2daQuhHYN066fqHG0j5YoLWe111aYBcTsTQ7gqxMSx vY5fiHJBQeTbtOYcVbG9lWTzEfVm1Jns262oF75dh.JDTEbTpAdr2ylnItA9mSpL6CdLe2oCKU7_ btqSGB6G0x2VYBBO6Twg0y3V_MAqJCXebGRnoZAbYnT5LloYnsJVOfuzXgbdvrG8HttXtcrkorod fDyQRvcl4Owvbzg4si8bZ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Nov 2021 19:54:13 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a6d4bebea471a42359ddf873a13f06ab; Sat, 20 Nov 2021 19:54:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Sat, 20 Nov 2021 11:54:09 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HxPPV0cmxz3k90 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="O0XEz6/W"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-19, at 22:20, Mark Millard wrote: > On 2021-Nov-18, at 12:15, Mark Millard wrote: >=20 >> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>>>=20 >>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>=20 >>>>>>> # uname -apKU >>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>> 1400040 1400040 >>>>>>>=20 >>>>>>> to: >>>>>>>=20 >>>>>>> # uname -apKU >>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>=20 >>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>>>> above. >>>>>>>=20 >>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>> example: >>>>>>>=20 >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>> =20 >>>>>>> ^ >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>> >>>>>>> ^ >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>> =20 >>>>>>> ^ =20 >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>> >>>>>>> ^ >>>>>>> . . . >>>>>>>=20 >>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>> on it. >>>>>>>=20 >>>>>>> This was from a use of: >>>>>>>=20 >>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>> Jail name: 13_0R-CA7 >>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>> Jail arch: arm.armv7 >>>>>>> Jail method: null >>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>> Jail fs: =20 >>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>> Jail pkgbase: disabled >>>>>>>=20 >>>>>>> but another not-investigated example was from: >>>>>>>=20 >>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>> Jail name: 13_0R-CA72 >>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>> Jail arch: arm64.aarch64 >>>>>>> Jail method: null >>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>> Jail fs: =20 >>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>> Jail pkgbase: disabled >>>>>>>=20 >>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>> was in a different port (autoconfig, noticed by the >>>>>>> build of automake failing via config reporting >>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>> being rejected). >>>>>>>=20 >>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>> system versions. >>>>>>>=20 >>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>> used in order to have bectl, not redundancy. >>>>>>>=20 >>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>> evidence of such problems based on the updated system. (Also >>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>=20 >>>>>> For aarch64 targeting aarch64 there was also this >>>>>> explicit corruption notice during the poudriere(-devel) >>>>>> bulk build: >>>>>>=20 >>>>>> . . . >>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>=20 >>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>> *** Error code 1 >>>>>> Stop. >>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>=20 >>>>>> I'm not yet to the point of retrying after removing >>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>=20 >>>>>=20 >>>>> Another context with my prior general update of /usr/ports/ >>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>> lots more I/O. >>>>>=20 >>>>=20 >>>> None of the 3 corruptions repeated during bulk builds that >>>> retried the builds that generated the files. All of the >>>> ports that failed by hitting the corruptions in what they >>>> depended on, built fine in teh retries. >>>>=20 >>>> For reference: >>>>=20 >>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>> those showed evidence of file corruptions. In general I've >>>> not had previous file corruptions with this system. (There >>>> was a little more than 245 GiBytes swap, which covered the >>>> tmpfs needs when they were large.) >>>=20 >>>=20 >>> I set up a contrasting test context and got no evidence of >>> corruptions in that context. (Note: the 3 bulk builds >>> total to around 24 hrs of activity for the 3 examples >>> of 460+ ports building.) So, for the Cortex-A72 system, >>=20 >> I set up a UFS on Optane (U.2 via M.2 adapter) context and >> also got no evidence of corruptions in that context (same >> hardware and a copy of the USB3 SSD based system). The >> sequence of 3 bulks took somewhat over 18 hrs using the >> Optane. >>=20 >>> root on UFS on portable USB3 SSD: no evidence of corruptions >> Also: >> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>> vs.: >>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>=20 >>> Both had USE_TMPFS=3D"data" in use. The same system build >>> had been installed and booted for both tests. >>>=20 >>> The evidence of corruptions is rare enough for this not to >>> be determinative, but it is suggestive. >>>=20 >>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>> not differentiated by this test result. >>>=20 >>> There is also the result that I've not seen evidence of >>> corruptions on the ThreadRipper 1950 X (amd64) system. >>> Again, not determinative, but suggestive, given how rare >>> the corruptions seem to be. >>=20 >> So far the only things unique to the observed corruptions are: >>=20 >> root on ZFS context (vs. root on UFS) >> and: >> Optane in a PCIe slot (but no contrasting ZFS case tested) >>=20 >> The PCIe slot does not seem to me to be likely to be contributing. >> So this seem to be suggestive of a ZFS problem. >>=20 >> A contributing point might be that the main [so: 14] system was >> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>=20 >> [I previously ran into a USB subsystem mishandling of keeping >> things coherent for the week memory ordering in this sort of >> context. That issue was fixed. But back then I was lucky enough >> to be able to demonstrate fails vs. works by adding an >> appropriate instruction to FreeBSD in a few specific places >> (more than necessary as it turned out). Someone else determined >> where the actual mishandling was that covered all required >> places. My generating that much information in this context >> seems unlikely.] >=20 >=20 > I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media > and it got its first corruption (in a different place, 2nd bulk > build this time). The use of the corrupted file reports: >=20 > configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl > ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 > In file included from conftest.c:27: > In file included from /usr/local/include/ogg/ogg.h:24: > In file included from /usr/local/include/ogg/os_types.h:154: > /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] > > ^ > . . . > /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] > . . . (nulls) . . . >=20 > So: 538 such null bytes. >=20 > Thus, another example of something like a page of nulls being > written out when ZFS is in use. >=20 > audio/gstreamer1-plugins-ogg also failed via referencing the file > during its build. >=20 > (The bulk run is still going and there is one more bulk run to go.) >=20 Well, 528 happened to be the size of config_types.h --and of config_types.h from a build that did not get the corruption there. So looking at the other (later) corruption, which was a bigger file (looking via bulk -i and installing what contained the file but looking from outside the jail): # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 0023b120 So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. To cross check on live system caching vs. on disk, I rebooted and redid = the bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : still all zeros. For reference, zpool scrub afterward resulted in: # zpool status pool: zopt0 state: ONLINE scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 config: NAME STATE READ WRITE CKSUM zopt0 ONLINE 0 0 0 nda1p3 ONLINE 0 0 0 But it is not a ZFS redundancy context: ZFS used just to use bectl . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 20 21:03:41 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 D0F7B188A7C7 for ; Sat, 20 Nov 2021 21:04:25 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4HxQyJ31g8z4bx9 for ; Sat, 20 Nov 2021 21:04:24 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id 9FE5F11F80C for ; Sat, 20 Nov 2021 16:04:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_PASS autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id 2355911F807 for ; Sat, 20 Nov 2021 16:04:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1637442252; bh=Jp1NHMjZ9gxLTccRACfW3jrSvhtanB/AxjahtLhlXG0=; h=Date:Subject:To:References:From:In-Reply-To; b=Hzzvsw71GeeXbXL9OQqs5Z33Vj7IOso9zlTEAhUel9OqgQcR4zi8Fc/O+XwBd+sXe 6uUeg7ozqGydIfDKBQZi3qqck2pirJW5T9KlymASnqmi44FftWWcNMbWpJIx7IrSZD DN2rVhSMrMESGsL/JegRZiHcpQDgVs/OEYoZEtYQ= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at zenon.morante.com Message-ID: <7f41d2d1-ef24-6e07-1ea7-a3a240d90a33@morante.net> Date: Sat, 20 Nov 2021 16:03:41 -0500 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 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> In-Reply-To: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050302030407050600070902" X-Rspamd-Queue-Id: 4HxQyJ31g8z4bx9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b=Hzzvsw71; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-2.85 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.85)[-0.855]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: daniel@morante.net From: Daniel Morante via freebsd-arm X-Original-From: Daniel Morante X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms050302030407050600070902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit May or may not be related, but here's a bt after a panic while running poudriere for a few hours.  I still have hw.usb.disable_enumeration=1 set.  I'm going to do a new install with the latest snapshot later today.  I'll post a bt of that without hw.usb.disable_enumeration once I get it. db> bt Tracing pid 0 tid 101633 td 0xffffa008230c6580 db_trace_self() at db_trace_self db_stack_trace() at db_stack_trace+0x11c db_command() at db_command+0x310 db_command_loop() at db_command_loop+0x54 db_trap() at db_trap+0xf8 kdb_trap() at kdb_trap+0x1c0 handle_el1h_sync() at handle_el1h_sync+0x78 --- exception, esr 0xf2000000 kdb_enter() at kdb_enter+0x44 vpanic() at vpanic+0x1c0 panic() at panic+0x44 deadlkres() at deadlkres+0x2c0 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 I'll find a On 11/12/2021 5:52 AM, Hans Petter Selasky wrote: > On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote: >> ugen0.2: at usbus0 (disconnected) >> uhub5: at uhub0, port 1, addr 1 (disconnected) >> uhub5: detached >> ugen0.2: at usbus0 >> uhub5 numa-domain 0 on uhub0 >> uhub5: on usbus0 >> uhub5: 4 ports with 4 removable, self powered >> >> I suspect these problems are caused by the above detaching/reattaching. > > Can you type "bt" in the panic prompt? > > --HPS > --------------ms050302030407050600070902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DJgwggX/MIID56ADAgECAgIQADANBgkqhkiG9w0BAQsFADCBkjELMAkGA1UEBhMCVVMxEDAO BgNVBAgMB0Zsb3JpZGExDzANBgNVBAcMBk5hcGxlczEpMCcGA1UECgwgVGhlIERhbmllbCBN b3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEbMBkGA1UE AwwSUGFjeSBXb3JsZCBSb290IENBMB4XDTE4MDcwNzE3MzUzMVoXDTI4MDcwNDE3MzUzMVow gYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFuaWVs IE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMwIQYD VQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAMU0vt8sGT82c8BLAT+otS3VQVw4rf566bmYzJ7wm+D/vcp5jiwL1PAnGFch bSSpe1KCFQ7LCnjrl7nQg1EglHKETfHI7QxVqE22q92G/2rIDfPnNTYlLJ0d5xmM0q1P+yEI XYZErQyBthDhHfrDIEdWJ5tWevfFAUFjXmWy5V7eHGgndB8TQFEp9ML6Bks4tKH3ykwAZbib hKd7L2EthiqSJvvyIP3Kg/AwVjX67JTbKgQfcsfYGm5dofHmL+3uIhovLL5HFbADU6AoqXlh lNY83RfaD60G6IhPZwzZboBi6qxHnjwqsbV+S81SZdoMEnHDMZNzP4RC27ZMaTmxH3IN8JN4 XuszONstvUAuzdhmcG4q+K7HrO+SG0eEhDBUrxKrmFCUh8pwYU2o4q52/yDrZasid1NBFHZt Wfsyoe1ArhqnO4yz95h53dR9aCISwOGIMExNUJlH91KYNrLeSbPMR7LXgu48hY+CGkSYXhcS fPF9p9OUjgUeZ02+K8iI4a0CYCjuJNF1N/rJ7UkT0b5hdkcLPrXCd8P6NfJotoX6cGITF7Rm z+fq/3NbjF2Gu3nWeCdOXyECW9/HBzTlILZI10VOmfqDGZK3z6SlRBlaXK4lUvbqfDM+E785 CxStIlNqx/FDM6O8F+OP17Yb1vNpDhAblV/eYFiGZOw0YZAzAgMBAAGjZjBkMB0GA1UdDgQW BBR8ncAAcpI2KRTREkGd4Qpdx7IpVTAfBgNVHSMEGDAWgBR6BEY736L1bCcrmtwFaEg93nZd uTASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOC AgEAs/eYLE+jKO3hpHJ8QYaL8FH7iFFNbB4SVBDyH0arb9uqK/FY8uGlOn2A9ul8cE7sSA3E dXptZzFqY+C69UjlV2kvw2+35gvKoiIncwYhCA2JOQgm0QaXBAxZijF5UOL3+i1IE8JpdShz IoUvPtXBQiVnW9HJ5jZnZJNy4Jid+RQd5fNL2WmJf1Ob48YoeB23Y0KUnUvhmmu52OUG+bni hbP4ULTL4egmR783ZA5CqBWFb0J7HhXDaPBM1dGf+gQ5YzJqGWZXZ3YRe83IlDXm76rK+wlO uPlRUGSBbkgv7YRKzBx2JNLdNPBXIDxT71b1kGip8q0Mk9f/VXeudgCLzqa1+gphE3lNYQMa 0CHYfezask6ee5999rezWDx/T2/U0xy8i+bBlRNL7QRwk5JRTOemxbJJ5fzdLgwxEjkASPWy nIrf1O6C9f2vkUVGAWEo8wqhO+iLLmTRTt0GTsaIzA5aBmMz4KoByjOVwy6wAwoLTcFQrbGE jk5Cve+1AlXylTyokaeiYnKBjPMPSa5e3gcr3DfYQN5SbN3hXc8OFfkYzwqkZz4kMIWlP7pQ O0NqX8N+IiHJFc8BB8T8P4GRjO7jJYGtCJeTSVrO5tacpvJvg0BsHf48IpETH7Hs0oy1IXdZ DJQOceJCuOwDe7Q1ELHtIrjDeloN1CR+7M3qNc8wggaRMIIEeaADAgECAgIQHTANBgkqhkiG 9w0BAQsFADCBiTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRo ZSBEYW5pZWwgTW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBM TEMxIzAhBgNVBAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBMB4XDTIxMDMyOTA0Mjc0 NloXDTMxMDMyNzA0Mjc0NlowgaYxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMQ8w DQYDVQQHDAZOYXBsZXMxJjAkBgNVBAoMHVBlcnNvbmFsIElkZW50aXR5IENlcnRpZmljYXRl MRAwDgYDVQQLDAdIb21lIFBDMRcwFQYDVQQDDA5EYW5pZWwgTW9yYW50ZTEhMB8GCSqGSIb3 DQEJARYSZGFuaWVsQG1vcmFudGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAyjTH7YpZsiRpbQUpldun7uSfij/VVxewKjq5HusXO81CWrth5nYIe754ASllND1BkJkI Y1eRDDp8fgvEDmddk8+8idUlhcKNhtuGs1Z43Bk6PjQTNefzT2agbgrS+4pZsDG2xEuNx28L y1A0pLzmsUtLDZpuW6wnrN+1KlFnDcBBRjC6cZxGYogcz/Kd35f4OtIXdxNOuBMyJcn2W/h9 YZi6msZejTbp/Hod8sqG5SnoZAVr9rn4X1+/KIDJDItHf10hzX65AgU0NJXIxS5sTP8DStst twAgAXyKjaIE2RTTvxqMhlT1wJCKG5t63PSZ7ZIN8Quy2F2nNJr5MCBkA1+cKC7UDXrHs9xT OsuCf0iOhR3KfN5aRNkR1gdqInqtd/oscWhKByqtIjo/bi77NDcChRMS6gYF+lo5STnhAsFz z9fjNMOQQ4cDdZ0VffTv8wgGUOdo6LHyXI38AQUrJMRFdjiD/ol1j8++rGH9veTtSoLtbKVl YsdYXJ7CQniqS/BuL0PH9q35aDxhz2Thgdb1WpOgb8lpwUliKFaitXk7HUy/t6ThlWDhWtCm bFJcWdTKZoPUIrDxSzHMiVglIhkO33DAYZYBRC9TlhTMYTJJHioXIX+pjZ+xSzklEZo7I5Ob /08lomPW8C9do76EJcqdMEIjbAFTtcLnoTeIXpkCAwEAAaOB4zCB4DAJBgNVHRMEAjAAMA4G A1UdDwEB/wQEAwID+DAdBgNVHQ4EFgQUneNjyWA303ludVIz+7MVlPRjTzMwHwYDVR0jBBgw FoAUfJ3AAHKSNikU0RJBneEKXceyKVUwHQYDVR0RBBYwFIESZGFuaWVsQG1vcmFudGUubmV0 MCcGA1UdJQQgMB4GCCsGAQUFBwMEBggrBgEFBQcDAgYIKwYBBQUHAwgwOwYIKwYBBQUHAQEE LzAtMCsGCCsGAQUFBzAChh9odHRwOi8vd3d3LnBhY3l3b3JsZC5jb20vY2EucGhwMA0GCSqG SIb3DQEBCwUAA4ICAQCNZqZqo1Y8DXGyt6xMuTTya5+aUoIMhcwPpDwsze9l4sjEdrbngjOl lC5Cx0h31mL41oyoPbO3K+qjvbZHORasZRcEA/1uM4v5yV8s9DMlboEDLCwe3sjG7IwNXhcU GvAoVEalg9mQpr0Qfdb/m4VhDvGsqZa0wW7+vl8Sof6tPqIh7blLKwLHQPt1sZ8yYX4Sm2Bk IwpCfuNAniZOWWPQEYw2hVEqh1nhyhKBxt7W8ioEK/we6Nd4ivBjzEo3SmVvGcJHlDBfEOmH TqhMJp+wA30UJx4+4o2Z4frhCVIzhy4mKhLkG9a0Jj/ihJ/Cn/7R4ezDJ+a+FHim+sfsUST1 QhThcj2SIyfDaYqjE+zVx5yfp5aCdKG4xQQzPWZC0FGaBQ4ON6CGUe+XuBssiOXK7tkO5OQf q/qE+82UiwpVrbQ0by12V22zwVk/DiCEVd2L6Fhs2tDbdte2uLPFAhOyc4E7AW7VGjL81arV 0/ACWBdhuCaNOqvsk7koukM2lksY5FGvz4zARKIySjEyj2uI+iRWQFOjO4cea7UZKjHc44gf JBehl/Gdp8cdrAxo7fCnMbH3fYbagq+pF94bLcQZm61zO01Qz7TFfbaDv4YjHOilEAB30JdH JqWjYBp8LFj75VR6Ixt+uUtWVfWKBzlpIBZufbLsWNRzJZo9+5+lzjGCBQEwggT9AgEBMIGQ MIGJMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEpMCcGA1UECgwgVGhlIERhbmll bCBNb3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEjMCEG A1UEAwwaUGFjeSBXb3JsZCBJbnRlcm1lZGlhdGUgQ0ECAhAdMA0GCWCGSAFlAwQCAwUAoIIC QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTExMjAyMTAz NDFaME8GCSqGSIb3DQEJBDFCBEAPM0zmAlAv8tPxi5NePllzUmJ00c5dQoK1EjWvRftA4DJY Y4ZppN8xaMJQQefkGcGAzyDb/WBAz6+Eb+kBj+JhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGBkzCBkDCB iTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRoZSBEYW5pZWwg TW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBMTEMxIzAhBgNV BAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBAgIQHTCBowYLKoZIhvcNAQkQAgsxgZOg gZAwgYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFu aWVsIE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMw IQYDVQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQQICEB0wDQYJKoZIhvcNAQEBBQAE ggIApKhQFnb0BV11qLDUXJe+jGZbLAme5DyNdU2pyv0xmU0TvM/hM2Be0q3iTYfTu3yL7XxS xWt7C619VECbwdSUbJ6q0VKFVu5rPmjbo5cG7HtF5M0XjdQKfSmsJ6jUijYi3PAJg3pexDQZ lo/r0cLWALbBpsEIj9a+SsyPZfWlTCi1NUe+2vYV9P8CLxAZqMAjOl2rBFyiPqtQaG6CH7vL ERipsMTddZZfNHfm4uX63pj2h1NC0rJof9H+FdSRbiroWZZKPPjrjyNpTk6hKm/FmD8wocfH mNvyk2QFhXGyhk0JITL55sk7SujgkJRg0GXxgKRCF6UbHoUU/RVfav0sSHeBbUZFKIawAbQY SKzFKsT7hw7jc3rKVO2NuHEWunaVH435CrHUgmJBOHGEtD7EDwzFsx/EZHPyM/hhMPpSP7TX m0U4JjQBubNPF4VfTQpF+gN0Ei9pyTUEJ5Q3XJZra8FxYa3OxZChdHv1jn/lMTnDCvl6Fxe4 ptrUR3xlECSDeqfvZntk24t6JvU1THcGiqHOw8OtkeQSPSzAQvP7uPB1p79cVIvdHA0MUNbW yxYKkqrhnfwOzgOvMbrAHVqDfQJkv4N7qYrJUMKnH2hmzfMskS9apRPNILG/Z0ta+aqQQkJ0 fow+prVOykjYUFEQFvP/oIBIY2ybdkAggD0wjj4AAAAAAAA= --------------ms050302030407050600070902-- From nobody Sun Nov 21 07:02: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 41058189303E for ; Sun, 21 Nov 2021 07:02:30 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4HxhDN6t79z4RSW for ; Sun, 21 Nov 2021 07:02:28 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id 93A7011F812 for ; Sun, 21 Nov 2021 02:02:26 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_PASS autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id CB3CA11F80B for ; Sun, 21 Nov 2021 02:02:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1637478143; bh=T2FJjT++Gf3TU3pW3bgOlAJhseMjuDKltt/zJckEZIw=; h=Date:Subject:To:References:From:In-Reply-To; b=bscTZ20Ti7tgsscMgUM5ncEa4lUf7HfAxWpceCQ+q354d1JY6lBDmhs/KdI6CdCmr rhkNCjEnzNU2kU51QU0SqCZLrptrR8rNOEPudW4jnoGU4lL4+/ghN7hNuWdhTZAOjN 76Y0Y26Y+7bEWFqgYsQDPFVK42UFT4YPPJKlO1Mg= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at zenon.morante.com Message-ID: <285be6e3-440c-5d3d-b4fa-e15802b47d7e@morante.net> Date: Sun, 21 Nov 2021 02:02:09 -0500 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 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <7f41d2d1-ef24-6e07-1ea7-a3a240d90a33@morante.net> In-Reply-To: <7f41d2d1-ef24-6e07-1ea7-a3a240d90a33@morante.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030405060006080109090505" X-Rspamd-Queue-Id: 4HxhDN6t79z4RSW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b=bscTZ20T; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: daniel@morante.net From: Daniel Morante via freebsd-arm X-Original-From: Daniel Morante X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms030405060006080109090505 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I have had no luck with 20211118 (4082b189d2c).  I was only able to get it two boot twice and in those two instances it just locks up during the network setup step.  The majority of the time it just panics when booting off the ISO image.  I tried about 13 times.  All my attempts are logged at http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/ Here's an example (of the panic part only): Release APs...done random: unblocking device. panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff00010a0c5000 cpuid = 178 time = 2 KDB: stack backtrace: db_trace_self() at db_trace_self KDB: enter: panic [ thread pid 0 tid 100694 ] Stopped at      kdb_enter+0x44: undefined       f901411f db> bt Tracing pid 0 tid 100694 td 0xffffa0000882c000 db_trace_self() at db_trace_self db> Just for fun I tried the same snapshot in a virtual machine (using ESXi for ARM) on the same hardware and same machine.  That booted and installed just fine. On 11/20/2021 4:03 PM, Daniel Morante via freebsd-arm wrote: > May or may not be related, but here's a bt after a panic while running > poudriere for a few hours.  I still have hw.usb.disable_enumeration=1 > set.  I'm going to do a new install with the latest snapshot later > today.  I'll post a bt of that without hw.usb.disable_enumeration once > I get it. > > db> bt > Tracing pid 0 tid 101633 td 0xffffa008230c6580 > db_trace_self() at db_trace_self > db_stack_trace() at db_stack_trace+0x11c > db_command() at db_command+0x310 > db_command_loop() at db_command_loop+0x54 > db_trap() at db_trap+0xf8 > kdb_trap() at kdb_trap+0x1c0 > handle_el1h_sync() at handle_el1h_sync+0x78 > --- exception, esr 0xf2000000 > kdb_enter() at kdb_enter+0x44 > vpanic() at vpanic+0x1c0 > panic() at panic+0x44 > deadlkres() at deadlkres+0x2c0 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > > I'll find a > > On 11/12/2021 5:52 AM, Hans Petter Selasky wrote: >> On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote: >>> ugen0.2: at usbus0 (disconnected) >>> uhub5: at uhub0, port 1, addr 1 (disconnected) >>> uhub5: detached >>> ugen0.2: at usbus0 >>> uhub5 numa-domain 0 on uhub0 >>> uhub5: on usbus0 >>> uhub5: 4 ports with 4 removable, self powered >>> >>> I suspect these problems are caused by the above detaching/reattaching. >> >> Can you type "bt" in the panic prompt? >> >> --HPS >> --------------ms030405060006080109090505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DJgwggX/MIID56ADAgECAgIQADANBgkqhkiG9w0BAQsFADCBkjELMAkGA1UEBhMCVVMxEDAO BgNVBAgMB0Zsb3JpZGExDzANBgNVBAcMBk5hcGxlczEpMCcGA1UECgwgVGhlIERhbmllbCBN b3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEbMBkGA1UE AwwSUGFjeSBXb3JsZCBSb290IENBMB4XDTE4MDcwNzE3MzUzMVoXDTI4MDcwNDE3MzUzMVow gYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFuaWVs IE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMwIQYD VQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAMU0vt8sGT82c8BLAT+otS3VQVw4rf566bmYzJ7wm+D/vcp5jiwL1PAnGFch bSSpe1KCFQ7LCnjrl7nQg1EglHKETfHI7QxVqE22q92G/2rIDfPnNTYlLJ0d5xmM0q1P+yEI XYZErQyBthDhHfrDIEdWJ5tWevfFAUFjXmWy5V7eHGgndB8TQFEp9ML6Bks4tKH3ykwAZbib hKd7L2EthiqSJvvyIP3Kg/AwVjX67JTbKgQfcsfYGm5dofHmL+3uIhovLL5HFbADU6AoqXlh lNY83RfaD60G6IhPZwzZboBi6qxHnjwqsbV+S81SZdoMEnHDMZNzP4RC27ZMaTmxH3IN8JN4 XuszONstvUAuzdhmcG4q+K7HrO+SG0eEhDBUrxKrmFCUh8pwYU2o4q52/yDrZasid1NBFHZt Wfsyoe1ArhqnO4yz95h53dR9aCISwOGIMExNUJlH91KYNrLeSbPMR7LXgu48hY+CGkSYXhcS fPF9p9OUjgUeZ02+K8iI4a0CYCjuJNF1N/rJ7UkT0b5hdkcLPrXCd8P6NfJotoX6cGITF7Rm z+fq/3NbjF2Gu3nWeCdOXyECW9/HBzTlILZI10VOmfqDGZK3z6SlRBlaXK4lUvbqfDM+E785 CxStIlNqx/FDM6O8F+OP17Yb1vNpDhAblV/eYFiGZOw0YZAzAgMBAAGjZjBkMB0GA1UdDgQW BBR8ncAAcpI2KRTREkGd4Qpdx7IpVTAfBgNVHSMEGDAWgBR6BEY736L1bCcrmtwFaEg93nZd uTASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOC AgEAs/eYLE+jKO3hpHJ8QYaL8FH7iFFNbB4SVBDyH0arb9uqK/FY8uGlOn2A9ul8cE7sSA3E dXptZzFqY+C69UjlV2kvw2+35gvKoiIncwYhCA2JOQgm0QaXBAxZijF5UOL3+i1IE8JpdShz IoUvPtXBQiVnW9HJ5jZnZJNy4Jid+RQd5fNL2WmJf1Ob48YoeB23Y0KUnUvhmmu52OUG+bni hbP4ULTL4egmR783ZA5CqBWFb0J7HhXDaPBM1dGf+gQ5YzJqGWZXZ3YRe83IlDXm76rK+wlO uPlRUGSBbkgv7YRKzBx2JNLdNPBXIDxT71b1kGip8q0Mk9f/VXeudgCLzqa1+gphE3lNYQMa 0CHYfezask6ee5999rezWDx/T2/U0xy8i+bBlRNL7QRwk5JRTOemxbJJ5fzdLgwxEjkASPWy nIrf1O6C9f2vkUVGAWEo8wqhO+iLLmTRTt0GTsaIzA5aBmMz4KoByjOVwy6wAwoLTcFQrbGE jk5Cve+1AlXylTyokaeiYnKBjPMPSa5e3gcr3DfYQN5SbN3hXc8OFfkYzwqkZz4kMIWlP7pQ O0NqX8N+IiHJFc8BB8T8P4GRjO7jJYGtCJeTSVrO5tacpvJvg0BsHf48IpETH7Hs0oy1IXdZ DJQOceJCuOwDe7Q1ELHtIrjDeloN1CR+7M3qNc8wggaRMIIEeaADAgECAgIQHTANBgkqhkiG 9w0BAQsFADCBiTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRo ZSBEYW5pZWwgTW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBM TEMxIzAhBgNVBAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBMB4XDTIxMDMyOTA0Mjc0 NloXDTMxMDMyNzA0Mjc0NlowgaYxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMQ8w DQYDVQQHDAZOYXBsZXMxJjAkBgNVBAoMHVBlcnNvbmFsIElkZW50aXR5IENlcnRpZmljYXRl MRAwDgYDVQQLDAdIb21lIFBDMRcwFQYDVQQDDA5EYW5pZWwgTW9yYW50ZTEhMB8GCSqGSIb3 DQEJARYSZGFuaWVsQG1vcmFudGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAyjTH7YpZsiRpbQUpldun7uSfij/VVxewKjq5HusXO81CWrth5nYIe754ASllND1BkJkI Y1eRDDp8fgvEDmddk8+8idUlhcKNhtuGs1Z43Bk6PjQTNefzT2agbgrS+4pZsDG2xEuNx28L y1A0pLzmsUtLDZpuW6wnrN+1KlFnDcBBRjC6cZxGYogcz/Kd35f4OtIXdxNOuBMyJcn2W/h9 YZi6msZejTbp/Hod8sqG5SnoZAVr9rn4X1+/KIDJDItHf10hzX65AgU0NJXIxS5sTP8DStst twAgAXyKjaIE2RTTvxqMhlT1wJCKG5t63PSZ7ZIN8Quy2F2nNJr5MCBkA1+cKC7UDXrHs9xT OsuCf0iOhR3KfN5aRNkR1gdqInqtd/oscWhKByqtIjo/bi77NDcChRMS6gYF+lo5STnhAsFz z9fjNMOQQ4cDdZ0VffTv8wgGUOdo6LHyXI38AQUrJMRFdjiD/ol1j8++rGH9veTtSoLtbKVl YsdYXJ7CQniqS/BuL0PH9q35aDxhz2Thgdb1WpOgb8lpwUliKFaitXk7HUy/t6ThlWDhWtCm bFJcWdTKZoPUIrDxSzHMiVglIhkO33DAYZYBRC9TlhTMYTJJHioXIX+pjZ+xSzklEZo7I5Ob /08lomPW8C9do76EJcqdMEIjbAFTtcLnoTeIXpkCAwEAAaOB4zCB4DAJBgNVHRMEAjAAMA4G A1UdDwEB/wQEAwID+DAdBgNVHQ4EFgQUneNjyWA303ludVIz+7MVlPRjTzMwHwYDVR0jBBgw FoAUfJ3AAHKSNikU0RJBneEKXceyKVUwHQYDVR0RBBYwFIESZGFuaWVsQG1vcmFudGUubmV0 MCcGA1UdJQQgMB4GCCsGAQUFBwMEBggrBgEFBQcDAgYIKwYBBQUHAwgwOwYIKwYBBQUHAQEE LzAtMCsGCCsGAQUFBzAChh9odHRwOi8vd3d3LnBhY3l3b3JsZC5jb20vY2EucGhwMA0GCSqG SIb3DQEBCwUAA4ICAQCNZqZqo1Y8DXGyt6xMuTTya5+aUoIMhcwPpDwsze9l4sjEdrbngjOl lC5Cx0h31mL41oyoPbO3K+qjvbZHORasZRcEA/1uM4v5yV8s9DMlboEDLCwe3sjG7IwNXhcU GvAoVEalg9mQpr0Qfdb/m4VhDvGsqZa0wW7+vl8Sof6tPqIh7blLKwLHQPt1sZ8yYX4Sm2Bk IwpCfuNAniZOWWPQEYw2hVEqh1nhyhKBxt7W8ioEK/we6Nd4ivBjzEo3SmVvGcJHlDBfEOmH TqhMJp+wA30UJx4+4o2Z4frhCVIzhy4mKhLkG9a0Jj/ihJ/Cn/7R4ezDJ+a+FHim+sfsUST1 QhThcj2SIyfDaYqjE+zVx5yfp5aCdKG4xQQzPWZC0FGaBQ4ON6CGUe+XuBssiOXK7tkO5OQf q/qE+82UiwpVrbQ0by12V22zwVk/DiCEVd2L6Fhs2tDbdte2uLPFAhOyc4E7AW7VGjL81arV 0/ACWBdhuCaNOqvsk7koukM2lksY5FGvz4zARKIySjEyj2uI+iRWQFOjO4cea7UZKjHc44gf JBehl/Gdp8cdrAxo7fCnMbH3fYbagq+pF94bLcQZm61zO01Qz7TFfbaDv4YjHOilEAB30JdH JqWjYBp8LFj75VR6Ixt+uUtWVfWKBzlpIBZufbLsWNRzJZo9+5+lzjGCBQEwggT9AgEBMIGQ MIGJMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEpMCcGA1UECgwgVGhlIERhbmll bCBNb3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEjMCEG A1UEAwwaUGFjeSBXb3JsZCBJbnRlcm1lZGlhdGUgQ0ECAhAdMA0GCWCGSAFlAwQCAwUAoIIC QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTExMjEwNzAy MDlaME8GCSqGSIb3DQEJBDFCBEDLBAO6K1at3ofGa379hWz5dYytxtKdmuFMOK5ljFvDmVWh TdLwprs32MVvjESO+rMnrhQgcq8ad7AXhzbf1pBJMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGBkzCBkDCB iTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRoZSBEYW5pZWwg TW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBMTEMxIzAhBgNV BAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBAgIQHTCBowYLKoZIhvcNAQkQAgsxgZOg gZAwgYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFu aWVsIE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMw IQYDVQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQQICEB0wDQYJKoZIhvcNAQEBBQAE ggIAJMEVPfmvWAtdsLVDFn4oBazt5a14AJh/tckas+t72tW+LiSH43DFJZhdXHQZt4hXX5dD tc2dbelBKK5NDjgS2sa1NVRDl9NjvS6+4WVU7y+BUDc8Ychh5GNnjvt87UmyPXxhKwC7p4cS 63O1xClDykG9vQ+3K9uOdRrvF//Mmlrl2iUz0fceSKxE4Amc960J2qPrgJQ6VjSKFjz6inbG kwJ9hsnKhnLgVgp9L8FRROdJogsC2pO385QGbHAt/eR4+/3+AfaeP06m7qxzrA80dly1fm24 68WZZuBnfjghB0MoxrcRaPg7k8roaLlT89HqYl3EA0GE4zrezDZvV2VulbRNq0fsc2fWJlvk psIdKjmhjwlpWKN7ewDmFAkRzPHGKKKrTO7BpBybkuB5UUcMl9Id3Xduxzh4JB1kium4tlLU EaygE8xd0JTXMvNFdx48bIKQ/OkMSfX68j6TLpVj7NwpNnVpANJ66C//nMngyETcxiZGUvEG 18IaLYb430C5YCyA+WqF53CHwKf6WttfyUHsIBnWveTL1b8vOgJ9NogarFZSGuvejU+Jnh8S il7ssE+ZyPWhlSkriNvLiPR+2XDrOqcxSTvZsevjlCva5IPQ56tSiXIlbvwlH3c8/r6UkBx1 rRYjwxT0hmfssZ52ZCE8cLH1P1DfH0TeQmc79XYAAAAAAAA= --------------ms030405060006080109090505-- From nobody Sun Nov 21 07:18:03 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 78A7B189CE0A for ; Sun, 21 Nov 2021 07:18:19 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4HxhZf54lsz4XLZ for ; Sun, 21 Nov 2021 07:18:18 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id BE62511F811 for ; Sun, 21 Nov 2021 02:18:16 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_PASS autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id 4976711F80B for ; Sun, 21 Nov 2021 02:18:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1637479096; bh=CBu/cmFg+sXtAlEJ8AlBCkethLfl0pTpf6yMbwqECCU=; h=Date:Subject:To:References:From:In-Reply-To; b=qeSADoeTyq8Q15ho9ffx10iC9M5jNTeqRzhsiozsrrVR5DSXvhxLLcoR8lNZ8pCoL c+EhElUkIAPK573tCiWpgWB3dDiviB9yk/xoLzMkQaZsYvAqEC2nULkkeCy0XdahW5 VXgMt3OC5RELBrgpln/fnFZm8WzGeJG9E2BZxZ+4= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at zenon.morante.com Message-ID: <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> Date: Sun, 21 Nov 2021 02:18:03 -0500 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 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> In-Reply-To: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010106090809030306010503" X-Rspamd-Queue-Id: 4HxhZf54lsz4XLZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b=qeSADoeT; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-2.95 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.95)[-0.954]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: daniel@morante.net From: Daniel Morante via freebsd-arm X-Original-From: Daniel Morante X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms010106090809030306010503 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Here's the bt: ugen0.2: at usbus0 (disconnected) uhub5: at uhub0, port 1, addr 1 (disconnected) uhub5: detached ugen0.2: at usbus0 uhub5 numa-domain 0 on uhub0 uhub5: on usbus0 uhub5: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub5: at uhub0, port 1, addr 1 (disconnected) uhub5: detached panic: data abort with spinlock held cpuid = 108 time = 1637478997 KDB: stack backtrace: db_trace_self() at db_trace_self KDB: enter: panic [ thread pid 11 tid 100111 ] Stopped at      kdb_enter+0x44: undefined       f901411f db> bt Tracing pid 11 tid 100111 td 0xffffa00005619580 db_trace_self() at db_trace_self db> On 11/12/2021 5:52 AM, Hans Petter Selasky wrote: > On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote: >> ugen0.2: at usbus0 (disconnected) >> uhub5: at uhub0, port 1, addr 1 (disconnected) >> uhub5: detached >> ugen0.2: at usbus0 >> uhub5 numa-domain 0 on uhub0 >> uhub5: on usbus0 >> uhub5: 4 ports with 4 removable, self powered >> >> I suspect these problems are caused by the above detaching/reattaching. > > Can you type "bt" in the panic prompt? > > --HPS > --------------ms010106090809030306010503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DJgwggX/MIID56ADAgECAgIQADANBgkqhkiG9w0BAQsFADCBkjELMAkGA1UEBhMCVVMxEDAO BgNVBAgMB0Zsb3JpZGExDzANBgNVBAcMBk5hcGxlczEpMCcGA1UECgwgVGhlIERhbmllbCBN b3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEbMBkGA1UE AwwSUGFjeSBXb3JsZCBSb290IENBMB4XDTE4MDcwNzE3MzUzMVoXDTI4MDcwNDE3MzUzMVow gYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFuaWVs IE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMwIQYD VQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAMU0vt8sGT82c8BLAT+otS3VQVw4rf566bmYzJ7wm+D/vcp5jiwL1PAnGFch bSSpe1KCFQ7LCnjrl7nQg1EglHKETfHI7QxVqE22q92G/2rIDfPnNTYlLJ0d5xmM0q1P+yEI XYZErQyBthDhHfrDIEdWJ5tWevfFAUFjXmWy5V7eHGgndB8TQFEp9ML6Bks4tKH3ykwAZbib hKd7L2EthiqSJvvyIP3Kg/AwVjX67JTbKgQfcsfYGm5dofHmL+3uIhovLL5HFbADU6AoqXlh lNY83RfaD60G6IhPZwzZboBi6qxHnjwqsbV+S81SZdoMEnHDMZNzP4RC27ZMaTmxH3IN8JN4 XuszONstvUAuzdhmcG4q+K7HrO+SG0eEhDBUrxKrmFCUh8pwYU2o4q52/yDrZasid1NBFHZt Wfsyoe1ArhqnO4yz95h53dR9aCISwOGIMExNUJlH91KYNrLeSbPMR7LXgu48hY+CGkSYXhcS fPF9p9OUjgUeZ02+K8iI4a0CYCjuJNF1N/rJ7UkT0b5hdkcLPrXCd8P6NfJotoX6cGITF7Rm z+fq/3NbjF2Gu3nWeCdOXyECW9/HBzTlILZI10VOmfqDGZK3z6SlRBlaXK4lUvbqfDM+E785 CxStIlNqx/FDM6O8F+OP17Yb1vNpDhAblV/eYFiGZOw0YZAzAgMBAAGjZjBkMB0GA1UdDgQW BBR8ncAAcpI2KRTREkGd4Qpdx7IpVTAfBgNVHSMEGDAWgBR6BEY736L1bCcrmtwFaEg93nZd uTASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOC AgEAs/eYLE+jKO3hpHJ8QYaL8FH7iFFNbB4SVBDyH0arb9uqK/FY8uGlOn2A9ul8cE7sSA3E dXptZzFqY+C69UjlV2kvw2+35gvKoiIncwYhCA2JOQgm0QaXBAxZijF5UOL3+i1IE8JpdShz IoUvPtXBQiVnW9HJ5jZnZJNy4Jid+RQd5fNL2WmJf1Ob48YoeB23Y0KUnUvhmmu52OUG+bni hbP4ULTL4egmR783ZA5CqBWFb0J7HhXDaPBM1dGf+gQ5YzJqGWZXZ3YRe83IlDXm76rK+wlO uPlRUGSBbkgv7YRKzBx2JNLdNPBXIDxT71b1kGip8q0Mk9f/VXeudgCLzqa1+gphE3lNYQMa 0CHYfezask6ee5999rezWDx/T2/U0xy8i+bBlRNL7QRwk5JRTOemxbJJ5fzdLgwxEjkASPWy nIrf1O6C9f2vkUVGAWEo8wqhO+iLLmTRTt0GTsaIzA5aBmMz4KoByjOVwy6wAwoLTcFQrbGE jk5Cve+1AlXylTyokaeiYnKBjPMPSa5e3gcr3DfYQN5SbN3hXc8OFfkYzwqkZz4kMIWlP7pQ O0NqX8N+IiHJFc8BB8T8P4GRjO7jJYGtCJeTSVrO5tacpvJvg0BsHf48IpETH7Hs0oy1IXdZ DJQOceJCuOwDe7Q1ELHtIrjDeloN1CR+7M3qNc8wggaRMIIEeaADAgECAgIQHTANBgkqhkiG 9w0BAQsFADCBiTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRo ZSBEYW5pZWwgTW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBM TEMxIzAhBgNVBAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBMB4XDTIxMDMyOTA0Mjc0 NloXDTMxMDMyNzA0Mjc0NlowgaYxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMQ8w DQYDVQQHDAZOYXBsZXMxJjAkBgNVBAoMHVBlcnNvbmFsIElkZW50aXR5IENlcnRpZmljYXRl MRAwDgYDVQQLDAdIb21lIFBDMRcwFQYDVQQDDA5EYW5pZWwgTW9yYW50ZTEhMB8GCSqGSIb3 DQEJARYSZGFuaWVsQG1vcmFudGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAyjTH7YpZsiRpbQUpldun7uSfij/VVxewKjq5HusXO81CWrth5nYIe754ASllND1BkJkI Y1eRDDp8fgvEDmddk8+8idUlhcKNhtuGs1Z43Bk6PjQTNefzT2agbgrS+4pZsDG2xEuNx28L y1A0pLzmsUtLDZpuW6wnrN+1KlFnDcBBRjC6cZxGYogcz/Kd35f4OtIXdxNOuBMyJcn2W/h9 YZi6msZejTbp/Hod8sqG5SnoZAVr9rn4X1+/KIDJDItHf10hzX65AgU0NJXIxS5sTP8DStst twAgAXyKjaIE2RTTvxqMhlT1wJCKG5t63PSZ7ZIN8Quy2F2nNJr5MCBkA1+cKC7UDXrHs9xT OsuCf0iOhR3KfN5aRNkR1gdqInqtd/oscWhKByqtIjo/bi77NDcChRMS6gYF+lo5STnhAsFz z9fjNMOQQ4cDdZ0VffTv8wgGUOdo6LHyXI38AQUrJMRFdjiD/ol1j8++rGH9veTtSoLtbKVl YsdYXJ7CQniqS/BuL0PH9q35aDxhz2Thgdb1WpOgb8lpwUliKFaitXk7HUy/t6ThlWDhWtCm bFJcWdTKZoPUIrDxSzHMiVglIhkO33DAYZYBRC9TlhTMYTJJHioXIX+pjZ+xSzklEZo7I5Ob /08lomPW8C9do76EJcqdMEIjbAFTtcLnoTeIXpkCAwEAAaOB4zCB4DAJBgNVHRMEAjAAMA4G A1UdDwEB/wQEAwID+DAdBgNVHQ4EFgQUneNjyWA303ludVIz+7MVlPRjTzMwHwYDVR0jBBgw FoAUfJ3AAHKSNikU0RJBneEKXceyKVUwHQYDVR0RBBYwFIESZGFuaWVsQG1vcmFudGUubmV0 MCcGA1UdJQQgMB4GCCsGAQUFBwMEBggrBgEFBQcDAgYIKwYBBQUHAwgwOwYIKwYBBQUHAQEE LzAtMCsGCCsGAQUFBzAChh9odHRwOi8vd3d3LnBhY3l3b3JsZC5jb20vY2EucGhwMA0GCSqG SIb3DQEBCwUAA4ICAQCNZqZqo1Y8DXGyt6xMuTTya5+aUoIMhcwPpDwsze9l4sjEdrbngjOl lC5Cx0h31mL41oyoPbO3K+qjvbZHORasZRcEA/1uM4v5yV8s9DMlboEDLCwe3sjG7IwNXhcU GvAoVEalg9mQpr0Qfdb/m4VhDvGsqZa0wW7+vl8Sof6tPqIh7blLKwLHQPt1sZ8yYX4Sm2Bk IwpCfuNAniZOWWPQEYw2hVEqh1nhyhKBxt7W8ioEK/we6Nd4ivBjzEo3SmVvGcJHlDBfEOmH TqhMJp+wA30UJx4+4o2Z4frhCVIzhy4mKhLkG9a0Jj/ihJ/Cn/7R4ezDJ+a+FHim+sfsUST1 QhThcj2SIyfDaYqjE+zVx5yfp5aCdKG4xQQzPWZC0FGaBQ4ON6CGUe+XuBssiOXK7tkO5OQf q/qE+82UiwpVrbQ0by12V22zwVk/DiCEVd2L6Fhs2tDbdte2uLPFAhOyc4E7AW7VGjL81arV 0/ACWBdhuCaNOqvsk7koukM2lksY5FGvz4zARKIySjEyj2uI+iRWQFOjO4cea7UZKjHc44gf JBehl/Gdp8cdrAxo7fCnMbH3fYbagq+pF94bLcQZm61zO01Qz7TFfbaDv4YjHOilEAB30JdH JqWjYBp8LFj75VR6Ixt+uUtWVfWKBzlpIBZufbLsWNRzJZo9+5+lzjGCBQEwggT9AgEBMIGQ MIGJMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEpMCcGA1UECgwgVGhlIERhbmll bCBNb3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEjMCEG A1UEAwwaUGFjeSBXb3JsZCBJbnRlcm1lZGlhdGUgQ0ECAhAdMA0GCWCGSAFlAwQCAwUAoIIC QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTExMjEwNzE4 MDNaME8GCSqGSIb3DQEJBDFCBEDH6afEtWGmCpmG6v7DvISX40XIxGtGK7MwiOOPqgpoEsZS lYiX7Zy2SPzvNEYmHC3zZ5blzMCfKgIo+gnjY9f8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGBkzCBkDCB iTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRoZSBEYW5pZWwg TW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBMTEMxIzAhBgNV BAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBAgIQHTCBowYLKoZIhvcNAQkQAgsxgZOg gZAwgYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFu aWVsIE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMw IQYDVQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQQICEB0wDQYJKoZIhvcNAQEBBQAE ggIABdH4knOiNQRs4PQC+bFzRFeFSL9nzXm1+yvD47Af6IQmb8T7Q7lr1Jgjum9GF3mbi30/ bSjlL/S8wZqCKhJUs2GrVYp9ncYjGkNmQJYhyX6Dgcpr9C7bwXrMndRXpbHSh8BlCp9/wKyY pmMgSpqv0ttLVKftUGbhhZVmqinigvU14bowv2URvd5Q/DbR0hsYm0YlUXCfCDlRP/lp9/d8 R+8JV2wSiXeXkvoXtb5ge/NfK8L/uFtEKi7uLSvHqWh0M1d/2zKDdk6mWemCkWgqpbolVasw ahUYQYHdRENm7JaV4HJr9VVsaK/icBZnw7fpuWir5pmGAriikbQ3asJqg5rxcyyPyhfMyKtu ed2HNEp5hHPJPIBsJpqRZ4dGkLcsW66Ofh1w6Ja39Ip1/NFpVS03qhsv9zebXVuVtAO9+bkN fQNZsFNa6wjThtfcLbudG2ganwZomTPWZLAhp2nm0S6semLhdYvNLidMzPPHi7+6Wn7gFSeh 8yH3iWpeCUY3e2Xhn678o2VV4JCgzMH6V+EtBSTdx018V8p8nwhx8C0VyGv+Ip9S8i+B/MqV tP3XrPvc87gXA8mMAyZRyKjMQ7G6++ydf/erECnjGSDVfUA5L2ASE13G507O19nIM+AZcIOj qo+YZ24EwAEzPNhnHDjlf1obZfjTHEZPIlN+3PMAAAAAAAA= --------------ms010106090809030306010503-- From nobody Sun Nov 21 15:50:47 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 290AF189263F for ; Sun, 21 Nov 2021 15:51:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4Hxvz43SXyz3P0R for ; Sun, 21 Nov 2021 15:51:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637509897; bh=QZSEXVV7FCogL5NbOUTECsNErnqrYYObbNZQsklWEuA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=r/T5YcS8y840HIuty/HiQvPzqNyjbk5hspQ5sSgeuyYCM3j0OkhgytCmk8strx3ALKBuwwIzfi63Ke1Qox74gnXT9AuNFLeH/VsRPscVBXcpzePghgOiuyeE7tVyYxfe/tYdQUS9mKVOodMhMqsyNIMZA1Zl8eYIDq0GXOiJoDi5UiL4zvxn1uwjkEioJCjTIIP+LHoS5UKCbj20Zc/75tzv6P40jx+mCZGMzHS5WAA0usYdX7JsuG1Shv4iAuoHyBg5T5vxp3igE9tgNq1/CIy4YmEIrvzOI8oJHtqCUcQjMKI23DKglDhRVBwQgXY+l/xXFcNAllTslkrHh5pwCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637509897; bh=RFWsQzl2v2I2nXC4DJ3ikpMeKzH5HZFYZZySPTNUrZz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Wb0T74S72scCFiulqYyK43FjLU46Fcm2veWZbipoPWgr1d4Vg7gItB3hPcPRBGMgN/sDfN3wtPXV7fyvJQFEHzRwIOr/IDBVH6p2K+g27dXyFCctBFRFVbJ2cQZ2J85olsSBkAyNSeYyHgQLpPr+slVMSe0u/KPUf+qowKGtrE/MhAnil8mxejaa/ZSNnj8HlIjHMyxl87NEkLDehTXjt3HKS+Biu9koVU2nPeCUK5yOiBCuuAOTQNy9qAe2oIDHJwNLO9+n/OYO8CHGKrEdVNDGk6JhQ2jW148qitisI3QLIXTsBHiAm69wM2TeVU4+BSXBRWUdSjbiOcIuGruFKQ== X-YMail-OSG: JKJw9FIVM1m3C82aTQft.Nz141yIMMdHHvkIjLLEbYUqu_jjBC1D.46UhvIqaBD 76teelPRC95TjqqurKg1GvJQWKsK3A.m5X5aMNaWTt1EX44QOeGqjjgrYdIsBFE0PhzVYh8ZUGWc yob_vrPYMYSTa7GyL.9s7SyAcfaudn7.FNX8py6vaChfmi72C8x424aMBAqzLjI_4.RckifbrWQM QyolScqF.uFFHdH68oQcUGVeMJ1X49bKXLSU0bpzwOHOkAj2kxtelrcVLL6PLF.JOnkhwIKZvheH UpNQw3yMm17bqDleVCunGrHHvFtv3vGyVZXXjnpVQIF5T6Ow2pexjDizpdcToKige2GtP4Tkfe_V FXf0R6AuGu.ohMpE0F2damb3qpI41czmbzG8UoX6erGLULRV1hZ6o4pBL1qw8duUae3GZ45qK7Zb PhF80whT92a5OXrjGSGYqCEpdfpzSem3qFGZDDxq75ui63X1g.h9VFhfbLSnoVyYCmtlkrE0_1sb 5pSzL6pKeepSxhM1lwfk.mowX9WdPmUf0w8vk.7BU2bmpQklT4NWHRl5JcZqZT49Vs4tj_rfbeVF QRewH2j1iscJUBes5eD4RTR7YF4.i.1NyCZzd6iksI4lA7lvJZ9aOCfYhM.TdqJlKU9XWi.bdlcm x9j7SbSnEjEh4Xze_XB..zjWJ.8SQL62BD.5bnhbu5OrhjXvooSJTqsckBXQxUcWlq8WqntLxJ0E 8MAfgMDTfKJcSyplM9RQ4l67qZWG_D1WrKwyICrHlpu9kdcakOtJKN_axqZEfy4GaqlymHCy62Zv 1ReeAS1Ig149ba122MtHK9rnw1yYnUTZM8thTSE2JT0ehuo0_frtKvHZbS0Fe8jbZmTSthDwe2M7 jKg.54nvYVgP2y2FD9fGaapr6pWfSUlXiN9GUbAgeLXKPpPto6paQLJJui7ypprVg0SUjRS0l8AT J5QU63NTNklXLDHUeJKVTMhkwkVILd3mNYY8rkNqunfdfmMpo5DgSB_t2UJUO856.Is7w_.1utri nAyk_4mBAAVikslN19T7wHpHDwOaSOU1n7zwcyho6Sk.Ag5IqTElxrfbjn4EfgHbYD.y0KtFauVT K4g7dB21PO74b7bSMwoGPosW6EzmrV7q7KvCmrqc0TtJPo4yBkkA7iMXVC13adzYMhtff4eDzCz9 5Xv7cOCIb3BCeCbtmI.bDArEHWhdc1V7o__Z38q60T5RnRD4TzGLt8xBIDZdH2s79WtScFcesgPe 5EPAfurxpXw9cxI7w8wL2kaONGctNUBHNp5nyYp1j7cWnmgvSJ9eyKcY7BHPHn3nlPg7K6ASQ5V1 I8MZzfdaNJFL_Ymu9bPQHMMVLl4bY_Knvjo24b0dKyVT.zW8yzK5cZmgbqFfPnS07riSExuvowcX .AQUwjyu2shJGVIVLNnYV2rqX6TQDepTBI.j9WSOfSLXORKLsYWnJ9l1XxGl0ewK71unWnhKBppy TQlNZ1cvOqpP_DXdab8ahsoOdNWmCfsenBD_6GPirQA7UaMuvPbxC7PhGe.2NCWiFbBzhf_c0.nm hTGP5Ca0n2NheBOuGzWkrfka5yl9P_q.XIXJVIG9NhsyY.y2IFuoWOENE4LWyqDAvbTVL6mIvwg5 EYqNs0s99_ZkH60bHwlZNY6aOTmP0zEJqInNPLmjTDjTQiOMccI.pDOFXl00f4Mpa2_dK6XNB9u3 qJPW91RMvFt2IHAaLOyPBP9t59ji8IVhcYcKTU17gTHdqjehxOPEBJr3QzhV34qh4cn50xEeeAiJ keuPM7S5BDtoh01Bnv.MXgn.TO9KRA5CqwMzXXpnikc6yDgJGikF3NWf5s8ZIoCCWRuhD9Mfr_6r KCTyqYFwUlGQZzlwmnr7AMIeWAwjwA3utCAcS7GGJ_RuA8_ErErkELPuVFXEzi617qn2zdvzGSSM p9SPc4OuCi2w3aBoPVwWLZtkfrBlbbcidFMjQ_3YwAkA.9RjFAZmoV9eBYiT7.YNDtDDpuxVHP.y z3Jn0pQYDZfC5v2IhHVtOEpwOaex3IIIGk.Xo6OOCtVaj.FKTGaPJ13pr5GXDFuAMTSAmsBS4xPl vQ3v2qMR4.FKBDq8MSm.mT6Ybal_faZbr57erYz1DXaa7.WYVCpPQbjRRzbzKBVIyr6VvrsIN5M8 VELf7NwXZkTJbKkyrU.WAIYvIcBENs4y1kTxI0vYUrd39eXTN8aEbtiUr2fACFNIFA1_KwCaNi4r s7dFCuLUNzW84eujv9AV.t0uOLOLKfZWHS4oYo.b.8g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 15:51:37 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 200c7f179f811ed8c8d4f0075a2965ea; Sun, 21 Nov 2021 15:50:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Sun, 21 Nov 2021 07:50:47 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hxvz43SXyz3P0R X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="r/T5YcS8"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-20, at 11:54, Mark Millard wrote: > On 2021-Nov-19, at 22:20, Mark Millard wrote: >=20 >> On 2021-Nov-18, at 12:15, Mark Millard wrote: >>=20 >>> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>>>=20 >>>>>>> On 2021-Nov-15, at 11:31, Mark Millard = wrote: >>>>>>>=20 >>>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>>=20 >>>>>>>> # uname -apKU >>>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>>> 1400040 1400040 >>>>>>>>=20 >>>>>>>> to: >>>>>>>>=20 >>>>>>>> # uname -apKU >>>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>>=20 >>>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>>> a general update of /usr/ports/ were on 2021-10-23 before = either of the >>>>>>>> above. >>>>>>>>=20 >>>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>>> example: >>>>>>>>=20 >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>>> =20 >>>>>>>> ^ >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>>> >>>>>>>> ^ >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>>> =20 >>>>>>>> ^ =20 >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>>> >>>>>>>> ^ >>>>>>>> . . . >>>>>>>>=20 >>>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>>> on it. >>>>>>>>=20 >>>>>>>> This was from a use of: >>>>>>>>=20 >>>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>>> Jail name: 13_0R-CA7 >>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>> Jail arch: arm.armv7 >>>>>>>> Jail method: null >>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>>> Jail fs: =20 >>>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>>> Jail pkgbase: disabled >>>>>>>>=20 >>>>>>>> but another not-investigated example was from: >>>>>>>>=20 >>>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>>> Jail name: 13_0R-CA72 >>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>> Jail arch: arm64.aarch64 >>>>>>>> Jail method: null >>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>>> Jail fs: =20 >>>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>>> Jail pkgbase: disabled >>>>>>>>=20 >>>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>>> was in a different port (autoconfig, noticed by the >>>>>>>> build of automake failing via config reporting >>>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>>> being rejected). >>>>>>>>=20 >>>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>>> system versions. >>>>>>>>=20 >>>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>>> used in order to have bectl, not redundancy. >>>>>>>>=20 >>>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>>> evidence of such problems based on the updated system. (Also >>>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>>=20 >>>>>>> For aarch64 targeting aarch64 there was also this >>>>>>> explicit corruption notice during the poudriere(-devel) >>>>>>> bulk build: >>>>>>>=20 >>>>>>> . . . >>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>>=20 >>>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>>> *** Error code 1 >>>>>>> Stop. >>>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>>=20 >>>>>>> I'm not yet to the point of retrying after removing >>>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>>=20 >>>>>>=20 >>>>>> Another context with my prior general update of /usr/ports/ >>>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>>> lots more I/O. >>>>>>=20 >>>>>=20 >>>>> None of the 3 corruptions repeated during bulk builds that >>>>> retried the builds that generated the files. All of the >>>>> ports that failed by hitting the corruptions in what they >>>>> depended on, built fine in teh retries. >>>>>=20 >>>>> For reference: >>>>>=20 >>>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>>> those showed evidence of file corruptions. In general I've >>>>> not had previous file corruptions with this system. (There >>>>> was a little more than 245 GiBytes swap, which covered the >>>>> tmpfs needs when they were large.) >>>>=20 >>>>=20 >>>> I set up a contrasting test context and got no evidence of >>>> corruptions in that context. (Note: the 3 bulk builds >>>> total to around 24 hrs of activity for the 3 examples >>>> of 460+ ports building.) So, for the Cortex-A72 system, >>>=20 >>> I set up a UFS on Optane (U.2 via M.2 adapter) context and >>> also got no evidence of corruptions in that context (same >>> hardware and a copy of the USB3 SSD based system). The >>> sequence of 3 bulks took somewhat over 18 hrs using the >>> Optane. >>>=20 >>>> root on UFS on portable USB3 SSD: no evidence of corruptions >>> Also: >>> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>>> vs.: >>>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>>=20 >>>> Both had USE_TMPFS=3D"data" in use. The same system build >>>> had been installed and booted for both tests. >>>>=20 >>>> The evidence of corruptions is rare enough for this not to >>>> be determinative, but it is suggestive. >>>>=20 >>>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>>> not differentiated by this test result. >>>>=20 >>>> There is also the result that I've not seen evidence of >>>> corruptions on the ThreadRipper 1950 X (amd64) system. >>>> Again, not determinative, but suggestive, given how rare >>>> the corruptions seem to be. >>>=20 >>> So far the only things unique to the observed corruptions are: >>>=20 >>> root on ZFS context (vs. root on UFS) >>> and: >>> Optane in a PCIe slot (but no contrasting ZFS case tested) >>>=20 >>> The PCIe slot does not seem to me to be likely to be contributing. >>> So this seem to be suggestive of a ZFS problem. >>>=20 >>> A contributing point might be that the main [so: 14] system was >>> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>>=20 >>> [I previously ran into a USB subsystem mishandling of keeping >>> things coherent for the week memory ordering in this sort of >>> context. That issue was fixed. But back then I was lucky enough >>> to be able to demonstrate fails vs. works by adding an >>> appropriate instruction to FreeBSD in a few specific places >>> (more than necessary as it turned out). Someone else determined >>> where the actual mishandling was that covered all required >>> places. My generating that much information in this context >>> seems unlikely.] >>=20 >>=20 >> I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media >> and it got its first corruption (in a different place, 2nd bulk >> build this time). The use of the corrupted file reports: >>=20 >> configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl >> ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 >> In file included from conftest.c:27: >> In file included from /usr/local/include/ogg/ogg.h:24: >> In file included from /usr/local/include/ogg/os_types.h:154: >> /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] >> >> ^ >> . . . >> /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] >> . . . (nulls) . . . >>=20 >> So: 538 such null bytes. >>=20 >> Thus, another example of something like a page of nulls being >> written out when ZFS is in use. >>=20 >> audio/gstreamer1-plugins-ogg also failed via referencing the file >> during its build. >>=20 >> (The bulk run is still going and there is one more bulk run to go.) >>=20 >=20 > Well, 528 happened to be the size of config_types.h --and of > config_types.h from a build that did not get the corruption there. >=20 > So looking at the other (later) corruption, which was a bigger file > (looking via bulk -i and installing what contained the file but > looking from outside the jail): >=20 > # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; > -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 > lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 > lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 >=20 > hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 0023b120 >=20 > So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. >=20 > To cross check on live system caching vs. on disk, I rebooted and = redid the > bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : > still all zeros. >=20 > For reference, zpool scrub afterward resulted in: >=20 > # zpool status > pool: zopt0 > state: ONLINE > scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 > config: >=20 > NAME STATE READ WRITE CKSUM > zopt0 ONLINE 0 0 0 > nda1p3 ONLINE 0 0 0 >=20 > But it is not a ZFS redundancy context: ZFS used just to use bectl . Using bectl (on the root-on-ZFS Optane in PCIe slot), I booted stable/13 : # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 and tried the sequence of 3 bulk runs: There was no evidence of corruptions, suggesting that the Optane in the PCIe slot is not the source of the problem of having some file(s) end up with all bytes being null bytes. So, overall, ending up with evidence of corruptions generated during bulk builds seem to be tied to main's [so: 14's] ZFS implementation in: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 1400040 1400040 because that is all that is unique to having the evidence of corruptions. Since there have been ZFS updates in main since then, it seems that the next experiment would be to update main and try again under main. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Nov 21 19:26: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 480BE189FBEC for ; Sun, 21 Nov 2021 19:26:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4Hy0l213R6z4bdx for ; Sun, 21 Nov 2021 19:26:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637522791; bh=UQXeru2+VtYhSe62lDjtgn7qwcxkI16gxbDrTs7O/3M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=jYLcS5yvlrorKav5xt2eaI+IV3ZK2wnUW+wRFCeedeECSkFeScjLvbjr3RE2+TVnwnLMogitnv+JXXFJPcfA94BVRI046Lbcvxu4rhRM4nVv+NdnknTs3Ogc5ASuZkj9jQX6ulqCOtUF5+dPSCdiLTaOoQUyI1HpQxWtWSS0phICqkggH7cMLZHUSi6zUk2BH+NMzyLzP2o2RdMr4PMwmP4TXi+d/fjLX0Jobeexh0W/XNnCovZPzJBouBEpqZztETChy0a47i/sKvSwUImB04Z7p275ELPREzXHfsyRgZ5+ILJMFgrd85V5M1XiPrZnSStjpoCdZU5fPUEUpWG3zg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637522791; bh=tSPbfGSl5NkfgvWFLMoKCiKuA0Oo9bXR2eKz5SDV0ah=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=fzKxifOaoKO9MLQMb2jIoafcg+X0ZdzIsq5ljRf7tVvGbSzWNpNj/nfqjoZV7Nl9tuzuplNQuH5UBjqh+NvvHIKLXQdG1MBywxJOGhX7uQ368p7KhBLy/cHbXV3FsDpPl2TVUZmYeSNZ5D6PnPeQHnRwnmz+J/2D3n3peUXwC3lxjH0w//705G/M2Q5MIDjT7vjzbeF1tSRChRRlFx1p9pjpVSOgBWM6yKjce4NTn6PqNPLAdWybvSjOE9Ks361EKYTfjcXu1UMVXwtTmQqT52/gTizu+iFuJO+CkP/kwchNOesEzJC1ROJjd2rAZkMvVQgNha9m+gA117HRRBRqhw== X-YMail-OSG: v5DMxQkVM1noRgNNjILvi7QZmFInriymCgyBrPhxjRuZp3ovoJqCqhazA_YI0Kr QoIqaFqF84._6vjET1YxDkpT89RjvKR4EZMlMM5SQ3tKLWPKjROm9SVKGUsZc5FGeHsx6hXiE_Sj L69ZPnVo0H8sBTOF3Y08gwfVXeYSDuK7W9A8kCj02IHRvz8vsIpO7d5DQlIO.FXcQb1pcn1QobhN 3UGOc1l.DZTmzAy_pwZM80i64GrhK85xz5nAFiiSP_TIQO5KgBK7.gWFrxp0Gbxiz4AqAFwotryh 4JhqvZffaPMYuklrhrfhB.wqsk1z5KZYAXgDhnl6gc6NO8Gfznvsifwlz.KphkaeLqp3UgP_rZEd WG2rUdGaJhcsIdmre1MEtnrKwHXr1DLzat5TsGzQ9vjwLz.6X5yx1XHAiv2Fb0eRrGITkk7FiGaE Ko1fnCcnpVlficm4JNGmubp2M3nzPQdiR6uI3opovXD5xcytNqsEuZusmf8WKvR05R6UPKwf8CS_ wy_evR.Zryk5SNB2nWWiWX2GIii9lZ6V2IiU3bFDJ9AhopWR_3Y6onJKzYtPPwKI.g5tNFVvjH8i VN_EcYdN4MV3Ho50O3o48RZgtw2mek7di48mJfN6Tl_k85gGbGIJF7Om6bkdpFDEY7srFVmFcsnF oTKTljBuiKzAxGrRh3cCDvkoDA9_L.efFUN.qs0dbehrftS1HTb.OJud8W6F48vJ8tSKc7mzNkSa Ah8yK4e0CToUr5qFpdgqGhucfL7NaQ2GwrNZpN2rmKirY.oc27qoWWsIdHX_nLZwhnfmBny8lRy9 kvI09sV2tKseZDfyjXTORinC2lgsv6gkkBPoxixlP0Kl.4X_AJxL.6EOgdw0JyTmGh6iLlaXyLH9 BVlCRIxZ3zr7c3ZMCp0dpjHjeyEjWafu7xxnWJlRZBi3.ittlem5vpraRh1wK9Z4IWN.VERUjHr1 x1F3rzovA_E99IjrABfqKO.oor1JVWeyuAijCF8hx1Gps3nAe7pMIA60NGvdPhDMD_Aqz2JyMOEq u_XiMab1YY2Weg7lB.Uzyi6WZ35Ba7qaxEFnEYHyRpWuL7MPOgrm2754VvdpHs69RUhiWJz0kp_k l0SE0YaMHwn2xum1oG1m8MKtqfkptPyOqCf2h20CCWOCTN7EsQ5lXr0uFyeIq0yeGdvBVfAH_30z ZK_eIrNKCujXfBAjijpU75PUMdfw0Xlm5rTp5MzAL1uw8G0Sb6Sd3SFojgpCdX5CMFsYiIOAveqe BCeoVJv9q.PCYt.HMSMMwzHTNhGXWWdJ6nntXq5bChsdlld90zmHhQsaM8uBNJsgNxdxIauE3WxM WpcCLeszbltSsRUtoW1SF.JDTJ9tdef66WsL5pmfkomwEn97NCt1agjpFWfn2TYpSUcKEAv6Pdc1 6V7olqIewK.DQptUn.UpYtt_dKHjVhSvxm9jnnogAH3dAXkOliIL3rJC3b47mgfTcR5DThMgAWBl q7tyAvjcXvxuywCnBvV2uO3UrGoFcA89LiZ6k4bAf7irRsaqAQC8o624Dbeai0V8pZHEA8gdcx9b W21Y3G3hqRxvx1NEV7_SaWHXyW5YF6Gnbjwt7Kv0VJ1y4t0ByxfRBvYYu9egT5DjIxlkg4mK6EA. H_2K27lz181h5MocN._nj4Fr5Zln6wpu5DLR.sor1UJphjOH52ZGo9OaXnGTzwJ0dmikg27DdCZs iDqMw3U3uJDPO0pjmpEDKkiU3Gco2lRR.7jsP7V34yttVsUqBW41iHV3sEtnmKuNAoa5o4fsLkem ku2zG7RJO9fS8SLaImC49VX61rT3JWoMgKIwhJ2hqSDGXYyoaASKtoh3pRaienVjppDBPEInxTDY RsevXAPY4xz9o73YQNROn03c6XzEvlrLlzuF3dF74nGu_CF8RG9NijKum3WOV9wKijKHmquGRKgv UukkPWWzsgg5p4JsDn51Ic2fou98RVRO2pWE8xeBLJm6kYgl_H2iKDr_u.oFcfG4Uv6kHQr.n0P4 ky8q7qvee55Wt38JOM8tK6k.jODoqOHGyuBs74dHux_92pTNoL74YnSKyBcF0fAN2.102e.XxyP1 6G8reheReBLaoD6fTwo45Dm2E1v1zEfLUBC2kIOIMg7Tpbsp.q2kcRbrvqPnT1FOC.omzPgggGsb 6BuiSQcDisgQoe1ofp.cZmOxuVjUspgOfCSrgIdwKiNS26B8on6udzVO1MysAkkUCekisX1Mzm9u OlYlggfPxKao7wdIPHXNp020nNKFkgBri1HeHTg.FvcO6wb.8gqeXqVvebpSSHwS51R7bK8rYoiy OPHql5ZqJf3mTkvOHTFZQiZw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 19:26:31 +0000 Received: by kubenode503.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 691f5a682ff34022694d036e6e5adf00; Sun, 21 Nov 2021 19:26:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 boot (HoneyComb): example crash during system checks Message-Id: Date: Sun, 21 Nov 2021 11:26:25 -0800 To: "freebsd-arm@freebsd.org" , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Hy0l213R6z4bdx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jYLcS5yv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.31: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.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.65.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Starting file system checks: /dev/gpt/CA72opt0EFI: 41 files, 242 MiB free (15469 clusters) FIXED /d x0: ffff000000e43ec8 (blocked_lock + 0) x1: ffff00013efa9f50 x2: ffff00000090e39a (cam_status_table + 1d132) x3: deadc0d8 x4: 0 x5: ffff00000082a138 (data_abort + 0) x6: 5 x7: 601 x8: ffff000000e43ec8 (blocked_lock + 0) x9: deadc0de x10: 0 x11: 3938700 x12: 0 x13: 8000 x14: 1de x15: 81ce x16: 425b9080 x17: 8000 x18: ffff00013efa9f40 x19: ffff000000e43ec8 (blocked_lock + 0) x20: ffffa0001a826000 x21: 0 x22: ffffa0001a826000 x23: 0 x24: ffff000000bed000 (queue_ops + 0) x25: 98967f x26: ffff000000e43ee0 (blocked_lock + 18) x27: 0 x28: 114 x29: ffff00013efa9f40 sp: ffff00013efa9f40 lr: ffff0000004b9028 (thread_lock_flags_ + c0) elr: ffff0000004b9028 (thread_lock_flags_ + c0) spsr: 2c5 far: deadc178 esr: 96000004 timeout stopping cpus panic: data abort in critical section or under mutex cpuid =3D 5 time =3D 1637492224 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec sp =3D 0xffff00013efa9990 fp =3D 0xffff00013efa9b90 db_trace_self_wrapper() at vpanic+0x188 pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 sp =3D 0xffff00013efa9ba0 fp =3D 0xffff00013efa9c00 vpanic() at panic+0x44 pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 sp =3D 0xffff00013efa9c10 fp =3D 0xffff00013efa9cc0 panic() at data_abort+0x290 pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 sp =3D 0xffff00013efa9cd0 fp =3D 0xffff00013efa9d50 data_abort() at handle_el1h_sync+0x78 pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efa9d60 fp =3D 0xffff00013efa9eb0 handle_el1h_sync() at thread_lock_flags_+0xbc pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 sp =3D 0xffff00013efa9ec0 fp =3D 0xffff00013efa9f40 thread_lock_flags_() at thread_lock_flags_+0xbc pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 sp =3D 0xffff00013efa9f50 fp =3D 0xffff00013efa9f60 thread_lock_flags_() at sleepq_timeout+0x10 pc =3D 0xffff0000004b9024 lr =3D 0xffff00000054b2a8 sp =3D 0xffff00013efa9f70 fp =3D 0xffff00013efa9fb0 sleepq_timeout() at softclock_call_cc+0x14c pc =3D 0xffff00000054b2a8 lr =3D 0xffff000000503134 sp =3D 0xffff00013efa9fc0 fp =3D 0xffff00013efaa020 softclock_call_cc() at callout_process+0x17c pc =3D 0xffff000000503134 lr =3D 0xffff000000502df0 sp =3D 0xffff00013efaa030 fp =3D 0xffff00013efaa0a0 callout_process() at handleevents+0x188 pc =3D 0xffff000000502df0 lr =3D 0xffff00000045b42c sp =3D 0xffff00013efaa0b0 fp =3D 0xffff00013efaa100 handleevents() at timercb+0x304 pc =3D 0xffff00000045b42c lr =3D 0xffff00000045be7c sp =3D 0xffff00013efaa110 fp =3D 0xffff00013efaa170 timercb() at arm_tmr_intr+0x5c pc =3D 0xffff00000045be7c lr =3D 0xffff0000007ff850 sp =3D 0xffff00013efaa180 fp =3D 0xffff00013efaa1d0 arm_tmr_intr() at intr_event_handle+0xac pc =3D 0xffff0000007ff850 lr =3D 0xffff000000493c54 sp =3D 0xffff00013efaa1e0 fp =3D 0xffff00013efaa1e0 intr_event_handle() at intr_isrc_dispatch+0x70 pc =3D 0xffff000000493c54 lr =3D 0xffff0000007fb238 sp =3D 0xffff00013efaa1f0 fp =3D 0xffff00013efaa230 intr_isrc_dispatch() at arm_gic_v3_intr+0x11c pc =3D 0xffff0000007fb238 lr =3D 0xffff00000080ff34 sp =3D 0xffff00013efaa240 fp =3D 0xffff00013efaa250 arm_gic_v3_intr() at intr_irq_handler+0x7c pc =3D 0xffff00000080ff34 lr =3D 0xffff0000007faff0 sp =3D 0xffff00013efaa260 fp =3D 0xffff00013efaa2b0 intr_irq_handler() at handle_el1h_irq+0x74 pc =3D 0xffff0000007faff0 lr =3D 0xffff00000080a140 sp =3D 0xffff00013efaa2c0 fp =3D 0xffff00013efaa3f0 handle_el1h_irq() at handle_el1h_sync+0x78 pc =3D 0xffff00000080a140 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efaa400 fp =3D 0xffff00013efaa500 handle_el1h_sync() at handle_el1h_sync+0x78 pc =3D 0xffff00000080a078 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efaa510 fp =3D 0xffff00013efaa660 handle_el1h_sync() at sched_switch+0x6a8 pc =3D 0xffff00000080a078 lr =3D 0xffff0000005197fc sp =3D 0xffff00013efaa670 fp =3D 0xffff00013efaa6f0 sched_switch() at sched_switch+0x6a8 pc =3D 0xffff0000005197fc lr =3D 0xffff0000005197fc sp =3D 0xffff00013efaa700 fp =3D 0xffff00013efaa790 sched_switch() at mi_switch+0xf4 pc =3D 0xffff0000005197fc lr =3D 0xffff0000004f03a0 sp =3D 0xffff00013efaa7a0 fp =3D 0xffff00013efaa7f0 mi_switch() at sleepq_timedwait+0x28 pc =3D 0xffff0000004f03a0 lr =3D 0xffff00000054bd0c sp =3D 0xffff00013efaa800 fp =3D 0xffff00013efaa830 sleepq_timedwait() at _cv_timedwait_sbt+0x110 pc =3D 0xffff00000054bd0c lr =3D 0xffff00000045e7b0 sp =3D 0xffff00013efaa840 fp =3D 0xffff00013efaa850 _cv_timedwait_sbt() at dbuf_evict_thread+0x410 pc =3D 0xffff00000045e7b0 lr =3D 0xffff0000013ca59c sp =3D 0xffff00013efaa860 fp =3D 0xffff00013efaa8f0 dbuf_evict_thread() at fork_exit+0x94 pc =3D 0xffff0000013ca59c lr =3D 0xffff00000048fbf0 sp =3D 0xffff00013efaa900 fp =3D 0xffff00013efaa950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff00000048fbf0 lr =3D 0xffff000000828ed8 sp =3D 0xffff00013efaa960 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 26 tid 100194 ] Stopped at kdb_enter+0x48: undefined f906411f For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 It is a root-on-ZFS context on Optane media in the PCie slot. I've no clue if this will repeat. I've never gotten this before. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Nov 21 19:36:08 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 D9FA018A45AA for ; Sun, 21 Nov 2021 19:36:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4Hy0y73wwcz4fbx for ; Sun, 21 Nov 2021 19:36:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637523374; bh=0P97hs2LFopknVvakMpaMypTVHAek2r71RRxDoiAKMM=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=nBiK3Tct6a5z3Hd/JAiJCiS/kRSLDqz83JxP4Y3bvutaTB6l9PttJSWFI79xvG+fvRfig5/SnrYfe3/kgg77ff8qOxvelodNtmJNU27T9w89RsbQyu8t07aC4j9bgkc3xE6HOFgC5LqfxHJtaJ5kSRUm3dYb1AmijZLgFPkbN8zl9jSutGN6fZyq/fpYhbXs8rlZb5bTwKmpLx3n+4W6RnQIVCZ+y9pvH5aqBf5QMlF6gXPZQl5oDnzfHOQkWRTzKM8SUEVV7RlkPzoNA9RWBr4RhchjLAp3jGxout9omD/bJOHcDPzKbSUG5xrdAXCaAiplhLVEq3zHqv5BeSzMgw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637523374; bh=lGi2VPVOFCy9Hm8DqPbAljjuy+k5FguqCZJaaRiUuJz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HXgXlvPBC2ZIJGhCQvxIBfizR5tUnkAZohuT2HC7Lsnp3qyBErlJl6dhiclRAEYq9ouZBXnX3SkTRe98DzxnIDqsW44qPKUss2Kus1JJgzpj/u4KJWKQWPq1ujQaeDbNl5rr9WbbOfmxjTAc8XmgVufKbk+HoEiUdxHyp+98XidJYC+eUeUGi4Q3iwB38ngR/clYRi9Co9JK3yP/ATHyfHNttBEp3PEFbK4JQf0sJKyQmbb/MO8mp12oa08jH2wJ+S1p2sg2BX5DiXMtlNYSfnSEVCK3iM5NsNZ+akyUl3HsabXYrqnvdro/HysM6e/UBf5G5UAGI9EMfe4SgwSuJw== X-YMail-OSG: nFblz9cVM1l2mPmfh2dv6OxJPk900BRd9BXyvj3.ILI9zz_w1OmxSl7f2JKddui vl_4leqGMtWz4JEsEmXvbfnH4feRWgYkyxcuQVgoQXe_ax.kMQvD.X6oGOGi03bUcoWF4bLTbUyB X8n3yqBDKIOhyY0BeWQXSJNUhp2lATMCWHFFUCwdYy3a4mjsbYgtbQ4WsdGHU_FHAs4ozypFVm9W BVfpTH_F808qJ88SwjadYNMUchxSvresekGdBYmULHmO5QTeIuLmcTO_XcoziBZiS6PZzMZbbfNi OAwng_jeKhEdyPoIOgw_bRsJtekhLh5hhX9tQr65gEgrVHKxHneD9syqZOZUSdr6tzBWpK3RIHio pE3MFFpHgaLJuJjrQSAXkRr6CrcC8XJoz65MrMz_oJJiQ2zUukzR7JPXfLSB4AWFnwQPPYz4fNNC 9ChLvdRk20cDe32rzd7q4EW02EvD.WYl_g2iz3YnA17z2V9_9Gozj6fiZG98aYxSpnqgDzJcWL7m M0Q1uP2u3QJBYvrlccCxRso_HYhqLLv1HDnn9QEq1lDKe..KF6R_ZdMncDL6Jie6W4hKUtEnf_og 0xzeQRSZsWlbv7WeN_9_1g6qiSf49jjeozcrj1eI8qRke5TwJQ.YqRVLJDoq89HpQbsqxRclkaih C78YJBdvm9a5a4grHTLwYDeZLB1q8yBJzTAB64CdQDFy8Y92vm.j3wXAOIamt75irOd6r_DnpEtH k7WkjdGjiwAbifT2yNgyFL60RD5d7G2vqZRsWmWY_wCPZrFm5Vwe_IBWZFzg_77OQfEefy9d8MA4 1gYg_yKmuFhba_aM_WT8qSE2YfXYUVkjSAHZo5ZXygBgOdjbY2T2JCOBDHQstbgNxoo2gi_fuu2p 16DtY480CHVMCP3nvlcUJz72cl9.nI6Fj1Habare5AHMlYc3eLuqmKAhBuLdWz6UQQ.WWuROQre1 LO3uaZeqcsPuGfoIGIw2Fj8VZvGZh27k2GuXsG5xxLQQPk88JCenzCjTWhONf5ANCjbBrTnbisZ9 3iejqmw7Bvmfo3n5W.LoSZdOkrFM.mBGCYFKblb2qmFF0VEN9I8tN3AftII2ESAUwfs9Z9zmeUW7 0GwOQsMl8UPiqtBUdd9Dw4HHQE9H_C99t0KSpCz1wVHjgNDc0kGrLBSTKKiEew9DuSgKb_gC0PFs xQDlzfludRrmZuHMWQddYh.zIogyBOjmV7qDCimBoFVftaR8BxFm0m53YXJPL0o17sMpvKt8QXX6 RSRWlVc3fRx5Or2XmEAV0KHiiyOd0tc1GryFjA.tpsrYi7BRBFZC0B9lY2DCX2DadG9hkUlruVqD H1mYWf_Jw13ue4oyMhr8h08OfNTZ2gr3_YAls9s1LB6zwutV_hSz9g_xYTvyUPKOfaeorATP7jEw UahOfabkwh6MnZEllBLPFNQX2wsSZK488bUk9CsK0CJaU0vKgDYGJNzuQHO8utql6kP5vY2gsA1l OJ2t.5AmqRmAJFT3doKRlXAtngmkrw20Agw2RzxdKgUnQbj0t00y6l3fjWMsTxuAUaiuOVWI0ojt XjBRjm3b.msRLTzL4JgKczGSWyfX00AO.GjO93wgxK_.pdZlzNyuoawR06HZhxPDS3M1JLQYHTTY G6oIBnmQE5w_pSSjsyoNalVTOx_dq02OWHlI2hZWPfVnO2mRKdTB4PJdIyOndT6TNes8SSi4IFdN z4oqMMJbV3VOZydKNwFkAd1v7wcMFGH6qR8yI_7csFrhkiF54_C31_lkYaxyuyScHNUkjQ6xiCxT kIoDYX_BUBg2361R9vPmjMWzTns5fX38n9V0Xqi7dtEMQfC7lGttt3k2nOnLG2gmz9eM4OMPY_L7 2cIfMvMitk2bvy8xTwMxJh34KNn.YzKobcLKKNiq9ZF2v5WH.ph7LcZhW3KAPIiXC_YuqpU0TqZ2 iinM3Qcm8Zkr4cgTQHdIW7htiQtYMXKZuJrI3UyDYSV4UXIt_W1J2w_tz1uoG0sedweNsgPuTa6W 4XQuI9HzaDm3Djie26Wp4b8OwU5dz_.FFORNKvTFF8Ul.aRoLRhcZ0UW.Rc0UbGWUk57hR2.vhkc zifW.aUQVnn7GLl.mRR5YNM8QZOc8ekryEPVBTH16cERry0Aw6DPvOECbFX5yeIWpX96AhMxMbXY 2w_wI12QTNvDcgHgFJDFp5fok80Xa_S6D833d45.KEp21h8wgoedGgy42T5cvtxiKJ6OcqI5OUSY O5fwFBdyjGsrInFd29WGLFBREXlVh.87EQGlEMv5hmKSS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 19:36:14 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b8c654c278341bc118ca9cf770e6c092; Sun, 21 Nov 2021 19:36:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 boot (HoneyComb): example crash during system checks (power-off/power-on form of reboot still fails) Date: Sun, 21 Nov 2021 11:36:08 -0800 References: To: "freebsd-arm@freebsd.org" , FreeBSD-STABLE Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hy0y73wwcz4fbx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nBiK3Tct; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.148: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.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.64.148:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-21, at 11:26, Mark Millard wrote: > Starting file system checks: > /dev/gpt/CA72opt0EFI: 41 files, 242 MiB free (15469 clusters) > FIXED > /d x0: ffff000000e43ec8 (blocked_lock + 0) > x1: ffff00013efa9f50 > x2: ffff00000090e39a (cam_status_table + 1d132) > x3: deadc0d8 > x4: 0 > x5: ffff00000082a138 (data_abort + 0) > x6: 5 > x7: 601 > x8: ffff000000e43ec8 (blocked_lock + 0) > x9: deadc0de > x10: 0 > x11: 3938700 > x12: 0 > x13: 8000 > x14: 1de > x15: 81ce > x16: 425b9080 > x17: 8000 > x18: ffff00013efa9f40 > x19: ffff000000e43ec8 (blocked_lock + 0) > x20: ffffa0001a826000 > x21: 0 > x22: ffffa0001a826000 > x23: 0 > x24: ffff000000bed000 (queue_ops + 0) > x25: 98967f > x26: ffff000000e43ee0 (blocked_lock + 18) > x27: 0 > x28: 114 > x29: ffff00013efa9f40 > sp: ffff00013efa9f40 > lr: ffff0000004b9028 (thread_lock_flags_ + c0) > elr: ffff0000004b9028 (thread_lock_flags_ + c0) > spsr: 2c5 > far: deadc178 > esr: 96000004 > timeout stopping cpus > panic: data abort in critical section or under mutex > cpuid =3D 5 > time =3D 1637492224 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x30 > pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec > sp =3D 0xffff00013efa9990 fp =3D 0xffff00013efa9b90 >=20 > db_trace_self_wrapper() at vpanic+0x188 > pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 > sp =3D 0xffff00013efa9ba0 fp =3D 0xffff00013efa9c00 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 > sp =3D 0xffff00013efa9c10 fp =3D 0xffff00013efa9cc0 >=20 > panic() at data_abort+0x290 > pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 > sp =3D 0xffff00013efa9cd0 fp =3D 0xffff00013efa9d50 >=20 > data_abort() at handle_el1h_sync+0x78 > pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013efa9d60 fp =3D 0xffff00013efa9eb0 >=20 > handle_el1h_sync() at thread_lock_flags_+0xbc > pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 > sp =3D 0xffff00013efa9ec0 fp =3D 0xffff00013efa9f40 >=20 > thread_lock_flags_() at thread_lock_flags_+0xbc > pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 > sp =3D 0xffff00013efa9f50 fp =3D 0xffff00013efa9f60 >=20 > thread_lock_flags_() at sleepq_timeout+0x10 > pc =3D 0xffff0000004b9024 lr =3D 0xffff00000054b2a8 > sp =3D 0xffff00013efa9f70 fp =3D 0xffff00013efa9fb0 >=20 > sleepq_timeout() at softclock_call_cc+0x14c > pc =3D 0xffff00000054b2a8 lr =3D 0xffff000000503134 > sp =3D 0xffff00013efa9fc0 fp =3D 0xffff00013efaa020 >=20 > softclock_call_cc() at callout_process+0x17c > pc =3D 0xffff000000503134 lr =3D 0xffff000000502df0 > sp =3D 0xffff00013efaa030 fp =3D 0xffff00013efaa0a0 >=20 > callout_process() at handleevents+0x188 > pc =3D 0xffff000000502df0 lr =3D 0xffff00000045b42c > sp =3D 0xffff00013efaa0b0 fp =3D 0xffff00013efaa100 >=20 > handleevents() at timercb+0x304 > pc =3D 0xffff00000045b42c lr =3D 0xffff00000045be7c > sp =3D 0xffff00013efaa110 fp =3D 0xffff00013efaa170 >=20 > timercb() at arm_tmr_intr+0x5c > pc =3D 0xffff00000045be7c lr =3D 0xffff0000007ff850 > sp =3D 0xffff00013efaa180 fp =3D 0xffff00013efaa1d0 >=20 > arm_tmr_intr() at intr_event_handle+0xac > pc =3D 0xffff0000007ff850 lr =3D 0xffff000000493c54 > sp =3D 0xffff00013efaa1e0 fp =3D 0xffff00013efaa1e0 >=20 > intr_event_handle() at intr_isrc_dispatch+0x70 > pc =3D 0xffff000000493c54 lr =3D 0xffff0000007fb238 > sp =3D 0xffff00013efaa1f0 fp =3D 0xffff00013efaa230 >=20 > intr_isrc_dispatch() at arm_gic_v3_intr+0x11c > pc =3D 0xffff0000007fb238 lr =3D 0xffff00000080ff34 > sp =3D 0xffff00013efaa240 fp =3D 0xffff00013efaa250 >=20 > arm_gic_v3_intr() at intr_irq_handler+0x7c > pc =3D 0xffff00000080ff34 lr =3D 0xffff0000007faff0 > sp =3D 0xffff00013efaa260 fp =3D 0xffff00013efaa2b0 >=20 > intr_irq_handler() at handle_el1h_irq+0x74 > pc =3D 0xffff0000007faff0 lr =3D 0xffff00000080a140 > sp =3D 0xffff00013efaa2c0 fp =3D 0xffff00013efaa3f0 >=20 > handle_el1h_irq() at handle_el1h_sync+0x78 > pc =3D 0xffff00000080a140 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013efaa400 fp =3D 0xffff00013efaa500 >=20 > handle_el1h_sync() at handle_el1h_sync+0x78 > pc =3D 0xffff00000080a078 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013efaa510 fp =3D 0xffff00013efaa660 >=20 > handle_el1h_sync() at sched_switch+0x6a8 > pc =3D 0xffff00000080a078 lr =3D 0xffff0000005197fc > sp =3D 0xffff00013efaa670 fp =3D 0xffff00013efaa6f0 >=20 > sched_switch() at sched_switch+0x6a8 > pc =3D 0xffff0000005197fc lr =3D 0xffff0000005197fc > sp =3D 0xffff00013efaa700 fp =3D 0xffff00013efaa790 >=20 > sched_switch() at mi_switch+0xf4 > pc =3D 0xffff0000005197fc lr =3D 0xffff0000004f03a0 > sp =3D 0xffff00013efaa7a0 fp =3D 0xffff00013efaa7f0 >=20 > mi_switch() at sleepq_timedwait+0x28 > pc =3D 0xffff0000004f03a0 lr =3D 0xffff00000054bd0c > sp =3D 0xffff00013efaa800 fp =3D 0xffff00013efaa830 >=20 > sleepq_timedwait() at _cv_timedwait_sbt+0x110 > pc =3D 0xffff00000054bd0c lr =3D 0xffff00000045e7b0 > sp =3D 0xffff00013efaa840 fp =3D 0xffff00013efaa850 >=20 > _cv_timedwait_sbt() at dbuf_evict_thread+0x410 > pc =3D 0xffff00000045e7b0 lr =3D 0xffff0000013ca59c > sp =3D 0xffff00013efaa860 fp =3D 0xffff00013efaa8f0 >=20 > dbuf_evict_thread() at fork_exit+0x94 > pc =3D 0xffff0000013ca59c lr =3D 0xffff00000048fbf0 > sp =3D 0xffff00013efaa900 fp =3D 0xffff00013efaa950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff00000048fbf0 lr =3D 0xffff000000828ed8 > sp =3D 0xffff00013efaa960 fp =3D 0x0000000000000000 >=20 > KDB: enter: panic > [ thread pid 26 tid 100194 ] > Stopped at kdb_enter+0x48: undefined f906411f >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 >=20 > It is a root-on-ZFS context on Optane media in the PCie slot. >=20 > I've no clue if this will repeat. I've never gotten > this before. The reboot attempt got the following, involving zthr_procedure instead of dbuf_evict_thread . Starting file system checks: /dev/gpt/CA72opt0EFI: FILESYSTEM CLEAN; SKIPPING CHECKS x0: ffff000000e43ec8 (blocked_lock + 0) x1: ffff00013ef9ff90 x2: ffff00000090e39a (cam_status_table + 1d132) x3: deadc0d8 x4: 0 x5: ffff00000082a138 (data_abort + 0) x6: 9 x7: 601 x8: ffff000000e43ec8 (blocked_lock + 0) x9: deadc0de x10: 0 x11: 3938700 x12: 1 x13: 8000 x14: 1ee x15: 81cd x16: 425b9080 x17: 8000 x18: ffff00013ef9ff80 x19: ffff000000e43ec8 (blocked_lock + 0) x20: ffffa0000c011000 x21: 0 x22: ffffa0000c011000 x23: 0 x24: ffff000000bed000 (queue_ops + 0) x25: 98967f x26: ffff000000e43ee0 (blocked_lock + 18) x27: 0 x28: 114 x29: ffff00013ef9ff80 sp: ffff00013ef9ff80 lr: ffff0000004b9028 (thread_lock_flags_ + c0) elr: ffff0000004b9028 (thread_lock_flags_ + c0) spsr: 2c5 far: deadc178 esr: 96000004 timeout stopping cpus panic: data abort in critical section or under mutex cpuid =3D 9 time =3D 1637492224 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec sp =3D 0xffff00013ef9f9d0 fp =3D 0xffff00013ef9fbd0 db_trace_self_wrapper() at vpanic+0x188 pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 sp =3D 0xffff00013ef9fbe0 fp =3D 0xffff00013ef9fc40 vpanic() at panic+0x44 pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 sp =3D 0xffff00013ef9fc50 fp =3D 0xffff00013ef9fd00 panic() at data_abort+0x290 pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 sp =3D 0xffff00013ef9fd10 fp =3D 0xffff00013ef9fd90 data_abort() at handle_el1h_sync+0x78 pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 sp =3D 0xffff00013ef9fda0 fp =3D 0xffff00013ef9fef0 handle_el1h_sync() at thread_lock_flags_+0xbc pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 sp =3D 0xffff00013ef9ff00 fp =3D 0xffff00013ef9ff80 thread_lock_flags_() at thread_lock_flags_+0xbc pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 sp =3D 0xffff00013ef9ff90 fp =3D 0xffff00013ef9ffa0 thread_lock_flags_() at sleepq_timeout+0x10 pc =3D 0xffff0000004b9024 lr =3D 0xffff00000054b2a8 sp =3D 0xffff00013ef9ffb0 fp =3D 0xffff00013ef9fff0 sleepq_timeout() at softclock_call_cc+0x14c pc =3D 0xffff00000054b2a8 lr =3D 0xffff000000503134 sp =3D 0xffff00013efa0000 fp =3D 0xffff00013efa0060 softclock_call_cc() at callout_process+0x17c pc =3D 0xffff000000503134 lr =3D 0xffff000000502df0 sp =3D 0xffff00013efa0070 fp =3D 0xffff00013efa00e0 callout_process() at handleevents+0x188 pc =3D 0xffff000000502df0 lr =3D 0xffff00000045b42c sp =3D 0xffff00013efa00f0 fp =3D 0xffff00013efa0140 handleevents() at timercb+0x304 pc =3D 0xffff00000045b42c lr =3D 0xffff00000045be7c sp =3D 0xffff00013efa0150 fp =3D 0xffff00013efa01b0 timercb() at arm_tmr_intr+0x5c pc =3D 0xffff00000045be7c lr =3D 0xffff0000007ff850 sp =3D 0xffff00013efa01c0 fp =3D 0xffff00013efa0210 arm_tmr_intr() at intr_event_handle+0xac pc =3D 0xffff0000007ff850 lr =3D 0xffff000000493c54 sp =3D 0xffff00013efa0220 fp =3D 0xffff00013efa0220 intr_event_handle() at intr_isrc_dispatch+0x70 pc =3D 0xffff000000493c54 lr =3D 0xffff0000007fb238 sp =3D 0xffff00013efa0230 fp =3D 0xffff00013efa0270 intr_isrc_dispatch() at arm_gic_v3_intr+0x11c pc =3D 0xffff0000007fb238 lr =3D 0xffff00000080ff34 sp =3D 0xffff00013efa0280 fp =3D 0xffff00013efa0290 arm_gic_v3_intr() at intr_irq_handler+0x7c pc =3D 0xffff00000080ff34 lr =3D 0xffff0000007faff0 sp =3D 0xffff00013efa02a0 fp =3D 0xffff00013efa02f0 intr_irq_handler() at handle_el1h_irq+0x74 pc =3D 0xffff0000007faff0 lr =3D 0xffff00000080a140 sp =3D 0xffff00013efa0300 fp =3D 0xffff00013efa0430 handle_el1h_irq() at handle_el1h_sync+0x78 pc =3D 0xffff00000080a140 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efa0440 fp =3D 0xffff00013efa0540 handle_el1h_sync() at handle_el1h_sync+0x78 pc =3D 0xffff00000080a078 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efa0550 fp =3D 0xffff00013efa06a0 handle_el1h_sync() at sched_switch+0x6a8 pc =3D 0xffff00000080a078 lr =3D 0xffff0000005197fc sp =3D 0xffff00013efa06b0 fp =3D 0xffff00013efa0730 sched_switch() at sched_switch+0x6a8 pc =3D 0xffff0000005197fc lr =3D 0xffff0000005197fc sp =3D 0xffff00013efa0740 fp =3D 0xffff00013efa07d0 sched_switch() at mi_switch+0xf4 pc =3D 0xffff0000005197fc lr =3D 0xffff0000004f03a0 sp =3D 0xffff00013efa07e0 fp =3D 0xffff00013efa0830 mi_switch() at sleepq_timedwait+0x28 pc =3D 0xffff0000004f03a0 lr =3D 0xffff00000054bd0c sp =3D 0xffff00013efa0840 fp =3D 0xffff00013efa0870 sleepq_timedwait() at _cv_timedwait_sbt+0x110 pc =3D 0xffff00000054bd0c lr =3D 0xffff00000045e7b0 sp =3D 0xffff00013efa0880 fp =3D 0xffff00013efa0890 _cv_timedwait_sbt() at zthr_procedure+0x20c pc =3D 0xffff00000045e7b0 lr =3D 0xffff0000014e2fb0 sp =3D 0xffff00013efa08a0 fp =3D 0xffff00013efa08f0 zthr_procedure() at fork_exit+0x94 pc =3D 0xffff0000014e2fb0 lr =3D 0xffff00000048fbf0 sp =3D 0xffff00013efa0900 fp =3D 0xffff00013efa0950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff00000048fbf0 lr =3D 0xffff000000828ed8 sp =3D 0xffff00013efa0960 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 26 tid 100192 ] Stopped at kdb_enter+0x48: undefined f906411f Note: All this started after a stress based I/O hangup test that required a forced reboot. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Nov 21 20:09:35 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 D1AE7188D808 for ; Sun, 21 Nov 2021 20:10:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4Hy1k01DDVz4sNh for ; Sun, 21 Nov 2021 20:10:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637525440; bh=PkWcy2dtb5VpjuCKQ6TprLl2ogwQvyH59OHLljTezco=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=pWdn2kvRh5r0VYf5DKSXDTTDvl2WCdR7JNNVFPPOyqT5+s/stN91L8tmNyKj6HT8+tTMItBoTmNZMF0iRvkfpFP3wkZynxJMR8IX0i7QSgRHLDtjRhpaElZ0E1m4ZKa/gWCMe2AJaXAAGA8sGhd0R4xR9UC+r7+ey1beh4IjIL7MkMSn36U2qb7qgYXNgaDQoplSlhJc0EqIeBSs5NaLkrNXa2VX2AGpMZzn2GXa37yPVYct6gSeY5d4Con2ffEDrh6MzLYKuvq6aeDLud4IlUHd/kP6oC8/F925xD3urDgzO9GF3d7+gj/IU//tBmFer1ky0TvAnamBY/BEkfKSUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637525440; bh=kYLQ7mRrGnHtzZpQ6z9VnO7Sc3cAtixFp8+KWz25hvl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kbdCKgbBWyvWgJ7mswCTufeCZxTII7cGE4N2xKeUuoN0R26oO8FgSYxBzzZof8bTO3vKE0Sri6vbC7QFyuuyLnRFtZCFXe/TdVK3q4VriK15xihGX09EHW14Akld3vTk1LR7p/Dk21ft89jAJ50IkYjaqdrZa2tGNZTFFwLXrMUb31wNFaMeQo3h9GzAKimHV1WQ1Kx7bvN/6kQ6PhrjCqC9k1y30jRhPRZnyPdoBAXdGQvFtYgu5RFgu3QkEJVv+m3nzdeb1M2amPhloa3oO1Y+QNq6+0dY4gXg5kHuSBJs4W2DJSxT7tZprU46QkzqzJFbkXc4i0od18Fs//U85A== X-YMail-OSG: VRDWmcwVM1mHMTgaPGaKlbZ4dJPtaF3HNwSduGP8QOBCRzpmG0twKjSWywWPFSY xjDeTrTIs1mstwI04ZhtCbWKRsElH.QqRaeRBKsm6z2K6.JSxcSCOvSWITsvsBEJXnIUsvpwDpA. Ph1NA2i22Nh4FDe9t4NpdN9P5jCoExjEpNLnx0WbeFhfRYtVI13B5tfJiD4xFk0FAQDbaJInP1E1 tARj2WzBEMpQz3490iEzyLlY7S39tolGEr6Znn_fofEYOD9U7CDtUlxD7BHAAQbNwPi70FUkIjz. 9Uir5FCS02DNSMCwShcgV7U3IzoOiW6oRQOAEYOjYhMuP9ex_iwQmTY.onXGcHGXRX0SuqbD5ASD mWYggkd34Ixwuy.D.V9c.6vpSN021EoTYeLxunMwNhmYDDhIBuOFYQnQJyzW9L7DXwPdcgDVbvGP rGqQxnf6jEGQ6UfpzoWqxxenz1DubaXi4BtDMu.QDLlr0uNSwf_MpAB0ofdaRp2Wd3cNf.gRthe8 jzGF5ypxP0mgKOYxuTIuptC.BuRZ8Rf6pt5MKhYNVgvZs12u1gEMUFOFSNSsLOCaig7qJpzU0O0d FWr2.hwkOzeLdAPlIOUD.U2lfrhLgIIxwHFQxIxvFKGBYwsGL4UOLtrraNmQWwLiM.zOx9yvQCz_ BF5EU9w6ZfW.D3r1dq0D2KNGYfY82TE.3lV1UroY5RYYw5D1iLeC.sQSA6yQiy14zAs5sQC9ePEU ScZHAdS_VRW89RzxBQu14mwDkaVE2pE5h_dDYNNH8EMx_2OR25FQ4K70ZqJvM7pEr.rTIgDdmLSL brAm5xhWZMYDjxZXEB_5RmW4JlfUW_OY_rm_7ry3nR6sZhWkDfyUsma7C6qN5bmNWiR.Cz2kE2Cj 5jH6wnqXpKY9imTCIJue5yXP9G4PVfJf6ftgwmKJvUzW70sGBAl2gfn0.7047ZqINyy_dS2EB96O TlKOr6YT4k9vg_TcHPvgdwLael6jqSq.BkXuprAgfoJ8Zvqc6Ml3aRLTSS8739BYctBsUwbSUpoc YHPrcM91_cLfAgDxLn.V..bgJ32Skg8w8.jfvb9C0uKuslZs0GXwOHHcAviUmzwdWrsPAXZN1YzK eDNO0YDAAoGCdjW5C0vPsfqxtxikTLl4s_O02bw9EayhWMpkh9LIT6l6fZ9aK5GUkPNGWW3gMKHM gV0c0ZQQhp9RR.Zy9hWP6z0pToo.aQe4bRb_DqEGMLyofNMhW7aM6anwjmmKTgeo1ZGWN5zUDWDF 5DIM58VJq9kvqkh4.2OkZ.cnCPaCUWSJjzxZqsH7vpVXKEp32ETF1TBwbGZ57wZQgSiAjYmuiPsL LV_k9hojiK44CM0mLkfFXSRr6J_5FEr4wAXTC73B0GgmrfcJepMhvEjyr68A1h1P4cpesF6N6kKH RDEiMuB4Nnhej3e.0NLLd3EOqb.efinh78R91yP0TkE12RyYnLur8v_w_6wjqNOJFaZNDbdZqU_k 2EWTbY7EDPPN_ye.UzZsVUy0BQjZ9U9tjw3XKxUWRyMWGDUNUmurBTIWwpBHpPryzEw3uNJbMKNU .GrEQytFgwu6PkApzhGewJ0UrOcfz5Ulj8XNbenD0SXxRicubsrI5NFQtk8LcFx89eTdw0vJyUpk Y6k6SSJ8oa0UO8dOW59Wpj.EXnfgVcsLYY4GyLtZPSrw3e7tjgm.BPcPryGkFPSimw5dEp60RT8W jvqwxW4v5Ij7ggYVW0PWyHTXQk_OY0_K4SG09ZE1TaPDlLqoQ9ygH0TuXTRBmhjDQzfl5dCJzmQo iud7WU.1MISY0VUTI8AUptiXqzlR22_0trZtaZ3HjcPYHBDk45S5FoGzXAYZh7SpTiJCUHjB2V3G zqlrk4Xur3dNl7DXcBOUvzjtINd86tHaWS50SDOFIUMsnPNaBbJe7DzkhzGohDsLz6jmWU262zRH jnrpqUR3KhVwyejA2XNq7fE157IzpmqS08v8OFoxKWHsK_1iJpd4xI8p663VT_AOgfHC6jEANX0I 4WRLCg36I8SdzT4WF70zs2b6QRhprOygKdfRFLq_dSdhBq8.kQODWufkuheLaw4GrPQjUkGQlUlH ybuaAs0MoZXCxczMMhliH3tWwhtVdDQj3CQZ9Pfz1LUsuHTazReos5OnFWUoaiLJhQxygjy5RZJH 5LWuIe6Frlt4MCwjgGvCsgTwo3lEUmOcFwZJrh3Pzt_UCCVfi4j8hfVFbroOsQ_OdI0b1ivAR0fw JPhmaF9ChN1hx4VO5h4P02RcVOgChg5cp0Gh1dRKZTBILag-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 20:10:40 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9488c875f50d8690f753f7afb465ae80; Sun, 21 Nov 2021 20:09:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 boot (HoneyComb): example crash during system checks (power-off/power-on form of reboot still fails) Date: Sun, 21 Nov 2021 12:09:35 -0800 References: To: "freebsd-arm@freebsd.org" , FreeBSD-STABLE Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hy1k01DDVz4sNh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pWdn2kvR; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.83: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.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.83:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-21, at 11:36, Mark Millard wrote: > On 2021-Nov-21, at 11:26, Mark Millard wrote: >=20 >> Starting file system checks: >> /dev/gpt/CA72opt0EFI: 41 files, 242 MiB free (15469 clusters) >> FIXED >> /d x0: ffff000000e43ec8 (blocked_lock + 0) >> x1: ffff00013efa9f50 >> x2: ffff00000090e39a (cam_status_table + 1d132) >> x3: deadc0d8 >> x4: 0 >> x5: ffff00000082a138 (data_abort + 0) >> x6: 5 >> x7: 601 >> x8: ffff000000e43ec8 (blocked_lock + 0) >> x9: deadc0de >> x10: 0 >> x11: 3938700 >> x12: 0 >> x13: 8000 >> x14: 1de >> x15: 81ce >> x16: 425b9080 >> x17: 8000 >> x18: ffff00013efa9f40 >> x19: ffff000000e43ec8 (blocked_lock + 0) >> x20: ffffa0001a826000 >> x21: 0 >> x22: ffffa0001a826000 >> x23: 0 >> x24: ffff000000bed000 (queue_ops + 0) >> x25: 98967f >> x26: ffff000000e43ee0 (blocked_lock + 18) >> x27: 0 >> x28: 114 >> x29: ffff00013efa9f40 >> sp: ffff00013efa9f40 >> lr: ffff0000004b9028 (thread_lock_flags_ + c0) >> elr: ffff0000004b9028 (thread_lock_flags_ + c0) >> spsr: 2c5 >> far: deadc178 >> esr: 96000004 >> timeout stopping cpus >> panic: data abort in critical section or under mutex >> cpuid =3D 5 >> time =3D 1637492224 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x30 >> pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec >> sp =3D 0xffff00013efa9990 fp =3D 0xffff00013efa9b90 >>=20 >> db_trace_self_wrapper() at vpanic+0x188 >> pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 >> sp =3D 0xffff00013efa9ba0 fp =3D 0xffff00013efa9c00 >>=20 >> vpanic() at panic+0x44 >> pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 >> sp =3D 0xffff00013efa9c10 fp =3D 0xffff00013efa9cc0 >>=20 >> panic() at data_abort+0x290 >> pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 >> sp =3D 0xffff00013efa9cd0 fp =3D 0xffff00013efa9d50 >>=20 >> data_abort() at handle_el1h_sync+0x78 >> pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 >> sp =3D 0xffff00013efa9d60 fp =3D 0xffff00013efa9eb0 >>=20 >> handle_el1h_sync() at thread_lock_flags_+0xbc >> pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 >> sp =3D 0xffff00013efa9ec0 fp =3D 0xffff00013efa9f40 >>=20 >> thread_lock_flags_() at thread_lock_flags_+0xbc >> pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 >> sp =3D 0xffff00013efa9f50 fp =3D 0xffff00013efa9f60 >>=20 >> thread_lock_flags_() at sleepq_timeout+0x10 >> pc =3D 0xffff0000004b9024 lr =3D 0xffff00000054b2a8 >> sp =3D 0xffff00013efa9f70 fp =3D 0xffff00013efa9fb0 >>=20 >> sleepq_timeout() at softclock_call_cc+0x14c >> pc =3D 0xffff00000054b2a8 lr =3D 0xffff000000503134 >> sp =3D 0xffff00013efa9fc0 fp =3D 0xffff00013efaa020 >>=20 >> softclock_call_cc() at callout_process+0x17c >> pc =3D 0xffff000000503134 lr =3D 0xffff000000502df0 >> sp =3D 0xffff00013efaa030 fp =3D 0xffff00013efaa0a0 >>=20 >> callout_process() at handleevents+0x188 >> pc =3D 0xffff000000502df0 lr =3D 0xffff00000045b42c >> sp =3D 0xffff00013efaa0b0 fp =3D 0xffff00013efaa100 >>=20 >> handleevents() at timercb+0x304 >> pc =3D 0xffff00000045b42c lr =3D 0xffff00000045be7c >> sp =3D 0xffff00013efaa110 fp =3D 0xffff00013efaa170 >>=20 >> timercb() at arm_tmr_intr+0x5c >> pc =3D 0xffff00000045be7c lr =3D 0xffff0000007ff850 >> sp =3D 0xffff00013efaa180 fp =3D 0xffff00013efaa1d0 >>=20 >> arm_tmr_intr() at intr_event_handle+0xac >> pc =3D 0xffff0000007ff850 lr =3D 0xffff000000493c54 >> sp =3D 0xffff00013efaa1e0 fp =3D 0xffff00013efaa1e0 >>=20 >> intr_event_handle() at intr_isrc_dispatch+0x70 >> pc =3D 0xffff000000493c54 lr =3D 0xffff0000007fb238 >> sp =3D 0xffff00013efaa1f0 fp =3D 0xffff00013efaa230 >>=20 >> intr_isrc_dispatch() at arm_gic_v3_intr+0x11c >> pc =3D 0xffff0000007fb238 lr =3D 0xffff00000080ff34 >> sp =3D 0xffff00013efaa240 fp =3D 0xffff00013efaa250 >>=20 >> arm_gic_v3_intr() at intr_irq_handler+0x7c >> pc =3D 0xffff00000080ff34 lr =3D 0xffff0000007faff0 >> sp =3D 0xffff00013efaa260 fp =3D 0xffff00013efaa2b0 >>=20 >> intr_irq_handler() at handle_el1h_irq+0x74 >> pc =3D 0xffff0000007faff0 lr =3D 0xffff00000080a140 >> sp =3D 0xffff00013efaa2c0 fp =3D 0xffff00013efaa3f0 >>=20 >> handle_el1h_irq() at handle_el1h_sync+0x78 >> pc =3D 0xffff00000080a140 lr =3D 0xffff00000080a078 >> sp =3D 0xffff00013efaa400 fp =3D 0xffff00013efaa500 >>=20 >> handle_el1h_sync() at handle_el1h_sync+0x78 >> pc =3D 0xffff00000080a078 lr =3D 0xffff00000080a078 >> sp =3D 0xffff00013efaa510 fp =3D 0xffff00013efaa660 >>=20 >> handle_el1h_sync() at sched_switch+0x6a8 >> pc =3D 0xffff00000080a078 lr =3D 0xffff0000005197fc >> sp =3D 0xffff00013efaa670 fp =3D 0xffff00013efaa6f0 >>=20 >> sched_switch() at sched_switch+0x6a8 >> pc =3D 0xffff0000005197fc lr =3D 0xffff0000005197fc >> sp =3D 0xffff00013efaa700 fp =3D 0xffff00013efaa790 >>=20 >> sched_switch() at mi_switch+0xf4 >> pc =3D 0xffff0000005197fc lr =3D 0xffff0000004f03a0 >> sp =3D 0xffff00013efaa7a0 fp =3D 0xffff00013efaa7f0 >>=20 >> mi_switch() at sleepq_timedwait+0x28 >> pc =3D 0xffff0000004f03a0 lr =3D 0xffff00000054bd0c >> sp =3D 0xffff00013efaa800 fp =3D 0xffff00013efaa830 >>=20 >> sleepq_timedwait() at _cv_timedwait_sbt+0x110 >> pc =3D 0xffff00000054bd0c lr =3D 0xffff00000045e7b0 >> sp =3D 0xffff00013efaa840 fp =3D 0xffff00013efaa850 >>=20 >> _cv_timedwait_sbt() at dbuf_evict_thread+0x410 >> pc =3D 0xffff00000045e7b0 lr =3D 0xffff0000013ca59c >> sp =3D 0xffff00013efaa860 fp =3D 0xffff00013efaa8f0 >>=20 >> dbuf_evict_thread() at fork_exit+0x94 >> pc =3D 0xffff0000013ca59c lr =3D 0xffff00000048fbf0 >> sp =3D 0xffff00013efaa900 fp =3D 0xffff00013efaa950 >>=20 >> fork_exit() at fork_trampoline+0x10 >> pc =3D 0xffff00000048fbf0 lr =3D 0xffff000000828ed8 >> sp =3D 0xffff00013efaa960 fp =3D 0x0000000000000000 >>=20 >> KDB: enter: panic >> [ thread pid 26 tid 100194 ] >> Stopped at kdb_enter+0x48: undefined f906411f >>=20 >> For reference: >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 >>=20 >> It is a root-on-ZFS context on Optane media in the PCie slot. >>=20 >> I've no clue if this will repeat. I've never gotten >> this before. >=20 >=20 > The reboot attempt got the following, involving > zthr_procedure instead of dbuf_evict_thread . >=20 > Starting file system checks: > /dev/gpt/CA72opt0EFI: FILESYSTEM CLEAN; SKIPPING CHECKS > x0: ffff000000e43ec8 (blocked_lock + 0) > x1: ffff00013ef9ff90 > x2: ffff00000090e39a (cam_status_table + 1d132) > x3: deadc0d8 > x4: 0 > x5: ffff00000082a138 (data_abort + 0) > x6: 9 > x7: 601 > x8: ffff000000e43ec8 (blocked_lock + 0) > x9: deadc0de > x10: 0 > x11: 3938700 > x12: 1 > x13: 8000 > x14: 1ee > x15: 81cd > x16: 425b9080 > x17: 8000 > x18: ffff00013ef9ff80 > x19: ffff000000e43ec8 (blocked_lock + 0) > x20: ffffa0000c011000 > x21: 0 > x22: ffffa0000c011000 > x23: 0 > x24: ffff000000bed000 (queue_ops + 0) > x25: 98967f > x26: ffff000000e43ee0 (blocked_lock + 18) > x27: 0 > x28: 114 > x29: ffff00013ef9ff80 > sp: ffff00013ef9ff80 > lr: ffff0000004b9028 (thread_lock_flags_ + c0) > elr: ffff0000004b9028 (thread_lock_flags_ + c0) > spsr: 2c5 > far: deadc178 > esr: 96000004 > timeout stopping cpus > panic: data abort in critical section or under mutex > cpuid =3D 9 > time =3D 1637492224 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x30 > pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec > sp =3D 0xffff00013ef9f9d0 fp =3D 0xffff00013ef9fbd0 >=20 > db_trace_self_wrapper() at vpanic+0x188 > pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 > sp =3D 0xffff00013ef9fbe0 fp =3D 0xffff00013ef9fc40 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 > sp =3D 0xffff00013ef9fc50 fp =3D 0xffff00013ef9fd00 >=20 > panic() at data_abort+0x290 > pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 > sp =3D 0xffff00013ef9fd10 fp =3D 0xffff00013ef9fd90 >=20 > data_abort() at handle_el1h_sync+0x78 > pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013ef9fda0 fp =3D 0xffff00013ef9fef0 >=20 > handle_el1h_sync() at thread_lock_flags_+0xbc > pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 > sp =3D 0xffff00013ef9ff00 fp =3D 0xffff00013ef9ff80 >=20 > thread_lock_flags_() at thread_lock_flags_+0xbc > pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 > sp =3D 0xffff00013ef9ff90 fp =3D 0xffff00013ef9ffa0 >=20 > thread_lock_flags_() at sleepq_timeout+0x10 > pc =3D 0xffff0000004b9024 lr =3D 0xffff00000054b2a8 > sp =3D 0xffff00013ef9ffb0 fp =3D 0xffff00013ef9fff0 >=20 > sleepq_timeout() at softclock_call_cc+0x14c > pc =3D 0xffff00000054b2a8 lr =3D 0xffff000000503134 > sp =3D 0xffff00013efa0000 fp =3D 0xffff00013efa0060 >=20 > softclock_call_cc() at callout_process+0x17c > pc =3D 0xffff000000503134 lr =3D 0xffff000000502df0 > sp =3D 0xffff00013efa0070 fp =3D 0xffff00013efa00e0 >=20 > callout_process() at handleevents+0x188 > pc =3D 0xffff000000502df0 lr =3D 0xffff00000045b42c > sp =3D 0xffff00013efa00f0 fp =3D 0xffff00013efa0140 >=20 > handleevents() at timercb+0x304 > pc =3D 0xffff00000045b42c lr =3D 0xffff00000045be7c > sp =3D 0xffff00013efa0150 fp =3D 0xffff00013efa01b0 >=20 > timercb() at arm_tmr_intr+0x5c > pc =3D 0xffff00000045be7c lr =3D 0xffff0000007ff850 > sp =3D 0xffff00013efa01c0 fp =3D 0xffff00013efa0210 >=20 > arm_tmr_intr() at intr_event_handle+0xac > pc =3D 0xffff0000007ff850 lr =3D 0xffff000000493c54 > sp =3D 0xffff00013efa0220 fp =3D 0xffff00013efa0220 >=20 > intr_event_handle() at intr_isrc_dispatch+0x70 > pc =3D 0xffff000000493c54 lr =3D 0xffff0000007fb238 > sp =3D 0xffff00013efa0230 fp =3D 0xffff00013efa0270 >=20 > intr_isrc_dispatch() at arm_gic_v3_intr+0x11c > pc =3D 0xffff0000007fb238 lr =3D 0xffff00000080ff34 > sp =3D 0xffff00013efa0280 fp =3D 0xffff00013efa0290 >=20 > arm_gic_v3_intr() at intr_irq_handler+0x7c > pc =3D 0xffff00000080ff34 lr =3D 0xffff0000007faff0 > sp =3D 0xffff00013efa02a0 fp =3D 0xffff00013efa02f0 >=20 > intr_irq_handler() at handle_el1h_irq+0x74 > pc =3D 0xffff0000007faff0 lr =3D 0xffff00000080a140 > sp =3D 0xffff00013efa0300 fp =3D 0xffff00013efa0430 >=20 > handle_el1h_irq() at handle_el1h_sync+0x78 > pc =3D 0xffff00000080a140 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013efa0440 fp =3D 0xffff00013efa0540 >=20 > handle_el1h_sync() at handle_el1h_sync+0x78 > pc =3D 0xffff00000080a078 lr =3D 0xffff00000080a078 > sp =3D 0xffff00013efa0550 fp =3D 0xffff00013efa06a0 >=20 > handle_el1h_sync() at sched_switch+0x6a8 > pc =3D 0xffff00000080a078 lr =3D 0xffff0000005197fc > sp =3D 0xffff00013efa06b0 fp =3D 0xffff00013efa0730 >=20 > sched_switch() at sched_switch+0x6a8 > pc =3D 0xffff0000005197fc lr =3D 0xffff0000005197fc > sp =3D 0xffff00013efa0740 fp =3D 0xffff00013efa07d0 >=20 > sched_switch() at mi_switch+0xf4 > pc =3D 0xffff0000005197fc lr =3D 0xffff0000004f03a0 > sp =3D 0xffff00013efa07e0 fp =3D 0xffff00013efa0830 >=20 > mi_switch() at sleepq_timedwait+0x28 > pc =3D 0xffff0000004f03a0 lr =3D 0xffff00000054bd0c > sp =3D 0xffff00013efa0840 fp =3D 0xffff00013efa0870 >=20 > sleepq_timedwait() at _cv_timedwait_sbt+0x110 > pc =3D 0xffff00000054bd0c lr =3D 0xffff00000045e7b0 > sp =3D 0xffff00013efa0880 fp =3D 0xffff00013efa0890 >=20 > _cv_timedwait_sbt() at zthr_procedure+0x20c > pc =3D 0xffff00000045e7b0 lr =3D 0xffff0000014e2fb0 > sp =3D 0xffff00013efa08a0 fp =3D 0xffff00013efa08f0 >=20 > zthr_procedure() at fork_exit+0x94 > pc =3D 0xffff0000014e2fb0 lr =3D 0xffff00000048fbf0 > sp =3D 0xffff00013efa0900 fp =3D 0xffff00013efa0950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff00000048fbf0 lr =3D 0xffff000000828ed8 > sp =3D 0xffff00013efa0960 fp =3D 0x0000000000000000 >=20 > KDB: enter: panic > [ thread pid 26 tid 100192 ] > Stopped at kdb_enter+0x48: undefined f906411f >=20 >=20 > Note: >=20 > All this started after a stress based I/O hangup test > that required a forced reboot. It is a bectl environment for that Optane: # bectl list BE Active Mountpoint Space Created 13S-CA72-nodbg R - 6.38G 2021-09-29 00:57 13_0R-CA72-nodbg N / 3.57G 2021-09-29 00:45 main-CA72-nodbg - - 7.99G 2021-09-29 00:42 13_0R-CA72-nodbg and main-CA72-nodbg boot fine, just 13S-CA72-nodbg has the problem. For reference: =3D> 40 1875384928 nda1 GPT (894G) 40 532480 nda1p1 CA72opt0EFI (260M) 532520 2008 - free - (1.0M) 534528 515899392 nda1p2 CA72opt0SWP (246G) 516433920 20971520 - free - (10G) 537405440 1337979528 nda1p3 CA72opt0ZFS (638G) Another attempt at booting have gotten reports of . . . lots of waiting notices . . . Root mount waiting for: CAM usbus1 Root mount waiting for: CAM usbus1 Root mount waiting for: CAM usbus1 Root mount waiting for: CAM usbus1 Root mount waiting for: CAM usbus1 x0: ffff000000e43ec8 (blocked_lock + 0) x1: ffff00013efa9f60 x2: ffff00000090e39a (cam_status_table + 1d132) x3: deadc0d8 x4: 0 x5: ffff00000082a138 (data_abort + 0) x6: 4 x7: 601 x8: ffff000000e43ec8 (blocked_lock + 0) x9: deadc0de x10: 0 x11: 3938700 x12: 0 x13: 8000 x14: 1dd x15: 81cd x16: 0 x17: 1 x18: ffff00013efa9f50 x19: ffff000000e43ec8 (blocked_lock + 0) x20: ffffa0000c806000 x21: 0 x22: ffffa0000c806000 x23: 0 x24: ffff000000bed000 (queue_ops + 0) x25: 98967f x26: ffff000000e43ee0 (blocked_lock + 18) x27: 0 x28: 114 x29: ffff00013efa9f50 sp: ffff00013efa9f50 lr: ffff0000004b9028 (thread_lock_flags_ + c0) elr: ffff0000004b9028 (thread_lock_flags_ + c0) spin lock 0xffff00004317b100 (sched lock 4) held by 0xffffa0000c806000 = (tid 100194) too long spin lock 0xffff00004317b100 (sched lock 4) held by 0xffffa0000c806000 = (tid 100194) too long spin lock 0xffff00004317b100 (sched lock 4) held by 0xffffa0000c806000 = (tid 100194) too long spsr: 2c5 far: deadc178 esr: 96000004 timeout stopping cpus panic: spin lock held too long cpuid =3D 9 time =3D 56 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc =3D 0xffff000000807770 lr =3D 0xffff00000011d9ec sp =3D 0xffff000156eea430 fp =3D 0xffff000156eea630 db_trace_self_wrapper() at vpanic+0x188 pc =3D 0xffff00000011d9ec lr =3D 0xffff0000004e1d10 sp =3D 0xffff000156eea640 fp =3D 0xffff000156eea6a0 vpanic() at panic+0x44 pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 sp =3D 0xffff000156eea6b0 fp =3D 0xffff000156eea760 panic() at _mtx_lock_indefinite_check+0x8c pc =3D 0xffff0000004e1b84 lr =3D 0xffff0000004b8ea4 sp =3D 0xffff000156eea770 fp =3D 0xffff000156eea770 _mtx_lock_indefinite_check() at _mtx_lock_spin_cookie+0xb8 pc =3D 0xffff0000004b8ea4 lr =3D 0xffff0000004b8a0c sp =3D 0xffff000156eea780 fp =3D 0xffff000156eea790 _mtx_lock_spin_cookie() at sched_add+0x400 pc =3D 0xffff0000004b8a0c lr =3D 0xffff00000051ac94 sp =3D 0xffff000156eea7a0 fp =3D 0xffff000156eea7f0 sched_add() at kthread_add+0x238 pc =3D 0xffff00000051ac94 lr =3D 0xffff0000004a01e0 sp =3D 0xffff000156eea800 fp =3D 0xffff000156eea880 kthread_add() at vm_pageout+0x1b8 pc =3D 0xffff0000004a01e0 lr =3D 0xffff0000007e5a18 sp =3D 0xffff000156eea890 fp =3D 0xffff000156eea8f0 . . . Garbled . . . sp =3D 0xffff00013efa9bb0 fp =3D 0xffff00013efa9c10 vpanic() at panic+0x44 pc =3D 0xffff0000004e1d10 lr =3D 0xffff0000004e1b84 sp =3D 0xffff00013efa9c20 fp =3D 0xffff00013efa9cd0 panic() at data_abort+0x290 pc =3D 0xffff0000004e1b84 lr =3D 0xffff00000082a3c8 sp =3D 0xffff00013efa9ce0 fp =3D 0xffff00013efa9d60 data_abort() at handle_el1h_sync+0x78 pc =3D 0xffff00000082a3c8 lr =3D 0xffff00000080a078 sp =3D 0xffff00013efa9d70 fp =3D 0xffff00013efa9ec0 handle_el1h_sync() at thread_lock_flags_+0xbc pc =3D 0xffff00000080a078 lr =3D 0xffff0000004b9024 sp =3D 0xffff00013efa9ed0 fp =3D 0xffff00013efa9f50 thread_lock_flags_() at thread_lock_flags_+0xbc pc =3D 0xffff0000004b9024 lr =3D 0xffff0000004b9024 . . . Garbled . . . But after that the next attempt booted just fine. zpool scrub got: # zpool status pool: zopt0 state: ONLINE scan: scrub repaired 0B in 00:02:05 with 0 errors on Sun Nov 21 = 12:00:09 2021 config: NAME STATE READ WRITE CKSUM zopt0 ONLINE 0 0 0 nda1p3 ONLINE 0 0 0 errors: No known data errors Further reboots into 13S-CA72-nodbg have worked fine. For reference: The HoneyComb is a 16 Cortex-A72 system. I've no clue if releng/13 (-p5) or main could be induced to get similar behavior to what 13S-CA72-nodbg showed for the Optane media. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Nov 21 21:00: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 C22DE18A84D1 for ; Sun, 21 Nov 2021 21:00:24 +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 4Hy2qD3k6bz3PyD for ; Sun, 21 Nov 2021 21:00:24 +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 21AAA16583 for ; Sun, 21 Nov 2021 21:00:24 +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 1ALL0OHV069262 for ; Sun, 21 Nov 2021 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1ALL0OI3069261 for freebsd-arm@FreeBSD.org; Sun, 21 Nov 2021 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202111212100.1ALL0OI3069261@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, 21 Nov 2021 21:00:24 +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="16375284240.fB0a.67989" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16375284240.fB0a.67989 Date: Sun, 21 Nov 2021 21:00:24 +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. --16375284240.fB0a.67989-- From nobody Sun Nov 21 22:13:10 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 668E4188A1E5 for ; Sun, 21 Nov 2021 22:13:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4Hy4RQ3NT5z4m4G for ; Sun, 21 Nov 2021 22:13:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637532795; bh=cG1gAy5HWwOfZn+Hcsx5HXHuuvTCZbU+hMWK+n+YiUo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=s5Nv+nnLLERybDe0+aIpoqwsFLOvhJ8I4xWydxQDuk9U+zLKizdE9u/i3hQBgQToXwsNk2cM3ki9eUOP7sHg1fyQ0OydxOGyVQ4tzhJgLWKr9fJi4P3dM24ASAlZa9GK39OgIWGJy/YZowxsFErDj66MR7Gp4dlsFlqD/ZfMFsqlV5lXWzgAygnsYwrDL8rDA3YEN/IF1qxmBfDu9DLpBy34LAm+qCgkyxFj41w+mBElPEJf9ZKnVh2cQxISPiLAbZozyRgKUBbl4tZNIq7GxchxZwezkxEiNKrJPgzIAejiWO+raisHDlLWVVj/eBEfFGWxf9owGgb/F9J0LZAYtA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637532795; bh=Ant+mWuHt0q4y4YSdmAMEI+sp/zhIRL74Fqy6zlbkII=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EZ/ozT4LW7NeqyravQgarXnTnu3IaQz9T5hbre8fQTWXahIh3tXmcfswFVUuxVcV59CrmBz6B4Aj0E2fzdGb5su9xQII7dWf3QfUCuJe43r1VshegUj5v51NNS8amCD9QdrjFuZIpXiKDAhqlEVdQyvYAwldJtQHK/BnY8z9/I+ZkKnxUCZQ0sWRfEz3OQCEsuqbLN/qNcp26b4Ykl+3Ge+eUDQ5xzl+lO/WFMQnHh0EdEHsCEHN6uD3GCE/AhvT6IUC31JqgfI6QcLVLJwM0d/5j7VOrBWPO094chXPSxPOafdwNqRl7kxFBEvktIFMWU4av65MlkGtd29kf8IwTA== X-YMail-OSG: 9n3.fQIVM1nVIDVEmkFkHOfcojNuaSRhH0IP2GsYrTZJjaCsKnPk_EUGOiJ.kMe ifd5SXawihDm_Lm8AnkeFzpV3yJk9Ctm197OzivlTZB3qC6GER3gu77NKVhEYwnLlxtOJA731yJq 764U9BtVUN9.UV2fp7H0BHSnYfbZIxsGharOuS2H69gc5smjBFVn4uZHT_RdFSniSVbskG7eYx3t B6TdAjTtsSNf6rVJRgPNLYV3W4xTtsascWD2h59lPwR0Upkb6CzpgEyoBAu1L2kVyl41CjIV1zlQ mC2ePIAMhTD1P71hP1Hajcj5gAqMUvxe.ql.2VOZE1EyVCdOGwdjAfT3e0wsM.e_kNvCpO5C5Bc1 bQzBXXgnsf3JMx7fFoLT8fuK0_lstTYvF91ee2DAy6_pZKHivS7o_unDMT7EmI2nqEiE9OCkYH2W xOSOvyRfu8kdGDMpv8pqw2pTcQeZ1wnTmvHoxv5Hk61iSSWsYKmga8ZFDi2O52blvWWiY40j5lL. yI7E.V78UfvEV_utimHiFdcGtRFMZTT9IWUoDG8Gd4cvFDuBaxQxGMMYGGIItk7freHd77x9gYoC 8WL6Jy421VcrN5Y3BudCxNF4LTsc1dINIEog70OCiWEAGFwfGhot1580ELqf42ViKDiGaUuVlunY 2fBX0efp06kznXNoi6dFJ9ZUVzO75ALUYWq7e8GvtlDH.M6La69eR0yvaBJ.GqH0v5SN3bvF8iKO OZbn5eVkukIdprFZ4ValWS1BlfWd6P9XAdy.tWl7fHskoqLv8X22EvbF3BFQgA_tQyShPofKp9kx V3EV2fQ0AjS5rfS0GgQ.7DfDRyEvcNJkEizpN9qop2QG5HGm.GRld4YfKqsaof9KCcgQYf30MuNV 7xSV3HBxsJ7RyROQsOmveJFlqAfliUcAELLZ5b8XJE8MPSaa1MwMdKJYskqOfQ1qZMMiscQhzLJ4 secxPRZCst62LA7_eKqYSY3eaAqCf9UQ9G7s9sDJtCEcXbdSJydk.UKk5KWKY2ch50MrrwXksUWb tsfbeuQcBUIkDYlAdAmTAVrtujhY9O7Q2sAq3luv5HLU9cir7hrzuAs3_YEtgNnnc522AnMzT1wH 4XKXU.iU4HtH1rpkX9eVdUr3LHFcOZNsNWCSxsxXoucd5a79rnVCtz0Vehg69oLfPL0E9m89xJGp 5r2byJ1u2DhW3DTAf6U_enVLAADSbiDIlnt6d21oBBAdDFyWvxofzpCQKUmAHwtqRuPmLUdiNVG2 7myCmskTP3tAv5oyJYtHFOjRPRmgSlMRMW4UVPOXwjU0mbOrsfNLzo0Umef5FVeFNZbpLxadsXqC vIdt7dx5Kol62QzcZBrScBu0c69A.v76ZdhfCKEmccf3V7Ja9ROkQA8.xa3QRS9LOjxO5DTdBzd4 cIxH6f9cw2jEreOaH1zyPWeevi3mTjmvmjMM3gpFckaHjAklizBAYQm5HKPxfmIcC86LSTc_1YGs MmOvGXhhsc3sMkXdky82nJq4gGyy8bENlos857rYMwUDUuEjoQ7LUkIftTWSdTYGpTqE.mgQyafR nFXFZpAl9cYWwXKiWORQJzfqF_6cZZE58iOw.GjeLSbzu4MQre7H31FY5lH1vdsGjndonPKoOFMo p.Fhowtiz05YrRFMa56WSNfDA040oFbdP9_AJre_u8lGJRcdTpCjSRuZf7xwF6z7plnaQQCSrLp7 yEBF52ukG9LnTox0HXEab5ZJrckNiNdWCBTQ7LTzCsMm0jtDnX32IqrKR7OEg1KBOmeWYtVs5UFD oSQQ9_FOJrzLgBx3UdsQcq8_v.PQr6152IXObfxS8VtXQjF_FU_XvLtbXZPoz8_WqdMDPsY01Tn2 52nm1MaG99fP0fqTLpBoTRBGvKGxdMLnuMcw0blaRpoO336gj1X08tVguI1JiC.fHgaO.M70pywZ vpWslNWa4wcXUUAjlgEPLuedlV.hO20rhTXUqxIhsrQh0bhMmFJokDADLskasZ6WkqRRp3ZSD4Sw uEMq_h.KoaoCwXu9SkeKht.RnAu.dpE205jSzroWC15Ew_34l0dj4KipwstNoZaPUoyXlz8QtqdR WqV08_9CrD0JkN2jRMblmjjAgwgm2KWvE8Wo7SLVb7O.yH1XK51s8ODl2mGLU96hX2au3ZzMrEsw eP6RLyOHqG81hncgrz.3Mq4P.oA7PNJjSrYeSTzVErnBJWeomM7TzGAns1_dbThz.8l1G6k62mmH c62lmmJUEnQRzSfyVgxoipSj192u7Gj3vcW1_W35zq4Q_GF4- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 22:13:15 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 505bee3b87c130c37f93dca6c4ef992e; Sun, 21 Nov 2021 22:13:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: tmpfs use and "stress --hdd ? --hdd-bytes ??G" can lead to hung up system (16 Cortex-A72's system example) Message-Id: Date: Sun, 21 Nov 2021 14:13:10 -0800 To: FreeBSD-STABLE Mailing List , "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Hy4RQ3NT5z4m4G X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=s5Nv+nnL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.55 / 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.05)[-0.053]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-stable X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Context: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 (It is a non-debug kernel build, but with symbols.) 64 GiBytes of RAM Swap: 251904Mi Total 16-core Cortex-A72 system (HoneyComb) root-on-ZFS on Optane media in the PCIe slot The following sort of sequence using tmpfs tends to hangs up the system long before the maximum swap usage would happen: # mount -ttmpfs tmpfs /mnt # cd /mnt # stress --hdd 16 --hdd-bytes 16G The details of processes seeming to hang up does vary. Sometimes ^C, ^T, and the like do not seem to work (or echo) at all. Top can stop updating for the likes of: # stress --hdd 12 --hdd-bytes 22G until ^C leads to stress exiting. Based on what top was reporting at the point its updates stopped, there still was lots of swap-space and no apparent need to have swapped out the kernel stacks for the top process. For example: 22% used. Another issue is that having systat -swap going as well leads to partial hang ups even for the likes of: # stress --hdd 8 --hdd-bytes 32G "Partial" in that some things stop but I've never had to force a reboot to get control: ^C for the stress run eventually works. I do not seem to have problems like any of the above for the likes of: # stress --hdd 1 --hdd-bytes 270G For this, "systat -swap" does progress the like of: Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| gpt/CA72opt0SWP 246G 154G XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX But not with the larger ---hdd figures above. I've not yet tried main [so: 14]. Note: These experiments are from attmpting to reproduce hangups seen during pourdiere-devel builds that have USE_TMPFS=3Dall and builders that are generating indefinitely growing log files. (This was actually under main targeting main .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 23 02:42:25 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 E2A3E18A9DC3 for ; Tue, 23 Nov 2021 02:42:37 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HypMd27Mzz56Hp for ; Tue, 23 Nov 2021 02:42:37 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x933.google.com with SMTP id y5so40711220ual.7 for ; Mon, 22 Nov 2021 18:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=1+l88g/drIEn1hApbBGlEpGsGPn6q1BOdxYpVoQUsfw=; b=aDTn6CqIVcvyqa0mXxhnMZQ2Eby6tK7roSYV0Fy2Y7RjwXkJqkJv51QHndE9BNnEvo BPF6LFuVkU6/wz07y2ds/O4z6zq4uWzCU7POFHfxuiIeUaDTRb35fYmXZZ/MVrnBWfUH F9NzZuBl+elE3gAQHxWOgFvlgJAKMIuzKZXw7NMuAxb4faVNT480m6aqsWvAS1rAlOD2 EvCAnZCfsw9J/QZmd7F/122ANoK09TZMYHFzHiriGSix53vZuqZFpoaOq6amTpb4ZQCs /nSwyxEQEHLMsGPdmzaCSXenZZ68Vieto5jM/4dd4OBOScYRri8k28SF3Gt0+WobYu4p YQBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1+l88g/drIEn1hApbBGlEpGsGPn6q1BOdxYpVoQUsfw=; b=zcXHTX3XLE3wrPeL/lI72X6lW4CmBVikDWPoPkOmVfTOanemHTRmpCYPp0NvNFLZWG st90p37ebwLqhpWR+LOh2pymByiEa5Wsr+DFbT6GkjfTlqn7U3354Jbduz3AD6qzi3SU 2w45KkXONk7XIrCgOg3AfQhE44dZ5DMqR94LUyjV0EP765LEVXqXfjzXj4wCouZrlaNr jEkpohDAlnhaqX/K+0LbQ9Wg3hlO9rtKG32RSYOsq8z08nvRkN2gt2YX4YUxfIY7eSNn mrGhyUDIOfvg/iw4yujnFahlLDXKFaDWwip5Wxjuyj3g4TdlZwdkpuG9jUTcLRU2vm9U K+cw== X-Gm-Message-State: AOAM530UkUr/doIVF4iHcyVnj3JE/RXDlS15/sNoH9+Aad0hdvNRaF58 gNlUh0+ylEmPSK+adzvp0UwdA/Si91qCWLwLGj4w+p9+MxVM X-Google-Smtp-Source: ABdhPJycvqU2gzPuUR7Lw7Lbe0983cR6RTd6zdEgEcvNgfqTJZRebF0m+98oHCuU1Rlb4QUzJ/K9rxa1Elohz73pUyc= X-Received: by 2002:a05:6102:160f:: with SMTP id cu15mr2609754vsb.11.1637635356481; Mon, 22 Nov 2021 18:42:36 -0800 (PST) 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 From: Juan David Hurtado G Date: Mon, 22 Nov 2021 21:42:25 -0500 Message-ID: Subject: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b1ed0105d16bb166" X-Rspamd-Queue-Id: 4HypMd27Mzz56Hp X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=orbiware.com header.s=google header.b=aDTn6CqI; dmarc=pass (policy=none) header.from=orbiware.com; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::933 is neither permitted nor denied by domain of jdhurtado@orbiware.com) smtp.mailfrom=jdhurtado@orbiware.com X-Spamd-Result: default: False [2.20 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[orbiware.com:s=google]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; DKIM_TRACE(0.00)[orbiware.com:+]; DMARC_POLICY_ALLOW(0.00)[orbiware.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::933:from]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000b1ed0105d16bb166 Content-Type: text/plain; charset="UTF-8" Hi, I'm trying to use the OS on a Raspberry pi 3 B+ Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for some minutes before showing the `login:` to enter the username. When I enter it, it takes a few seconds to ask for the password. While doing `freebsd-update fetch install` it took a plenty of minutes, so I canceled the process and then did `freebsd-update fetch` and then `freebsd-update install` to see what was going on. Found that the process was at `wdraid` state. Doing a simple search, I found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to 2Mb. It seems to help, but not by much. Look at this: freebsd@generic:~ % time freebsd-version -kru 13.0-RELEASE-p4 13.0-RELEASE-p4 13.0-RELEASE-p5 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w :( What could I be missing? Maybe I need to tweak partitions and use some kind of configuration/optimization? how? I do appreciate any guidance you can provide in order to troubleshoot this. PS: I don't think it is the microsd card since it runs raspios fine. PS2: The red led is turned off at the boot process so no way of knowing visually if the pi is running. Weird is that the led turned on again after `shutdown -p now` hehe. -- Juan David Hurtado G --000000000000b1ed0105d16bb166-- From nobody Tue Nov 23 05:44:21 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 85D121897F23 for ; Tue, 23 Nov 2021 05:44:32 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HytPW5ShGz4qZS for ; Tue, 23 Nov 2021 05:44:31 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pl1-x634.google.com with SMTP id k4so16075951plx.8 for ; Mon, 22 Nov 2021 21:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QOeY2MFdlWbID3IRa6z6NxOOFw9aynS7jlLgbpiJp4Y=; b=Z1GznH6tKgxibwy9mr1oIuWxReapXKR+wYAkhV3SfuVUih3YZRgbkpOXo8bi3dlsKT 7+ajYdQY0yjjmj1I5OWB2vVBB7MAEzj8I9zxh36DKPH9ztKHPZQ8Gh1EAVZdzGjuSq/L h86qLXnoXogLOW8b9Xzmp1D3VCZZDGlNeBFahcj47/JgBKhbRVRbCA54BFJCFJhZDdLR Xg4ERW0SkhKVHjCfS5JHcSPHi99rkiUaCumGQFu4nXGDP/gwTC8Y9PlSMOwrzVW7UB44 oJOGZdaudWiyQfgq9q+9rjSxHt9OP78300VsFTRcGFNsG3vvLqT5jSIGV09emsJzQIAF +Kmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QOeY2MFdlWbID3IRa6z6NxOOFw9aynS7jlLgbpiJp4Y=; b=QI5uUebM+x/i2bQohCkyU5Wh5ScDxRUTt2FknL4wio1uOfRcAVDhUBZdMG0PqveWBo 4s4KkZJs8R/d5GVbYvRdA+TEOBQEt1ZclJEj0TJeLh3NS6ui1zSiDfpupKANJt523xna LjzHYaX309HawBj3xQWHhEYNvgbB8WNX3NWOiK69LWdccvJZd62SSzlZl0yEktfwKflT 3GqJ0HZsck6OjgoVDwoVvh0Fle8rZGv0vhgxRrFEI7e+g6AJFRlfEw84EyHp31vIPNup d9ukv4zlMcx/Tsj1sHewRFm/OjAdETEqMz8mDzJhVqk+4XTJXDgjg1+nM6gCAho0yi+7 iTRA== X-Gm-Message-State: AOAM531/9wN/2AZBIWGEL58UP7secWbKXHsDF4gon4N6ntVji20L97as T7W5qhl98YNhkLqWikeBT2zN9JRiDlA3YyaK X-Google-Smtp-Source: ABdhPJwfUddbtxEIULmZJSgQVX0yPP66jyUjm5OxXxTq/irqWXK2jldqxWqXcPK9zmc0bh9P14J0Og== X-Received: by 2002:a17:902:9888:b0:142:8731:4b55 with SMTP id s8-20020a170902988800b0014287314b55mr3707242plp.51.1637646264411; Mon, 22 Nov 2021 21:44:24 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id z10sm11038550pfh.106.2021.11.22.21.44.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Nov 2021 21:44:24 -0800 (PST) Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: freebsd-arm@freebsd.org References: From: MJ Message-ID: <94d868fb-3646-598f-fdea-7d4c61bae4c1@gmail.com> Date: Tue, 23 Nov 2021 16:44:21 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HytPW5ShGz4qZS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z1GznH6t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-0.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.619]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_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::634:from]; NEURAL_HAM_SHORT(-0.52)[-0.519]; NEURAL_SPAM_LONG(0.68)[0.679]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 23/11/2021 1:42 pm, Juan David Hurtado G wrote: > Hi, I'm trying to use the OS on a Raspberry pi 3 B+ > > Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for some > minutes before showing the `login:` to enter the username. When I enter it, > it takes a few seconds to ask for the password. I had similar experiences. Do you have any USB devices attached? One thing to watch for is any mounting of USB drives. I also had problems with certain cables connecting USB drives to the Pi but when I placed them on a powered hub they were fine (not slow to mount). As a reference, running devuan I had no issues. If you have USB drives attached, try this: place hw.usb.no_boot_wait="1" in /boot/loader.conf > > While doing `freebsd-update fetch install` it took a plenty of minutes, so > I canceled the process and then did `freebsd-update fetch` and then > `freebsd-update install` to see what was going on. > > Found that the process was at `wdraid` state. Doing a simple search, I > found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to 2Mb. It > seems to help, but not by much. Look at this: > > freebsd@generic:~ % time freebsd-version -kru > 13.0-RELEASE-p4 > 13.0-RELEASE-p4 > 13.0-RELEASE-p5 > 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w > > :( > > What could I be missing? Maybe I need to tweak partitions and use some kind > of configuration/optimization? how? I do appreciate any guidance you can > provide in order to troubleshoot this. I've never tried this. Is this now possible because it's a Tier 1 architecture? Would not memory be a constraint here? You definitely wouldn't want to be using tmpfs system. > > PS: I don't think it is the microsd card since it runs raspios fine. > And usually they start exhibiting write issues beforehand if they're going to fail. Have you looked in /var/log/messages to see if there's any help there? Matt. From nobody Tue Nov 23 08:43:11 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 5D7D318A1564 for ; Tue, 23 Nov 2021 08:43:23 +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 4HyyMt2lCHz4kPb for ; Tue, 23 Nov 2021 08:43:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637656994; bh=Pr6rR2lEIfwENCla7H0CNaTIcvKHU82y4b/a7y0tciI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=tKaxyNgTyzkWAKTo05lLISYom1SvAEV+Ky18NnxNgA8MqhIZseaiU5sTpmN8cy1pYjTLHXpFbQxM+MHiXogPmh0agnbnMB5Nbia+GhDB/UixM029Fbx/tkgRE8X7Sp8z0FI+Vrobgynx+VnvScUz7mLSsMyv8QxkYS46nnEr8chuaILLRy7wlDizlYJpQh933YDGTt2um+GmsOzFE8piLNtBVgT3aKb2kyxYJ+uBRp0R8qZwhGjuvv5LvQznvGQoxr+0fXpmc/n1BSw2kdfHVzJCPXAmT3HcpIxpfscpPmto8P7zBzcG0wFXiovmN1TBQLlqrX3xeSnRHJ6Ygbhr+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637656994; bh=B7BH871VGILXRG1SSveUIOq/fa4OnrzJnS7SDhRwq5Q=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ooqMCcTmDXcbxIF7lwsIeZ/AMBhArZAFrYrK9WHSDuzsJxTGJb3exZ9f8hmfRlKJwN7OFXOj+1LxrXnIOThIrQRx09AIp8IDbkX757A2vMRiP2b+i7wFS/YxIDJu/TDrGYXWFoW2+cTaXnqA4PiV4w4fJlx7u7WVLOSwF+AlDhShddaZilY+B9R4JK92DuRH5pcVwZnd9uFw02cHCuj+cjTs989SKdKLL5zD0T1pKM1V1/sQRx9COc0gYXY8YXruZN3youuZW5w3s1+YM4eLO8yYPW1nj4FJoGQvcucErnlmTWGocPIUGv798Rl1HEeEqy29D/kL9FKopr7NZNdHMA== X-YMail-OSG: LgrVpEEVM1lfa8sU9CCUUaZr7z3Q1zd3osOMZLuq8X_ZlGcLgBOI_Bau7fgGYHD NvQ4ImAerwFhD5Ozrb535bG90TOBMF17IqEcIWmS1lMT3201l5LIHW3XzPqxjs8NPSnx1kIgrHMr Xww0vC0Yn.HpdqULhks0niq9VbBw2EJzPOFxqhb1Cp7DaFc7Fd5mOXPpaJqekxtJ_qEbmtyNbFHo WdQ7SDGVcIsWm6nnok55puMWceBVELVSrtqtDiG2sNQeUWGIwJqqrChjmImWTCZkVOxoSrs_ZB.W hk0lRNXB4.ZoAZziMfGwdtxI5f0.VOXrVBzm0SAbevviL04P6488hAIma8Pkmt70WIeKK6N7iSRl PJXqa2pcprqfUvQeP5p0oXowc70618sYXVO95vOO_aInUzgt12uvbDnYuVPU67DMAhLLgp7RWern o34DVRco6VprsibbHDTB1GWJoqiunVStU64aTYCAtIAxZsUOQ8sGGgH2jTi3HNaDodf23JcTjabJ J41XAwtuqPyqTwPqGad_Mlbt5maV2_9Vy2LxgtoAliHNBliAwSycxNr7dN9nQYB5LWdMJ802kMMD KbNuPpJ6e6bNuGLQv43ReAmyoyHaKY04JcVCR0Q_8T11ivW4.Rp7I3L9TV7CT5Lmm5hQVnZcbtbx 98Kd3OLa8tzUTwOf477z33xCIIbqmCl37fQioBi.6kUOgBq8u5XE1gPYfLh7JAs4aP6HvKKfL.rh mQQaXOLIBGp9ltARkcKG.NquqgpPxC8cFbzJPQ0yV8a4wVsqhlf_CPoSEH7tvpZ2L0C12MsaWF4v s1LtoCK9IabjcheYGFkBuFCXViWD684ddPTcBZDL3ydQTI_cBdvgLvlMJbCXPlcEE2owexMtrj0U c_qfyBnWVr7PxbI9PZJOnDgVq9.0RYrIgZX8bhSNivyBRPchvl4rALgruVl0ki2wbDVaT6ZDTOMH NZrE38lbQyi1_rxn_skdc6eiQ_WPEQz9Yvy2SB8VuUFcumRdhWhoTEZvO4i3VfxUOqKiKhOrWFCX cv_bTdnUaonw8S0eIwg8L59LFo.cWg3WO5WM7oF7S7p4D.01xkpoETmTo3gI4GVDZ.tKK2pKR29t t3Nkb1yDyfM1V9Ag8jPgKjywAKbenyl2a_efMQIe7FoV3Fk0mqgA6hH.sAP4PVhXvxN7XF_BrwbY q17X0OVqBRBUji_J0.m2aGA9rRS1JTJbr.TAPG9eRSjBxshOWCQoXC.A0_qXycYXaiNXZmlbcEZM vvXNM.aCuWnrJrPuskFnC.MHEts20.st4eV2O4Obqh8.Z8PdVjrdmia_NPyw9SXvVcJNOCHuRRsc 6JgHFhUE_C7cqd8t.mij80xXnwMAbaxor1X0i.ZFghlHDg5zgvATOteyIs0kRp_xCyejwKeUnG7U B_BT7hk1b0nG7jbRy1SJnN269Bn7UjEQ_urA3AtjPfTkYXbDNrTthBF.tXtuzzYnQ96j.nDTG2nr ksS.E5IPHdTu5PtPuA6ofwJUoHY4oqOG1rP_72yaiCzhXQZ8B21NHgDI_SkBDjwMJLz.PuLyHNEk skRADvS9H3NtQYqQ2qFoR15EB3_sF9bhoiJblIZ3a10dSC3PsX6W6IvPJfOAopf0vdFCRgSTAWHu 6ogK3rowlVQyYqbWisSzmN0OhpppHobH9Ykc7r8op4jZU3dcFuIMBYM1210jLbMX6TmrHxcxWLOD clcy3_33OS8Qho7Z0x3boN9yq0G5YrBl1JEROUh6h7PGYogpgj99f9Uzn8jgp9v5dIQF1KQyCcba tCXEhAzhf0373npJ.8nUC11wcdz0n99teac05U6bClTVLCZNJ2TJg2wvUMxqonTrh_1uZpFIpPTs GA6QzBhpr3OZCzVTStBpGqoFt5I9bCajBTA7lAA18Plw.fJtvlmPtS50YV.NKviqH9OsxYA77qzC cFmvD.7LC166ZgYzwxYi9W79iPlAgmVlUvqFexKxQA8ICgaxuhKAcOvTZ_CKV.A3Qhjtfkkt_mvA IE9T6.vHAtV2rqBX9KXOvZkhporPV5oDjJ6PTgAI_jiVhYxQgLKCldIivuCmWdKL2j7pCA.VHIs4 i34HKo7e9v6_G_.Kx3q1gDwmDryMH4a_KHmmsk2uNqFgXIsSN9W87IWRBArWccptMvLGGdQdiH2E BmiMHGyl5_6xuL2Fqiyz1_sAUY0W2g9NEjpw5N3B0K09QvIX_FniY6EZx.uD0MCUJrKORuC4o360 5r8pgiAYbAKpr91TliGudAffPkfb88hboe__fJP0mZ2rI5g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Nov 2021 08:43:14 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3d7e4f650e22930b114022d53702e6ba; Tue, 23 Nov 2021 08:43:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Tue, 23 Nov 2021 00:43:11 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <52F86CFA-7189-4AB6-BFB8-BFAB7EDBAFC0@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HyyMt2lCHz4kPb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tKaxyNgT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; 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] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-21, at 07:50, Mark Millard wrote: > On 2021-Nov-20, at 11:54, Mark Millard wrote: >=20 >> On 2021-Nov-19, at 22:20, Mark Millard wrote: >>=20 >>> On 2021-Nov-18, at 12:15, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>>>=20 >>>>>>> On 2021-Nov-15, at 12:51, Mark Millard = wrote: >>>>>>>=20 >>>>>>>> On 2021-Nov-15, at 11:31, Mark Millard = wrote: >>>>>>>>=20 >>>>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>>>=20 >>>>>>>>> # uname -apKU >>>>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>>>> 1400040 1400040 >>>>>>>>>=20 >>>>>>>>> to: >>>>>>>>>=20 >>>>>>>>> # uname -apKU >>>>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>>>=20 >>>>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>>>> a general update of /usr/ports/ were on 2021-10-23 before = either of the >>>>>>>>> above. >>>>>>>>>=20 >>>>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>>>> example: >>>>>>>>>=20 >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>>>> =20 >>>>>>>>> ^ >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>>>> >>>>>>>>> ^ >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>>>> =20 >>>>>>>>> ^ =20 >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>>>> >>>>>>>>> ^ >>>>>>>>> . . . >>>>>>>>>=20 >>>>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>>>> on it. >>>>>>>>>=20 >>>>>>>>> This was from a use of: >>>>>>>>>=20 >>>>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>>>> Jail name: 13_0R-CA7 >>>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>>> Jail arch: arm.armv7 >>>>>>>>> Jail method: null >>>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>>>> Jail fs: =20 >>>>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>>>> Jail pkgbase: disabled >>>>>>>>>=20 >>>>>>>>> but another not-investigated example was from: >>>>>>>>>=20 >>>>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>>>> Jail name: 13_0R-CA72 >>>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>>> Jail arch: arm64.aarch64 >>>>>>>>> Jail method: null >>>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>>>> Jail fs: =20 >>>>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>>>> Jail pkgbase: disabled >>>>>>>>>=20 >>>>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>>>> was in a different port (autoconfig, noticed by the >>>>>>>>> build of automake failing via config reporting >>>>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>>>> being rejected). >>>>>>>>>=20 >>>>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>>>> system versions. >>>>>>>>>=20 >>>>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>>>> used in order to have bectl, not redundancy. >>>>>>>>>=20 >>>>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>>>> evidence of such problems based on the updated system. (Also >>>>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>>>=20 >>>>>>>> For aarch64 targeting aarch64 there was also this >>>>>>>> explicit corruption notice during the poudriere(-devel) >>>>>>>> bulk build: >>>>>>>>=20 >>>>>>>> . . . >>>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>>>=20 >>>>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>>>> *** Error code 1 >>>>>>>> Stop. >>>>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>>>=20 >>>>>>>> I'm not yet to the point of retrying after removing >>>>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>>>=20 >>>>>>>=20 >>>>>>> Another context with my prior general update of /usr/ports/ >>>>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>>>> lots more I/O. >>>>>>>=20 >>>>>>=20 >>>>>> None of the 3 corruptions repeated during bulk builds that >>>>>> retried the builds that generated the files. All of the >>>>>> ports that failed by hitting the corruptions in what they >>>>>> depended on, built fine in teh retries. >>>>>>=20 >>>>>> For reference: >>>>>>=20 >>>>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>>>> those showed evidence of file corruptions. In general I've >>>>>> not had previous file corruptions with this system. (There >>>>>> was a little more than 245 GiBytes swap, which covered the >>>>>> tmpfs needs when they were large.) >>>>>=20 >>>>>=20 >>>>> I set up a contrasting test context and got no evidence of >>>>> corruptions in that context. (Note: the 3 bulk builds >>>>> total to around 24 hrs of activity for the 3 examples >>>>> of 460+ ports building.) So, for the Cortex-A72 system, >>>>=20 >>>> I set up a UFS on Optane (U.2 via M.2 adapter) context and >>>> also got no evidence of corruptions in that context (same >>>> hardware and a copy of the USB3 SSD based system). The >>>> sequence of 3 bulks took somewhat over 18 hrs using the >>>> Optane. >>>>=20 >>>>> root on UFS on portable USB3 SSD: no evidence of corruptions >>>> Also: >>>> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>>>> vs.: >>>>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>>>=20 >>>>> Both had USE_TMPFS=3D"data" in use. The same system build >>>>> had been installed and booted for both tests. >>>>>=20 >>>>> The evidence of corruptions is rare enough for this not to >>>>> be determinative, but it is suggestive. >>>>>=20 >>>>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>>>> not differentiated by this test result. >>>>>=20 >>>>> There is also the result that I've not seen evidence of >>>>> corruptions on the ThreadRipper 1950 X (amd64) system. >>>>> Again, not determinative, but suggestive, given how rare >>>>> the corruptions seem to be. >>>>=20 >>>> So far the only things unique to the observed corruptions are: >>>>=20 >>>> root on ZFS context (vs. root on UFS) >>>> and: >>>> Optane in a PCIe slot (but no contrasting ZFS case tested) >>>>=20 >>>> The PCIe slot does not seem to me to be likely to be contributing. >>>> So this seem to be suggestive of a ZFS problem. >>>>=20 >>>> A contributing point might be that the main [so: 14] system was >>>> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>>>=20 >>>> [I previously ran into a USB subsystem mishandling of keeping >>>> things coherent for the week memory ordering in this sort of >>>> context. That issue was fixed. But back then I was lucky enough >>>> to be able to demonstrate fails vs. works by adding an >>>> appropriate instruction to FreeBSD in a few specific places >>>> (more than necessary as it turned out). Someone else determined >>>> where the actual mishandling was that covered all required >>>> places. My generating that much information in this context >>>> seems unlikely.] >>>=20 >>>=20 >>> I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media >>> and it got its first corruption (in a different place, 2nd bulk >>> build this time). The use of the corrupted file reports: >>>=20 >>> configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl >>> ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 >>> In file included from conftest.c:27: >>> In file included from /usr/local/include/ogg/ogg.h:24: >>> In file included from /usr/local/include/ogg/os_types.h:154: >>> /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> . . . >>> /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] >>> . . . (nulls) . . . >>>=20 >>> So: 538 such null bytes. >>>=20 >>> Thus, another example of something like a page of nulls being >>> written out when ZFS is in use. >>>=20 >>> audio/gstreamer1-plugins-ogg also failed via referencing the file >>> during its build. >>>=20 >>> (The bulk run is still going and there is one more bulk run to go.) >>>=20 >>=20 >> Well, 528 happened to be the size of config_types.h --and of >> config_types.h from a build that did not get the corruption there. >>=20 >> So looking at the other (later) corruption, which was a bigger file >> (looking via bulk -i and installing what contained the file but >> looking from outside the jail): >>=20 >> # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; >> -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 >> lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 >> lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 >>=20 >> hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more >> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 0023b120 >>=20 >> So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. >>=20 >> To cross check on live system caching vs. on disk, I rebooted and = redid the >> bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : >> still all zeros. >>=20 >> For reference, zpool scrub afterward resulted in: >>=20 >> # zpool status >> pool: zopt0 >> state: ONLINE >> scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> zopt0 ONLINE 0 0 0 >> nda1p3 ONLINE 0 0 0 >>=20 >> But it is not a ZFS redundancy context: ZFS used just to use bectl . >=20 > Using bectl (on the root-on-ZFS Optane in PCIe slot), > I booted stable/13 : >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 >=20 > and tried the sequence of 3 bulk runs: >=20 > There was no evidence of corruptions, suggesting that > the Optane in the PCIe slot is not the source of the > problem of having some file(s) end up with all bytes > being null bytes. >=20 > So, overall, ending up with evidence of corruptions > generated during bulk builds seem to be tied to main's > [so: 14's] ZFS implementation in: >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 > 1400040 1400040 >=20 > because that is all that is unique to having the > evidence of corruptions. >=20 > Since there have been ZFS updates in main since then, it > seems that the next experiment would be to update main > and try again under main. Given that the issue seems to be a ZFS issue, I updated to: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #21 = main-n250903-06bd74e1e39c-dirty: Mon Nov 22 04:15:08 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 (which involved updating some ZFS material). I ran the sequence of 3 bulk's again: no evidence of corruptions. For reference: The bulks targeting Cortex-A72 and Cortex-A53 each took somewhat under 10 minutes more than the earlier stable/13 and main [so: 14] builds that otherwise matched (including the Optane used), for bulks that each took somewhat over 6 hr either way. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 23 13:47: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 09E0818A66FE for ; Tue, 23 Nov 2021 13:47:07 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4Hz56K600Cz3rkm for ; Tue, 23 Nov 2021 13:47:05 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 1ANDl4T8083212 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 23 Nov 2021 07:47:04 -0600 (CST) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 1ANDl4Nd083211; Tue, 23 Nov 2021 07:47:04 -0600 (CST) (envelope-from mike) Message-Id: <202111231347.1ANDl4Nd083211@mail.karels.net> To: MJ cc: freebsd-arm@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-reply-to: Your message of Tue, 23 Nov 2021 16:44:21 +1100. <94d868fb-3646-598f-fdea-7d4c61bae4c1@gmail.com> 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="us-ascii" Content-ID: <83209.1637675224.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2021 07:47:04 -0600 X-Rspamd-Queue-Id: 4Hz56K600Cz3rkm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.67 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[karels.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.969]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Matt wrote: > On 23/11/2021 1:42 pm, Juan David Hurtado G wrote: > > Hi, I'm trying to use the OS on a Raspberry pi 3 B+ > > = > > Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for som= e > > minutes before showing the `login:` to enter the username. When I ente= r it, > > it takes a few seconds to ask for the password. > I had similar experiences. Do you have any USB devices attached? > One thing to watch for is any mounting of USB drives. I also had problem= s with certain cables connecting USB drives to the Pi but when I placed th= em on a powered hub they were fine (not slow to mount). As a reference, ru= nning devuan I had no issues. > If you have USB drives attached, try this: place hw.usb.no_boot_wait=3D"= 1" in /boot/loader.conf > > = > > While doing `freebsd-update fetch install` it took a plenty of minutes= , so > > I canceled the process and then did `freebsd-update fetch` and then > > `freebsd-update install` to see what was going on. > > = > > Found that the process was at `wdraid` state. Doing a simple search, I > > found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to 2M= b. It > > seems to help, but not by much. Look at this: > > = > > freebsd@generic:~ % time freebsd-version -kru > > 13.0-RELEASE-p4 > > 13.0-RELEASE-p4 > > 13.0-RELEASE-p5 > > 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w > > = > > :( Another data point: on my RPi 3B+, I get this: rpi% time freebsd-version -kru 13.0-RELEASE-p4 13.0-RELEASE-p4 13.0-RELEASE-p5 0.372u 0.053s 0:01.34 31.3% 27+178k 28+0io 0pf+0w rpi% time freebsd-version -kru 13.0-RELEASE-p4 13.0-RELEASE-p4 13.0-RELEASE-p5 0.372u 0.047s 0:00.41 100.0% 27+174k 0+0io 0pf+0w So it's not a general problem. Mike > > What could I be missing? Maybe I need to tweak partitions and use some= kind > > of configuration/optimization? how? I do appreciate any guidance you c= an > > provide in order to troubleshoot this. > I've never tried this. Is this now possible because it's a Tier 1 archit= ecture? > Would not memory be a constraint here? You definitely wouldn't want to b= e using tmpfs system. > > = > > PS: I don't think it is the microsd card since it runs raspios fine. > > = > And usually they start exhibiting write issues beforehand if they're goi= ng to fail. > Have you looked in /var/log/messages to see if there's any help there? > Matt. From nobody Tue Nov 23 13:49:47 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 89C151889C3F for ; Tue, 23 Nov 2021 13:49:59 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hz59g3Fhwz3tWX for ; Tue, 23 Nov 2021 13:49:59 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x92a.google.com with SMTP id az37so43814334uab.13 for ; Tue, 23 Nov 2021 05:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yfA7SLap/0nSalEOERKJ1lchW4diucjy0NmAfYzztL4=; b=WjKFsC8+McNhmxK7d00Hqx4L+2UeuHH6urw2ta833fp4fbsMQNIslzKLe2ijhWELts kzDnfE3KL4GPvk9yV4CrrREczU8YnOoIMtUNouLpSSg4L+5r4MyOe8AwccAKirzGk3PW ONwWorTytX4UbpAcvtLtxiwesLlsZDJdkWvpHs0zvjAM+HIsBOUe3hE+k/fGIkmxgspB WkRh61lthrH1XG0oghbWFwnOfJMPltcx8zo+0FeGbcYGck5oWAJ036Zb/a0yYcoOkNDe 5bMCCBD3XYiJg8ywSiqFSQqI+M4QSBS+qv9uQoiokZytR4XDndrOSuDou0c/z8FylkCt SbkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yfA7SLap/0nSalEOERKJ1lchW4diucjy0NmAfYzztL4=; b=gRrFBetEos6aaAAJo8WofdRXV7mrF9Ptw5PlmnOmLCzrWCVtevwzNaU866xQvKS4le 7+iwNp6SyY0xh1V6qZWPyBNxKvufuGpHQ1jP8XV025KT8ztwQPStfXMqCJZuVQAD+XHF CST6hWwmOm9OPiOwlM0/4nXflsemhtFL31vKwEU71MP25ZzmFOfLXDpJ+hAXEUFRAEAy vGQGM72T2HZNPxvGtL/M3pTOaaCtokb6/Rys6Ju5bTD3+UT98okc2aC0PeTpTpAHLqjl yRw6P178EeKQtA0RQOtmubrLfeceGgVIX8KCjhTbERqEKfOInFd41X14DPD6MkSotUn+ XwFA== X-Gm-Message-State: AOAM532+9twV7NcZIAjvlP2hg0rgRoMj3wmTHBhHc3VmkAsZMUe2/ahF 7DSeZ97NT4E49f3fDEgwGysZJjL7PXMIe5LUbQ4qdtA6c1Mh X-Google-Smtp-Source: ABdhPJwANABFaVIsr3OD4zqx46nXs3Zz2RuF5wpdevRfj3WmJLHw3TrAMLjJorFUYagwji5ncUJ/moYN7Uop2wCW350= X-Received: by 2002:ab0:3b12:: with SMTP id n18mr9154251uaw.2.1637675398651; Tue, 23 Nov 2021 05:49:58 -0800 (PST) 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 References: <94d868fb-3646-598f-fdea-7d4c61bae4c1@gmail.com> In-Reply-To: <94d868fb-3646-598f-fdea-7d4c61bae4c1@gmail.com> From: Juan David Hurtado G Date: Tue, 23 Nov 2021 08:49:47 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: MJ Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000065040a05d175042a" X-Rspamd-Queue-Id: 4Hz59g3Fhwz3tWX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000065040a05d175042a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I had similar experiences. Do you have any USB devices attached? No USB devices attached. Only hdmi to see what was going on. > I've never tried this. Is this now possible because it's a Tier 1 architecture? Sure, system upgraded from 13.0 to 13.0-p5 (only supported on 13.x, not on 12.x) > Would not memory be a constraint here? I'm not sure, it never shows excessive memory consumption. Only what I'm mentioning about wdrain > And usually they start exhibiting write issues beforehand if they're going to fail. I'll try another microsd later and see what happens. But why does raspios not show this kind of behaviour? > Have you looked in /var/log/messages to see if there's any help there? Mmmm nothing I can find suspicious but let me post the message from a fresh install https://bsd.to/PJgm El mar, 23 nov 2021 a las 0:44, MJ () escribi=C3=B3: > > > On 23/11/2021 1:42 pm, Juan David Hurtado G wrote: > > Hi, I'm trying to use the OS on a Raspberry pi 3 B+ > > > > Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for some > > minutes before showing the `login:` to enter the username. When I enter > it, > > it takes a few seconds to ask for the password. > > > I had similar experiences. Do you have any USB devices attached? > One thing to watch for is any mounting of USB drives. I also had problems > with certain cables connecting USB drives to the Pi but when I placed the= m > on a powered hub they were fine (not slow to mount). As a reference, > running devuan I had no issues. > > If you have USB drives attached, try this: place hw.usb.no_boot_wait=3D"1= " > in /boot/loader.conf > > > > > While doing `freebsd-update fetch install` it took a plenty of minutes, > so > > I canceled the process and then did `freebsd-update fetch` and then > > `freebsd-update install` to see what was going on. > > > > Found that the process was at `wdraid` state. Doing a simple search, I > > found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to 2Mb= . > It > > seems to help, but not by much. Look at this: > > > > freebsd@generic:~ % time freebsd-version -kru > > 13.0-RELEASE-p4 > > 13.0-RELEASE-p4 > > 13.0-RELEASE-p5 > > 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w > > > > :( > > > > What could I be missing? Maybe I need to tweak partitions and use some > kind > > of configuration/optimization? how? I do appreciate any guidance you ca= n > > provide in order to troubleshoot this. > > I've never tried this. Is this now possible because it's a Tier 1 > architecture? > Would not memory be a constraint here? You definitely wouldn't want to be > using tmpfs system. > > > > > PS: I don't think it is the microsd card since it runs raspios fine. > > > > And usually they start exhibiting write issues beforehand if they're goin= g > to fail. > > Have you looked in /var/log/messages to see if there's any help there? > Matt. > > --=20 Juan David Hurtado G (+57) 319 252 3773 www.orbiware.com --00000000000065040a05d175042a-- From nobody Tue Nov 23 17:34:51 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 1715A18AF162 for ; Tue, 23 Nov 2021 17:35:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4HzB9t18JCz4cnK for ; Tue, 23 Nov 2021 17:35:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 46A904E6D9; Tue, 23 Nov 2021 17:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1637688892; bh=6zN7UVek+MyEluyD7oyJuztliNMnTh2tXxHzs0+EiJo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lGNNTcuiwmNp6ffGo6SVke643vBxlHtX1hrqNTUMJ+MvdxC0ZqNjZCYJi/rXXLHv4 uKq8NTpphyIUp9Vgv/AZK2i0w8hbybooEpPHs8imuhbZYK8zJxW8ENbMs0WrqafWMT te2L79pSu1DykAotEK3AKZ48q8wBkUDPclUkeka+JvQRKdOgIFEZF2t/Z/69jcvwtn U1VHfS9dSPudKGDR6LZu4lDXQUc9aoFCENS+lr+C0qCzOZ4guPiC71FMs+m1b96jZ6 0BKhhHwXb6XckX9lfGeALhVdaLQWSKvOmkRxr/zV5NI+xRdX0JopIIV5sRbk8Ey9JU bBdTIF9ByylZqY+FzjHFPpxJXlN3VXfffdQKawIGlL3FqG8Ec2vWZKOqxkW5tgkeXT ZGtVldx7uPsvH/hPZEsxcVpBj9Msl3sXoE+9S5DCx93SLkv1fbRGag3+dsQm5VglOu mXSx+4t8jIZ3QhdPGS7bCuEVxd+fyxPW4VtN9DdwxRqPOc/iP0ZTFL9SFw0sN/J9+v rM35KLe0ccLFB/qlOOmFalA5EUsWAF7loQJ6/FsUq22Aui7bh3aI6n6QbMrXsVPRzx YUHiX9nhkCwBRZOyjCS+AR8rumGDtEfz6HQeJmOb1eaEgFrnc2s73mI+GwYDxXKf6V LjD0hAna0eq5RivblahJ74RE= 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 12.4 \(3445.104.21\)) Subject: Re: 14-CURRENT Kernel Panic due to USB hub? From: Andrew Turner In-Reply-To: <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> Date: Tue, 23 Nov 2021 17:34:51 +0000 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> To: daniel@morante.net X-Mailer: Apple Mail (2.3445.104.21) X-Rspamd-Queue-Id: 4HzB9t18JCz4cnK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=lGNNTcui; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-2.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Can you create a bug for this in bugzilla so we can keep track of it? Andrew > On 21 Nov 2021, at 07:18, Daniel Morante via freebsd-arm = wrote: >=20 > Here's the bt: >=20 > ugen0.2: at usbus0 (disconnected) > uhub5: at uhub0, port 1, addr 1 (disconnected) > uhub5: detached > ugen0.2: at usbus0 > uhub5 numa-domain 0 on uhub0 > uhub5: on usbus0 > uhub5: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub5: at uhub0, port 1, addr 1 (disconnected) > uhub5: detached > panic: data abort with spinlock held > cpuid =3D 108 > time =3D 1637478997 > KDB: stack backtrace: > db_trace_self() at db_trace_self > KDB: enter: panic > [ thread pid 11 tid 100111 ] > Stopped at kdb_enter+0x44: undefined f901411f > db> bt > Tracing pid 11 tid 100111 td 0xffffa00005619580 > db_trace_self() at db_trace_self > db> >=20 > On 11/12/2021 5:52 AM, Hans Petter Selasky wrote: >> On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote: >>> ugen0.2: at usbus0 (disconnected) >>> uhub5: at uhub0, port 1, addr 1 (disconnected) >>> uhub5: detached >>> ugen0.2: at usbus0 >>> uhub5 numa-domain 0 on uhub0 >>> uhub5: on usbus0 >>> uhub5: 4 ports with 4 removable, self powered >>>=20 >>> I suspect these problems are caused by the above = detaching/reattaching. >>=20 >> Can you type "bt" in the panic prompt? >>=20 >> --HPS >>=20 From nobody Tue Nov 23 19:38: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 B8B2718A1894 for ; Tue, 23 Nov 2021 19:38:38 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzDvy3bVQz3pMP for ; Tue, 23 Nov 2021 19:38:38 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x931.google.com with SMTP id a14so238056uak.0 for ; Tue, 23 Nov 2021 11:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JwyXFVj9Jtqxhkc/1WnVgPyTBuHTr/Y0srdLE+XmBAg=; b=Du10mQHgs01kXOYJ9Bp1FXBgWLAg4IHhuHnqoijnMP09YqG3iDW9mkSwtLofgxuSmB uv1jTjPXUEDInX5NJmBQCT1XNY38dXRKlQXmpgCmgHCAJscj3TpuGQpg3RTGx/Ky1WxL eotQeuLGFa+eZppmYXm1PJjLOJaELl/BSkvM9lC2ravVheJ6HaSTUkqwJdbzknAdb4Vy D9yT2jqnAcDimYApGtw89k2l7tktSBgiLt1PjEJ+y7ejuNYUvPUppa27/DuTpc00l/Wd QosbmMcIK7LfhjPkdoyD9UipkxQZt2LjqjuJxU9bN91bjo8Kglq+xAem7Lezwr3zHD9A BA6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JwyXFVj9Jtqxhkc/1WnVgPyTBuHTr/Y0srdLE+XmBAg=; b=l4uqtUrl/d7nSLK5NOewduy2EAPN9Q2JESClx0LlBAO3Tw008sfbPjnU3zrnKKEgQi WUEglJUu7gPuUErAhcSINGdqSJCkdHciWaHMGC57T/JawldmpwY+5pEG6ANaIPBXR5NV EDMfNc2syDp96OlzdgGNVaqYwplBSZfLneElF/8VtFmwVUNyRKd22tfSCzqHbmPtwKCX F1zd6k9dWY4+EoeM0ZffszdPAxR14v6lIGabYvtsgWAOko1k+UEr6/Uu+I/en12PTwV7 6XYTJVcffAwnnVXCmbl3ixv3yXmEJCD6LtUxyw2ZKg0e5t2qyx9EzOHRMPZan0QxkZhE MUtQ== X-Gm-Message-State: AOAM531GfFm8+YNF4JssL8rzKfInBLcZ0tuQ/a4u4t4LN9+622dY+dN8 slgVICcaUwXspBDP/W7T7NGwiX7XVqCC3uayQ/wd X-Google-Smtp-Source: ABdhPJzm3xid8+YA496gpabo4hEkpCeFgzu1rm+ZWCrsivuDpgIu+9N8b9RgnkpLqBaSBKxo5Qxm7oR0pmnlylklgNI= X-Received: by 2002:ab0:3b12:: with SMTP id n18mr12118662uaw.2.1637696315668; Tue, 23 Nov 2021 11:38:35 -0800 (PST) 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 References: <94d868fb-3646-598f-fdea-7d4c61bae4c1@gmail.com> <202111231347.1ANDl4Nd083211@mail.karels.net> In-Reply-To: <202111231347.1ANDl4Nd083211@mail.karels.net> From: Juan David Hurtado G Date: Tue, 23 Nov 2021 14:38:24 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: mike@karels.net Cc: MJ , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000272b7a05d179e31c" X-Rspamd-Queue-Id: 4HzDvy3bVQz3pMP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000272b7a05d179e31c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > So it's not a general problem. Hi Mike, I have tried with another raspberry and with another micro sd (class 10) and in another location and same behaviour: It takes hours to do a `freebsd-update fetch`. After tweaking vfs.hirunningspace it seems to help a little but the system still feels laggy. That's with a fresh install, no extra services or apps. El mar, 23 nov 2021 a las 8:47, Mike Karels () escribi=C3= =B3: > Matt wrote: > > On 23/11/2021 1:42 pm, Juan David Hurtado G wrote: > > > Hi, I'm trying to use the OS on a Raspberry pi 3 B+ > > > > > > Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for so= me > > > minutes before showing the `login:` to enter the username. When I > enter it, > > > it takes a few seconds to ask for the password. > > > > I had similar experiences. Do you have any USB devices attached? > > One thing to watch for is any mounting of USB drives. I also had > problems with certain cables connecting USB drives to the Pi but when I > placed them on a powered hub they were fine (not slow to mount). As a > reference, running devuan I had no issues. > > > If you have USB drives attached, try this: place hw.usb.no_boot_wait=3D= "1" > in /boot/loader.conf > > > > > > > While doing `freebsd-update fetch install` it took a plenty of > minutes, so > > > I canceled the process and then did `freebsd-update fetch` and then > > > `freebsd-update install` to see what was going on. > > > > > > Found that the process was at `wdraid` state. Doing a simple search, = I > > > found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to > 2Mb. It > > > seems to help, but not by much. Look at this: > > > > > > freebsd@generic:~ % time freebsd-version -kru > > > 13.0-RELEASE-p4 > > > 13.0-RELEASE-p4 > > > 13.0-RELEASE-p5 > > > 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w > > > > > > :( > > Another data point: on my RPi 3B+, I get this: > > rpi% time freebsd-version -kru > 13.0-RELEASE-p4 > 13.0-RELEASE-p4 > 13.0-RELEASE-p5 > 0.372u 0.053s 0:01.34 31.3% 27+178k 28+0io 0pf+0w > rpi% time freebsd-version -kru > 13.0-RELEASE-p4 > 13.0-RELEASE-p4 > 13.0-RELEASE-p5 > 0.372u 0.047s 0:00.41 100.0% 27+174k 0+0io 0pf+0w > > So it's not a general problem. > > Mike > > > > What could I be missing? Maybe I need to tweak partitions and use som= e > kind > > > of configuration/optimization? how? I do appreciate any guidance you > can > > > provide in order to troubleshoot this. > > > I've never tried this. Is this now possible because it's a Tier 1 > architecture? > > Would not memory be a constraint here? You definitely wouldn't want to > be using tmpfs system. > > > > > > > PS: I don't think it is the microsd card since it runs raspios fine. > > > > > > And usually they start exhibiting write issues beforehand if they're > going to fail. > > > Have you looked in /var/log/messages to see if there's any help there? > > Matt. > > --=20 Juan David Hurtado G (+57) 319 252 3773 www.orbiware.com --000000000000272b7a05d179e31c-- From nobody Wed Nov 24 09:51:52 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 EFC2018A3FC6 for ; Wed, 24 Nov 2021 09:52: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 4Hzbrj6wkvz4tpj for ; Wed, 24 Nov 2021 09:52:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637747525; bh=bCGOc/atqdaplKG5LVe0cUoT6S6RhyRRjKS0H9RNbpE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=RCqx7aFuoIaIKyfehI8vF3CDVwh59TJaz2DaIdzi1dv+sNWlPzKSWUjtg8c//3Hcse3aQQBAyjfqQ2D6nye4h0cKmK67HOAvuvdKQ33SbSkzKgfhcjNwAAiqNkNoGyBBA9FFPeQ3jTPpsUfiQG3nSlY4BDmkkdjZMDXxt2EAYS4L5qUR9iXLBZk0LhM2d5dLgZDPA+Ora5bPF4WqJCGXN7q4ep+MBNahOFdNS6ImKwHI7sSO6zUVXLWfdMKt3UpSp2GOpeMzdy5v5/bz3pNWLwD43BQLwQdg8thkTrPxRZBD4d2O/LLE83xDPFDtLvwzQr0W7pZQMUJnV787x6Pstg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637747525; bh=s1fUl75MfpqU1ia484CPbW4r+Ph/zVhZ/MNx22hJg/j=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NlAjWa/wIqwML9CeqVSVPvpTBZQbws1uKzjzkJUkuDB1JeUwMDwORRbVEOOO6Jzd7SNblVlsROcjS0FTWL3YiedDApiwyxatNm7zToeBIauhbP0QvMPmKB0uUB48baYmi0UpjNew5Tv7udlY8Nd27fQv1315eZ8UvwDiO/n9gHsRSTnIASA6gqmsxVgoQCcr6F1YOvxWwtqd6rFOYKIywTN0yVtDVULW5LIutU6muqEoUUZUUHKA6xypa295afVWd3+6S0MVo5zFC7hK1I5/btQf9CIQRco3+CjEIEXLQIiF+fCRy6JWTU9XJpSHjnA0haIIj/Bf/QaXcjxorLMMYA== X-YMail-OSG: pAfA6bMVM1mMkJmKX7Sg0EBbyDz1HgyiT7C6Pip_G5vq070_ZW43ovJEyYuLyvr UxCLnBuib6Upy4XqbrcShwlJkpld_zLg0XyxbkWbBdlKwr4x2Vvg8Ypr3jKVHRan8HMo4KiM8tBu IYqe5_DcNlBjn1_1jMeKWLBIH8vzqkzZbBWqErgCBOoWvGH6KjrFljZGwwyrTkSFhOf61Vlh4fAQ Wk83luStPpRfUDkGtEtFbgSnBQfTKyRmNJpXBEnNdyJo27X9PcaVJCvZ6doaieiRk8UNbP0oqrkk zohqk8yzIiRdMWcnkN1yx9zaaxFWgBgN6cUC0_pQ4RvCHLHPFp8o6SYlq.gzvE8m7N117U0sTjgN bKf3QD7LgeRnCKRYhU8cL1gphnqx91P9E7oBdJ04vKhtoxleb6oTsXWpsyz.rQE7VE05KREaT_BM c.WQIya2u2KzTRZ84zRyF8SRjYlDZ0kfj1mr3XJ3aEzkwXhGHmRmI8XWAihV.AfdLhU.hFb3il9U _vX7QIdC4WtDooA7v7CCD1P_zCHVnzXEogmIxzhw4frlJMpdOHgVkeho_3Hl8PEOI2RNc9uE_dIX 0YIg06CoDNf_sYbuvMQa9sL7XSUrOLC0wDlzWL0PGiYUGDgEoMI.ib._IiSMO38y2mRKcmB83.5m QziWAnBAbEXy.Dzmzzycvwreuajl1yBuYDYjzFMqxjvyefEP7BQKfYqS3zpqA0oad.s9qeZIhGwm 1Xrogh1F7KlHyY6gJINmvI1FutFd8JlnqOJHgDU0G2iLes0hHmO5tniAzHaydN6Io.axEhEKwK_4 72K4ovpQklsQDBTquPU2ZV7BLgG3Dj1.GTZwCnhoU_d2AK4ZN895yYPol1Ac46ZmOJp_22Y6Qlam eaj9Acj4Gc7ZGOAd1LTMM57y5OeswY7VQY.ILPcoA3NOdcfO7m8RUCpGUcpGQgNEjWQR5J97trxd xnKoRq1PWttVv1BUTXnvKc4N_MSKOxYWzo7eJx.bCw5DW2VpShN1hWivoKy5H3J2qweV2lj5UbZr IbEHVWx0ZR2j5s8kpG1_hJklrA0LhwBm0WVvB1oPEw.RjRTF2BX0CCJNbGS0pW6os6FBpfM8R9em S3FeIJXD1ROtIcx_TwDpbZVNRIUVwxhF.z7cfWiyDwBm0HO7DeEKybGYjBCRmtEKvc97b_UBHOwm kVdsYlgPFWV0NAnB1FZXhUpHkR9BD9iAaozCPiYKJ6vgAWjPEEU34iO.4m8XT_YUfGeAnHgR0PXY A1EYzEVLgntSXJwHESqb9uF2JqEhOsq2HIpaoSJ8FGyLzSEthxPdIntBdgsJ7gMNJNd0Zr4QYUfB bUewyHyFKTvIJ8QkqAgbCMBKLq4jN4P9bVx6HI9kbYoFfc8RhNdhhteiIoFHkDU6jMjY4O.bkSvs wL.ml3b0jafoekZLK3oBVfcARMbRydFRbIK2Lh8lrZwBf3mQ9q2Rk1lkVKzlpfv_fXmx4_gnwLho zhXmuTtTaQ_G_fuoOyEupTOes3puYnS8jQHLK1oAAMJn9mK51EaU897nwNhKBie8fX5mgadbXlUV iU_jHrHH.q1qUHDSY1lP9PlaEm9bhMJYd1iQ5AcsQQ9N3RIP0AeXstxLdkDS6Y9hDmAPZrxGCC90 kUK0iFe3AofnegHEr.s7ehpnWdEwTNPYbf4DABro.UvMpttT4BSgXjTB6FAo4DPBrzCal7U3hAmd I3lGLm4a2BWugz_nqYnt9_Lrd5BAWuO_LstKGgbughNNUTLw4ASu8fTGwzAY5l0WKzBL.wTNw2iU hugH44_nd.1RIH.lcDlIehSCWnJuYauIwv7ibmKtvl2eXYQ9qkDIfWKwH_8oCBymGzrVcTKipw6o 7KgC1YaM_SkZxiBKl.Aj4fdZqBtUNuEW1DDzvVUlAZ6.q0b_XCZc6OPAxEdA67g9Jkje1npG3JXc LPAN4dOFoIH5eawBFijTW_DQLh.o_8YiWQFymM7hdl6UEShYUaswEr2m6tYm8KARhTRprwao13v1 Rm2BW..xtRDgr48uQuUUxe7364aKyOmS5vSzG_DqJ3Yg5rB85AIOv5LVGmmPwFkPJxWJuo0355rt qronfYNwqDk0AWkW4Bv_xT2H87_L0Ecy2muyzO37SN5U3adnVbXhJmFgqUDbjktb6xB_bvgyG.x1 o0tTg3_EnsDvf1z1xAXfFmQ_9V.10nm0WPUxpSx3lyk0F5nr.0lLsO4.kxuD.YnLyIDFMYflmqgX Dinw5PPXriOkEZFUWI3rC9y7QRwbTajTQauAFCctocn3v X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Nov 2021 09:52:05 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 945cd50141304a5dd0050a915999ffd3; Wed, 24 Nov 2021 09:51:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: git: 32a2fed6e71f - stable/13 - openssl: Fix detection of ARMv7 and ARM64 CPU features Message-Id: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> Date: Wed, 24 Nov 2021 01:51:52 -0800 To: allanjude@freebsd.org, "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22.ref@yahoo.com> X-Rspamd-Queue-Id: 4Hzbrj6wkvz4tpj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RCqx7aFu; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.61 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.851]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [Actually, the main [so: 14] equivalent.] All Cortex-A72 based . . . First, older system versions (before that update) then after the update: RPi4B 8 GiByte (older FreeBSD first, otherwise new), Cortex-A72's: # openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 51925.92k 58449.46k 60430.32k 61050.13k = 61180.98k 61482.75k type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 28880.07k 30837.33k 31630.29k 31855.62k = 31921.54k 32034.53k So: slowed down, unlike the other examples below. # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 51894.33k 58540.45k 60815.22k 61534.47k = 61906.84k 62042.10k So: back to the prior speed. But all these are based on config.txt containing: over_voltage=3D6=20 arm_freq=3D2000=20 sdram_freq_min=3D3200=20 force_turbo=3D1 (The RPi4B has a heat-sink and a fan.) Note: See later about the RPi4B CPU features. MACCHIATObin Double Shot (older first), Cortex-A72's: # openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 50808.49k 58466.08k 60769.11k 61444.92k = 61767.94k 61707.61k type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 163579.14k 456319.27k 786544.01k 940234.41k = 1003230.55k 1005671.31k HoneyComb (older first), Cortex-A782's: # openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 57659.60k 64599.05k 67719.81k 68373.74k = 68724.24k 68793.80k type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 177925.57k 502311.65k 866287.95k 1036500.35k = 1106598.06k 1106721.91k Rock64 (older first), Cortex-A53's: # openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 18378.23k 23401.45k 24834.99k 25206.10k = 25337.86k 25258.19k type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 52711.29k 163586.49k 318738.69k 420277.93k = 461373.44k 463192.06k OPi+2E (older first), Cortex-A7's (so armv7): # openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 9343.10k 11156.39k 11827.64k 11995.30k = 12025.86k 12031.32k type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 11013.41k 13598.44k 14034.26k 15045.97k = 15262.90k 15302.66k For reference: For the RPi4B examples (2 notes added): CPU 0: ARM Cortex-A72 r0p3 affinity: 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D *** NOTE the lack of ",SHA2,SHA1,AES+PMULL" above *** Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D *** NOTE the lack of ",SHA2,SHA1,AES+VMULL" above *** AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D For the MACCHIATObin Double Shot examples: CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D For the HoneyComb examples: CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D For the Rock64 examples: CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D C For the OPi+2E examples: CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features:=20 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, PXN, LPAE, Coherent Walk Optional instructions:=20 SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2=20 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 24 12:29:41 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 98E1218AAEB7 for ; Wed, 24 Nov 2021 12:29:53 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzgLm3xMzz4tnT for ; Wed, 24 Nov 2021 12:29:52 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x935.google.com with SMTP id j14so4648219uan.10 for ; Wed, 24 Nov 2021 04:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/sIyvZCy3Hpdxc1CQL9W/nitdbihfxScM5V+FES1xWA=; b=OkZP+DnjcmiXQHyQqoLzwym00Kgto5MaZ2hxyoHfGkHp30SJKeDKDmhFt7ttiNYWdw hHGJpoVldeplrUZy4NffiujNiMaSxcG4i/5MThI4gXTW31BWi6jPOGB9BD4a/hmyR1x/ nv2sBwOIN5E6ZRiN0SCiZhweWh4zCevGlLEH9OGiOLynGy9Fwp4J/NKezId0pcKOwJTo W/ZkFBpLjtpPEL2GqHXMxYGIctvlXgVwMGb5MvRcsoIB7xKa4GC6Ud/oDX6lTRxc28D8 bJwnvfJC0dl0fY8CH7+qRa0qFMGiF/a/diqIChwU/zFaJsDByfyVuIwOG3e5G0ATsFdT Q2yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/sIyvZCy3Hpdxc1CQL9W/nitdbihfxScM5V+FES1xWA=; b=MmFq9X/Ci0pQRVIH7/u7e63+ea/ZjQsGXFc7gMOn0tHdryQlw3ZTI5m9rrF4fzQYro VhW2pjpgTXcKpu29HrP0s9SXE4WcadL3QPscJG3MeNXlL7TLqn/Z1MlrgH3eUgefnsfp eAUmtPJzjtPZwf5ys6kYBDZe84WlfIRKF3QVSzcwLW+Bn9ZlfdCGqDF71mICyVNoCJSV usIZPbyPReto/Rx7/cW7u+kWuANh0CSThkcql9OTKGIoTXUe5cDFTaxXeLLY7ESS6+ss t75y2Ak6UaxOkUwToyL669ECOOQ2JTYC+7lJSthEaLY0luhW2SsHI/OlypDcE7ip/4dG Qysg== X-Gm-Message-State: AOAM533yg2VyULUps+62Z4QtFmXAq9nFKzgAk88bO2WdFrCZ4hVFfyFT emDl8bQ7BlL20BEnP9+TRizb9XBNc/nl6OadN9wN717gBw== X-Google-Smtp-Source: ABdhPJxnhB6wNcL4rLF7ZRpOD8QPFYvhV5yf4uHT4aXXLo2xSfZBsBPvmjhTq+F2c008bVA76hjeNEmJVAiC13cBzfI= X-Received: by 2002:a67:e0d6:: with SMTP id m22mr23025340vsl.15.1637756991894; Wed, 24 Nov 2021 04:29:51 -0800 (PST) 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 From: Juan David Hurtado G Date: Wed, 24 Nov 2021 07:29:41 -0500 Message-ID: Subject: What is the best supported SoC by FreeBSD? To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000bb0f6905d188036e" X-Rspamd-Queue-Id: 4HzgLm3xMzz4tnT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=orbiware.com header.s=google header.b=OkZP+Dnj; dmarc=pass (policy=none) header.from=orbiware.com; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::935 is neither permitted nor denied by domain of jdhurtado@orbiware.com) smtp.mailfrom=jdhurtado@orbiware.com X-Spamd-Result: default: False [-1.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.895]; R_DKIM_ALLOW(-0.20)[orbiware.com:s=google]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[orbiware.com:+]; DMARC_POLICY_ALLOW(0.00)[orbiware.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::935:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; NEURAL_SPAM_LONG(0.32)[0.318]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000bb0f6905d188036e Content-Type: text/plain; charset="UTF-8" Hi, I'm working with a raspberry pi for a project. I've been using raspios for two years. But recently it has become pretty unstable for our use case (mainly because systemd). Device will host influxdb + nginx + grafana I'm using FreeBSD on my main workstation and on some servers and I really like all the features so that's why I'm looking to use FreeBSD here too. Few days ago I'm testing FreeBSD on different raspberries but I'm getting a laggy system in all of them (discussing this in another thread)... maybe those raspberries are not exactly well supported by FreeBSD? I guess that if there are bugs it will take time to resolve them and unfortunately I'm not an OS developer. So my question is... In your experience, what SoC do I need to look better in order to use FreeBSD? If they are close in price to the pi the better. PS: SoC should be able to connect to a network. So ethernet or wifi. I understand some wifi on the board is not supported. so at least if it has a usb port for a dongle is ok. -- Juan David Hurtado G --000000000000bb0f6905d188036e-- From nobody Wed Nov 24 13:48:03 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 7DB5718B3076 for ; Wed, 24 Nov 2021 13:48:19 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzj5G214kz3qhL for ; Wed, 24 Nov 2021 13:48:17 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Wed, 24 Nov 2021 14:48:09 +0100 id 00DB3FC5.619E4299.00013F0F Date: Wed, 24 Nov 2021 14:48:03 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: What is the best supported SoC by FreeBSD? Message-ID: <20211124144803.5cf02572@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0git295 (GTK+ 2.24.33; i386-portbld-freebsd11.4) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hzj5G214kz3qhL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-0.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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)[]; DMARC_NA(0.00)[dino.sk]; NEURAL_SPAM_MEDIUM(0.93)[0.932]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.985]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021 07:29:41 -0500 Juan David Hurtado G wrote: > Hi, I'm working with a raspberry pi for a project. I've been using > raspios for two years. But recently it has become pretty unstable for > our use case (mainly because systemd). Device will host influxdb + > nginx + grafana > > I'm using FreeBSD on my main workstation and on some servers and I > really like all the features so that's why I'm looking to use FreeBSD > here too. > > Few days ago I'm testing FreeBSD on different raspberries but I'm > getting a laggy system in all of them (discussing this in another > thread)... maybe those raspberries are not exactly well supported by > FreeBSD? I guess that if there are bugs it will take time to resolve > them and unfortunately I'm not an OS developer. > > So my question is... In your experience, what SoC do I need to look > better in order to use FreeBSD? If they are close in price to the pi > the better. > > PS: SoC should be able to connect to a network. So ethernet or wifi. I > understand some wifi on the board is not supported. so at least if it > has a usb port for a dongle is ok. > Look at http://wiki.freebsd.org/arm and http://wiki.freebsd.org/arm64 (and some subpages there as well). As an example, boards from Pine64 community (http://www.pine64.org), when supported (newer ones in general take some time to gain FreeBSD support), works quite well. Regards, Milan From nobody Wed Nov 24 14:33: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 61F4A189B41B for ; Wed, 24 Nov 2021 14:33:46 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzk5j518dz4cq1 for ; Wed, 24 Nov 2021 14:33:45 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x934.google.com with SMTP id p37so5514452uae.8 for ; Wed, 24 Nov 2021 06:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9XhhpOGhIl130NqZetBMoiWHuZr1ssLVou4khNpcXuA=; b=YCJer5V+0Fkp4pkkJTO/Mev/cLG2kFimks+PIueAMxNMkaIA0fAzkrd2hUfHHR0l8c jd/L6YUR9qOQQYLWh4+YnBPpGFuTDt30YYqluZCNVoApYPtQSl0cDkgPWo4lxNCX+/0i aE49zXR2rrVGw2sB5E3VgzWf1VkheOXokBIgxsxyZ4RgHkwQdqqh0bdZ+G6G4dfT3L1q 8zzGl8MjRBD6o9l1XPxHHnsLWwlLB8s/709HwgdX7V4yEBfplCDMT6Bb49NB7Uck9ryb 7fj1wtBACeMthBnHEbdeZpH05B45JDC+9lWhMUMkVeLoA8qjbjht/IhIncmveTmAeSQq Cegg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9XhhpOGhIl130NqZetBMoiWHuZr1ssLVou4khNpcXuA=; b=2M1bPxKgLpiMhdc+ohYANgbDDDrd5t6UWQC7C2zxJW+DHfn6Fu73tXKowJhtF+pqj1 lVQdrkG68IEOFaslLDWK+TuVtEfJ5SNakpTawHQKsg46V1AqiVwf9DjCIkEN+SFRrydj Zd1AOXnpoyitXXvdeV9ixuZYu/EdgW3Eg9Lig50hf9/CSXWJCYKQQdkT3Bzkups8GPN+ QV7oWz+Pf3R+8clDJj+z4y0S7ZaMDdM7H+CCjIii8EA/kbFrurwugwv5eEzm66aRalSU acQBX3XzDuY8FF3iNDXSiabAUtGY3voy5DVKAjt/zLwfJa2LgVsGZro6zfx6r+36YANi 7KNQ== X-Gm-Message-State: AOAM530ma+ioetvOQWMhbhx3KUBQGBBgLyObc/XoymAovjZ4IH/Osx1p n/wYydWbPF0mG2FOqyileykUKR3YjLh2q3XtOkt8oBgHI5IC X-Google-Smtp-Source: ABdhPJyzQ5zu6IEiOd/wCBzcD1AVk80RLNkWcLexHryPV/Ri43E4iGcUDLgTdwcwi6BVY/79bpaGYLo4/40L0CsKGfU= X-Received: by 2002:a05:6102:3ec3:: with SMTP id n3mr24475839vsv.48.1637764424994; Wed, 24 Nov 2021 06:33:44 -0800 (PST) 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 References: In-Reply-To: From: Juan David Hurtado G Date: Wed, 24 Nov 2021 09:33:33 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c723ae05d189bed8" X-Rspamd-Queue-Id: 4Hzk5j518dz4cq1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=orbiware.com header.s=google header.b=YCJer5V+; dmarc=pass (policy=none) header.from=orbiware.com; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::934 is neither permitted nor denied by domain of jdhurtado@orbiware.com) smtp.mailfrom=jdhurtado@orbiware.com X-Spamd-Result: default: False [-3.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.894]; R_DKIM_ALLOW(-0.20)[orbiware.com:s=google]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[orbiware.com:+]; DMARC_POLICY_ALLOW(0.00)[orbiware.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; NEURAL_HAM_SHORT(-0.98)[-0.981]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000c723ae05d189bed8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to @evadot and @f451 on Discord, seems there is the issue: Raspberry Pi 3B+ ``` root@generic:~ # dmesg | grep -i mmcsd mmcsd0: 31GB at mmc0 0.4MHz/4bit/65535-block ``` Raspberry Pi 4 with a different card: ``` mmcsd0: 31GB at mmc1 0.4MHz/4bit/65535-block ``` So no matter the pi or the card, the microsd clock is at 0.4MHz while in raspios same cards gets 50 MHz apparently Seems that explain the behaviour... So is this a FreeBSD bug? or a card issue even if I've tested with different cards? PS: A brand new sandisk ultra is on the way so I can test with it. El lun, 22 nov 2021 a las 21:42, Juan David Hurtado G (< jdhurtado@orbiware.com>) escribi=C3=B3: > Hi, I'm trying to use the OS on a Raspberry pi 3 B+ > > Boot is pretty slow. It hangs on `ue0: Ethernet addresss: ...` for some > minutes before showing the `login:` to enter the username. When I enter i= t, > it takes a few seconds to ask for the password. > > While doing `freebsd-update fetch install` it took a plenty of minutes, s= o > I canceled the process and then did `freebsd-update fetch` and then > `freebsd-update install` to see what was going on. > > Found that the process was at `wdraid` state. Doing a simple search, I > found about `vfs.hirunningspace` so I tweaked it to 1Mb and then to 2Mb. = It > seems to help, but not by much. Look at this: > > freebsd@generic:~ % time freebsd-version -kru > 13.0-RELEASE-p4 > 13.0-RELEASE-p4 > 13.0-RELEASE-p5 > 0.365u 0.045s 0:41.25 0.9% 20+177k 14+0io 0pf+0w > > :( > > What could I be missing? Maybe I need to tweak partitions and use some > kind of configuration/optimization? how? I do appreciate any guidance you > can provide in order to troubleshoot this. > > PS: I don't think it is the microsd card since it runs raspios fine. > > PS2: The red led is turned off at the boot process so no way of knowing > visually if the pi is running. Weird is that the led turned on again afte= r > `shutdown -p now` hehe. > > -- > Juan David Hurtado G > --=20 Juan David Hurtado G (+57) 319 252 3773 www.orbiware.com --000000000000c723ae05d189bed8-- From nobody Wed Nov 24 15:53:52 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 EC08618B1433 for ; Wed, 24 Nov 2021 15:53:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzltH4t08z3PvH for ; Wed, 24 Nov 2021 15:53:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1AOFrq8B026220 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 24 Nov 2021 07:53:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1AOFrqnk026219; Wed, 24 Nov 2021 07:53:52 -0800 (PST) (envelope-from fbsd) Date: Wed, 24 Nov 2021 07:53:52 -0800 From: bob prohaska To: Juan David Hurtado G Cc: freebsd-arm@freebsd.org Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ Message-ID: <20211124155352.GA26072@www.zefox.net> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HzltH4t08z3PvH 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, Nov 24, 2021 at 09:33:33AM -0500, Juan David Hurtado G wrote: > Thanks to @evadot and @f451 on Discord, seems there is the issue: > > Raspberry Pi 3B+ > > ``` > root@generic:~ # dmesg | grep -i mmcsd > mmcsd0: 31GB at mmc0 > 0.4MHz/4bit/65535-block > ``` > > Raspberry Pi 4 with a different card: > ``` > mmcsd0: 31GB at mmc1 > 0.4MHz/4bit/65535-block > ``` > > So no matter the pi or the card, the microsd clock is at 0.4MHz while in > raspios same cards gets 50 MHz apparently > > Seems that explain the behaviour... So is this a FreeBSD bug? or a card > issue even if I've tested with different cards? > > PS: A brand new sandisk ultra is on the way so I can test with it. > Very strange. I get bob@www:~ % dmesg | grep -i mmcsd mmcsd0: 64GB at mmc0 50.0MHz/4bit/65535-block on an old Pi2 running FreeBSD www.zefox.net 12.2-STABLE FreeBSD 12.2-STABLE r370512 GENERIC arm and root@pelorus:/home/bob # dmesg | grep -i mmcsd mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block on a Pi3 running FreeBSD pelorus.zefox.org 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 06:06:55 UTC 2021 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 HTH, bob prohaska From nobody Wed Nov 24 20:11:02 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 8E18718A739A for ; Wed, 24 Nov 2021 20:11:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4Hzsb329FHz4tvS for ; Wed, 24 Nov 2021 20:11:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637784663; bh=qEgXt5i9KArXa4DJUv8cz3EaNh+qOvCYTWOeyh+Tg7A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kiZHQpneRTuOD+Kgbd5mQpH2FiZia+6FZWBb2ePI2W6IjGV5zJTY1Ip5RIze+2U0F1ds6cHNfvXu/si+UfgHz3WRn1CC7uYQdXbA/5e6NaQk/cMzy7IH1BUKd8VbjID7VXPt0dNmDa9WRQuFRzXrvTlnIeIbUIrzfHHaoAMli+Vf5OVDfu4uohT3ElUG0PjRe7aYYrToOGg3DQMudcY+L7Z3flkjak9DwKPpLDI5hsKgcjEUR9e9RrKehr+OWThxduM+svizRrmd5/Ta1OEocO0lRlUg1kpi1we6b1SRrEnDanBOcFnzcXZOiqskJICQO6HNuI9JP+TyqW9MnM9xIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637784663; bh=7mKfeoytlLxG74aoPxDYXnhfM7hSh7TuumD1xihwklZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=teQpL9qIc/rIW10dzUfUAL8oiZweiEMPgV/SSjHMLojsaDF12tG1uL4UypLqmUlABgAzTA2zrqGG63toWV9yrorx9N2ICXUTAwvyIA48U2nbdCLYJzbGw1YH5hztt4iqwK6nKuq7fMhov4O6VuA1h2C/Ne/dSecZ36HLb6ZETZb+35rXz4IvM4BucrRUlGOEfJnnisEpdzGN/N2Y5EKvLSwHIpmOWj1fBZaKxRA+f9N+giaXINKcOs+8z4SkmQPkpwbPmz3Q9n9wg+EQVM6hpQlvhOpnzC9Oh0XcMG3r2O7teEFN8UD6/nvr3NmNap+j7XlYxH7eDVNoz/y8VrvsRA== X-YMail-OSG: WOXpsZsVM1mFwNFczOC7bB2_iU9uLsd5EqCyqI5LU4XXQGkJybGf4lIMCLwrtjG S9uKcJi8wfYoan3FWyiXCs_47FAh3kQYfz_RSNGJ6HJn6SdNcQISJUMZ7Ry_mM1rssjKrhVAHsQr rFKLgdGGKLpZ4AhF6BBjVtHTEHrzTZzpjNHdQryEoE41V53WLReschMdQ7RUjb3airqrG73PP8zC HcWJqgTWlusXVyfDVsr3nupKA.BPkHCoaHH_OiKi7Onuw7p2mwwBdsr0DurC_kz_.paeKfjYeAFE zmhizlb8zCrIl2TOpvY0hy6jXEPqsnOqrmvAUyiPoTaJiPsBJyJ8HVchG1Wbg25prMRy0v.GFwh7 FkzDLSFQZaotQdZ3s0BDNTDvPUk.aIrSuw.8PZSHRPF6.XOzcEog9xpOJ7ignVqKQz8QptGX1XTF PnwhpQmVZ8Q8o.DXwkkE3786y3Q6F126vo_dxGERXmG27f5jxIGpLgyijqR6_RZnNkTKbjYYbEOF ZEPt2KUpsEB9aWWivp23OuRF7VXGY.EFXVAZ7q3WOVAEb1KVMaC6LX6NL9SDdJfkQaNZW7Gl5XO_ jaWQjYhjczs69GRBHDBOdpmWx67u_OjDyhYiVqI8vMzYug_rlcbtnczFBT0rai0516H5HGztv222 7AMcFvpoHqp_3RD46H6Lc8PgYQu_.eU4K.19z1l1gRZ8dSbXMhnkC0QQZx5ZqzTOM.CSPT6ui0Us L7wXrOuljfumGuDEv7.thbzdRFRCNsJHBw37dznHj_fS_7Mw_KefZTI8SErTEIHFUzRK2_UdnoAn qRxBOCamPb0q9__OoFEaOioHHR6BfV4P85iRwdx7S.DXcsFD8lU7gAJX1VCYPbwW9HmMflr93fvv 3IHEbHOTikdXVt3qgVYzsdOQOP96LHN0K9AkN6gXQSXUw9qiRqqGYsRCQiwSmwB7CgRf4c9h.q0C o_kzj4ZDPeI_ASnKe5IWIEw.zKdoMUz.ANrkPXGGUf7WpTYHij1.IMrH.AC3kI1nTpwoVofQ.vto GwFbD7e_7A28v3SbW870QSiAxexr8OBSkjoH445wAdQO52hnLwOec2ndEPCIKIDusI4McTdtHmp4 sbG.NpI49_iHR3iwbxJJS1W16y0.Jc788FfgMOGvMMz8BrYdgdrhe20O_ueoBJBp6jGXGo3hjqa0 vPD8jqiWd6cRaTz82pWoN2RozoHl3DyOIcB0UXKXOjSYKYl1WA1IeroSvl6xB0MpjopUzbAiQSw4 a.dIh_7bwXV1b8ykl_NNfsRs1XLYH4m04I4omeZ30u3vjOURuohLFcvLBjT.YO4IHn6MEhBhDzwv 9HVpFu9rdhY56rjrcs7mPl8Yx6Q_GIyuIrTLgsF5MYs2cjRk80lipaVPvGnCg99qTYvddy54tcxa qEbuRsXzGrL52DTcE5Ry7w5uelBtNmhvjOeNuIhj1uzvadChdGYT1OSHALpyWVos0JqMV.cAagEH YzLKwRC9gApv3qrBf0TwJqT1KRsC_oTaZQIWU9vHJZRyrZuBHoS4RPEhbPYI167JcECfkgXjVcX_ MhJ73rLz_GJoPt_18equ.WMT1sQxSNVSmbta5cgl.aWhsKNS.EVuEan4RuP1xwKESuS8dtI6PdkM k6aXIY47Vfb7MJ6LX3q9kuC9QMQJtSSj_IiEfLnxjEBc7vRiy1KIgQAulBwCT.AwZFZcKv_2VeNW gmeYuM_A2ChwKPnC5KNDv3wzgCezmbvzhqC9oPHjHoCeGqclpxaJfVNIGvP86Pyf4SAGA9gcXVq6 Q2L9RMV1X1hwY8aT4A_rgnNQGp8M8fDKPHqyNAh2PHpwgleugESoRgj58ki3FKQEu4FVSvKCKG5e bwKaLAT4WfeBN5eBbV.WWp8wZMi_G1RaXp0gA0WOfczm5SeXoeeJgxqE2eCnV0dwHM_yTnd7DLtm mKF4zgUmLOglB1kCxQ4SQvnfyVEc2ZnVZVUQ4seUi_bhT7Uu1Tz8ST18nsgTtLaOrcpXDNXZqm0w 6A3w.0WTtUTx1rucd6EY7bMa4BtmBJS6xyIHawnuttdVrptIjBoAFNygp_CLVgOVxSeb6JyAhqdQ qnUZoYE3I3wT9ogfeqoJ3sOvws_YOKuQbEdx5oumEAP3Jz038itFiNWQs0mkf.Ug4nAUwFvQJSGt ScoAza7oFhfd5mOZ6.DJpSpfngelORjUBjnJ.MonYOfLKoUSJ4kKSkc712LUztdsDtvr1j1Tl4yV cS42cHdJz8yd4eQIgD9pIYOi0RXtKzaTHZv6KEIeOYhFstPN6i.CWMsybPupJFUhW X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Nov 2021 20:11:03 +0000 Received: by kubenode514.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 15534e9ad2cfa2c7f741affc789ab21a; Wed, 24 Nov 2021 20:11:02 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: <20211124155352.GA26072@www.zefox.net> Date: Wed, 24 Nov 2021 12:11:02 -0800 Cc: Free BSD , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hzsb329FHz4tvS 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 07:53, bob prohaska wrote: > On Wed, Nov 24, 2021 at 09:33:33AM -0500, Juan David Hurtado G wrote: >> Thanks to @evadot and @f451 on Discord, seems there is the issue: >>=20 >> Raspberry Pi 3B+ >>=20 >> ``` >> root@generic:~ # dmesg | grep -i mmcsd >> mmcsd0: 31GB at mmc0 >> 0.4MHz/4bit/65535-block >> ``` >>=20 >> Raspberry Pi 4 with a different card: >> ``` >> mmcsd0: 31GB at = mmc1 >> 0.4MHz/4bit/65535-block >> ``` >>=20 >> So no matter the pi or the card, the microsd clock is at 0.4MHz while = in >> raspios same cards gets 50 MHz apparently >>=20 >> Seems that explain the behaviour... So is this a FreeBSD bug? or a = card >> issue even if I've tested with different cards? >>=20 >> PS: A brand new sandisk ultra is on the way so I can test with it. >>=20 >=20 > Very strange. I get >=20 > bob@www:~ % dmesg | grep -i mmcsd > mmcsd0: 64GB at mmc0 = 50.0MHz/4bit/65535-block >=20 > on an old Pi2 running > FreeBSD www.zefox.net 12.2-STABLE FreeBSD 12.2-STABLE r370512 GENERIC = arm >=20 > and >=20 > root@pelorus:/home/bob # dmesg | grep -i mmcsd > mmcsd0: 16GB at mmc0 = 50.0MHz/4bit/65535-block >=20 > on a Pi3 running > FreeBSD pelorus.zefox.org 13.0-RELEASE FreeBSD 13.0-RELEASE #0 = releng/13.0-n244733-ea31abc261f: Fri Apr 9 06:06:55 UTC 2021 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 >=20 Since an RPi4B was mentioned . . . Booting main: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 got: # dmesg | grep -i mmcsd mmcsd0: 31GB at mmc1 = 50.0MHz/4bit/65535-block Booting stable/13 (same USB3 SSD boot media, different bectl selection): # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #15 = stable/13-n248179-f4aba8c9f0cb-dirty: Tue Nov 23 11:31:51 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300521 1300521 got: # dmesg | grep -i mmcsd mmcsd0: 31GB at mmc1 = 50.0MHz/4bit/65535-block Booting releng/13.0 (same USB3 SSD boot media, different bectl = selection: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p5 FreeBSD 13.0-RELEASE-p5 #2 = releng/13.0-n244765-2646dd665909-dirty: Thu Nov 4 00:19:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 got: # dmesg | grep -i mmcsd mmcsd0: 31GB at mmc1 = 50.0MHz/4bit/65535-block I'll note that I've never seen the 0.4MHz problem in the past either. But, the above ignores: What RPi4B firmware vintage was in use? What U-Boot vintage was in use? What FreeBSD loader.efi vintage is n use? ( in the /boot/efi/efi/boot/bootaa64.efi ) Note: in my context I have the msdosfs file system mounted at /boot/efi/ . Your context may be different. For example (in may context, for all 3 FreeBSD variations): # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) # strings /boot/efi/u-boot.bin | grep "U-Boot 2" U-Boot 2021.04 (Apr 08 2021 - 10:46:22 +0000) But I'm not aware of anything good to search for in the copy of loader.efi . I also doubt it is contributing to the specific problem. You may want to report such details for what you have tried. Your various boot media may have distinct versions of one or more of those. There is also the issue of: What specific version/variation of the RPi4B was in use? To my knowledge there is only the original version for 8 GiByte RPi4B's: v1.4 . But that is not true of various other variations. You may want to be explicit about which RPi4B variation(s) and version(s) you are using. This even gets into the labeling on the SOC's top, for example: BROADCOM 2711ZPKFSB06BOT TE1919 045-23 B3 W vs. BROADCOM 2711ZPKFSB06COT TA2105 054-05 B3 W The B vs. C in BOT vs. COT is significant. (I'm not sure of that should be O vs. 0 (zero) in the middle.) As I understand, the vintages for the combination of Firmware/U-Boot that I use would not work for a 2711ZPKFSB06COT context. Other notes: If I boot (via USB3 media) with a microsd card in place that has no firmware, the microsd card is seen and accessible. But card removal and insertion is not recognized, basically limiting me to what was in place at boot time. If I boot with no microsd card in place, card insertion and removal is not recognized: no microsd card access. (Ignore using, say, a USB reader in the above wording.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 24 21:19:16 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 41EBD18A2B80 for ; Wed, 24 Nov 2021 21:19:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4Hzv5t29bjz3pmg for ; Wed, 24 Nov 2021 21:19:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637788763; bh=Ou+P6n9KgO4atKbMDo7CKwoZFLXqQ4734h1kwHEVmW0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=EgmpDXuYilJBCWi8llQgw/FN1GkL0h8AABubZ7DPRp1l0q3JfBmlB9g8GWU4FZCeA8YLtMAN32uDyM6StFvmm59QQ5hjg6A2C2Gi41N2kWIrImGCLJVPGKhs5pD9Wkz907FvMYhBt46aDEcPzJYC8BsW5D32d7ms2cfN5gGnBRw8N1cEkWsZCHHt7FIQ4UGw0mpA6fYAjpD8AAJzqSpqABcisX5lIjP2I9W2PxsFiUxh5k4V726rHV6Mq2qkkMhRN5LKK2QI9YaTz13RgR6rav7ByvpXroABiowEK2JT8CJPMPUkEY3igqfPlqkyhSa1cCMgKEpoyFf4x/8DtCmzFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637788763; bh=J4qGR9WGo/Qxh2/xs2K49Bs+2foSiiaswTTEAd0c6OO=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HI/iOr7udXwYpOXvIVx2Cdqb137g0h0m4YBXksMb4Iss6GQZiva6YnijwtQE0/2aaLsXd+tErjhoCo0d41L19cgh0yplb45QuVyj03JPnqGuOQe6q95frH9iTzaJxORMeXGqoB6VA+f2fiaH+F4kcXsI4CgGOMRQ4nrTkrm4QblUg7w8b/sZYSFlNTxbHe5dk1PZtzvnrMqL7ojTvjZt/XzJ5+9+zBCY/DhcVriw2kvaXDlAMjL1d6WGCL/Vzkx/4qo21ZP6M+wqxSyW9UREIyY90kWQ9nYwH0JFPS8BXJy1GntaLtWr1XQ2z+SVM1XJLNWwjKG99MkmsF+mlfuzCg== X-YMail-OSG: STys2RoVM1m.lsf9WW6nKHJRwpIE3BJIQTvYf1UcX64GuygFZJgrpkkuVOfUwum HqhSxBuy_ap1mbZ3f71RqN_q0S1hbhs4njHLh3tkmjjt.1mkthXtPROlam.yfgaBD4KapLsk1DZj Tmk5W38toRqnThAD4co4Ei5vflRSc.ZSueJEgsHtLIYwDZH59jG.ZFoBSYLbYBEBEW_Sp4Ipp2vo jOvIVrKFWRJ0MK36SXVCzDiXdohg8r2oJXyDnklOBGXdWFWnyEtQHnPMCAU2sSoBKvhXlzydgZSS .woyxvTyAcXIgfXfUKRgVSKGAqRXG6NF433mIZC7zmEkn83JBsf9RcqAIJdl6cbwxuYp3EVbzqXc bk7uC3fDj1uwHE89pR.pDwvReECOHEnhkvkuv9qeTxJS97n5RfzYWri4Co37JwCvqKCxi0iwg7i3 3NLeYEsFxe8Hy3L9gzWDrwh_5ch06wPpmXf28EZB_b8IioFC6JACK2yLwTk.8QzaH8Kl1vQlOzH7 YPCsft1Jw7Zh8Z.hAxiCAstmbX4jcx2JBPynh1BoWIbv_fPkQWESBL.tDoDcwXQdlLTJFFY2gkXg PuGwWgpkhEN0DKy0HxKD78CCcbqxiM4OwHSeHD3VNnE5FU0Kf__dvkyZ8607KlG1p3XJkvwxBLbZ 5hPIuxnuJhdJiPImwgc.5TefB8JhGB0Beoc9iRkL.tEnFHM2_DBAiKtCVq7sawN_veoSDtLmsEod C_uaeaqgchWaAYsC2nAIJQaAl9k6EeFNo.v5z6cxW5Ii_iwaa4LzoOfdPvTjiXlTMvpt_xn9mA4m iy8X.qsvRv4qk4xU78DTjzQJSVLslF.Nj0sOXKn9SrkCnyK1Ycz0y8bats3lCrmuDLUGj8QORdC7 m9xc1j9DQ1INII73fmpXwEApiC4qDvtuIFDEZbYPhO18yRQCLAWzRIDcd6H7EyL5aSmes6EgWSLR _SQ8S0d6CDf2SWV0cmajcvvRql0cklIGtM7z_6R4c8CDWvCFOL6_OHEcppQ7lQlVGez9soE3HLTh i3wR2djsvqmcBElK69INQEXE6cdVnfsiK2lApzu3rDDGO_SEVxHDwtvbS9BtPjgGhgnHRl.CYoA_ svTsCwAJMj3pkPCMpcnO5XwVYppogicFmTUELGe2guWVbc9gVAfuVujic3SyjLENsdWYD3f3CJSm G_Qhxf_rb7vfYFpA4fu7f2FNTb24hvHck5YZpqbrH6STnuMq4oyIrl4BlQky1H2mlsr_YzfuSq6c qOt5dUS.XIuYLFGwB582ui1kfnFpOv_h6.N9fUuTNrzSkuIcL713sLdTjK9PeCG_E2kWw7Ggd8ys PgrG6_qxmSQBFAjdyQ0X_42tW8O5l8t3BRam_hlu5yVBOopoXOP6XHNETKSQI37y1ShrLOxNhWGi xOYhFLS1cJb4s9sA_B6v7iSiV4b5L4ngsQNSwSl6fPdlZhEsjurYJl9kBQX1MBnufRxHTmj1_Van 7TzKm485bNeRdr4O6v5rFvfB95NWVDSwTk5UHwAYOSqA0a3uBN1o3pf9JmRY5n1WRNe1_gIreaq_ eRaT81ghiPyfoFY4zP6Qg5MKS7N1Mh18vI9IuA2qQpBaxUdp2Q5grZr19yLue7LvHdyfInXq7ytB Osryx6rgPTwPTAe_90QOVeBMSNWRPicE8ICLUUel11yGDIcNr6ps_m2gaNjA5WHvX78qClLrn4sZ LQ7p7LvqtJJ3uSW3cSF5bDC36B584D7_3gM0REoJGJxMCqMI5HRy13l9dAiTg1xFl8uKKbgBZzVo tgsOFpsg3gNccn4JJxMgWaklqDGbEFKubRfXbTDkhg3EiZMuHxg50gkN5X7tnmDBTYxn_cWOPdKL RqWESqxY.i2qijK8m83LL.wK9iB1GLA0549Vnq_n3Ghu63VtlP6dXcn7cETvtIihib7KrCRl_P5L YZJatn6si10llYRy01PjEz3Q8sGL2v97TQYKZexPbDneUqVdUPZObdi4vxEXikh35frXgamtCkif JWU7dek6Cb2FV0zw9BK.CkacxPvPKLaIrh3Fy.xW0UBLrCRAQlVmFLTqqRLz8e8xOL3Zz1A9OWE2 LwUHBsquYTCasdKDfYnxn3tws_ylTtqClo0ihpVJ4YZRj7DO.M2TDuVh8VrEH1nRRmEkfRmyfK2r AJVaJ_sQ_mqA_P7R5CFD0PQkmHKiz9SCHwoKpCic.vDDkPk3zBwdIz6CHDELN0y2V9R9OO2e_XKJ r3uD2wVNwiGYujZjogR5xObjhHcvpqAaWHm8q46Vj4RzK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Nov 2021 21:19:23 +0000 Received: by kubenode530.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6a0e54fe85e44fe56f90ddf70201b456; Wed, 24 Nov 2021 21:19:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: git: 32a2fed6e71f - stable/13 - openssl: Fix detection of ARMv7 and ARM64 CPU features Date: Wed, 24 Nov 2021 13:19:16 -0800 References: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> To: allanjude@freebsd.org, "freebsd-arm@freebsd.org" In-Reply-To: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hzv5t29bjz3pmg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EgmpDXuY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com 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]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(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.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.24)[0.242]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; 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.64.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 01:51, Mark Millard wrote: > [Actually, the main [so: 14] equivalent.] >=20 > All Cortex-A72 based . . . >=20 > First, older system versions (before that update) > then after the update: >=20 >=20 > RPi4B 8 GiByte (older FreeBSD first, otherwise new), > Cortex-A72's: >=20 > # openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 51925.92k 58449.46k 60430.32k 61050.13k = 61180.98k 61482.75k >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 28880.07k 30837.33k 31630.29k 31855.62k = 31921.54k 32034.53k >=20 > So: slowed down, unlike the other examples below. >=20 > # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 51894.33k 58540.45k 60815.22k 61534.47k = 61906.84k 62042.10k >=20 > So: back to the prior speed. >=20 > But all these are based on config.txt containing: >=20 > over_voltage=3D6=20 > arm_freq=3D2000=20 > sdram_freq_min=3D3200=20 > force_turbo=3D1 >=20 > (The RPi4B has a heat-sink and a fan.) >=20 > Note: See later about the RPi4B CPU features. >=20 >=20 > MACCHIATObin Double Shot (older first), Cortex-A72's: >=20 > # openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 50808.49k 58466.08k 60769.11k 61444.92k = 61767.94k 61707.61k >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 163579.14k 456319.27k 786544.01k 940234.41k = 1003230.55k 1005671.31k >=20 >=20 > HoneyComb (older first), Cortex-A782's: >=20 > # openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 57659.60k 64599.05k 67719.81k 68373.74k = 68724.24k 68793.80k >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 177925.57k 502311.65k 866287.95k 1036500.35k = 1106598.06k 1106721.91k >=20 > Rock64 (older first), Cortex-A53's: >=20 > # openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 18378.23k 23401.45k 24834.99k 25206.10k = 25337.86k 25258.19k >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 52711.29k 163586.49k 318738.69k 420277.93k = 461373.44k 463192.06k >=20 >=20 > OPi+2E (older first), Cortex-A7's (so armv7): >=20 > # openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 9343.10k 11156.39k 11827.64k 11995.30k = 12025.86k 12031.32k >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 11013.41k 13598.44k 14034.26k 15045.97k = 15262.90k 15302.66k >=20 >=20 >=20 > For reference: >=20 > For the RPi4B examples (2 notes added): >=20 > CPU 0: ARM Cortex-A72 r0p3 affinity: 0 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > Instruction Set Attributes 0 =3D > *** NOTE the lack of ",SHA2,SHA1,AES+PMULL" above *** > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > AArch32 Instruction Set Attributes 5 =3D > *** NOTE the lack of ",SHA2,SHA1,AES+VMULL" above *** > AArch32 Media and VFP Features 0 =3D > AArch32 Media and VFP Features 1 =3D >=20 > For the MACCHIATObin Double Shot examples: >=20 > CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > AArch32 Instruction Set Attributes 5 =3D = > AArch32 Media and VFP Features 0 =3D > AArch32 Media and VFP Features 1 =3D >=20 >=20 > For the HoneyComb examples: >=20 > CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > AArch32 Instruction Set Attributes 5 =3D = > AArch32 Media and VFP Features 0 =3D > AArch32 Media and VFP Features 1 =3D >=20 >=20 >=20 >=20 > For the Rock64 examples: >=20 > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > AArch32 Instruction Set Attributes 5 =3D = > AArch32 Media and VFP Features 0 =3D > AArch32 Media and VFP Features 1 =3D > C >=20 >=20 > For the OPi+2E examples: >=20 > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > CPU Features:=20 > Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, > PXN, LPAE, Coherent Walk > Optional instructions:=20 > SDIV/UDIV, UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:3 LoUIS:2=20 > Cache level 1: > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 2-way instruction cache Read-Alloc > Cache level 2: > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc Note: as the issue applies to stable/13 and main [so: 14] (for example), I continue to use the freebsd-arm list instead of a list that reports commits to stable/* but not to main. Relative to: #define HWCAP_FP 0x00000001 #define HWCAP_ASIMD 0x00000002 #define HWCAP_EVTSTRM 0x00000004 #define HWCAP_AES 0x00000008 #define HWCAP_PMULL 0x00000010 #define HWCAP_SHA1 0x00000020 #define HWCAP_SHA2 0x00000040 #define HWCAP_CRC32 0x00000080 The single-bit enabled OPENSSL_armcap that gets the slow result is: # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 28427.04k 30712.32k 31446.00k 31683.40k = 31829.10k 31839.55k The illegal instruction ones for aes-256-gcm were: # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) (sha256 does not match for what is illegal.) Ignoring the illegal-instruction producing bits, HWCAP_FP mixed with any one of the other bits was also similarly slow. As for all the non-illegal-instruction producing bits: also similarly slow: # env OPENSSL_armcap=3D219 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 28922.63k 30711.51k 31522.15k 31722.15k = 31788.97k 31845.03k Disabling just HWCAP_FP from that got the fast category of result: # env OPENSSL_armcap=3D218 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 49543.14k 58068.22k 60236.56k 60724.37k = 61216.09k 61212.99k As for sha256 . . . # env OPENSSL_armcap=3D0 openssl speed -evp sha256 . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes sha256 22434.19k 59895.91k 117258.16k 156264.31k = 172624.81k 173848.52k (I'll not list all the similar performing ones but will list all illegal-instruction producing ones.) # env OPENSSL_armcap=3D4 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: 4082055 sha256's in 2.99s Doing sha256 for 3s on 64 size blocks: 2752520 sha256's in 3.02s Doing sha256 for 3s on 256 size blocks: 1372584 sha256's in 3.03s Doing sha256 for 3s on 1024 size blocks: 470215 sha256's in 3.11s Doing sha256 for 3s on 8192 size blocks: 64700 sha256's in 3.07s Doing sha256 for 3s on 16384 size blocks: 31847 sha256's in 3.00s Illegal instruction (core dumped) # env OPENSSL_armcap=3D16 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: Illegal instruction (core dumped) (16 worked for aes-256-gcm but 32 did not.) So: no significantly slower examples of single enabled bit cases. No (non-illegal-instruction) 2-enabled-bits examples were dissimilar for the speed. For reference (avoiding illegal-instructions): # env OPENSSL_armcap=3D235 openssl speed -evp sha256 . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes sha256 23185.66k 62689.73k 125814.72k 167981.88k = 187833.65k 188968.95k So: also similar speed. Need any other specific bit combinations? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 24 21:23:13 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 2DFFB18A634F for ; Wed, 24 Nov 2021 21:23:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4HzvBR0pKwz3rbt for ; Wed, 24 Nov 2021 21:23:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637788999; bh=/jCO0yFG9yUwDJSPyvx1rJi28RbAh2+05yxE/HAHQbk=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=VlPf4I0yGOvYJ4DK+cDFne5B9dbfKX6b3H2wK+2avEZc3AmVStlaDsuqV9yzACqRUblh+piy0W2wOdYVea1gs2dgLEbse/WYx0bdbOJ/nEnt1QhkX+RAVvzGT8Ef06SlqARiFJwKj/uBKvqSd1k6x/Dg2uK9ZT5w512Vvg089j6DHhZtAXfFHVDHMFTukVJ8P/KDZjMbcod6LkE3Y8F42y2zbq5SFuw879ZJuLAR2ee5Pe2F29jNrF1gjkPNIy6KcYCPpTPCKsVoPNQOgVo4NawXne667WaX2/jgCfj/V5ZtRtI2Z3mldA6fSdm58gwTEyb4taInyygLMkDo+wt8qg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637788999; bh=a599yZ4jvF5miC/+tK8HCpQdvNpRBs7BwWBKDTYa4qb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JCp7OZNXaG8XbgWcpZy5XSU0BBluhodxyuVMXZbVyt0A3UIus24EYQtnrTC8iSoVECOefFiIsGpPH405Q3kcXIS+oGMoTyaoqRn/94cOL/bJosQRRMRPh5NtZ+28DT7ofdKIhr/G9OJpRIMr+EKGayMh6LkBWgj4PS40IfthBtub0kNXE7j/hR5ulj9Qp0QaXyYrMLZib0GeEf11lh8dgW7hHEpkl460PQA08VArfvhTmjoD6sB3OPqWsFJnio/wAZZAzHSqppAd4XQ+vqfnrCRZAs5LCdtlHFi5bzCxC67EVubentcLRvzgKL0OCtifNAkQl/CSDbZcOOWZv2Tg+A== X-YMail-OSG: FKdAVDIVM1m3iPdtdg4J40eTswR2ixQoh_JzjGBnkhN3QvNfjpJZDCiPfljEQhO pD4WB8BHo8WbrEe_fkkEpER9YV_yWRsyqCAmWr.YQpgEGakLpuWkFeCo6KQiWyf1XJAiZMojrq34 4zJ2Dlt.BoBqy_erx8Ba7sr7fq2TQW63kwXhZKx6i5dIgZK1ZJnIyUjXZ_H1CC7zivuA7enDeGYJ U3zNwPdhRikCsyuhGw0SC30JiwNYqfNqp5QvaZTVOrt2AeDqSnqrcyb3I5a4SM7VakI_vaJOvQ49 OJdbQdU6IIIzM_FQvNqsDkR7AaxDaozRJoPsLFdsACfcAlaO9.rUF_.UYwCHbV1xmp_A58fhRh1p OVu8bB51YrvufW6ozthamBeF_pi62vQIS0I_Zyhxn5.bvCQotZzfRC0eIsd7TBlmw3Ls1whc.Urd NtqN1m6cF8Oh_3CT1RMUtdqqg0c2YO5T.YqXvEmj7fi3g4_j6y2V__IzA8dWylJ36wZd95pVIL3F nh6UCl1u4EUKmIj0VZyHIjWeq5_2Ye4ryhdbTpwbTrOuCQGdFFzbjfwOkPDDls1k6PLigrIdobiT Lqqxz65qFkQGYJPBrzaArxGbidS7LvzSP_pFaYwJ2O46R8eK6Aolqf9n66ajkIl.9gQmn9fwG.iR iTGNrAXZ5StwTE1et9GvEN0URDhFKO.jFAAPnrYEKbNl81vyLuDo_CUF7fzBCQcccq4TLrI58WvU D9HHKCvas4ZEBYNSe3urgSORFjVlpH64xFVd2S7Vd.pqLHRUINNglSxDtv.Wl9TGtg_LKecF1RaH WByhyUleYvi8r_oFRqd6x2rxmepcBHbwK9_5EiFgSXlaiwF1BRBWHlbom6ySHsJJJuCMAJGji085 MEyQxsuL6LlQvD_DYA6Bv1Kk9StLKcb8YhvnNpViydHY9UQeRitw91i3WJdGW6wMoPxQ0zTIeIwn xrFzNB5TgIv4GMDs2Y7X9Dwb6F2D6SuimONI_gfVKq7AwzlsGRkdsUTUhWkoQWSdCHKrLtKRmGJb UhJe_g1kcgdrD7szumoKlpNk8sEPXHSwjqU6f9KX5QytkCW8FFyaugIQBE3t1iEBh.y3l1eTCpQl 9xzIjwnXU69lQMwB.pRHMDop1ZFNZXsgAP1S71uAftvH63QIfI1V2SsqFgbvDUgcybPsuvzx7i7Z 0W8JMUY5sXo9mOrU30id.UOQ2.QT3Qpqujrz9vSiHJQVLoHgOQ30sw1lu6wmt.H_1WaMCIMWTkPS Q7RE.u3_LQ4m5stzTuTCa2TqJWEIq0w1vthnJ8VvKGjTOlBIDvpmyy8EvOciFTsRasVVb2dFs0XX yofc_Buw2GJqvudlT.96G3Lu7l1NPvbzbqH7qlj9LByvXhUn17QbyVhwHHfBfD8Rj8i7upJP6ZNo DFl5VkuW57vFRynoTBOfDD6KS8uAIPY8qJN74R3V3XB01gzJJrNuhtYvN3cdQRzt3LdTyAsoGjpA 7qitLoZ63s2AFvrBQKfktRRmdjSblydMmUUVs6kHTI1nNPR13t7l.KtiRtEOb3Y3lo26mtNawdot 7EEVMrC71.dOtIP02Rul.pddDDSkvniwunc4jFvOHpAaQqOVsoCxQt3aEyVdxoMdW20h5V0GO8k6 i45U8GgJVy2AhqdjXqn3SaU8bRIK2ZIJF4EwnOwgqvUV1Qt_3sRF7k56H_ZjGAFVCFFn9GAwC98m vI8CAwKc06tkM_4aWSed5VOtsoJCofA6.3cDTsFbestYOkMBy.dwb25LAaxxwPmNlFNw14sMCidq s1kD15Vqx94YZ3nf4QpLElYk.rgQJoNRiHsot8bvH_tfs5znqsxOHWK8Km8B.SXG217mXloQa_WP lezJdnB4ICDcir1deoXDDziFoqwfKSWa.koQ.IVwZeem6OpTMswsxP26ewRyuf9VfsTHm86ISAYy AHE1UbxK8k84LuJOSvt.ngPQpskZWCLu7nK79YHp8ePjLNfNTb4hlbRQt67GSM40oN53r4xK49Du b9L_wC3CAf4irUk23q_sxKRDr8OKDzXa1O_Rq.YIWWUFYIDy2Ywr_38Y4_avv9BBk7JXultNXdvp RVyd60cGUZcQpaEUOt63wXoAWWLl7NujtXvtoCTlgQ7G7OPf2pzoOx_zcV2iDuJhU1Prvm0nM_aH XXHByd.xC4kmJQs6F0HZ0GQ2AchsBYF3rQ91hWoUru5FGz51TehxZMVrMKGLpmnGu.KY3ImKm_yG IkFLpUF42zr2eK8QdhVWeLXI3S.2yvVOZPbtlmsy7AEe3 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Nov 2021 21:23:19 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 69fd08a8df7afc8c6c2e6f66af9ca4ba; Wed, 24 Nov 2021 21:23:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: git: 32a2fed6e71f - stable/13 - openssl: Fix detection of ARMv7 and ARM64 CPU features Date: Wed, 24 Nov 2021 13:23:13 -0800 References: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> To: allanjude@freebsd.org, "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HzvBR0pKwz3rbt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VlPf4I0y; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.33 / 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.31:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(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.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.25)[0.247]; NEURAL_SPAM_SHORT(0.92)[0.925]; 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.69.31:from]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 13:19, Mark Millard wrote: > On 2021-Nov-24, at 01:51, Mark Millard wrote: >=20 >> [Actually, the main [so: 14] equivalent.] >>=20 >> All Cortex-A72 based . . . >>=20 >> First, older system versions (before that update) >> then after the update: >>=20 >>=20 >> RPi4B 8 GiByte (older FreeBSD first, otherwise new), >> Cortex-A72's: >>=20 >> # openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 51925.92k 58449.46k 60430.32k 61050.13k = 61180.98k 61482.75k >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 28880.07k 30837.33k 31630.29k 31855.62k = 31921.54k 32034.53k >>=20 >> So: slowed down, unlike the other examples below. >>=20 >> # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 51894.33k 58540.45k 60815.22k 61534.47k = 61906.84k 62042.10k >>=20 >> So: back to the prior speed. >>=20 >> But all these are based on config.txt containing: >>=20 >> over_voltage=3D6=20 >> arm_freq=3D2000=20 >> sdram_freq_min=3D3200=20 >> force_turbo=3D1 >>=20 >> (The RPi4B has a heat-sink and a fan.) >>=20 >> Note: See later about the RPi4B CPU features. >>=20 >>=20 >> MACCHIATObin Double Shot (older first), Cortex-A72's: >>=20 >> # openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 50808.49k 58466.08k 60769.11k 61444.92k = 61767.94k 61707.61k >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 163579.14k 456319.27k 786544.01k 940234.41k = 1003230.55k 1005671.31k >>=20 >>=20 >> HoneyComb (older first), Cortex-A782's: >>=20 >> # openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 57659.60k 64599.05k 67719.81k 68373.74k = 68724.24k 68793.80k >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 177925.57k 502311.65k 866287.95k 1036500.35k = 1106598.06k 1106721.91k >>=20 >> Rock64 (older first), Cortex-A53's: >>=20 >> # openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 18378.23k 23401.45k 24834.99k 25206.10k = 25337.86k 25258.19k >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 52711.29k 163586.49k 318738.69k 420277.93k = 461373.44k 463192.06k >>=20 >>=20 >> OPi+2E (older first), Cortex-A7's (so armv7): >>=20 >> # openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 9343.10k 11156.39k 11827.64k 11995.30k = 12025.86k 12031.32k >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 11013.41k 13598.44k 14034.26k 15045.97k = 15262.90k 15302.66k >>=20 >>=20 >>=20 >> For reference: >>=20 >> For the RPi4B examples (2 notes added): >>=20 >> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 >> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >> Instruction Set Attributes 0 =3D >> *** NOTE the lack of ",SHA2,SHA1,AES+PMULL" above *** >> Instruction Set Attributes 1 =3D <> >> Processor Features 0 =3D >> Processor Features 1 =3D <> >> Memory Model Features 0 =3D >> Memory Model Features 1 =3D <8bit VMID> >> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >> Debug Features 0 =3D >> Debug Features 1 =3D <> >> Auxiliary Features 0 =3D <> >> Auxiliary Features 1 =3D <> >> AArch32 Instruction Set Attributes 5 =3D >> *** NOTE the lack of ",SHA2,SHA1,AES+VMULL" above *** >> AArch32 Media and VFP Features 0 =3D >> AArch32 Media and VFP Features 1 =3D >>=20 >> For the MACCHIATObin Double Shot examples: >>=20 >> CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 >> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <> >> Processor Features 0 =3D >> Processor Features 1 =3D <> >> Memory Model Features 0 =3D >> Memory Model Features 1 =3D <8bit VMID> >> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >> Debug Features 0 =3D >> Debug Features 1 =3D <> >> Auxiliary Features 0 =3D <> >> Auxiliary Features 1 =3D <> >> AArch32 Instruction Set Attributes 5 =3D = >> AArch32 Media and VFP Features 0 =3D >> AArch32 Media and VFP Features 1 =3D >>=20 >>=20 >> For the HoneyComb examples: >>=20 >> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 >> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <> >> Processor Features 0 =3D >> Processor Features 1 =3D <> >> Memory Model Features 0 =3D >> Memory Model Features 1 =3D <8bit VMID> >> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >> Debug Features 0 =3D >> Debug Features 1 =3D <> >> Auxiliary Features 0 =3D <> >> Auxiliary Features 1 =3D <> >> AArch32 Instruction Set Attributes 5 =3D = >> AArch32 Media and VFP Features 0 =3D >> AArch32 Media and VFP Features 1 =3D >>=20 >>=20 >>=20 >>=20 >> For the Rock64 examples: >>=20 >> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 >> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <> >> Processor Features 0 =3D >> Processor Features 1 =3D <> >> Memory Model Features 0 =3D >> Memory Model Features 1 =3D <8bit VMID> >> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >> Debug Features 0 =3D >> Debug Features 1 =3D <> >> Auxiliary Features 0 =3D <> >> Auxiliary Features 1 =3D <> >> AArch32 Instruction Set Attributes 5 =3D = >> AArch32 Media and VFP Features 0 =3D >> AArch32 Media and VFP Features 1 =3D >> C >>=20 >>=20 >> For the OPi+2E examples: >>=20 >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >> CPU Features:=20 >> Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, >> PXN, LPAE, Coherent Walk >> Optional instructions:=20 >> SDIV/UDIV, UMULL, SMULL, SIMD(ext) >> LoUU:2 LoC:3 LoUIS:2=20 >> Cache level 1: >> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >> 32KB/32B 2-way instruction cache Read-Alloc >> Cache level 2: >> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >=20 > Note: as the issue applies to stable/13 and main [so: 14] > (for example), I continue to use the freebsd-arm list > instead of a list that reports commits to stable/* but > not to main. >=20 > Relative to: >=20 > #define HWCAP_FP 0x00000001 > #define HWCAP_ASIMD 0x00000002 > #define HWCAP_EVTSTRM 0x00000004 > #define HWCAP_AES 0x00000008 > #define HWCAP_PMULL 0x00000010 > #define HWCAP_SHA1 0x00000020 > #define HWCAP_SHA2 0x00000040 > #define HWCAP_CRC32 0x00000080 >=20 > The single-bit enabled OPENSSL_armcap that gets the slow > result is: >=20 > # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 28427.04k 30712.32k 31446.00k 31683.40k = 31829.10k 31839.55k >=20 > The illegal instruction ones for aes-256-gcm were: >=20 > # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm > Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 > env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm > Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 > (sha256 does not match for what is illegal.) >=20 > Ignoring the illegal-instruction producing bits, HWCAP_FP mixed > with any one of the other bits was also similarly slow. >=20 > As for all the non-illegal-instruction producing bits: also similarly > slow: >=20 > # env OPENSSL_armcap=3D219 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 28922.63k 30711.51k 31522.15k 31722.15k = 31788.97k 31845.03k >=20 > Disabling just HWCAP_FP from that got the fast category of > result: >=20 > # env OPENSSL_armcap=3D218 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 49543.14k 58068.22k 60236.56k 60724.37k = 61216.09k 61212.99k >=20 >=20 > As for sha256 . . . >=20 > # env OPENSSL_armcap=3D0 openssl speed -evp sha256 > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > sha256 22434.19k 59895.91k 117258.16k 156264.31k = 172624.81k 173848.52k >=20 > (I'll not list all the similar performing ones but > will list all illegal-instruction producing ones.) >=20 > # env OPENSSL_armcap=3D4 openssl speed -evp sha256 > Doing sha256 for 3s on 16 size blocks: 4082055 sha256's in 2.99s > Doing sha256 for 3s on 64 size blocks: 2752520 sha256's in 3.02s > Doing sha256 for 3s on 256 size blocks: 1372584 sha256's in 3.03s > Doing sha256 for 3s on 1024 size blocks: 470215 sha256's in 3.11s > Doing sha256 for 3s on 8192 size blocks: 64700 sha256's in 3.07s > Doing sha256 for 3s on 16384 size blocks: 31847 sha256's in 3.00s > Illegal instruction (core dumped) >=20 > # env OPENSSL_armcap=3D16 openssl speed -evp sha256 > Doing sha256 for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 > (16 worked for aes-256-gcm but 32 did not.) >=20 > So: no significantly slower examples of single enabled > bit cases. >=20 > No (non-illegal-instruction) 2-enabled-bits examples were > dissimilar for the speed. Incorrect description of what I tested: I testd only 2-bit combinations involving HWCAP_FP being enabled. (Same as for aes-256-gcm .) > For reference (avoiding illegal-instructions): >=20 > # env OPENSSL_armcap=3D235 openssl speed -evp sha256 > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > sha256 23185.66k 62689.73k 125814.72k 167981.88k = 187833.65k 188968.95k >=20 > So: also similar speed. >=20 > Need any other specific bit combinations? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 24 23:25:46 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 D1DD3189DAF2 for ; Wed, 24 Nov 2021 23:26:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4Hzxvr4rKmz3lKH for ; Wed, 24 Nov 2021 23:26:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637796353; bh=ravsKM7T8R4YAShdXw/8UXlx8cmEv7ht759V1zT5uTU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jMQUpYGSBXN5TblDysqhR0uFmZdhVyOeJB9doIzbvN6684U6R7X/byy5+53nRW70DTkdq5VQKdUOexD1usf6ZF7jGp7ALg2QBKjTGhaAxK8TW+Y2gDYBABTgC2722tHEbA4lQZWvRq9vC8RSqb0VLeMzhYoazOj9ns7fRM7iPxx8AupI7QzlkOq7o4/WjxKPBm+gBfw9MalupOnQrS+VbHA3GJmmvftZIbkZnfyZoPdw14VS/5RAOgfFTMqWymtulMa1LsJ/lHiQJUqc35V1aTNn+quvrpJhbxGStz/EoJH5FAzAr5gJkWs9jutzPi2aYfPZRhrzFCc/aYJjLxN8Mw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637796353; bh=oIA5y36gmZMpjQC1OBAcBD7ImWO8LuMlFpxME+kGLh2=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NF0d/6nzuBDrjkf/OlmaIdV+INtVZG7zVpVJcDPrhzd9/Fkd+6pRNfZBi0s85jjNyX6sMsTlLt1vk6bR76mAamayHg//YWwyA2du6sgRpgjcRKP8XqTuF2tiXOywfGHtc/yVAZV60HoBZT6SrdPyala+oFvQ8EkqyzCUFBIn15mCRhZtGdAkYKDo1hitAX7/Zqz6+MjLlkp0ApLgTkwy21J49lWpgh3gP1eAmhhAH3RNuTeYaKFYK1W4sFHWjDXEYQsZmR24ev+exem0wKzwr/JomzTlMcpBWbhZ1twlJ3he0SZEe8PN2EDSmMx2Qlsohv0mz0sLVJpXvy9gvmQs6g== X-YMail-OSG: 6usYMfoVM1k8BCOPEJSG4vT3rtBw2uPXPtnBi8KucSCDi52IbnPT965r4NlH2GH np0JJRHy5zP0HNWUEa1GU_wVdzBUzNJFgrcY3E7rYqNA2TYjTatSLut47.iQPt0SH.Vb96CxsnvV hsn8wbWCVX2GW7N9Az46i8KmjELFKwW9rHecBkAi_wSsYX.LwfSqSFs8R3TMZMTJwwhOm4r4cQlR _q5ULQVbyKsQ4AUHDlEh87TX7JP3p4F.XMMWa.7G2YHjEJiuzB8e8pvlqj9vTSq.WH00kCpuEbdW zfWqwCB9c7iiQvgrPjyZJ_jBs8YaR6II8n2w.sDlQ5MNejyGREpsNfOaxKrSx6YCymngwQ0jhVaT VRzrkBiacnPkuICoRbDzKUKPkECV.veDzOPn_kGnfkTPLvTZ27p4xO2rTXfYSqSdcm7UbG_0JDXz lwWD04f6PiBsuVFW3.x3UNnt0huFC1Qmz8d28jgOU7P0GNtIV72JZfz_l.5lYWNhq9dm8EpR3pIj sYNd0AF6uyKSASAuxWaCMCcPxAwQD6.VuCJi9zJfZ7jr8T70czo3oS6fk7DUZa5Ha2CAJoxcDSuY zPrlDq4w80cfOkSizcEsFKvXopFloUzPVpxDzt0WNj5lRUuIOFrCXUxDSGIC5mxLtu9illgvxmpO ZKVlJvwmSATv9qiQ9H9ciKKfI54ptwBP9cDjyFSMesHFVWG60GGWzuw5P_XE_h43jQt9jJxbovIP NvL4Nl7s2atpMjqdywLkEzdUAH_jTibrHy2t4gxh0UIbIqC1v0IY.H2Tt9b7QBFKKCZI3adI.y7a CZL6y1oiNUMMTqS6RpTnP2Rx1WwhGk2TSnVyPXBoRGwyBR0JfVyxMM7zn1p4Brk4yI0LYHLjnhQa jJBC.TAdPD9rz7lSjhpV5LMN6jdBsTq0QLjcBQaS1ya25w2FmBF.S4MQmoX6c0j9Gj43upOcf._n PAGheo8yS.5ABNOp8hH1A6F8WEvNK9KVcdLlfdQb_ySpil3E9EcBHRnl9KJrQxZUwCsqeCzu4r6U GA189hMddxDcKGK1WkfgXjhfXCHn1Z27P993YeaFt6DYEfHmfilN66zNajLOmSj84580qQ.DFbs. llTHGXC.2f2jkxwdPnoVf9PUm.TSEBlg1cb0U8Lhj454W5c4Lwf_WCnahmm3meKqwxiu8MKSEDYx 9cyVHUpTc18GwAbHI0tDKpTflKjmORjavossUSF9aQMlh.1uTHv73641t230t.W2gsdjHkJjf8aT xbjkJL1jjcNBd9VJFZ0IlxsGnO.REX_kbji3NOBx_UP5ymY0LBRu2iazE8b_HZ5Ws7hU7vxAPdY2 nZjv5X3f6964CTEixG84Jz22tzaNsjSg03EodKY2WKRYO6dhRFYeqHHkrLEQ062hzmK5JdZdjmnY sy3X2s0R8GWHXQAGX.IOln60gmJCfRVCRB49n70K8iB2wUjNgHSCQO1GDfRIPdfcnxN1BCWg0zsG JcDE5hQbUxNwkkXiS6p0p9AttQjsv3dSsH6W2gc_5WfgnuVZ6FIPsfAer28DXVFn4EmCLGtg38LR SmCHIcwoGSKqpkPWrw.uGALaR901HU6tfe2T43k3LHaac8gspgKzYNephyHm_Q8XvzSDkrFYG3rj OHip1z4znIt2bbDLeK8xbNUxw78LN2owZQ.eYuFPYNILRPI9TrVzjE3qTE0WBeB2s.vid7aX8CG7 FWRfo9MJ21_57v5qwlOYXd5AwGSpMCVH3fLQFsPigRQ2vAcna488qBaz75j463MUwoBbXQRbePU0 9gdq0MblxVfVH90w7qkJNBNINn64d2XQNO4ewYy8htOFeuxVaxX.Q0A.ZTQ9eAjMERzNR3q8piVb 1LYEwpgO_GsSE9emPWgsqmkstZrGH8VfH3ZgkJUCqXAwGacg85j3N.2Cx7cIyFFf54W3MYPoCgTv ZNljr3wyYuMzxABpAFIbX.oH4mpHISwhnMyow6gKVjIJnlm8sUWTrH_gB9MGpd7VAGyZmjDw1etL H6LFPULLJO1lOs_Fru.zMT5.O3h59JbeGuq1INiPoJA.FI3mRvp7RxJgt48.gLsxXSEVKLrlP8e7 7xmhi5Qb6RC2WdJLJduNGsoaKhmlHojSh8K_TKdNq.HaOSA74ygz_SHW3254Lq_ibU8UgNG3ZEJ4 0FvxrgDWI5PI.e8804pcHtCq23JV5.JL6ItrD1e3.3WvwMxhjEF4xxmx5D7XDdhWRTBkylN7nV2W nMX3SSYge.my1qdM4cQRoBF1fnXRMFYWV3_dpN.ofOzEFww-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Nov 2021 23:25:53 +0000 Received: by kubenode503.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 24b767a362038dd9f21e6c3ab4b6c668; Wed, 24 Nov 2021 23:25:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: git: 32a2fed6e71f - stable/13 - openssl: Fix detection of ARMv7 and ARM64 CPU features Date: Wed, 24 Nov 2021 15:25:46 -0800 References: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> To: allanjude@freebsd.org, "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <059B833D-6C04-4171-A3C6-737CD5EFC01A@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hzxvr4rKmz3lKH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jMQUpYGS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; 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.68.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 13:23, Mark Millard wrote: > On 2021-Nov-24, at 13:19, Mark Millard wrote: >=20 >> On 2021-Nov-24, at 01:51, Mark Millard wrote: >>=20 >>> [Actually, the main [so: 14] equivalent.] >>>=20 >>> All Cortex-A72 based . . . >>>=20 >>> First, older system versions (before that update) >>> then after the update: >>>=20 >>>=20 >>> RPi4B 8 GiByte (older FreeBSD first, otherwise new), >>> Cortex-A72's: >>>=20 >>> # openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 51925.92k 58449.46k 60430.32k 61050.13k = 61180.98k 61482.75k >>>=20 >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 28880.07k 30837.33k 31630.29k 31855.62k = 31921.54k 32034.53k >>>=20 >>> So: slowed down, unlike the other examples below. >>>=20 >>> # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 51894.33k 58540.45k 60815.22k 61534.47k = 61906.84k 62042.10k >>>=20 >>> So: back to the prior speed. >>>=20 >>> But all these are based on config.txt containing: >>>=20 >>> over_voltage=3D6=20 >>> arm_freq=3D2000=20 >>> sdram_freq_min=3D3200=20 >>> force_turbo=3D1 >>>=20 >>> (The RPi4B has a heat-sink and a fan.) >>>=20 >>> Note: See later about the RPi4B CPU features. >>>=20 >>>=20 >>> MACCHIATObin Double Shot (older first), Cortex-A72's: >>>=20 >>> # openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 50808.49k 58466.08k 60769.11k 61444.92k = 61767.94k 61707.61k >>>=20 >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 163579.14k 456319.27k 786544.01k 940234.41k = 1003230.55k 1005671.31k >>>=20 >>>=20 >>> HoneyComb (older first), Cortex-A782's: >>>=20 >>> # openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 57659.60k 64599.05k 67719.81k 68373.74k = 68724.24k 68793.80k >>>=20 >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 177925.57k 502311.65k 866287.95k 1036500.35k = 1106598.06k 1106721.91k >>>=20 >>> Rock64 (older first), Cortex-A53's: >>>=20 >>> # openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 18378.23k 23401.45k 24834.99k 25206.10k = 25337.86k 25258.19k >>>=20 >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 52711.29k 163586.49k 318738.69k 420277.93k = 461373.44k 463192.06k >>>=20 >>>=20 >>> OPi+2E (older first), Cortex-A7's (so armv7): >>>=20 >>> # openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 9343.10k 11156.39k 11827.64k 11995.30k = 12025.86k 12031.32k >>>=20 >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 11013.41k 13598.44k 14034.26k 15045.97k = 15262.90k 15302.66k >>>=20 >>>=20 >>>=20 >>> For reference: >>>=20 >>> For the RPi4B examples (2 notes added): >>>=20 >>> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 >>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>> Instruction Set Attributes 0 =3D >>> *** NOTE the lack of ",SHA2,SHA1,AES+PMULL" above *** >>> Instruction Set Attributes 1 =3D <> >>> Processor Features 0 =3D >>> Processor Features 1 =3D <> >>> Memory Model Features 0 =3D >>> Memory Model Features 1 =3D <8bit VMID> >>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>> Debug Features 0 =3D >>> Debug Features 1 =3D <> >>> Auxiliary Features 0 =3D <> >>> Auxiliary Features 1 =3D <> >>> AArch32 Instruction Set Attributes 5 =3D >>> *** NOTE the lack of ",SHA2,SHA1,AES+VMULL" above *** >>> AArch32 Media and VFP Features 0 =3D >>> AArch32 Media and VFP Features 1 =3D >>>=20 >>> For the MACCHIATObin Double Shot examples: >>>=20 >>> CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 >>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>> Instruction Set Attributes 0 =3D >>> Instruction Set Attributes 1 =3D <> >>> Processor Features 0 =3D >>> Processor Features 1 =3D <> >>> Memory Model Features 0 =3D >>> Memory Model Features 1 =3D <8bit VMID> >>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>> Debug Features 0 =3D >>> Debug Features 1 =3D <> >>> Auxiliary Features 0 =3D <> >>> Auxiliary Features 1 =3D <> >>> AArch32 Instruction Set Attributes 5 =3D = >>> AArch32 Media and VFP Features 0 =3D >>> AArch32 Media and VFP Features 1 =3D >>>=20 >>>=20 >>> For the HoneyComb examples: >>>=20 >>> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 >>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>> Instruction Set Attributes 0 =3D >>> Instruction Set Attributes 1 =3D <> >>> Processor Features 0 =3D >>> Processor Features 1 =3D <> >>> Memory Model Features 0 =3D >>> Memory Model Features 1 =3D <8bit VMID> >>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>> Debug Features 0 =3D >>> Debug Features 1 =3D <> >>> Auxiliary Features 0 =3D <> >>> Auxiliary Features 1 =3D <> >>> AArch32 Instruction Set Attributes 5 =3D = >>> AArch32 Media and VFP Features 0 =3D >>> AArch32 Media and VFP Features 1 =3D >>>=20 >>>=20 >>>=20 >>>=20 >>> For the Rock64 examples: >>>=20 >>> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 >>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> >>> Instruction Set Attributes 0 =3D >>> Instruction Set Attributes 1 =3D <> >>> Processor Features 0 =3D >>> Processor Features 1 =3D <> >>> Memory Model Features 0 =3D >>> Memory Model Features 1 =3D <8bit VMID> >>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>> Debug Features 0 =3D >>> Debug Features 1 =3D <> >>> Auxiliary Features 0 =3D <> >>> Auxiliary Features 1 =3D <> >>> AArch32 Instruction Set Attributes 5 =3D = >>> AArch32 Media and VFP Features 0 =3D >>> AArch32 Media and VFP Features 1 =3D >>> C >>>=20 >>>=20 >>> For the OPi+2E examples: >>>=20 >>> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >>> CPU Features:=20 >>> Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, >>> PXN, LPAE, Coherent Walk >>> Optional instructions:=20 >>> SDIV/UDIV, UMULL, SMULL, SIMD(ext) >>> LoUU:2 LoC:3 LoUIS:2=20 >>> Cache level 1: >>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >>> 32KB/32B 2-way instruction cache Read-Alloc >>> Cache level 2: >>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >>=20 >> Note: as the issue applies to stable/13 and main [so: 14] >> (for example), I continue to use the freebsd-arm list >> instead of a list that reports commits to stable/* but >> not to main. >>=20 >> Relative to: >>=20 >> #define HWCAP_FP 0x00000001 >> #define HWCAP_ASIMD 0x00000002 >> #define HWCAP_EVTSTRM 0x00000004 >> #define HWCAP_AES 0x00000008 >> #define HWCAP_PMULL 0x00000010 >> #define HWCAP_SHA1 0x00000020 >> #define HWCAP_SHA2 0x00000040 >> #define HWCAP_CRC32 0x00000080 >>=20 >> The single-bit enabled OPENSSL_armcap that gets the slow >> result is: >>=20 >> # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 28427.04k 30712.32k 31446.00k 31683.40k = 31829.10k 31839.55k >>=20 >> The illegal instruction ones for aes-256-gcm were: >>=20 >> # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm >> Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >>=20 >> env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm >> Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >>=20 >> (sha256 does not match for what is illegal.) >>=20 >> Ignoring the illegal-instruction producing bits, HWCAP_FP mixed >> with any one of the other bits was also similarly slow. >>=20 >> As for all the non-illegal-instruction producing bits: also similarly >> slow: >>=20 >> # env OPENSSL_armcap=3D219 openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 28922.63k 30711.51k 31522.15k 31722.15k = 31788.97k 31845.03k >>=20 >> Disabling just HWCAP_FP from that got the fast category of >> result: >>=20 >> # env OPENSSL_armcap=3D218 openssl speed -evp aes-256-gcm >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> aes-256-gcm 49543.14k 58068.22k 60236.56k 60724.37k = 61216.09k 61212.99k >>=20 >>=20 >> As for sha256 . . . >>=20 >> # env OPENSSL_armcap=3D0 openssl speed -evp sha256 >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> sha256 22434.19k 59895.91k 117258.16k 156264.31k = 172624.81k 173848.52k >>=20 >> (I'll not list all the similar performing ones but >> will list all illegal-instruction producing ones.) >>=20 >> # env OPENSSL_armcap=3D4 openssl speed -evp sha256 >> Doing sha256 for 3s on 16 size blocks: 4082055 sha256's in 2.99s >> Doing sha256 for 3s on 64 size blocks: 2752520 sha256's in 3.02s >> Doing sha256 for 3s on 256 size blocks: 1372584 sha256's in 3.03s >> Doing sha256 for 3s on 1024 size blocks: 470215 sha256's in 3.11s >> Doing sha256 for 3s on 8192 size blocks: 64700 sha256's in 3.07s >> Doing sha256 for 3s on 16384 size blocks: 31847 sha256's in 3.00s >> Illegal instruction (core dumped) >>=20 >> # env OPENSSL_armcap=3D16 openssl speed -evp sha256 >> Doing sha256 for 3s on 16 size blocks: Illegal instruction (core = dumped) >>=20 >> (16 worked for aes-256-gcm but 32 did not.) >>=20 >> So: no significantly slower examples of single enabled >> bit cases. >>=20 >> No (non-illegal-instruction) 2-enabled-bits examples were >> dissimilar for the speed. >=20 > Incorrect description of what I tested: I testd only > 2-bit combinations involving HWCAP_FP being enabled. > (Same as for aes-256-gcm .) >=20 >> For reference (avoiding illegal-instructions): >>=20 >> # env OPENSSL_armcap=3D235 openssl speed -evp sha256 >> . . . >> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >> sha256 23185.66k 62689.73k 125814.72k 167981.88k = 187833.65k 188968.95k >>=20 >> So: also similar speed. >>=20 >> Need any other specific bit combinations? >=20 chroot'd into a armv7 context on the RPi4B gets different results for aes-256-gcm: having the HWCAP_FP enabled speed things up. # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 35983.70k 41987.64k 44077.00k 44693.54k = 44685.68k 44717.40k # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm . . . type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes 16384 bytes aes-256-gcm 55339.93k 64644.18k 68001.37k 72708.53k = 74237.56k 74247.87k # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) # env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) In general OPENSSL_armcap=3D2**N was slower and OPENSSL_armcap=3D(2**N)+1 was faster in a similar manor. Similarly for 218 vs. 219. sha256 did not show such a distinction. The armv7 illegal-instruction generation cases for sha256 were: # env OPENSSL_armcap=3D4 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: 3313106 sha256's in 3.02s Doing sha256 for 3s on 64 size blocks: 2403376 sha256's in 3.02s Doing sha256 for 3s on 256 size blocks: 1289917 sha256's in 3.02s Doing sha256 for 3s on 1024 size blocks: 446543 sha256's in 3.00s Doing sha256 for 3s on 8192 size blocks: 64123 sha256's in 3.03s Doing sha256 for 3s on 16384 size blocks: 32756 sha256's in 3.08s Illegal instruction (core dumped) # env OPENSSL_armcap=3D16 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: Illegal instruction (core dumped) Note: I focused on large scale differences in general. I was not trying to find the optimal combination. For that I'd also have to test out repeatability/variability for each OPENSSL_armcap value that was in the faster range. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 00:13:11 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 643361898CA6 for ; Thu, 25 Nov 2021 00:13:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4HzyyR1H7tz4cFv for ; Thu, 25 Nov 2021 00:13:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637799198; bh=y3QmrXxri32nhf98decydJd8FPXrT/nYSNp6VXvfU6c=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=EN7f+660+vcP+4eKpKpL1cXYHfIPjIu/o5PJtwcJFxZZfDQr/4xeFOZAC84136zgtQhFzIsK5eOAZi8wm7hqI1GtQOvYS+rxv59o9wlhpgfExgNxvLkgI8ap+OavqsIRAuEaTfGSh087KaGtH80a9dpR6q+NjxO+pdAQTFKhnA7umxTPvCBYiVArrBmjU2SOb+w6HZ+5lLldBwV4F62szYV9k4PCL2Vob4FdutOZEf+lYHmokxo04OxH0nTfEpf/8IVgq+eoFaZ6XJACDzEqtPcgSmhXv4fXgNGUZdwl4jpmdcgD3HBz2cmv+v5qYr1JmkxgYm+toIgGPppobo/7ig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637799198; bh=RFOMaVT47VjxH6Vggpoamj5Cybs6mLnVj89/7XdEq5E=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CcmQnUu4PYOoIF1rrHI2NOHe9peVCR4ArUpwpxOCcl5nlZ+2bLyLxhZX78fwVPgZRmpjaY21bofzgaz0c44BWirOpLiC2fxXFd6e540aoh6Qh2A8UkgEOiX8C1XjlHkMZMVOyBBIRgajnjJr8iyKfYb9+8rdky4iIPHhyJFsH1uK1tChQ2VlHpDVYf1DIWTheFQQ6pe5NEs+rGOEFAK/F9TJC5hQktUM78+fVQwzVzdPyKruWc0dKsfqc/QIcCo11DT+rukpsTq7/LN6Olr5y4rtSOqO6lUewhuPx0antQfvHixBGnqTBUA61TtOoAmveAFPG8bxPt/Gt8uZEXw+lQ== X-YMail-OSG: 6BDl608VM1nm.O6RGO.GNbBy1BhklHwKILeEg3JlFQpXu6wHk1ZH9s_iB7v4WWi ESe3Dllnen1VtHm_LQEuOs9xKd_vW6to_rGAVi3RyBwnRZKzz.CndnyIDcP1HtB3J8Vdc9SkY_te 2sQmJPhYs3AU5a9LiSUM2_PP2ouHBOhklItdbv4NlAOo0tD9ebtglI2Q4XO_s.gRFPNGWUgtWm2x .ZAF3y1Bh1z85PcbIGF6Kr_OdBRMEWsEZvV1s1nxOgrHVoci1KXDWTV.rqHtW7tZY1BSjAkHddJA oRqpjlnQdoXIY8MstwMhmMD68OkwsCMu6_ga5odEx34kz0p5ZerugFwWhRWGFbczBUXmFLUo2vrM 7gRjU3c2LFfK1JIJafRJ3dBhaHy3COCFGuZ2JPWzdHSDa.9pSpTZytdiihHOgZZ_M3CWHpQchay0 smaK6VeNCyPzUO_pAVE9L0FFY14sBD99rvSX44Do2.JcE7d2xyB9JT97gw.vH36GV96C5G0ZZLGv 57A5QDT7Xz9igL8h7tihhWaM_PaxAl21jLZ_HDqMAUr8oMwg6NLvc78yV.xW0G5LCgfi1gi9rM6H sDbyBmeLRk9rv.zTZWDRR7fTBOpeagwQ7kPbtGtKNangzU88He8yKjpQ7_hqDodoccVNjhoKmNC2 y1LPjQt2STU5HU8HrvwV5f9o1xts8gsEc.GwUPEUuD48w1Uel7giHNQpNNlMMe1W4qQixlHM0DcH _hW_o3VbLcau3Q3gJZs74rhla52WCxHv8HnwQvybRC74Doxyw2_zJBfdfHGt3o27rxNc0_rfVJXL J5w7vszm4nG3Cvv6qez_QyM6NcR8Xl657o3ITRchAatxxoh9pADugWo..IIx130fBuhM9oQ0rCp8 WB4QV8h6LCQojpneNUYoEF1TV43hQlGUWAFx_j2gSozheE.zs3iE_iVaTa1p7A7eWlB2BggPplfb sfmR9J5x6YDkBkYv91bVCwwfYQ8py7hTpRIdi5f_z1NsKbnnNKBqxPDNnMQdfwJkEjKV.cRStkLe HZNPmZeeSZDApjmcOzlDxa73V2e2EMG0eusGFZanRHGJF9dKRLbKoEGejykRtrRQQyY_ae0iNJRK z0EyW0g0ahPE2BrH08bGyW1bqCxzmhfPprZip0IQ9a_00c35_P9eXeR6j7B427S9nSmyKmhoFEOW nYwE9EDksF54RsGx4it_TjAet5QT4JCV2MHbGijBkJujQCdSTCJ62bipn6lVXlg7_G_kaYVQrEON Z8MwZZ7Q_XlKhDlWuGvApcvgTF6ZyhVjPZaJ8hEwCP8B8_LmkAyzJ3GoucUYYhfbNQ5Vv2L5Wlxp dV_9i2Cpzm382WJLw5ERiCwNSBkSLZW.XJEq570IBxRaWbpj1iFQK24RmAGc1IO9P.X8lXrUhCOe HfEQrp2jkkrTjk0B09sVL2sLoDgOEiIj1OwshymQhGSRcMM4wjDEeIPkQ8GTJxMgwt.vUw7dw18E gW3FN0xhqrbHapzyqTX6Bh02NFdJz0OT54gGoIENAJcmujjwyueZB9jVtvhKrz.BORtrFJ3Q4RJt z9ba9DlsWHZ_zvfPtbMPoCT.viWWIK99ck1ieC4g_jbNnsqshcPJdhyN5tdY0w6iRF8hjOYyElMP OehJ9kpTmW179HkPyOvZOLlpCHSuM0ArMiHNVDUAAS8UnkFJc2hzYQhSwtTyPnFwb1ZQYRreRDWA _LU59q5Z5RElJffb_gyhGn8psOzHNShbvvnhZ9Pf50XW_8fzoKL51EshCOKMZ4AFfXo_sZNisXow uqnvzwyEVe14C4aHVLv8X4xkwEXxq7fwMf86iU5OdFOIxv1yNqAPN0lGPefm2kpHM7QoqpXG2RK4 ebiThchPpVgXeHB_Eyc3_qfn2uRL8jy97lJl4X4SlXF5_Rum53dJampxGpKhQGxSftbnaX7uEGgv bK.hIWwztccg3kLaRuJ5e6CpQQejlta_mK1bZRomY9TBqdxJC161NKR_FukP1OaINemZc4LIRBwM Tn2lMKKjPFd1yUFq4KbjDSFEa8fBn6KthJc_javf86.nHGUyyvStvJ7V8wn0yGR4ilzxhuIexqTf lFdRpeZAIxmr_8e3OTQUL6CbcvP2tt3o.5GB0RT4fr2eqjq9Eqsku7WQyDGzJYCXU2liZV83m3oy 1h2fJjyqSf28mPjbvY8YZ9IAp9tk5AGPYLbkeHiKGWPHC2xnCc9sudhea_TGJPwXgB4IIdenx_m8 Q0icb_AgXVCGjFs055HrRNzc4CBDO01I93Ahm7EkzjiFySiB.m0gbsFUj1QdYg2C3XRWqMvmEqiu sUi9s46pJmE1MQwIOlcACEMo- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Nov 2021 00:13:18 +0000 Received: by kubenode537.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 83f1962b8367c0681299ba25802a93b8; Thu, 25 Nov 2021 00:13:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: git: 32a2fed6e71f - stable/13 - openssl: Fix detection of ARMv7 and ARM64 CPU features Date: Wed, 24 Nov 2021 16:13:11 -0800 References: <0CEA37B8-CE7F-4BAE-92B7-E71C5FD1BC22@yahoo.com> <059B833D-6C04-4171-A3C6-737CD5EFC01A@yahoo.com> To: allanjude@freebsd.org, "freebsd-arm@freebsd.org" In-Reply-To: <059B833D-6C04-4171-A3C6-737CD5EFC01A@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HzyyR1H7tz4cFv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EN7f+660; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.84:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(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.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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.64.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 15:25, Mark Millard wrote: > On 2021-Nov-24, at 13:23, Mark Millard wrote: >=20 >> On 2021-Nov-24, at 13:19, Mark Millard wrote: >>=20 >>> On 2021-Nov-24, at 01:51, Mark Millard wrote: >>>=20 >>>> [Actually, the main [so: 14] equivalent.] >>>>=20 >>>> All Cortex-A72 based . . . >>>>=20 >>>> First, older system versions (before that update) >>>> then after the update: >>>>=20 >>>>=20 >>>> RPi4B 8 GiByte (older FreeBSD first, otherwise new), >>>> Cortex-A72's: >>>>=20 >>>> # openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 51925.92k 58449.46k 60430.32k 61050.13k = 61180.98k 61482.75k >>>>=20 >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 28880.07k 30837.33k 31630.29k 31855.62k = 31921.54k 32034.53k >>>>=20 >>>> So: slowed down, unlike the other examples below. >>>>=20 >>>> # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 51894.33k 58540.45k 60815.22k 61534.47k = 61906.84k 62042.10k >>>>=20 >>>> So: back to the prior speed. >>>>=20 >>>> But all these are based on config.txt containing: >>>>=20 >>>> over_voltage=3D6=20 >>>> arm_freq=3D2000=20 >>>> sdram_freq_min=3D3200=20 >>>> force_turbo=3D1 >>>>=20 >>>> (The RPi4B has a heat-sink and a fan.) >>>>=20 >>>> Note: See later about the RPi4B CPU features. >>>>=20 >>>>=20 >>>> MACCHIATObin Double Shot (older first), Cortex-A72's: >>>>=20 >>>> # openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 50808.49k 58466.08k 60769.11k 61444.92k = 61767.94k 61707.61k >>>>=20 >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 163579.14k 456319.27k 786544.01k 940234.41k = 1003230.55k 1005671.31k >>>>=20 >>>>=20 >>>> HoneyComb (older first), Cortex-A782's: >>>>=20 >>>> # openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 57659.60k 64599.05k 67719.81k 68373.74k = 68724.24k 68793.80k >>>>=20 >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 177925.57k 502311.65k 866287.95k 1036500.35k = 1106598.06k 1106721.91k >>>>=20 >>>> Rock64 (older first), Cortex-A53's: >>>>=20 >>>> # openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 18378.23k 23401.45k 24834.99k 25206.10k = 25337.86k 25258.19k >>>>=20 >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 52711.29k 163586.49k 318738.69k 420277.93k = 461373.44k 463192.06k >>>>=20 >>>>=20 >>>> OPi+2E (older first), Cortex-A7's (so armv7): >>>>=20 >>>> # openssl speed -evp aes-256-gcm >>>> . . . >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 9343.10k 11156.39k 11827.64k 11995.30k = 12025.86k 12031.32k >>>>=20 >>>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>>> aes-256-gcm 11013.41k 13598.44k 14034.26k 15045.97k = 15262.90k 15302.66k >>>>=20 >>>>=20 >>>>=20 >>>> For reference: >>>>=20 >>>> For the RPi4B examples (2 notes added): >>>>=20 >>>> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 >>>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>>> Instruction Set Attributes 0 =3D >>>> *** NOTE the lack of ",SHA2,SHA1,AES+PMULL" above *** >>>> Instruction Set Attributes 1 =3D <> >>>> Processor Features 0 =3D >>>> Processor Features 1 =3D <> >>>> Memory Model Features 0 =3D >>>> Memory Model Features 1 =3D <8bit VMID> >>>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>>> Debug Features 0 =3D >>>> Debug Features 1 =3D <> >>>> Auxiliary Features 0 =3D <> >>>> Auxiliary Features 1 =3D <> >>>> AArch32 Instruction Set Attributes 5 =3D >>>> *** NOTE the lack of ",SHA2,SHA1,AES+VMULL" above *** >>>> AArch32 Media and VFP Features 0 =3D >>>> AArch32 Media and VFP Features 1 =3D >>>>=20 >>>> For the MACCHIATObin Double Shot examples: >>>>=20 >>>> CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 >>>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>>> Instruction Set Attributes 0 =3D >>>> Instruction Set Attributes 1 =3D <> >>>> Processor Features 0 =3D >>>> Processor Features 1 =3D <> >>>> Memory Model Features 0 =3D >>>> Memory Model Features 1 =3D <8bit VMID> >>>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>>> Debug Features 0 =3D >>>> Debug Features 1 =3D <> >>>> Auxiliary Features 0 =3D <> >>>> Auxiliary Features 1 =3D <> >>>> AArch32 Instruction Set Attributes 5 =3D = >>>> AArch32 Media and VFP Features 0 =3D >>>> AArch32 Media and VFP Features 1 =3D >>>>=20 >>>>=20 >>>> For the HoneyComb examples: >>>>=20 >>>> CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 >>>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> >>>> Instruction Set Attributes 0 =3D >>>> Instruction Set Attributes 1 =3D <> >>>> Processor Features 0 =3D >>>> Processor Features 1 =3D <> >>>> Memory Model Features 0 =3D >>>> Memory Model Features 1 =3D <8bit VMID> >>>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>>> Debug Features 0 =3D >>>> Debug Features 1 =3D <> >>>> Auxiliary Features 0 =3D <> >>>> Auxiliary Features 1 =3D <> >>>> AArch32 Instruction Set Attributes 5 =3D = >>>> AArch32 Media and VFP Features 0 =3D >>>> AArch32 Media and VFP Features 1 =3D >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> For the Rock64 examples: >>>>=20 >>>> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 >>>> Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> >>>> Instruction Set Attributes 0 =3D >>>> Instruction Set Attributes 1 =3D <> >>>> Processor Features 0 =3D >>>> Processor Features 1 =3D <> >>>> Memory Model Features 0 =3D >>>> Memory Model Features 1 =3D <8bit VMID> >>>> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> >>>> Debug Features 0 =3D >>>> Debug Features 1 =3D <> >>>> Auxiliary Features 0 =3D <> >>>> Auxiliary Features 1 =3D <> >>>> AArch32 Instruction Set Attributes 5 =3D = >>>> AArch32 Media and VFP Features 0 =3D >>>> AArch32 Media and VFP Features 1 =3D >>>> C >>>>=20 >>>>=20 >>>> For the OPi+2E examples: >>>>=20 >>>> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >>>> CPU Features:=20 >>>> Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, >>>> PXN, LPAE, Coherent Walk >>>> Optional instructions:=20 >>>> SDIV/UDIV, UMULL, SMULL, SIMD(ext) >>>> LoUU:2 LoC:3 LoUIS:2=20 >>>> Cache level 1: >>>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >>>> 32KB/32B 2-way instruction cache Read-Alloc >>>> Cache level 2: >>>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >>>=20 >>> Note: as the issue applies to stable/13 and main [so: 14] >>> (for example), I continue to use the freebsd-arm list >>> instead of a list that reports commits to stable/* but >>> not to main. >>>=20 >>> Relative to: >>>=20 >>> #define HWCAP_FP 0x00000001 >>> #define HWCAP_ASIMD 0x00000002 >>> #define HWCAP_EVTSTRM 0x00000004 >>> #define HWCAP_AES 0x00000008 >>> #define HWCAP_PMULL 0x00000010 >>> #define HWCAP_SHA1 0x00000020 >>> #define HWCAP_SHA2 0x00000040 >>> #define HWCAP_CRC32 0x00000080 >>>=20 >>> The single-bit enabled OPENSSL_armcap that gets the slow >>> result is: >>>=20 >>> # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 28427.04k 30712.32k 31446.00k 31683.40k = 31829.10k 31839.55k >>>=20 >>> The illegal instruction ones for aes-256-gcm were: >>>=20 >>> # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm >>> Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction = (core dumped) >>>=20 >>> env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm >>> Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction = (core dumped) >>>=20 >>> (sha256 does not match for what is illegal.) >>>=20 >>> Ignoring the illegal-instruction producing bits, HWCAP_FP mixed >>> with any one of the other bits was also similarly slow. >>>=20 >>> As for all the non-illegal-instruction producing bits: also = similarly >>> slow: >>>=20 >>> # env OPENSSL_armcap=3D219 openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 28922.63k 30711.51k 31522.15k 31722.15k = 31788.97k 31845.03k >>>=20 >>> Disabling just HWCAP_FP from that got the fast category of >>> result: >>>=20 >>> # env OPENSSL_armcap=3D218 openssl speed -evp aes-256-gcm >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> aes-256-gcm 49543.14k 58068.22k 60236.56k 60724.37k = 61216.09k 61212.99k >>>=20 >>>=20 >>> As for sha256 . . . >>>=20 >>> # env OPENSSL_armcap=3D0 openssl speed -evp sha256 >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> sha256 22434.19k 59895.91k 117258.16k 156264.31k = 172624.81k 173848.52k >>>=20 >>> (I'll not list all the similar performing ones but >>> will list all illegal-instruction producing ones.) >>>=20 >>> # env OPENSSL_armcap=3D4 openssl speed -evp sha256 >>> Doing sha256 for 3s on 16 size blocks: 4082055 sha256's in 2.99s >>> Doing sha256 for 3s on 64 size blocks: 2752520 sha256's in 3.02s >>> Doing sha256 for 3s on 256 size blocks: 1372584 sha256's in 3.03s >>> Doing sha256 for 3s on 1024 size blocks: 470215 sha256's in 3.11s >>> Doing sha256 for 3s on 8192 size blocks: 64700 sha256's in 3.07s >>> Doing sha256 for 3s on 16384 size blocks: 31847 sha256's in 3.00s >>> Illegal instruction (core dumped) >>>=20 >>> # env OPENSSL_armcap=3D16 openssl speed -evp sha256 >>> Doing sha256 for 3s on 16 size blocks: Illegal instruction (core = dumped) >>>=20 >>> (16 worked for aes-256-gcm but 32 did not.) >>>=20 >>> So: no significantly slower examples of single enabled >>> bit cases. >>>=20 >>> No (non-illegal-instruction) 2-enabled-bits examples were >>> dissimilar for the speed. >>=20 >> Incorrect description of what I tested: I testd only >> 2-bit combinations involving HWCAP_FP being enabled. >> (Same as for aes-256-gcm .) >>=20 >>> For reference (avoiding illegal-instructions): >>>=20 >>> # env OPENSSL_armcap=3D235 openssl speed -evp sha256 >>> . . . >>> type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes >>> sha256 23185.66k 62689.73k 125814.72k 167981.88k = 187833.65k 188968.95k >>>=20 >>> So: also similar speed. >>>=20 >>> Need any other specific bit combinations? >>=20 >=20 >=20 > chroot'd into a armv7 context on the RPi4B gets different results > for aes-256-gcm: having the HWCAP_FP enabled speed things up. >=20 > # env OPENSSL_armcap=3D0 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 35983.70k 41987.64k 44077.00k 44693.54k = 44685.68k 44717.40k >=20 > # env OPENSSL_armcap=3D1 openssl speed -evp aes-256-gcm > . . . > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > aes-256-gcm 55339.93k 64644.18k 68001.37k 72708.53k = 74237.56k 74247.87k >=20 > # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm > Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 > # env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm > Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 > In general OPENSSL_armcap=3D2**N was slower and = OPENSSL_armcap=3D(2**N)+1 > was faster in a similar manor. Similarly for 218 vs. 219. >=20 > sha256 did not show such a distinction. >=20 > The armv7 illegal-instruction generation cases for > sha256 were: >=20 > # env OPENSSL_armcap=3D4 openssl speed -evp sha256 > Doing sha256 for 3s on 16 size blocks: 3313106 sha256's in 3.02s > Doing sha256 for 3s on 64 size blocks: 2403376 sha256's in 3.02s > Doing sha256 for 3s on 256 size blocks: 1289917 sha256's in 3.02s > Doing sha256 for 3s on 1024 size blocks: 446543 sha256's in 3.00s > Doing sha256 for 3s on 8192 size blocks: 64123 sha256's in 3.03s > Doing sha256 for 3s on 16384 size blocks: 32756 sha256's in 3.08s > Illegal instruction (core dumped) >=20 > # env OPENSSL_armcap=3D16 openssl speed -evp sha256 > Doing sha256 for 3s on 16 size blocks: Illegal instruction (core = dumped) >=20 >=20 >=20 > Note: I focused on large scale differences in general. I was not = trying > to find the optimal combination. For that I'd also have to test out > repeatability/variability for each OPENSSL_armcap value that was in > the faster range. FYI: on the OPi+2E (Cortex-A7) a more generates illegal instructions than a chroot to armv7 does on the RPi4B: # env OPENSSL_armcap=3D2 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) # env OPENSSL_armcap=3D4 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) # env OPENSSL_armcap=3D32 openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: Illegal instruction (core = dumped) env OPENSSL_armcap=3D2 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: 579668 sha256's in 3.01s Doing sha256 for 3s on 64 size blocks: 436508 sha256's in 3.00s Doing sha256 for 3s on 256 size blocks: 240826 sha256's in 3.03s Doing sha256 for 3s on 1024 size blocks: 85768 sha256's in 3.04s Doing sha256 for 3s on 8192 size blocks: 12248 sha256's in 3.04s Doing sha256 for 3s on 16384 size blocks: 6096 sha256's in 3.00s Illegal instruction (core dumped) # env OPENSSL_armcap=3D4 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: 582757 sha256's in 3.00s Doing sha256 for 3s on 64 size blocks: 443027 sha256's in 3.04s Doing sha256 for 3s on 256 size blocks: 241189 sha256's in 3.04s Doing sha256 for 3s on 1024 size blocks: 85722 sha256's in 3.04s Doing sha256 for 3s on 8192 size blocks: 12074 sha256's in 3.00s Doing sha256 for 3s on 16384 size blocks: 6097 sha256's in 3.00s Illegal instruction (core dumped) # env OPENSSL_armcap=3D16 openssl speed -evp sha256 Doing sha256 for 3s on 16 size blocks: Illegal instruction (core dumped) I should note that my buildworld's and buildkernel's are set up to involve -mcpu=3Dcortex-a72 or -mcpu=3Dcortex-a53 or = -mcpu-cortex-a7 as appropriate to matching the target hardware. The armv7 chroot's builds used -mcpu-cortex-a7 as well. (The installs are of the same system build as for the OPi+2E .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 01:38: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 761DC189E0CB for ; Thu, 25 Nov 2021 01:38:35 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J00rp1htNz56QF for ; Thu, 25 Nov 2021 01:38:34 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 428368D4A129 for ; Thu, 25 Nov 2021 01:38:32 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5ABFDE7084B for ; Thu, 25 Nov 2021 01:38:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ZGyf059NJR-v for ; Thu, 25 Nov 2021 01:38:29 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 65706E70814 for ; Thu, 25 Nov 2021 01:38:29 +0000 (UTC) Date: Thu, 25 Nov 2021 01:38:28 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-arm@freebsd.org Subject: world linker error "can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment" Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4J00rp1htNz56QF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-1.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; 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]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_SPAM_SHORT(0.84)[0.841]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I am trying to update one machine (also across the LLVM update) and I get the below error. Anyone any ideas? ld: error: relocation R_AARCH64_ADR_PREL_PG_HI21 cannot be used against symbol __stderrp; recompile with -fPIC >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/lib/libc.so.7 >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a ld: error: can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/lib/libc.so.7 >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a ld: error: can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/lib/libc.so.7 >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a ld: error: can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/lib/libc.so.7 >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a ld: error: relocation R_AARCH64_ADR_PREL_PG_HI21 cannot be used against symbol libspl_assert_ok; recompile with -fPIC >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a(assert.o) >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a ld: error: can't create dynamic relocation R_AARCH64_LDST32_ABS_LO12_NC against symbol: libspl_assert_ok in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a(assert.o) >>> referenced by assert.c >>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a cc: error: linker command failed with exit code 1 (use -v to see invocation) --- libavl.so.2 --- *** [libavl.so.2] Error code 1 -- Bjoern A. Zeeb r15:7 From nobody Thu Nov 25 02:51:03 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 CEF40189C3B4 for ; Thu, 25 Nov 2021 02:51:14 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J02Sf5LXVz3mh8 for ; Thu, 25 Nov 2021 02:51:14 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x936.google.com with SMTP id i6so9334606uae.6 for ; Wed, 24 Nov 2021 18:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RfwKtRzyxNXI07FV4Iow1tl/wn6kLpi7SRbv8FhnGWo=; b=BCq8FBqmEDRm2WhiWfUqETk+K9GUzf6gUYowKIEhF415gNAvgFpaX/B28dYwFNpAWR LKLxliNYpDrtfUy+i9duTMnXjB5dRbmxS63qfGdj9MhoHuwjTVSgZScMqc34GbT1CBlY x/Zp8M+XQW6ecFAXMkyvea+OcfDotI7+LYsG3+80kUGhSEkKflICiLuHzmBlvSRY3sr0 5gSlSeJcZAruRPueE3gTJCMc7FYGythaY2THXM+Sbs6Q/jWyyooAXlg/PPT2JQak4stl rXrS8Jjxfa6ydJxn3xIovboZ7l6VCg6hG47rCW59Qbc/R86BSxHC5hkgp215eAxglvY5 dOaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RfwKtRzyxNXI07FV4Iow1tl/wn6kLpi7SRbv8FhnGWo=; b=uSrG0iwATPsI+WVke0yTd6NNZmDA0llkPSGbUI4gTQuuYkuMS/nMmuVzcP44TtMU6i ZD5mlTgTlTyiUrRx+8EvRP1soGQRZUb6bX4sP91PR7dYR5YP+nZlk6SWBXMXbQlMdLoQ jRKweOtP+Gw5cdfdWE9XjhqHEV37qGqYIgpBhUDkDhO0LEOVoPmJcdMKTmYb3TlftWIo 9FjjXm/UR5IB2lDo9Xc3Zk7IFfnCieQjhKO17uGStP8e5zHO3GAxndst8CklN1UTrygj oqi6Jzg4gDXUhqcLakK3T83Tr2nvUgRvT39KPkgb/5mawBSdpBKUHKCxsnBBw28UfXUd 4N4A== X-Gm-Message-State: AOAM53134/twDHWFbOkirpvixE8oqFO53MCavt5UqhQMthxb98++eUa2 fgq88gdDWxLSZfAXmTKvwcG6Z0wOmbQ5gOwn8vWK X-Google-Smtp-Source: ABdhPJwjeFT+8FPXd3f3m62hxn6Z7gu8PuNokMWfQCsrG/s4u03Q4apCWCbhWaITD8o4wee7r2S3FRKbv/ICDJXZ+Ww= X-Received: by 2002:a05:6102:c0e:: with SMTP id x14mr4312338vss.24.1637808674261; Wed, 24 Nov 2021 18:51:14 -0800 (PST) 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 References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> In-Reply-To: <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> From: Juan David Hurtado G Date: Wed, 24 Nov 2021 21:51:03 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: Mark Millard Cc: Free BSD , bob prohaska Content-Type: multipart/alternative; boundary="0000000000003d618905d1940cd5" X-Rspamd-Queue-Id: 4J02Sf5LXVz3mh8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000003d618905d1940cd5 Content-Type: text/plain; charset="UTF-8" Thanks for the feedback ! > Very strange. I get Can you share the brand model of the microSD cards that you are using? Just for reference. > bob prohaska > What specific version/variation of the RPi4B was in use? I'm using raspberry pi 4 / 4 GB RAM > What RPi4B firmware vintage was in use? > What U-Boot vintage was in use? > What FreeBSD loader.efi vintage is n use? > === > Mark Millard This is what I get: root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) root@generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) PS: I've installed netBSD using the same card / pi 3 B+ combination and it runs ok at 50 MHz. I'll try tomorrow on the pi 4 ``` arm64# dmesg | grep sdmmc | grep MHz [ 2.009317] sdmmc1: 4-bit width, 50.000 MHz ``` --0000000000003d618905d1940cd5-- From nobody Thu Nov 25 03:11:34 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 7C96A18A6DCD for ; Thu, 25 Nov 2021 03:11:46 +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 4J02wL1Zmnz3sTm for ; Thu, 25 Nov 2021 03:11:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637809899; bh=DJe3mu22jUuiltcgpJmvU6NAOU+yr9hSUmeOtRPjR+c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rVeQsT860yiMMMcpW+Wwuy2woUVtB24ehaRSGKi/Dp2PZwfHy9v4RL56NHJ31i1N4U6qjzeeV4ztCbg39nvpiRlVJcjcZWWSVZAgd6qNE8oTILm8x2NUUkiA/BCQfpAEPwpVZl6zR5Kvbf6LamprkAmZnbo4spfMEpwEUIkJpmvv9QXEayB6x2OguuqkPL8AbFKwi/WzQ4vzQkYn1N2gi3UkXN0LUlOMJCbIppNu6ARO/5PcsNbaRvASIjMq22ps2So7Z5oDTOrm/b0Q/dF7RyPi57/Q6IfO4n0OmB+e+Fv/kjvlpr5rs8Vs2YjILU05TrzxizJJfK1CB5Zxd4uZRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637809899; bh=QWv/wQdnSrIILm68LQqfiJ1rNchCPmgjrRCgDC4H4jh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hweLnr8ab/LVVUzaq+TJtZZJw5bfVq0rrTC87rl7RyFPf9WUd/wu7LVI843Gl94hGXh/ktFobbw+uV3dNtwy2KVG0KRbMgsgyrJyeFMnRL5RnIEbZVDyCxFs4O2sDrygGqOeqxVXLJN+ovv+Lmaro1hWBM1xUPwSa7aPVQQdQEIFcQW4V9UIzKJloYPtwbDvglP0dq0A2/1mozw8u3FGwlTLxFUh6wd6lxpjsr59yCr+rpUio4pq56xUpR8kTTLJPINOnpRoIOBHC4rf6j2+4U+hHJtKKfNNFavgqyo6rQuWMUu0BK+G9Uoivci+wlkp5Dotpp0vEP1sOe1ljaRz5Q== X-YMail-OSG: J1L6rE4VM1l9o_yJ3ihKMeipYvVnr4dgpEvRFlqafTOzvYvMPnxh5rkRECMYXqF YF5RfOABHbWE4vguYcj77MfukScWhSd.6E_fZESYmJ9eZFepyd83.eOkBnDEiNAj86brxL2TxmXX 0ETAHQMVTWph3lcAn25moTpuvF4AjvYcmPIdk.Qx1gyiEZ5_DXvEBroTuxxR9ri239IEwX.QykA_ Hsy6y3ROUWz7Th_j5HyQZ9MuzdhT1dex6kxQLo7b_n6DrRxksX5mMpkQt4eztdIC.mfQOdAuhYc1 bdNLbfcxNdPL7vNcKnA1gIhvr133kgTNxztt7AKA0iFBMKZG3IkcM2xPhihog2INdIXt4ov10xOa f0SA9LmN3ux9JcHTEWJIfvrS.QWLJzB0CU9belkOzXlnBVRF0f4Eym0EU0G.v0mHFBfFw7mYPTmN BdD9sJksz9T95wIQAoaFP5JIIN5MYJ0V6.SkYcympbSRHZLEISN_P1V556HBGPJcPADEG_K4.Wat 47NmeLfAIIT4j9IWKJngYXgser4IcR02ej4x7knFbdL7cDDnB_hNHClNdVe0UaWNgyNhrbySGEhc Wwtui6GV17EsT7Ewm7SRDgFtS3VgOg83hayNQF5BLLhlcE8AGBb9yKSNEccUMcMR2ykfhjr1HDhE Aq7nc.Nl21V3Xe.eFdGUZgcf9b5DsQSDuNRg6ycGPrAECFjZ.kAvVOy9ysT4pUw09dc79Djw5HHr Z81OuXPNlWrqChxOSVm2NmHQfpVo.aAhLKn_z5zUNjIrazp8F5eLC8Ncq3TI5wyTZUpxOdGLKP.1 11NF9Z_9eeuzS6O1VBLb4IPFm2VmHohgNz3Vw9xl0z7EmPDTDzWKKl8_eqI4S5GkZCA6vQ5B4.zH Z.iP_.SSJ2brar52hMrlK4.JOsZOi4sEInRjF8rcrvm5m0_9wToErLb4FTrY2dM_SvJ.QA2DZAoy lp_a0DDoBGCUpVhmoqCnvJACXn3PKFkLnQr7z.GkXC2jR8gFarDB4M7ljBX4K4_zbjtjAbg2zv9q Vv_.HzMgKldjjqxjK9NYYlpSqGJHP.tuAPOnvkSyw3I0EcRFEMxIUD5o_s7kc4bChfMNWxbb_mRW NnJxVGVZIesFTSLQqyKxGitqYXypKtyyeuvvrTpUPQlmFAFc9Kx2pBUT7I7tJrPbT90FZU7i7gVV oesHP2SGeEB4HEryBcsJFefqEhiEepuCdpOBKlNCY04BS0nniwt7trXOL9qLjjXd5jYwqJTaTAnF qEubwF5tGL1VF09FdMjC2rDtg4WzL_NuRUDUVenBRy0UkEecqlaS9w5CVDHRFexgIoRs9vv.TA0r TiOaPhHM0QXoGe09I6HHkSFwxW_uirOvNzSteLGzaMnd.tNFB9GfllXwWEBubU.MmArimpqbbrC2 Xk5_xy8M5xk7ZZeK1z8KWYNGwWfcDZhTsxocQIZASXOIj11wtLjZfQZd80Y2NyhrMKyuBNDd0o6Z 4q_.w6_EybqPrYZ4F3Ir0X7XOEG6ePoIpBXqowwIuk7mYiv8nBAFi3kvM4zqdN.aBn7j8BRSCGjI l39Klq2haTU3pBxx9vs2r3pvFOpbXiE7PM3jFKky3KsHCdocKK6BMUp7blRtK4g6zq2tPotD7Jet .XbfhxQ2tq0ptzc03RKtfD3PzJWMgCUYb_14immiG8xW.U14alLE4OD2vFivJ_3wEMfsl45lOBsB nuAoEhel3y8bl7QVjDAZwqMHEwvClbV2xfs_5NesMKFSj_PDfIwOOckVIT_61cNmQQKdNTMRsziA u4PdH6y5fkry23AGPXe2w3G1iLBl80yyFe1Fc4RtkakSewlSpLTTpKaOocZQ17HKFMfGGuryAD_9 s_Q1xYjf8uuq4tyOCav2TjF1qtIs0FkySWyxiN._rHY8t9G0bfav0FdPgE703XVnVBMu0xtR1HKZ xQjCLSDabTvwH.LfFE8qn1qqa9cHzDFx9kL3xMFsxXTI_9q1.Ghs2n_BjQlgfIZz3DIvNV2QjApF Sf8ZcVJJvq30hP9vEfpZfB0hssvJAJwRgrmniv5_gutijwxfBDj4TOUkyxPAvkkVVo1j6wbOrvdF VjaL3mEzjStVNYJ.Y_2D_NyH1AauS05IEJ1Qp.AAAjqaqWFBbb5Rwxhc.KVvEKoGTOlCdtPJtVof XV0Fj31E0IP5tpW1Q4vxZHRvuZyypM9o9uTyOEIxTW4kCeD_g0HoHL0xFWVI.rCPVnxKFHzcJ1hE bOcfxnpJuTgeki0tOOrtWr4IJsD.wZUPXQs0tPGYrlW80hA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Nov 2021 03:11:39 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4084bff79d170c1fdda2edf59017bed8; Thu, 25 Nov 2021 03:11:36 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: Date: Wed, 24 Nov 2021 19:11:34 -0800 Cc: Free BSD , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J02wL1Zmnz3sTm 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 18:51, Juan David Hurtado G = wrote: > Thanks for the feedback ! >=20 > > Very strange. I get > Can you share the brand model of the microSD cards that you are using? = Just for reference. >=20 > > bob prohaska >=20 >=20 > > What specific version/variation of the RPi4B was in use? > I'm using raspberry pi 4 / 4 GB RAM There are: v1.1, V1.2, and v1.4 revisions of that. Which? (Hmm. got to go. . . .) > > What RPi4B firmware vintage was in use? > > What U-Boot vintage was in use? > > What FreeBSD loader.efi vintage is n use? >=20 > > =3D=3D=3D > > Mark Millard >=20 > This is what I get: >=20 > root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >=20 > root@generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 12:10:40 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >=20 > PS: I've installed netBSD using the same card / pi 3 B+ combination = and it runs ok at 50 MHz. I'll try tomorrow on the pi 4 >=20 > ``` > arm64# dmesg | grep sdmmc | grep MHz > [ 2.009317] sdmmc1: 4-bit width, 50.000 MHz > ``` =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 03:52:07 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 BCAEA189CF9B for ; Thu, 25 Nov 2021 03:52:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.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 4J03q82X13z4cRd for ; Thu, 25 Nov 2021 03:52:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637812332; bh=Dm6yxvnIvn2+HHj9KVLyGrXacTJa4a3s588n8DvqfNI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tSdyEMljtrhgvTGSmFxkFJzZNda1nvyQOsLb7b87XF/p3DxmklKl/l+BcmRAejN4BZuqBY/ODYMay3CA77r5DYjGE+/oSyK9NA2/ftjushOoqy8Oq0zEd0OcxU/orZJ/cLkazaEtuQKQshbtYJ2e73KneVanizwumT/Mf+LawOLRUFlbtRiwvMiO9PVpdNdCLeUsU1D5SjBL7maWgXd8v0w3hgpGooG8QVYwm0sbxwkyq/CvRo7LJhwwQTcKAmEQiXzLCpY/nYPpV8pT4fqNDGRXjv8uknqKpeixqvBJdyJCt5eTfQg/hrNNOPoYRPw2rm8jBpZ6pCDOtU/3m9TZvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637812332; bh=8l1BUlsQ7V30byl4N0tMtnjAP1kKwA6I2q6E2h7dp0K=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OfyktP6ifzFQm31xMZ3+ph+bu2NQIj4hOxmQ2ns1xAqKhVuH/1i1kjCEv7D0OrNnBA9I6sEk1gyr9j53wkJEsi5KVYrYWelavgDK1JAuqMLkrnTVKlTyJlq7StrMBTgqeVe/9eHbqIQ43wLytpxWv0Ap3wbYtfplnEh66EiP+Mh8vuaDLM+lVHHD7pH92W6maiTotXDkwmUrlD0sc9DTUPdmYSH5vYnXQswizObK8WvX/+3NUvCiNRb6fGYuKkeAFPgDsxYYJH9c+/uN8vOsCmSeKH1rvu3u+N6m4jR2aVqiYkyHLgzoLtHXS/pfAiDv2msYKr3p/t47tNbjwU46TA== X-YMail-OSG: KJIgsQsVM1l0Db0Merqmm.tCdtEXvsJ2ESFQLakQfF2yuCMzbI1d7llhRI0IhUi KYLheA2eJfAZcEaDkGkmvZflDvHTXRq0j9wcX0a2wlN1rxWpzdRmF3gFyQpr5SIFl.1QdAuGLVwa VrhZuMwBdGqq4bwEnzOhQw9dbYfsmoFLcrit2Rjt4egcMoF.6kBqJq8EKveGlnk1.EiZzxpvTiXb Ip0rEAWf.Z_eBuNlkwgmIk9HQ008QsP90G13Z7g6czH9KyEZJbDJSY5ebOxjzMdKDpwXNDiE6mw2 cdPlJSdxrf._ZrfjefopH9KXGklbWByyp6OzVxLHv2vzSIj0p6kRanbbPemDfyuXmexgHK.mZXoA 2ThrJeO1lIohpuqGuOP9Ns7s0Vm1go7Q_1eiFUqxgnaZoU2N16sWj5qQUPqwklq_5BKJxYbv8Utu S7qu95hpU3jTDgXG9xNUXDaYliDrRQD4hZJLqY1jL79mErjaW6zBzXiCng0CaweLyTomXDD5LfD6 xWLEtfearPY1aXAL2oGHZLc6lnTqtAv1wsXiJJrfAew2n.CV6eA1e3og6j4ziRP56eLKTa8Tk06m ROQsaQYdpsPZ6z3BFlWgQrnkK2dO7aovC28wbn78MPWmFryEp5YzAMp7HPAUiH7jzoBwL_NaNM4. NN174pSZShzv_Kl7u2iweW9opR1hvu.oR_WDJerzX3LZxjYKnRWIjM89I6tjY1CUtyxYI0jmc4dR u5sprCTMQ5ywkIO.glzYsCS4zTa3d5ILi3jN7J7_U.MDXBVQpAlZHkzNJFxzYp4XkLCRGjyvO.WJ HW3Uv2ALFbkEasB8bXgyo.twLNPCWSrY7zjA45nwuhnMXKPSW81Z6OkjRxXs653GrFZm9Cp1RZXG psn.6UCxj6X7wo1kl.yqiLuk0Ev4o0766pm11sGzgeJmJ47KxYumDQRp85O_uZ6dhvGzLCKyTlKT 0NpahJRbdSTGyxSbuXHCbbpiKeeCQpgCWPqfYvsfEkWMXYcb9xcgPbG6nf55LyMUkhzOQgVhJ1l5 6OtOwnKlq5wT9pMl3dulzK1G6Nnm8l6axp4D6Lg8Hyfafib7hWCofHc6ykp3IfqwFXlOA8Ud.d1m t7WvLg3nVFoIw9ymq6FFJQ0n2LqQOM6AfHgpaJ3mNbBTT01Bg3gjs.HYdUlr98Z1oxxSdovSivhq xsdAcnQQNPO29AZ0Dk5SAwDw42wbSEe8USG.m3f3NMHYX9D3AvFzkm6tm9l9G3DGBGki1HgbflXD 9h.FQQM.U1ajln1jq5ZtK_BSFTxQT..5TFF0CFwwPrcEGvm7cJUvqy4HyPaSIRfb15H6mVQRUWE7 6XPtkJlzBgKFnsNnpXspWUO48Hjej.Eg3dlqAU3R6jAllKIOmutvEMYaUnRArEuIbuX4GyFWI8h0 CtkbqG7ff9eHEj2nf_mLpm54pnD8t26_bilrqDz0iOzRkazBeA1M14tF1pj54cCbbRbLhq2rzhcZ TsuFui.5kmEQN1d1gmOARLRfY6vh3deevAqGtfxky6v8jWFfgYsPjlDOv01Wqak9LlAYI00izvZ6 oT0V6bygOwRL9LrRQ40fVf2QH3tmMdAUE18l3nHK00bFTcNa76ZnfU_zgU.4zdhdmW_u2Q72Tmkh riG5Thv7PBkDXp1jl6_zSXIE2hzCH.Bb9rNmhRWOoaZxkJPjVKNZOQ0sWLcmb7OIM0T2X0SJOFEk Z9hObGCJF3IWL2TBZliZJskGpW.WIDkIvq0hB3X4aERfBlQ0dujixy9ib6ELejlRequotkRJVv52 XGpoFQA48QsJI_C2aJMIKUuriTiDS3ovqHceHwtp81V_Yd92hFYcG5nZ7jKQPf0dBGJvsqeHllHu Qi.UDRYQ.ZZ.8jfXlXrJXSAjxtdwkPDLV7ZmODcERB2cT4ciGQHwvcaNaD2mTueyOD8Pz1G8HMN1 ZsLt.8GgrDsmETn42tk42D.GGKcD3j2q7iP4b9MblbZ8FQIBmG.H7i.EIuEONMbifAIOIvf2CpA_ vOmPTGTGYSQF3LT3esgPOwvLVbbL2XbZsgPVTVWeP8Qe_ejFJDBKhEPxUoQJAv_OKvMljDDewqk1 kZOTUErddXe1mPdIS4q79XW8zvq.SDU45gKLzJRUZtSeftX.keb1w1K4AUfYxNtiOE0tHGHL4kt5 kIeA2Dh6M93kAGe9ZZu4MsmanxYP61LCZVvRXlva.Y9KaqtrAwVq3deNEbWz1TLQXRbwQ_lvx5Sc O2vhmVH51BPYW9UYdVCHto_oYVoeoY3rDi_PA_NnaPryzXg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Nov 2021 03:52:12 +0000 Received: by kubenode516.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 53f9daa53e41fc26baba09e21deac655; Thu, 25 Nov 2021 03:52:09 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> Date: Wed, 24 Nov 2021 19:52:07 -0800 Cc: Free BSD , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J03q82X13z4cRd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tSdyEMlj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; 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.204:from]; NEURAL_HAM_SHORT(-0.93)[-0.935]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 19:11, Mark Millard wrote: > On 2021-Nov-24, at 18:51, Juan David Hurtado G = wrote: >=20 >> Thanks for the feedback ! >>=20 >>> Very strange. I get >> Can you share the brand model of the microSD cards that you are = using? Just for reference. >>=20 >>> bob prohaska >>=20 >>=20 >>> What specific version/variation of the RPi4B was in use? >> I'm using raspberry pi 4 / 4 GB RAM >=20 > There are: v1.1, V1.2, and v1.4 revisions of that. > Which? >=20 > (Hmm. got to go. . . .) Can you see the labeling on the top of the SOC? If yes, 2711ZPKFSB06BOT vs. 2711ZPKFSB06COT Which is present? >>> What RPi4B firmware vintage was in use? >>> What U-Boot vintage was in use? >>> What FreeBSD loader.efi vintage is n use? >>=20 >>> =3D=3D=3D >>> Mark Millard >>=20 >> This is what I get: >>=20 >> root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" >> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >>=20 >> root@generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ >> VC_BUILD_ID_USER: dom >> VC_BUILD_ID_TIME: 12:10:40 >> VC_BUILD_ID_VARIANT: start >> VC_BUILD_ID_TIME: Feb 25 2021 >> VC_BUILD_ID_BRANCH: bcm2711_2 >> VC_BUILD_ID_HOSTNAME: buildbot >> VC_BUILD_ID_PLATFORM: raspberrypi_linux >> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >>=20 >> PS: I've installed netBSD using the same card / pi 3 B+ combination = and it runs ok at 50 MHz. I'll try tomorrow on the pi 4 >>=20 >> ``` >> arm64# dmesg | grep sdmmc | grep MHz >> [ 2.009317] sdmmc1: 4-bit width, 50.000 MHz >> ``` =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 05:51: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 3B63A18B3530 for ; Thu, 25 Nov 2021 05:51:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4J06Sw1v3Pz3mly for ; Thu, 25 Nov 2021 05:51:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637819504; bh=2z/u3692Rok7Mymyx+Hi9+oX1/e5ew+DgHtYzzTgJJQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=smMG3nXHELyyebN+WWEKOaRM325GC7zcrxb/Wr+l+MUcf/EKVwTAnv9hZyd9pObAcYd0BtuOigPGj0NMqYaYqxUvHNHNF//yJ07qIJRI/zNrAs/DwrIYwexMkHZlQeQMoKhpMm/pAjgm2XqsiRDyJNuQVZMirKyI4LjViIuxraFzNm9Zsn1liChGcV7+HBXldsy/zjK39oBHU9xowBKF/5+gFhnlV25Xmf49nkCOhHXHVtzuAD//809qxwuOQcuvTAjTUn4oB+UPL3eE3O4En1WRRWT/sBRLn1fVyeIqvBBIIbzIKmmHWHgpbkK8Nas9Aqnr75KYytKK6tpXMyYrlg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637819504; bh=HPhgbFfZM+f1D4RQJWYxkOno4lj9jg7hJ8/6EnyvZqg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ppAHIEFwsE3wSBCFjR5YFcKtNvc8dWdM72gqwGcupWpbw05wUc4fcysorBiTpHyLSwcZkwX9mZ3O8SEHvX2eU8TcvPt/T3qgPUsnqpnOGkVB10krVTbAIBsi4zDhEpcO3ovp/dMYpHd7wvxoLt1LGg4N4NQhkLilZDLr/vok+aUMZWCLNrMILjnGztxS1KZOSMWqu/ba9NpHX/g1eKF7A8bjpCROtKLWR7+HOME6Mf9nvF+eGC6efFCe0rpfhlZPSz9TL705CP6Y7kTJLGNEcM5RlnxHc7DUXKjSZTs5IBzDok92fWrXLPkCNn839C0EpFSa6Ictvuv3GpdKOoI8xQ== X-YMail-OSG: z6CmlU0VM1kJPoSQ3sGio9lo4Jyr8WnSvqzkEIxcMY_2QyzjZY.4axO1wEyEuLT 7sJ44yExvvS6fWbYRaDsbMsZJyABLeHJnI08CAqKAtQ.6VVG2zJmHBbBH2KLbitSfdoqQo2uXF35 3zIR6JhyjXkHwxuuLb4nNOrkhXJoPvO21611zuHFjZyVRbyOxcbueDF0ZSKlwOqElHj4J7ekicGJ j.NWh2HpFfEGHQCbHGk69LdAFH8AadAglFQg3Rg6vDDUSqJFrd.q4qsoOGg47zMBx60vuV4IQOHu g5YWglvQaw3YrJSawa_CmKlsT2mUVMlBswFO2m2BPmrGQr13fE.eQ7yKY8Lvm7QU4RhWIfw3L7Yl 5LLTG54EVQrRpGugzSn44GdF4UcQC5o3PXyIvb.pK7ZUinyL3oNHsw4I1u23X4CSuZFVx6QOXtuv j_9mqQjBgkxDhI1mlvbl8hQ99MTpOc_6rv3KzwkDRRchT9L4duJHbpjGDyYb0UN4f6PKz6QcddPs 1LgzG9Wr0GdEVWAY16bDAJmLb_83f3ueGmfhU4eW0jKf9mSlwu0imoi09OWJbVqcGoC4zdyyN8Hh 253FknZFdzxxnq2g2DP1QV6Yc6OhCivzaa7.OpJ2fwVVQRXn0qi4vM2Yj9Y0G2zpsHhD1z4fftSS aqTiPHHN1Vhq.s9iymQNQYLBuwCy0s5SXCo5h1m9AqYcEi_8t1lRV84ZObVhGbaGqqkbZJmh_50k 6C8rg9PV9DPL1XKftwa8HN83qwezAqeS8A8YEPa_AW8NqShqmHmiwfl.O_GTtcsNcJY8xRZq5zDF DRbkEGP8qrz2apFtAUwGMk1ZXyqF1OhmOf_0SQvBoxeC7C7QB8yHneFmmLTbe_DcZ9fqtwa7dKK9 ihvCa0e73A5oTuW6taQUvgWuDjJFKTmwczIXurLyyzxkKCPoNm5a.TfPq3wjldq.LPwmRQ3QLGW2 rhOBr2gJdyfBeFv6HSlZEVjkXbazwogAMWlSGIR95sE1FK2GUcrEf5NHdY42chQbyI4Y_MAYmvma PCmjnFOEqDXHMwDLptbJNZAhZ3Iy7JM8vl13sr_Hbwtt7p5wuRH2gEE0xx8dmuf2utA3BcpkNR_y d1le6h9gK6OVv5ffh1qA3bCFibxUEz7flAB6BoV.0EUfsbuR_TUpGNqvs2hMKYKuFxp1UGQnk6Lm CvYtgOYz1uThaD7Lwe.QaE9HnRZGdp2FI.MpH2SHu0UwcUmQLQL0laloRsmvmPjKUW_XaRAL1NEA r0oJ810D_Gl.n0nJKZ674JutSaPlx8J591oJuds5_P5ig67DUo4YmMbs2chCeQvqp9aLJO88UkAQ nhEWhDdaLgIJOV_kl3GznDj8I.4ZFxKc1Nv5OnYD0h3W9dMNyeHmBrLEf2ekLN5dmSwFkQkhz.un FcH8elo8.0BCVovz78zX5KNeQmNAFWZq99B4.X9E0h2HaXIFE63sjjhiY.GH.l.xNA95Yj1MKWPV 3AqpaIbE0PJshIQbL.M6oS3ZFklqeMngkMgeKjRxa2yhjJmS_YK3UD8uawHiSwRsf7m68SzndHnR TO6ESiizdPwCKxwtObj6rnDfPVqATHqq.2_ZmU2id.7MAfWHeby1g_2GPk82EtEKHd3ihiRE8Zit myR4wdqYZ6WnRFGIEHQxWMfX2Onkl8whBqW_5ZAOEIxr26pd3HTivnbIM_QRJQ4EUGscHt5.3ahI kk62Ie8tUuy9XSeybf1pNWjh3F6e3CAT.phJGImSnDIYCCcD3MQdUu4ndcLPf2w2cCCf.hbFK1co JBP9t_tbDe9cW.sw9xJI6Nv5K29mwLtF7vaMhrs7IP5MzXG0eb7yPnjopkHedqPUor3yXSx.PZE. PaDdznjqPb_dEHwdJ5XE2u7yMe4AnABEKcsWRGqNVZvNdp4s9Z4YKaoxULIKpfo5kRVSVnO4bLjm Szm2ekLWFgk8tXXQmlHApNenqIEo8UKI.TCh2YSCGNvxXJNXPjNkspkFpzq81dzCzM7t0h52I1Rh s0bg2pAdCMl7dKG3rsVFXOdUBzvL1zw2WUqOpKfAKdYol0zhtPPnKEPSXQP4B0tVHNIIabk21dbT 3DAAtPb750oloqG2upokvE.KDPZ7PXBNz0.m1ZKBDz8SZu2SqY844pgQuxTEDJ4EDwmN1mE9Y0nG xeJ02_KM8xLoiysvR4BYGSr7ROSOrGrbmFSY4HfRt3PGFB0LjU5BxU3FhUJ7sal7A70qwifBCTMj lKR0XrX8PH8WYFEQFqbEe_v6o61iHlwc93ZFRCF2Ea.rpIjmgGwpgWpe2R.VHow1ZvaA5kX6RSyW x_J7TY0Qvm7v85tMA.XcZNow- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Nov 2021 05:51:44 +0000 Received: by kubenode530.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6e44298f99bca65b61fcee58be3daca6; Thu, 25 Nov 2021 05:51:32 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> Date: Wed, 24 Nov 2021 21:51:30 -0800 Cc: Free BSD , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <9D5EEE28-4481-4B09-8F4D-1A486745B559@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J06Sw1v3Pz3mly X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=smMG3nXH; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.39 / 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.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)[-1.000]; 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.32:from]; NEURAL_HAM_SHORT(-0.89)[-0.888]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-24, at 19:52, Mark Millard wrote: > On 2021-Nov-24, at 19:11, Mark Millard wrote: >=20 >> On 2021-Nov-24, at 18:51, Juan David Hurtado G = wrote: >>=20 >>> Thanks for the feedback ! >>>=20 >>>> Very strange. I get >>> Can you share the brand model of the microSD cards that you are = using? Just for reference. >>>=20 >>>> bob prohaska >>>=20 >>>=20 >>>> What specific version/variation of the RPi4B was in use? >>> I'm using raspberry pi 4 / 4 GB RAM >>=20 >> There are: v1.1, V1.2, and v1.4 revisions of that. >> Which? >>=20 >> (Hmm. got to go. . . .) >=20 > Can you see the labeling on the top of the SOC? If yes, >=20 > 2711ZPKFSB06BOT > vs. > 2711ZPKFSB06COT >=20 > Which is present? >=20 >>>> What RPi4B firmware vintage was in use? >>>> What U-Boot vintage was in use? >>>> What FreeBSD loader.efi vintage is n use? >>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>=20 >>> This is what I get: >>>=20 >>> root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" >>> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) This is not what I've been using (2021.04) but I no longer remember whatever I knew about the differences in behavior. >>> root@generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ >>> VC_BUILD_ID_USER: dom >>> VC_BUILD_ID_TIME: 12:10:40 >>> VC_BUILD_ID_VARIANT: start >>> VC_BUILD_ID_TIME: Feb 25 2021 >>> VC_BUILD_ID_BRANCH: bcm2711_2 >>> VC_BUILD_ID_HOSTNAME: buildbot >>> VC_BUILD_ID_PLATFORM: raspberrypi_linux >>> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 = (clean) This matches what I'm using. So if the RPi4B version is similar, it would not be the problem. But if you have a 2711ZPKFSB06COT, it could well be. As I remember, someone with a 2711ZPKFSB06COT (but 2 GiByte), was unable to use the above frimware vintage. >>> PS: I've installed netBSD using the same card / pi 3 B+ combination = and it runs ok at 50 MHz. I'll try tomorrow on the pi 4 >>>=20 >>> ``` >>> arm64# dmesg | grep sdmmc | grep MHz >>> [ 2.009317] sdmmc1: 4-bit width, 50.000 MHz >>> ``` I forgot another thing that contributes to the boot behavior, seen via RaspiOS to get the information. An example inspection of the version information for this is the following. It is extracted from an old freebsd-arm message, not a current examination. # rpi-eeprom-update BOOTLOADER: up to date CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable) Use raspi-config to change the release. VL805_FW: Using bootloader EEPROM VL805: up to date CURRENT: 000138a1 LATEST: 000138a1 (I'm not aware of how to get this information under FreeBSD.) For someone to try to match your context to test it, the BOOTLOADER version is another thing to match. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 10:39:53 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 67D2818B84D1 for ; Thu, 25 Nov 2021 10:40:06 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (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 4J0Dsd16lkz4sH2 for ; Thu, 25 Nov 2021 10:40:05 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637836798; bh=YKoZBB4fkTeJF/suYZHrlYBeiEddKODwLz906ve0qbY=; h=To:Subject:From:Cc:Date:References:From:Subject:Reply-To; b=nyEvLkJc5i54J/hf1MtBhCppv79twACezIMRuWvK+azyq8QCKvcELWvMKAaXc8GMXKJDyHXGk480s1PwCzadA/CR2NQ1nbR3JsYKLQjmLQ5eui6F9ecZoFDIexhF7KSbNTVaSLlWrkc2fC1b7AV9BxCBg+Q3w8vJQCI/2UQKWOY/bKjgYABtO52X7AUgJpOOZMgIqvmzbq/Nle0YZgzBvHm78g9eZtltR+OrfRz6lUXBGyRTyiqzKYEyrcG5tAV+NLQ0mgLChgl2c16BGMV14wN8a1m0FAa5h16cHbTXiKwy21UDfRlXnme9wx/b5iq+wj6q0q1T55DCalOBXcUq5Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637836798; bh=saeM4WpnJUEHwb2xTIGRf76mBCX5yR9OaOxqm+BEZ/w=; h=X-Sonic-MF:To:Subject:From:Date:From:Subject; b=BHklRVtYtuaKdVaDSWWI+IzL0sN+1wzxilo1jmrrT+4L2aOiXHkpcqMzPeDXyrqGc4710165DOQ9BTdJYOxBXE5yECk6UN1SF3gZcJf4b9Lzog604+oQpGDIU3vZ7gtBCpEdlvUz9qSUtz6oQIGRx5RLF6X/+p3d+vKPiJgWKmQFl/5ZSww/9gXs/SUB3pZ/4TfLLI2rE+PMU2VzxFqhEGz1084cO8AO7aCRiSxq+SlrBwTvVbKuaW9/uPjMn81Nwwcs63nkNWIyrwWKMYM5RRnB1oNqwPkSeg8TxjDNP65X03U65UYrqePa5boqolSLOJMAkihxM9XEa3H9r8Sf4w== X-YMail-OSG: y4vqcNwVM1lvYybmig77.OcalWN3A8J.2qsph7zTzu7gstR9qhv.4g69f0WNmpj boHfBPHUk.GSIlEn0rCmo5uk1eMrFYLH5m91OfjClFarWJtZaNMqfQSOBHONLfQgYXi2B5we3d23 1q54OgU0xeNZHBff23oIyS16f3icoabDanChx6lcU.2IjBUvuAjw8LyRMAK_mTlnAbmaMa_x9_0t sSrCIUR_oN2lmV7HDxrCsUDu2Iuod3GcASnJjU5wKWit7jTg7TZwMpRrmbx5dg3xlRl99_jEBaxw vZSp4olNiAJu8rvuXyD5HeeIn3U6sgA78J_P3SIoLM_jUjsznhuOahS2yOkcpdyvALdq.NSzc4tb vwhEVN6_cHxj9oIyw436GL05GeqtNsncZThjmfBa9_qmNwpYX1DM_ZFzdhI0.JF507epWpyhLBJ_ 4UUCBhvOKLjKj49Xsxy7grPXf77mdLeCod3z9rzJyIa57NAbF9H04Vriy19aYe48BAEonGUwRKSZ ZTCbRc1.P4rKgMRrnqd1vb.DLgc37nagB9ttKysWmBHwbI99yA3OFMnFDXRCRtl4vB9gPhom.VMq I4rm2oKqcM0xPQ2fxKvHIKsrPhyrC4lCWmEAxVWQtuaYKV2hCoSmOww1J2yOEmYrYxO9m8Y_rjri YumpVu.WXIP8SsPpBxNY6z_65wx8fTvnj1dnMGe8nnM4ry1YUajLQX493uz2_Z8gN5hVl8hLQgN5 fQ2O1GxAl5a9fCx9ch.uG_I4nL2JFTSZyy.1RwkRNt0CFnmwM07_Jk__ofRczmlIVOcNBe9LUH1m hyJNUwgeFAd2WqjgyOo.1JrfLlgpw9CPkK0jJlp5S2esxlQ9bPUzZmd9F_v_H0znTT1lpUUu6UHk IGoN65u9YsI9l1ERw7VEQSk8LWnaa_A5ui_2VOLBYZwMt6yZxoNdJDARz63ZHXWwTR46BI38wY5V bTIWTJzl2ClsTGit3G_dAzjga5y5gQ9tmFRELN8A2HEUadLLqpOuVkVBtsJvoSr.pstAbmMJLQi_ QBeV5g3HdVUbGRzWYfMUhp2G0v0fKvQdOsCpjmNvxpwKgGVySo9AA4tFDnxx9TKtvnO19Sn9RC22 hHF_uPiwZiQ9RrEBzwa_ueYCFBkhk_ROG_i9mwybWiUV81oSe418Nr0butSaunSa8Hz4wrpNchp7 MakyX4w0E9sReTTrCyf98png.OxwFT7lxCdEm7VVIfFF0fX63paxt_XtV8gGZAR5f9QaYZpjP5Ww DfBMgyzp_uKB.Jtt1e9NurKT3zMOvxFSDWwRXfz4et8z9xvgP2FDMVJHLwxXoWOqFx_H2BSdTUhU vQAuBsS75cr9UrOc37X2DIsjLlnIQyDTnByGBLmZGewUG7fG5Iw70F4KuTHmLe9SR8tfCbMT0Uor 66g8gKPuY3PzlUaJ0zFOK6D8Jr3CPWyYn.p7s2tB7MS.th8kZBDhfGat1nxxD8H8AEXAYPvOnBvP .jrzV8c3KlFwIl5Ff3GzQPkqpzVLb3NGK0ZbhqvK76ca3RZk1mDQVirsKd1KbhFQ0n9_o.rS86iS x5qG34nnpG3b1.mlBYHrW1icSq3acRwpsqVqSbPynQdRazJE9dkYsjSI34nwER8F2wrXXAT6ULiy nVe80LBx9MVgm666lF7clxHCn2pXJhxqjkLUtMowQ.Ak50hR0ewf46SeOR1BiC03UKRnUveoxalz BIDaVZvBsPSNDS40Di8as_kzy9yh5nQMZbukIruWZoUu7P2F32eh9hT_cB7yKCYHvLnrNHe9WiWG 0atpVod9Zm3wVMs3oLnt7o_XmkV15NVa1sFR_p4HBCuCSc6imbGPbu18ShQR01va7OfQ7wV6z4If 7NfCHCUSXFl9lVkiWajXlX9aAqaTqfINoYFEqDw3iyYfMn12NhFscSTGKTaWNe.OPnuBrj_aR0cN bXnljUNQv.TDofdUDM9ip9miNsC0QFTI7RTPL4Nu.XPycmZznejY1Kqjf0x.szJgpaAzELphgG3U vGCLdgiqfCSag4bnP4ETXcnhG_dMR7J5ETNOLdkMQkTMY7pv4rZL3wEBMC5wkLClMdrAq30RByoO NyPfiqpApVa1KJw1dWRujLPpgf_h.0GCOXDtURA14LcaVMIeDff7OyBF0Bjawao94_0gh4fEp_WV PIUhg6MKuqwHFfRJvPkOeZrLywh0v5V.Jf94OzlEGGgRxMvZhGoFRk9GRI_YM2tQGsI7rndFmxiD TnT7I3GhAsiTpLzd0GOhsclcU63aQ1k0r1lVcTtX6Z5N8zqQp2_R6Fee0hfeiNqQnELFvgVw0Fgw R4QB8lKu6Fe3HST0WVNLjdrWI5KQUGSAaW_tTj0O_nc9hSNB3MBVVWnd63eUZQtgdqNF7xZw8B3M 76KFV3JRiFR4qv46kLhWHYL22DpUwyhSMgqCK0rRlfkyekCXge61gfUst32B2eJCeLRTCG5StSw. werw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Nov 2021 10:39:58 +0000 Received: by kubenode503.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c99b1323df133c9f49ea91a01b50291b; Thu, 25 Nov 2021 10:39:56 +0000 (UTC) To: freebsd-arm@freebsd.org Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ Cc: wb7odyfred@yahoo.com Message-ID: <263f439e-43bd-b813-fa8a-14cb2c85c85a@yahoo.com> Date: Thu, 25 Nov 2021 02:39:53 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.8.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: multipart/alternative; boundary="------------69E4829E703704D5577829FD" Content-Language: en-US References: <263f439e-43bd-b813-fa8a-14cb2c85c85a.ref@yahoo.com> X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Rspamd-Queue-Id: 4J0Dsd16lkz4sH2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nyEvLkJc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of wb7odyfred@yahoo.com designates 74.6.129.41 as permitted sender) smtp.mailfrom=wb7odyfred@yahoo.com X-Spamd-Result: default: False [-2.62 / 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)[74.6.129.41:from]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[74.6.129.41:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_LONG(0.38)[0.377]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; FREEMAIL_CC(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Reply-To: wb7odyfred@yahoo.com From: Fred Finster via freebsd-arm X-Original-From: Fred Finster X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------69E4829E703704D5577829FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Mark Miller and others, We need to /*audit*/ the  /boot files, plus other source and binary files to confirm we are using the same binary software.   Just tell me if there is a work flow, that I am not familiar with that audits files to verify this set of sources match that set of sources.   Yes, the point of this "group of emails" is to look for the Poor performance on Raspberry pi 3 B+. Also compare(audit) Raspberry Pi updated firmware files  to the same files in the FreeBSD 13.0 Stable (or FreeBSD 14.0 Current) sources. Here is an example of using the md5deep  audit tool explained on my blog post. https://ghostbsd-arm64.blogspot.com/2021/05/audit-your-boot-files-with-md5deep.html *Example Usage for md5deep* I put an /*md5deep*/ example using the source files config.txt and start4.elf and fixup.dat for my use in May 2021  on my blog https://ghostbsd-arm64.blogspot.com md5deep -z -b *   > ~/audit_bootfiles_raspi4b_may12.md5 Here is the manual page for md5deep http://md5deep.sourceforge.net/md5deep.html http://md5deep.sourceforge.net/start-md5deep.html https://en.wikipedia.org/wiki/Md5deep Github location for HASHDEEP/md5deep tools.  Read for information https://github.com/jessek/hashdeep from Jesse Kornblum Github I suggest using this audit tool /*'*//*md5deep*/' to keep track of files each of us is using with the raspberry pi Freebsd sources in the binary images we create. I always wanted to compare the /boot directory of files in the freebsd sources to the updated versions of the same files from the raspberrypi github.com sources for the firmware files. https://github.com/raspberrypi/firmware   Look the boot files were updated 3 days ago.  approximately November 22, 2021   are those flies updated in the freebsd sources to build for Raspberry Pi 4B?  The test sbc computer, I have available?   I just want to see updates that fix problems in the raspberry pi github, promulgated into freebsd sources.   With an audit tool, we can prove yes those changes are here in the FreeBSD sources.  or prove NO these changes have not been incorporated yet.   Example in U-boot.bin April 2020,  then there is a newer version of U-boot.bin.  I think you, Mark Miller, mentioned this in your analysis in a separate email. I welcome other methods to audit the source files, we all use. So we can verify that I use the same source files in my binary build of FreeBSD,  that you use in your binary build of FreeBSD. I am very excited about the Tier 1 build for (aarch64) ARM64 by FreeBSD Foundation.  I use and test their snapshot builds from https://freebsd.org/where https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20211118-4082b189d2c-250820.img.xz November 18, 2021 snapshot image for FreeBSD 14.0 Current for Raspberry Pi 3/4  Thank you  FreeBSD Foundation for this service you provide!! Your friend,  (pardon for my mistakes and lack of knowledge of the FreeBSD build process. ) Fred Finster mailto: wb7odyfred at yahoo.com telegram group  I administrate:   ARM Open Source https://t.me/joinchat/ST6N61pnu3Di8zgk You are welcome to join and contribute. --------------69E4829E703704D5577829FD-- From nobody Thu Nov 25 17:55:10 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 D0AB618BABC7 for ; Thu, 25 Nov 2021 17:55:21 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0QWs5G5xz3qqr for ; Thu, 25 Nov 2021 17:55:21 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x931.google.com with SMTP id p2so13788735uad.11 for ; Thu, 25 Nov 2021 09:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5Ys9ZHPUenhsN+2wCR5p0WawBkiR1iIBqVfxqotDRQ=; b=U8Ywt8MlqOwJlTM+9iIkGxFoA87Ls7PZevBRzzZGeIL59K4hk3BqZ4hFRedXFUf4Rs 4g4/lxgBCJfKYfJvV4uPeqO/+BHRjlYLPkNuVP8FV8B9iL4HIPcv1wV/Wn/AmeM2lE65 3WmpwrCdl3m3g4d2wfv7IjTFvBCf2XS9hebM8HDEvF5e9EddWnZ2oBvjCW3IkaJlOJMZ tdTMQRv2aJSFjET5l5OsShyx85DnV508tF6PFcibYasl7V032EKgp3D/ekBDZiRPF7d4 otpQ62PyOSj9H2qQTKNE38ue9xCQO4RpMYOjhWP8Rp3aa31lF3c240qKu0QGr2qUVJ+2 kSqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5Ys9ZHPUenhsN+2wCR5p0WawBkiR1iIBqVfxqotDRQ=; b=mIVjiOZCoj7KTJVsXEHa73B8caVw3Cd5fJ2wajme9crXgqk6/h+kFJejQnVKh0dZfu cIRwlq0vl8ExrM0/4lgmGNK0aHIs49qA85stQ86wUvXu7ZK8zofTVtpQbR1zX/R53kML YB9XlMmoPqtj/PVSQJWlA/z3ZZhyA4IQk8+FzeE+JMouwUqee/jGPnvxj6YFOcH64iwy ZvYIqk+/ad8dWrgMGlOJXe4a0oVMSJOnvPjTBBYHuaK0VBHd5fgfk4y0BIBev0S4JHUI Gw2+5MDYUBUjbpV1As2dv1kZ5/z6W0ch1d0mJ51SKyPOU2f7zwAkzXhe5qItuyAfZS9I 6e9A== X-Gm-Message-State: AOAM530Aox5UiQMAKiJQ6D+ckgfV0sGnB/kfgpeg5476mQc0auGAbYAH 7UGf8kVVtSh7VPYZInD7kpK0Kkn5MJz0sEjq0cH3UzXoNIIf X-Google-Smtp-Source: ABdhPJyXMN6EoBthc8ORruRnJCPuJC1KquZOT3pkhv6DF+zBuQ8oVX5wlmEYtKC9PqkNN7rRbUEy9evqe++9tu3OXoI= X-Received: by 2002:a05:6102:358b:: with SMTP id h11mr11864079vsu.24.1637862921321; Thu, 25 Nov 2021 09:55:21 -0800 (PST) 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 References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> In-Reply-To: <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> From: Juan David Hurtado G Date: Thu, 25 Nov 2021 12:55:10 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: Mark Millard Cc: Free BSD , bob prohaska Content-Type: multipart/alternative; boundary="0000000000009de6d205d1a0adb2" X-Rspamd-Queue-Id: 4J0QWs5G5xz3qqr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000009de6d205d1a0adb2 Content-Type: text/plain; charset="UTF-8" > There are: v1.1, V1.2, and v1.4 revisions of that. > Which? Raspberry Pi 3 Model B Plus Rev 1.3 Raspberry Pi 4 Model B Rev 1.1 > This is not what I've been using (2021.04) but I no > longer remember whatever I knew about the differences > in behavior. I've made a firmware update using `rpi-update` on the rpi 3 and `rpi-eeprom-update` on the rpi 4 (while on raspios). Same 0.4MHz so far on both of them when using FreeBSD. As for the label on the SoC... I have heat sinks in both of them :) I wonder if there is a command that I can use to get that information without removing the heat sinks. Thanks! --0000000000009de6d205d1a0adb2-- From nobody Thu Nov 25 19:29:38 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 5FFD318A1CEA for ; Thu, 25 Nov 2021 19:29:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4J0Sck6L84z4tSF for ; Thu, 25 Nov 2021 19:29:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637868581; bh=gaM3zl8MjiHDv86mwqhnB0WRsgPIhMRK6g+OwMXlESw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XFh6lcI21CbOFwJMaftrr/I3rWv+m1Vq9FUmXycfuOFTcOAPXZMkqU0OYpNXoX/beSlY5+7C7YJ5kXr3bLzZpfM+CwSS6GeJ450XXCWFZvchqH4UYYBTfOHaOUR/lcb+nhpR+kOpftKxKayL+ZJACyBSn0tFIBuHQzCiYwbL2V6SQfW4JLUm3yh6BtFCg57hxmzD4nJnMqnWA/O5r8Bt8PyDMju6BQ1fDeYX2QMZD2AhpzIq5cpQFDdcTRz+7mWrkdsuqJWXBBZ15k1mJ3I8CI8E/CYX2RWdC3a6aVLAzfKHLZcn7v4eseUlehanbYCi0RW5dyck9OMfYtwNvFS13g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637868581; bh=xpwDpoJtsONZae694u100tbBr7s6kwsJPFPLwrnbCqc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iUk4f+7EHpGDvODeniEQX/HLP2f9KOuTWEj7gIeOuhcYwlNnXHwK7wkYtUEgwoDuc1EbDOpPGxfm/BDDwJS1mlJNnbxqjUOlotucH6IB0/8s6HTjqssX5ds8zaLa3ldJN5Zc48C8S4+EZ0MeGGNrklEi4s1VsbkfCnmQJwXPmF3tcI5SR1W9XswprP9D8GQUyONU9jN2VI3/J44FjCQAgr6hiV6Ztd6J1RVS8p5U2lswmPzhAHMr4QqzkQa5fX2JDovQaxJMKaPAP64oJPUUyudWHSCKEveC78wmUUg+oHfSEVc4EQhoiTsOekGqXS4q3N9cFX14C0afp9wRq52XCQ== X-YMail-OSG: 2I1mPX8VM1k02ISf55Kl0Mg_wXS7y7hcjZ7Ca8saR4mda2I9JPa73fak7eOogU6 523fjdpwJeRJLbRFgAp2HLPaa_uSjjLsX_w20GhshN5nxdaVsgycmPxzOoG.dRIodDpC31QTTeqz Mk45gQsD5d.SV.R_XWZtsEaVm.QTxTg408GeMpjy9X5q7uBLyDPDo8LBYR8iJHuf5gvhDcoP3kAA v4Z97JhMLyjKn15dPI7MHVC3SaD_n.HV01mavuioWIOuvP.lbedxrRM6RlBgbFw11HfRFhzENXpO UtRbNoBL_HlWhUK8OFuvas0HeLG8cybzfS4sevrsTyOmHtsnHdnMk5qknotJuLi1KOs7bzTpgcWU 77wvgu5twIQoz2ijUpwSNArhhkLp7GsAHEYJc2mcEmZJutbQMS6oFPr4GBnxIwTowkELp4IagIFu znDMZP5fdipqCJGbClhy6TUa4y6dUAGKMWx56LZHzEaqlLkNMX7vqy8JIDYbf7QkUadggasL2fZz oCKU1GK6XWB8OlOhYKAXdMlFjLLFiqnFMxo7MTz3rGId5YmIJ89Ax.fphF05EjOSjlfV_Qilw598 hLU9aT6dicCaeDkgu6_f68KkZPZDgL5oUsBiQUHz1wMxGQJQCOu7Y._zI9zHLYBb..fNePfKpajC BR18CbujPWTo17ccnOpyLmZIBjUWCxdLlO4jrov4XwWFlNWOKPCaVC6ABgqjsaWi2Nf.Oz2eTejP uckq2CFM7u0cxEZdhy9oRwVrvc_i6SUPhH1N3JYHVP.w4qvqJNmWBb6laQWcVmdKDXfXm3fO7h_6 Vb3QP.CvNaXRxbmzwPmToW0vY5U8PpuzGUsivbD.ITmf5Fhub_nPq5k5VhtG3qKubBhswHDl_mpk KQjRnNQ0HbwBC8yAzbKeSJ_yDQSpjIKnMTKKPi3g1W5DXlYfQMJtpZs1r9IrGH1aKsFCTztcKagP 51y7KT6s4FOKtMFjvd0DbdDD_gQdgb9agLYuRy_ZHxVQrqds4DN_SxPXCpcw.n6rItmQywyfi9Xw ekCarjvgBBg8dhApx0eOdaK8h5g1ntj4MVKkobrWAxZ1VoxCZqgGvbNJvN5Tur7tNSTYcaL6Ug6x zA12OxFt6mtbvwytQwqB2Jcgh2jjbOC0KlTNDjdWcqHUYK.B.N3l.Nc9oeLS4qQYAXWBTbCsUIm7 bxkFRDoVcwe_ZNSDFaqY6mn4YVyf3r75tOcXw8ebOXByJdI8lAGHs_avFyIvz2c2G6tcf_mLrbBQ 1TkQPMMNp7xzEzY1997bevCzg224SKTwb1w3aLiJdOa1qR3.PooUVIiWZKfYLFGRxkHckgfTa10Z GAwk94zw_GvN1PFgBmMDqo92qwJ768uAnCdRGQKhDIwgFZNlbq.LSVmcdwjNVPlC3S9Nc_83c7UO Jahz.vW3UbWimUi.Zzew5zzFBdRxYdRRgLShyLBlvCWiTbdsYVj59oFUCG06Vy7nuZLf7mPA9Afa lfaa3zX.7TT6dmSxeOF9yRa_mfXzu82X9J8nfFKae5zVUEyt0..xI_4znNLi8SD1qP_7xnUi_rnP 38vHqGEN0bQflBTYS74VxyrCK0zRAHPikvQm2YBqQp2DIpJbW3zDfQBoomIauT9k57_r3xkv_969 XByjoaUs8dGW6vltZhnXNVdCaMxnF.n7wIBBvJBUz991IFc9ScUKL4zwLo34Ri4YrmWbFdm3IkTC dQWsp0xWO40o6SOTWDZ5kD1puKGzzA4j9tzXPD3hqie2sp4peUdHqx5fv6PKKVn77MH7WNsP3Xn9 Hbfo5zBWu4C6N0epIUKNIALguf3hNChiNAacVammM2uCrG29MNRmS2_xI3lzYMnoLPgGmVwEg9hI pPmLGxESfQf_mALVUsKpdVTqABo1PD4U0NUBiF7ewdCllAePlXoUWG4.PLgsdBSuNxk8M6IFCzEy X2P4x8aRm3zTmy26maxKKvBpRNVz4rOlq3n8.3G7VwpRLvnTR6VDe5u8NhJ0wBS1L2JnVpKkqmS3 gB5QN6KZzdrJOc6Pc3hL7bBKBtF2w21E38TkjBAJUh8FLO_74LHm1zdZCVChL1WbDnT5aBbHaukv oZOlSJ2sh..bO0Y7rKuu7sBwKsyQ_oM5yyzxOwwa.t5d9cajyFa28kUCwbvxsp32FrN74Imb7vPu HK_.4w9i3Boo7T6vhUVv2U2lJbmQa5qlt9khLsU1AoNQoeLC_bxFt2lGtgjmr7AXQmvuj3V1cF0A R7fh2OoAyw1AFAnlrDY.ZEm1m2UpS6ukXItJTipC4qYUkYIMkLOTOBCZ31RojTEdYywP4.n7GpNN nXPm1BCKQL5tjF1Qy4Dd6EPQdzQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Nov 2021 19:29:41 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6c704fb1cc77d51b052d74db76cf0014; Thu, 25 Nov 2021 19:29:39 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: Date: Thu, 25 Nov 2021 11:29:38 -0800 Cc: Free BSD , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J0Sck6L84z4tSF 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-25, at 09:55, Juan David Hurtado G = wrote: >=20 >> There are: v1.1, V1.2, and v1.4 revisions of that. >> Which? >=20 > Raspberry Pi 3 Model B Plus Rev 1.3 > Raspberry Pi 4 Model B Rev 1.1 In a few days I likely will have access to a 4 GiByte RPi4B Rev 1.1 . >> This is not what I've been using (2021.04) but I no >> longer remember whatever I knew about the differences >> in behavior. >=20 > I've made a firmware update using `rpi-update` on the rpi 3 and > `rpi-eeprom-update` on the rpi 4 (while on raspios). > Same 0.4MHz so far on both of them when using FreeBSD. >=20 > As for the label on the SoC... I have heat sinks in both of them :) > I wonder if there is a command that I can use to get that information > without removing the heat sinks. For the RPi4B: being an older variant (v1.1) would mean 2711ZPKFSB06BOT . 2711ZPKFSB06COT only showed up more recently. (I'm not aware of any software query equivalent to the labeling on the SOC. But not being Rev 1.4 (or later), finding the label explicitly should not matter.) For the RPi3B+: I'm not aware of ever needing to know any labeling on the SOC. I focus on the RPi4B's as I at least have access to a variant and should soon have access to a match. No RPi3's currently and I've never had access to a RPi3B+. There haev been past reports of RPi3B+ oddities on the lists as I remember. I normally do my own buildworld buildkernel and install such. I build with tailoring, such as -mcpu-cortex-a72 for targeting RPi4B's and other Cortex-A72 systems. Thus my normal context would not match in an audit vs. your context. And I've picked other things like RPi* firmware versions based on experiments. (Various releases have historically been problematical.) Other than running one USB related bug in FreeBSD via my -mcpu=3Dcortex-a72 builds, I've not had mismatches in behavior in general. When I've access to a 4 GiByte RPi4B Rev 1.1 I'll produce a microsd card from an official 13.0-RELEASE image (so no -p? at the time) and see what happens when using it to boot the 4 GiByte RPi4B Rev 1.1 . I'll look up the eeprom version in use in the RPi4B Rev 1.1 when I have access and report what it is. I definately updated it in order to have the usb (no microsd card) style of booting be possible. It will be another thing to compare. (It is also something that an installed-files audit can not cover.) So far the one notable difference in our context's is your context's U-Boot 2020.10 vs. the 2021.04 in my context. I can capture a binary byte sequence of the output of a boot, such as verbose one. Looking for differences in such might prove useful, given well matching contexts if my results do not match yours for the frequency involved. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 25 20:16:58 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 5455F18BAA09 for ; Thu, 25 Nov 2021 20:17:10 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0TgV1dFVz3kPX for ; Thu, 25 Nov 2021 20:17:10 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x935.google.com with SMTP id l24so14599697uak.2 for ; Thu, 25 Nov 2021 12:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/kyBDGBjVBg+62VGhge3N97FfHQLDbVYe++5PTX7DE=; b=EmUanfr2L6lXBkYzEqGFH83I00KYmjPxf2ixfqp+cMralFVXuxBuZaANzYZRls7Uvk D4qIAtQEisH8lrBEnXwTR6n4OfhAygd8ihusPK4C07p8LN8DMIniN7xI4bRwJ8HZfx/l uKQKeyP3NSzc2tJmnRXDDTPAixq70ZFLum6dKrfJAI1sRDCqIyGMNoIGbQBJdYQ5l/gZ KtUb1HT5wQ+dNW8B9p7pamFMNPMcFJr7vdJP7oEwlm78euTLH2Gg6cXkKZnDLUOnXuvH KJfIK/y4bkYGpZNpC7BND61zoAOEHJrYGtCuxTYhZzSd4AVlfCFH/ReA/faQTUbLDRKe Vj4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/kyBDGBjVBg+62VGhge3N97FfHQLDbVYe++5PTX7DE=; b=M2IDZPd9S8ORtrWyW38Kxf5yrafGId+vvCyY09Uppnok8kHFuiUtzlWnVptHFhHbtr MHzzcQd2cM3WBpd7TL6ViRILxIMd+pSBnEqYPBdliyEiMmeFcuJIMpepF5/63DEbF2hV HEAdWUFVPf+Utgr9JRmWaivMTSXdM3asWPRxqLt0pyi0q1lUJL9AHKipIcVdpPlfoxV9 ycSXkmoa+mXZNL7BQcXfu284ik/+M3//a8ODm/P4uSgkCSfj3s5f/6IP/LYeagxZ/iXV KGFp3wwF9ohVN245YgOrm6FY++RhnT6zeH9Ks89SM+C9DtydZQmmkuFveCArR2Bk9+py dMZA== X-Gm-Message-State: AOAM532GOB3s3l0JNOdSS5QIoQDpDNMviCSvrYzmjsDuPIagS7liMn9b WDOp+erj237hjngOAltiaUEHzhHXKWiHQ5o4LMWzN/rq1tfm X-Google-Smtp-Source: ABdhPJxKUNyfSbMx1VHWaGaQnI7lFoiAzZ7bxAZ4df+xux6BJyd9VvwXqnqP9/3mFGTgPUsIzoWQR0RE60CZ5S4xMVM= X-Received: by 2002:ab0:7095:: with SMTP id m21mr30602198ual.82.1637871429638; Thu, 25 Nov 2021 12:17:09 -0800 (PST) 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 References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> In-Reply-To: From: Juan David Hurtado G Date: Thu, 25 Nov 2021 15:16:58 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: Mark Millard Cc: Free BSD , bob prohaska Content-Type: multipart/alternative; boundary="000000000000c06f8405d1a2a881" X-Rspamd-Queue-Id: 4J0TgV1dFVz3kPX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000c06f8405d1a2a881 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I've used `sysutils/u-boot-rpi3` (for the 3B+) and copied the u-boot.bin file to the sd card before the first boot. ``` root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" U-Boot 2021.07 (Nov 12 2021 - 01:50:18 +0000) ``` Now I'm U-Boot 2021.07 and at the same 0.4MHz :) I'll definitely wait for the new microSD to arrive hoping that it will work= . PS: Current card says HC I in its label and U3. Weird is that other systems do work well with it. El jue, 25 nov 2021 a las 14:29, Mark Millard () escribi=C3=B3: > On 2021-Nov-25, at 09:55, Juan David Hurtado G > wrote: > > > >> There are: v1.1, V1.2, and v1.4 revisions of that. > >> Which? > > > > Raspberry Pi 3 Model B Plus Rev 1.3 > > Raspberry Pi 4 Model B Rev 1.1 > > In a few days I likely will have access to a 4 GiByte RPi4B > Rev 1.1 . > > >> This is not what I've been using (2021.04) but I no > >> longer remember whatever I knew about the differences > >> in behavior. > > > > I've made a firmware update using `rpi-update` on the rpi 3 and > > `rpi-eeprom-update` on the rpi 4 (while on raspios). > > Same 0.4MHz so far on both of them when using FreeBSD. > > > > As for the label on the SoC... I have heat sinks in both of them :) > > I wonder if there is a command that I can use to get that information > > without removing the heat sinks. > > For the RPi4B: being an older variant (v1.1) would mean > 2711ZPKFSB06BOT . 2711ZPKFSB06COT only showed up more > recently. (I'm not aware of any software query equivalent > to the labeling on the SOC. But not being Rev 1.4 (or later), > finding the label explicitly should not matter.) > > For the RPi3B+: I'm not aware of ever needing to know any > labeling on the SOC. > > I focus on the RPi4B's as I at least have access to a variant > and should soon have access to a match. No RPi3's currently > and I've never had access to a RPi3B+. There haev been past > reports of RPi3B+ oddities on the lists as I remember. > > I normally do my own buildworld buildkernel and install > such. I build with tailoring, such as -mcpu-cortex-a72 > for targeting RPi4B's and other Cortex-A72 systems. Thus > my normal context would not match in an audit vs. your > context. And I've picked other things like RPi* firmware > versions based on experiments. (Various releases have > historically been problematical.) > > Other than running one USB related bug in FreeBSD via > my -mcpu=3Dcortex-a72 builds, I've not had mismatches > in behavior in general. > > When I've access to a 4 GiByte RPi4B Rev 1.1 I'll produce > a microsd card from an official 13.0-RELEASE image (so > no -p? at the time) and see what happens when using it to > boot the 4 GiByte RPi4B Rev 1.1 . > > I'll look up the eeprom version in use in the RPi4B Rev 1.1 > when I have access and report what it is. I definately > updated it in order to have the usb (no microsd card) style > of booting be possible. It will be another thing to compare. > (It is also something that an installed-files audit can > not cover.) > > So far the one notable difference in our context's is > your context's U-Boot 2020.10 vs. the 2021.04 in my > context. > > I can capture a binary byte sequence of the output of > a boot, such as verbose one. Looking for differences > in such might prove useful, given well matching contexts > if my results do not match yours for the frequency > involved. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > --=20 Juan David Hurtado G (+57) 319 252 3773 www.orbiware.com --000000000000c06f8405d1a2a881-- From nobody Thu Nov 25 22:32:29 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 E440F18B70E2 for ; Thu, 25 Nov 2021 22:32:37 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0Xgn1Mrqz3J99 for ; Thu, 25 Nov 2021 22:32:37 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pl1-x633.google.com with SMTP id u11so5452311plf.3 for ; Thu, 25 Nov 2021 14:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZKFnEowYFk/507FXFIzH1dilE26gTlNny0E4hPLxECo=; b=F+nymTKK4E7rYl299HjmcuvFqsPEtYDXSXkjsWI9u9FW1k4yMOmwuQqkOJMwMW80Nh iG+kCwf/1eoApHtzW5i5F9cXZnal3rqsScFl+ST/799y0Gkn2jt7ceaBsm1JzvhQZU0v 7HHFM/UmICuRatGXO9yyBuGzg+946suZZ3hH5FnCfJOds+bdjWtda09dJVHAuNdx/3Sg yUZuksW9kAq7WxA3WahpbFnbl588+uSswv0iENRv9+Qj+kWWitpRiZzBj+5MOG+FcnTr bEzHyO/LFn2M2MKm9j+kbTUpNzt3C5/o71NufUB7gdLgW28ZhR9rms2IkmlT9zOKqxxF tBYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZKFnEowYFk/507FXFIzH1dilE26gTlNny0E4hPLxECo=; b=dYu2rOwF1KUhU8IrNDNX5Jtauy9TH+668KfaMgSiFCjuq7j4/3b+wwWsioGGm+8PqW ZG4LE/+VcJj5drJUkwmuYqroTOyj0Z7OjAEqNhOJ1UygsEr4vt9oiNEONoCCmkWmatgC fUVF0UF/wddd6dsMwIqJnYAo8XEBbPZQoPTN/PUlVBH+WHR7Qf6PdSds7RWQEUz+nrKz /WHEc4QSuYaWGoS1vh5lecEV3EXyh7x5nFehuXFE3oYLtu60yNSK7ZpjVr77DBpI6DzM sFEZjAlMdoSp53j1aZGUAzBL8HoXB6cXkNETOZv81iz41y+RPQYcxBmoxHvqQcvXR7Vi sEhg== X-Gm-Message-State: AOAM533bigJ6EAggyysWYqjWzNWMdmvI0Id2AGXAQ8X5j17k3aWM9pYS r+y2I/5VI+3eK9PO//kEL1uxiA/nWwEuqu7p X-Google-Smtp-Source: ABdhPJzc5a7M4rR2l368Fp08KC88YrUonJRVjxUnHRqvtz0oMVm26uIvG4KBUEWmy3Jf9yOCEVqvlg== X-Received: by 2002:a17:90a:df01:: with SMTP id gp1mr11318438pjb.28.1637879555501; Thu, 25 Nov 2021 14:32:35 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id i193sm4268312pfe.87.2021.11.25.14.32.33 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 14:32:35 -0800 (PST) Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: freebsd-arm@freebsd.org References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> From: MJ Message-ID: Date: Fri, 26 Nov 2021 09:32:29 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J0Xgn1Mrqz3J99 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=F+nymTKK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::633 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.00)[0.001]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::633:from]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N HI Juan, On 26/11/2021 7:16 am, Juan David Hurtado G wrote: > Thanks, I've used `sysutils/u-boot-rpi3` (for the 3B+) and copied the > u-boot.bin file to the sd card before the first boot. > > ``` > root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2" > U-Boot 2021.07 (Nov 12 2021 - 01:50:18 +0000) > ``` > > Now I'm U-Boot 2021.07 and at the same 0.4MHz :) > > I'll definitely wait for the new microSD to arrive hoping that it will work. I have a RPI 2B with Sandisk Extreme 32GB and its diskinfo is as follows: # diskinfo -tv /dev/ufs/rootfs /dev/ufs/rootfs 512 # sectorsize 31861506048 # mediasize in bytes (30G) 62229504 # mediasize in sectors 4194304 # stripesize 3145728 # stripeoffset 3873 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. SDHC SE32G 8.0 SN B3C83C06 MFG 10/2016 by 3 SD # Disk descr. B3C83C06s0 # Disk ident. # Attachment Yes # TRIM/UNMAP support 0 # Rotation rate in RPM Seek times: Full stroke: 250 iter in 0.151175 sec = 0.605 msec Half stroke: 250 iter in 0.148608 sec = 0.594 msec Quarter stroke: 500 iter in 0.298612 sec = 0.597 msec Short forward: 400 iter in 0.190279 sec = 0.476 msec Short backward: 400 iter in 0.191797 sec = 0.479 msec Seq outer: 2048 iter in 0.764279 sec = 0.373 msec Seq inner: 2048 iter in 0.769431 sec = 0.376 msec Transfer rates: outside: 102400 kbytes in 5.805765 sec = 17638 kbytes/sec middle: 102400 kbytes in 5.954521 sec = 17197 kbytes/sec inside: 102400 kbytes in 5.891870 sec = 17380 kbytes/sec Your card(s) should at least get these values. My dmesg sample: uhub0: on usbus1 mmcsd0: 32GB at mmc0 50.0MHz/4bit/65535-block bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF If I read your cards correctly: >root@generic:~ # dmesg | grep -i mmcsd >mmcsd0: 31GB at mmc0 >0.4MHz/4bit/65535-block >``` >Raspberry Pi 4 with a different card: >``` >mmcsd0: 31GB at mmc1 >0.4MHz/4bit/65535-block >``` I guess the first is Silicon Power but I don't know the last one, Texas Instruments?. So, maybe it is just the type of card? That doesn't explain why they work in linux, though. On the forums I have read where anything but Sandisk seems to be problematic. I have always run Sandisk Extreme (pro) on Raspberry Pis and never had any slowness and just 1 failure in many years. Regards, Matt. From nobody Thu Nov 25 23:53:15 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 069D418BCB21 for ; Thu, 25 Nov 2021 23:53:19 +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 4J0ZSt5kJZz4Tb9 for ; Thu, 25 Nov 2021 23:53:18 +0000 (UTC) (envelope-from greg@unrelenting.technology) Content-Type: multipart/alternative; boundary=Apple-Mail-38E0BB4A-7464-4E60-B52E-831514788D40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=key1; t=1637884396; 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=fi8O8zHyyYdIfKvZ7NmvtLRyKql812rfRi3HImD5hvc=; b=YTqNurg2ewxRk5AHb5ehuXpUTXkvVzbTqIsH2ZN76pqq+NG/Ede4/CIY6cpaKe7dEML7By 71YNoZTWaIT35VbgluxLebWb/SnxtjBoM6Wm9orylux7zdnoMRW20EKGJ0bOglKz7UWgSC QkruYJ7wKi7WbvnN/1FbOBPyErvoc1pMLN+32dHGPWMRNHnWcOzuMVK5fSWFlX2iJnQkoX su2KwKZJvgopc/xumhOAfakt5w4FTvxlfOoLamra7m2cVbhOz+otzE1iPsltYFiNEVq1/r 7q7uPzPpbZkb7jD2T5NxtuGj2uRTNp9B47q9qTkqJC/Eq1NB7ASe3uYq5ZABFw== Content-Transfer-Encoding: 7bit X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. 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 Subject: Re: world linker error "can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment" Date: Fri, 26 Nov 2021 02:53:15 +0300 Message-Id: <5B9D4DF1-32FE-4918-9A8F-DF528E88BD05@unrelenting.technology> References: Cc: freebsd-arm@freebsd.org In-Reply-To: To: "Bjoern A. Zeeb" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: greg@unrelenting.technology X-Rspamd-Queue-Id: 4J0ZSt5kJZz4Tb9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: greg@unrelenting.technology From: Greg V via freebsd-arm X-Original-From: Greg V X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail-38E0BB4A-7464-4E60-B52E-831514788D40 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 25 Nov 2021, at 04:38, Bjoern A. Zeeb w= rote: >=20 > =EF=BB=BFHi, >=20 > I am trying to update one machine (also across the LLVM update) and I get t= he below error. > Anyone any ideas? >=20 >=20 > ld: error: relocation R_AARCH64_ADR_PREL_PG_HI21 cannot be used against sy= mbol __stderrp; recompile with -fPIC >>>> defined in base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64= .aarch64/tmp/lib/libc.so.7 >>>> referenced by assert.c >>>> assert.o:(libspl_assertf) in archive base14-251054.3ede04c= 78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch64/tmp/usr/lib/libspl.a That would be https://reviews.freebsd.org/D32521#739094 =E2=80=93 this was f= ixed in the final version of the patch that actually was committed though. And I=E2=80=99ve just checked that it all builds on aarch64 too. Works for m= e, and presumably for anyone else building world in the last 10 days or so. S= o that=E2=80=99s weird. Maybe some leftover /usr/obj state somehow causing i= ssues or something?= From nobody Fri Nov 26 09:21:54 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 63B2118AB52C for ; Fri, 26 Nov 2021 09:22:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0q5D1fjsz3Kpf for ; Fri, 26 Nov 2021 09:22:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EC0308D4A129; Fri, 26 Nov 2021 09:21:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 20C59E70815; Fri, 26 Nov 2021 09:21:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XCKXVXthCBIa; Fri, 26 Nov 2021 09:21:55 +0000 (UTC) Received: from [169.254.1.48] (unknown [IPv6:fde9:577b:c1a9:4902:2cb2:a87c:b0d6:7458]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A894AE707D9; Fri, 26 Nov 2021 09:21:55 +0000 (UTC) From: "Bjoern A. Zeeb" To: greg@unrelenting.technology Cc: freebsd-arm@freebsd.org Subject: Re: world linker error "can't create dynamic relocation R_AARCH64_LDST64_ABS_LO12_NC against symbol: __stderrp in readonly segment" Date: Fri, 26 Nov 2021 09:21:54 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <4C688B42-E443-4B44-9048-7B84BCE35982@lists.zabbadoz.net> In-Reply-To: <5B9D4DF1-32FE-4918-9A8F-DF528E88BD05@unrelenting.technology> References: <5B9D4DF1-32FE-4918-9A8F-DF528E88BD05@unrelenting.technology> 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: quoted-printable X-Rspamd-Queue-Id: 4J0q5D1fjsz3Kpf 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 25 Nov 2021, at 23:53, Greg V via freebsd-arm wrote: >> On 25 Nov 2021, at 04:38, Bjoern A. Zeeb = >> wrote: >> >> =EF=BB=BFHi, >> >> I am trying to update one machine (also across the LLVM update) and I = >> get the below error. >> Anyone any ideas? >> >> >> ld: error: relocation R_AARCH64_ADR_PREL_PG_HI21 cannot be used = >> against symbol __stderrp; recompile with -fPIC >>>>> defined in = >>>>> base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch6= 4/tmp/lib/libc.so.7 >>>>> referenced by assert.c >>>>> assert.o:(libspl_assertf) in archive = >>>>> base14-251054.3ede04c78c7c726ed79a39d22c65a58d0ecc5d00/arm64.aarch6= 4/tmp/usr/lib/libspl.a > > That would be https://reviews.freebsd.org/D32521#739094 =E2=80=93 this = was = > fixed in the final version of the patch that actually was committed = > though. > > And I=E2=80=99ve just checked that it all builds on aarch64 too. Works = for = > me, and presumably for anyone else building world in the last 10 days = > or so. So that=E2=80=99s weird. Maybe some leftover /usr/obj state some= how = > causing issues or something? We found that this particular build issue is caused by WITH_CDDL and = WITHOUT_ZFS as a result of a recent commit to fix library dependencies = in that area; markj has given me a patch and I tested it successfully = for that specific case last night at almost 2AM; I assume the issue = will be solved the next days in main. Sorry for not following up = anymore last night right away. /bz From nobody Fri Nov 26 11:48:48 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 207B018A8CFC for ; Fri, 26 Nov 2021 11:48:49 +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 4J0tLS5Rn7z4nwX for ; Fri, 26 Nov 2021 11:48:48 +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 982CA10A for ; Fri, 26 Nov 2021 11:48:48 +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 1AQBmmRX089189 for ; Fri, 26 Nov 2021 11:48:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AQBmmYa089187 for freebsd-arm@FreeBSD.org; Fri, 26 Nov 2021 11:48:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 255048] arm64/ROCKPRO64 freeze during heavy IO on external USB 3 disk Date: Fri, 26 Nov 2021 11:48:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hlh@restart.be X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637927328; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V3H1Jjh96s46/CPrFIstELTd/vqP8bfxiXGijPNbmWU=; b=lBSnUUwVzsgC9JRe3L8NkUTexg8hyPthsQsCeGAlJgfjNJKd38NQVBlFUkZXevc0EpdwIg MiY8r3fGOFM05KiAnCMCPpE1ASIBSdzCctXl7dYiKFVmmumTGkJ66iY6qM4mmyppe7mWAc S3TRrplGih+rtoQ41z46Qcou/dmJfas8Qz0G6DBINBm8Z+0Beq7l1YQZKTfNGZSebhGDyp Nnkd7/UMtzLS5i92b8eRHmOGbU3U1/zxdQLrnw5pCe9OydcGSdX36uh9scgz5EJKklBe6O YKi2qg9fgBa+7ZoiSys5KL5pqlSm+FGRj1LQVYJyFyP1hVZ0FNspLrbtIehrPw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637927328; a=rsa-sha256; cv=none; b=QhuG99HdoeQO3ppSVdMIU3CIFeGJffeN0MebbhIN3fHuA4oi+zc2pqOwtpKSewcLmwLs/G Wi1HSKEMPEeFRHutTGgBLpDhskvDN0rQwlCNfysgWbP863xiFqQ5q9FoCSEm51k3NE3Z/P 7i3Y1C+XrsbUX+wTqXSy9uyRxz3fpk06X7hGYCeGn+m6xd58NGOjnXFUjV2xhIaTOzAU1b y9mZTWsuFuGXa4KJsRNHarwcZXqLZYQ7tzOs0J0RPzNYdAw7GEuPNBIM7sqK15qKaspGBm 4t6b1J0sigmEkVIakJPqsVg3ovFtwtZjHYGOnBO3adpcH0hsxxlNx2C2NHz4Zg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255048 Henri Hennebert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Closed |Open Resolution|Unable to Reproduce |--- --- Comment #19 from Henri Hennebert --- 2 times after more then 80 `cd /usr/ports && git pull` the same freeze happ= en. So a SSD disk on USB3 reduce the chance of deadlock but the problem is still there. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Nov 26 18:35:48 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 AE2BD18A5D9E for ; Fri, 26 Nov 2021 18:36:00 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J13NJ41Qmz3pyP for ; Fri, 26 Nov 2021 18:36:00 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x935.google.com with SMTP id r15so20345209uao.3 for ; Fri, 26 Nov 2021 10:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ejkIMU1hlb14yV2/BKTJALIQOO+z15JYkhsznHprIbw=; b=ASuFILhN0pxftByD9EzHQOYWc3mX6UPci6kXnbHU7qe+Etx5rDo60SBTfzH3vo1GOf K4bfHnEde332D1pV7kf9NDxwMh0aQPavxiSmMie5mgdQWAbBpN2RsRGS9llxcokLhqR3 av5GMfud6LzqCZD02IBGH5meGbppKMvl89vKkLz9DPPSxaD2Vcd15oixanRjHuLZ76c4 R82UsrNPpbnxCUhyzwIQ5VBIwaQy7eoEGo+bk1qJKWqib/6SMTXc/Zd7m6bpBKwMpDj6 HLUQ2zHzhCCl6HYbYvNmfuY0SMNtLfwxhCWoKeKVkYL+CK4t+ZpN68/jt0/ch4otge/v higA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ejkIMU1hlb14yV2/BKTJALIQOO+z15JYkhsznHprIbw=; b=5G3QHpLrC7l/G9IniPRR6jhS0ajCVshuK5VOGY2NtHEgxtgG0OkFXdaZr2GYQWGZWV 36A8uwniPnl3Nh5A2qmJHgmDDR4d5hxg7Uw4akU3sgw+02/1M2IBqXRkz9dZe14rfWUL +T2NdurkU33DlhtEvwCpnSiKc5+fE8+pSf6okgiYBK7p+fvMTpsVeHPVkL4i0rneUjwa cHRwyPpWuio7l5KyAKhltsIGKLMNaj2H2CtSXUrkzOvsHh+UcQHGFS8ONFVrmi6AkTNZ /zz5GvqnByJl3Sumz61mDXzmgudPqPUaEFAqtifReovmzNaULgTmLI0okgg65Tyt5JET 79zw== X-Gm-Message-State: AOAM531xsjP8PRYVpNFfj44+mND78sHXeGUygL948dnalFkEYbPkV/yN JxZFfaoe1vIpCjsfsmXSaAoWMo1ZycW42xdSyBeUB0rZ1gRD X-Google-Smtp-Source: ABdhPJwDPMU8gVpNQ2hj3eHQsLCpyXMrX8II3tMFmVfrxDyRs6ExILnUkKNjGN64/8+/5TxC2+lGEWhnEVs6i2vOqt0= X-Received: by 2002:ab0:1e04:: with SMTP id m4mr35888780uak.100.1637951759943; Fri, 26 Nov 2021 10:35:59 -0800 (PST) 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 References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> In-Reply-To: From: Juan David Hurtado G Date: Fri, 26 Nov 2021 13:35:48 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: MJ Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cf9cc005d1b55ca7" X-Rspamd-Queue-Id: 4J13NJ41Qmz3pyP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000cf9cc005d1b55ca7 Content-Type: text/plain; charset="UTF-8" Thank you so much for your time you all. New microSD arrived today. It is a SanDisk Ultra, see this on the Raspberry pi 3B+: ``` root@generic:~ # dmesg | grep -i mmc mmc0: on sdhci_bcm0 mmcsd0: 32GB at mmc0 50.0MHz/4bit/65535-block ``` 50 MHz !! What a relief. Other OS like RaspiOS and NetBSD runs well on the other cards, not sure why. I still don't understand why sandisk is the only brand that works for FreeBSD apparently. I'm willing to give more information if needed or even to open a ticket in bugzilla if you find it useful. Have a great weekend !! PS: I've also bought the usb ttl cable if I can give any more information using the other card via serial console. -- Juan David Hurtado G --000000000000cf9cc005d1b55ca7-- From nobody Fri Nov 26 19:04:50 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 B55F318B49CD for ; Fri, 26 Nov 2021 19:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4J141r2dx7z4Ylg for ; Fri, 26 Nov 2021 19:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637953496; bh=h0BBM8FmwsP30CfLehYhtMj6aQAIt+Tz5e972nJg6tY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ro/nx90nUfl2wAvk38pGMQUSHxRv2qoqFqz2p98uDNT3SCGj7iUHRazI9/JrR2G//gC4EG4eisaSdGV5izRhoOCRbWiuVbNR3xoKasqRXC92laMnWt2GKjxw4HsMz8TQgoD99fCoy4SkjERjV4arb9SrrVz8QB03o6bnqX+WEIOZTeHWjgq3/ETZ7xGZd7C9itSAz9yK318I+DPRILJ+pIBs0Lmz/hqi8/S+NmQhFiP9jit+kIKwWyEHoYtQYIJZx2DB0ELNFnoKagjVj2YckkZ+PWUnP+kTnBWwRzGC7FWtD+fRAPsNqGikivi93vQnDWBkJloH+wTaz+HUkumAQw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637953496; bh=DZv/KIVroJdn9fTCCFvKCY7wwo2fqN3VOKmudMyHa41=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=i0C9VvVvBXgDKjf6Nx3r+loii1k0gTljobxspT142FRju0w+amPOLlXAQAbTQX13TOIZMByHslMlxKLWFXy0aumvU81Wzzcj0/OnSpFZlXy7IfkrabWiKifabgD4rbUCUQ02jo9T37Y2X9sK4fq+nUPjw/Hj6wH0mOfJcrgG9v6pHqNp7Jy+qXSsjLP482Gis/fY80PtdLenG8bNaqE08BwMUQRCoE/vK/gFfDpsESKgyFh20k7sBjWc43ofh46ZmOX8TfAuAGMcYSkK42Z7x8XlrRzESPplbIZWuVQaicspk2qdX5CH+USep1Vf9QAJqMMC9HI/8u0g/ujBQ0QuJg== X-YMail-OSG: QSIT90UVM1mksvzRk.Kev0Cpzqa3sKhn9UWt7owRgODIINn.MXQ3_mFOzFCBNvZ k8nt8EcGXOM6I8Ap8pCmISCGF4I9OG1f3wJp4Ch6VMTxjjVbcTAQYeJUlbAufwe2JEvS56yKIVKZ SbdkoJ0mucNgYDw5JBeVvplaiQVadmp_ay2Sz0YvRQcLf_uDRwnBxeLt6C1MJkhmqvLhlw5fERvL SAysLH8wt0Ulx3RyIWr6tZTiI_E1fPFQe2ZBPXKF7F1ZEM0Yjqq8eDsp9DvTi8W2WbicTHevbpFv HG7YG62PHSIJV7sPog_kGLHikwrOnlNR_nbaKxP20CTGUvIY4soHJkPcnXE3dKq_GXlaAtkA_sXd 2y8UapQ0JrRuZ4eAtwlfrQC9aFzwNC7OxoGVRMGelVNPFL31xF.ZB3ueqJNJ8dLQfBtzg.1FHfW_ C7a8E9vBN4Juj1YqTevUFzkiqRc47m9nTD2DJRn9PCiRatBInSXA4SuwDFNO09oZ7V7ZK1b2ob5G qLroGS2BXxl0tyTNksSa0DuCb.2oLDQK2BZBI3_FDdx4JFQtaTwIjSftOD5rBnYaMDi_PbQ66big 7MuFA9nH5xbPydYwUxe1bYeTXBRAIYZBOsgws1lkLyfCEI8ChuHMO8LnTCvBXLfEaiAg8fmH70cc UGoqta9U7cpzeZ5FpM58H_Q5pGo9HbPkIzj0o1ngg0uqaJU9.gWnbPPL3.fJY_yLGsGOa13FK3TC JyxnFbkevc_DjDtMbITz9qQNQRw8gz_7qCZA5471VSA1CfNgiXr.hNA7L0MO1d8gq0ZNKPMetIcf X3SdUIig_5D1D_XSfVp48FIBU5H2pR0sSlj2OL6KTzCnczYHiY2q2151LQPYU28emP8mCX5gVKeH DkvD.ov6F9tnj6JAZ.VLxEziZQWb2qlSNabaojDK4zumFs6uVkNs3tJqp6y9SfsbM9kvtGUqge84 zX5WUck8WZi1RVPoPj03JcH2dVBprGMdlf.BRR8Zl4caqJXxihPmSg_USlhLv5Qg6xUIokBFEOMN ie5Fbae2OLt1SVhd_C7GhAiqd.IQ561gsiM4wKkaoZCyVvet_uEJB1B1YLY6SJoIQvzEI210I6Gm mjSaKvWaE_4T.VDno_AdP7.9p0Fw8m3kgEUdesY3Jn_XyHJ2tDOAaX8vyDjUFchFGi7cudJ9DeV8 acpo9K_jkQYKWo6mYKqjbuRKc7VaTpN6R9Jy8l8Dze3RA0gO7hJep_mVeZEjFUauv10WhMpFtNb. rk__ujU9qzL9q0JbHi.Ou9s1OktQAZyu9dD7gq3kLwmXdn0OctXzaVy8G9h8ZBKSjkiBcVfwSG9x qFvZx4zBop.om9rN97j.DoLnnSoZJksHrc8c_V3X2dUR5duVFmHDpiy9vmPafhu3AW6HKVqrIiFo kbxSBYGj28A1EhlbIyLsCGIV5tknO16aB30Q0Dn92KAQL91HSn3SMGY6OPEO22Fg5o6ZLNBJxxrg .s.ubpzulAvsBQjyQtvFi73CGJ7YHzJTfoGIIhPY03iK.bw8CW8zhEbjgEMFVKoqQVHRtJe.dcJN 0.5tAduJE4SPyQIyTOmEAEpWv0PYBLoOAChokDg_.wlT2ab1GIiBeS2oprwahzAJf7A9VTrAQp2r C1GeENgKjdoXTg9vCdUFuEz3OVMRRFqaan0BB3Jw5xb_dKgmNpAEHjLi0TiVPAhDq8SGiHTPx.fS Oazuq.9aUpwQ0CXYDD9PfhjQmgmG_NfUwcb_ghQUrz_CpUw7gcKFLG8aqyLLJPmZUEwggDXBKclP DKVM.5CMNn4rG3Whyh.A_eJ2ioXFBmeBrLC2cU4fnfPAMAM330lNCKg_SExxPftAOe1vD2kG9_dN ztmttfGwhUqNExCLiihsbVeu6spo6UweaoHb.5svjLJC8vB2xnEUntds6SMm6lzQSARZydfr4Ous 1hrnRs4vZPnO8J7bH5XsrIvQwjTx_SuDrz82kfxTqK1GJUcTQEYXH5SFVW2FbsrKfoiiR55d7lBV Qwv9EBA_JqtrVpcJ058_L7_5YSs3KN7N7KZUQ.TGE2DXYyHkTHtGjNurrEPUGEOVcsYdqgr5v1CA jVVIKmj2y32cPuo6PKaGl9UG1MKW45RUHGfVTCJ08vxpS1Skwhf6r3dGyeGPH8zUgPQZUe11dhzS sNQR7D5MLCScsMYzMbKDKzOffyTrRpPxkGsVY4IGom06rI35M_bAGKw_uKst4oDMkEcCl6es_Eix idqkqznzV9iL6kGfCfzv8JkSIPMU9qN879lwGLuCdcuF7 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 26 Nov 2021 19:04:56 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b036f7fcf346ae5794b7131c5afdd473; Fri, 26 Nov 2021 19:04:53 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: Date: Fri, 26 Nov 2021 11:04:50 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <0D62833A-295A-4DC7-AC7D-7A86FA06F89B@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J141r2dx7z4Ylg 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-26, at 10:35, Juan David Hurtado G = wrote: > Thank you so much for your time you all. >=20 > New microSD arrived today. It is a SanDisk Ultra, see this on the = Raspberry > pi 3B+: >=20 > ``` > root@generic:~ # dmesg | grep -i mmc > mmc0: on sdhci_bcm0 > mmcsd0: 32GB at mmc0 > 50.0MHz/4bit/65535-block > ``` >=20 > 50 MHz !! What a relief. >=20 > Other OS like RaspiOS and NetBSD runs well on the other cards, not = sure > why. I still don't understand why sandisk is the only brand that works = for > FreeBSD apparently. I have non-sandisk microsd cards that work fine --and other sandisk models of microsd cards that also work. Mostly I use non-ultra sandisk ones as it turns out. But once I could boot via USB I no longer use microsd cards very often in the RPi*'s that can boot from USB without a microsd card involved. > I'm willing to give more information if needed or even to open a = ticket in > bugzilla if you find it useful. It does not seem that my direction of activity is relevant if it is media-type specific for the behavior. So I'll not be experimenting further with any RPi4B's (or otherwise). But if you make a bugzilla report, various things about your RPi* configurations that you have reported would be appropriate to include as context. > Have a great weekend !! >=20 > PS: I've also bought the usb ttl cable if I can give any more = information > using the other card via serial console. There are various settings for getting more debug output on the serial console for the RPi* stages of things. Some go in the config.txt but one goes in the eeprom content. As stands it does not seem that such would have helped for the specific problem: The problem is later, after the RPi* eeprom and firmware stages. You may never need such, but at least you are forwarned about the possibility if you think it might help something in the future. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 26 20:40:42 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 3E1CB18BFCAE for ; Fri, 26 Nov 2021 20:40:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4J168S5rzWz3mGX for ; Fri, 26 Nov 2021 20:40:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637959250; bh=zkkRQtuyn5B8sKlBH40smaJ4BNECfg2ZURpHvtdsD8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=n5rLLdae/4nWt3qUkGLNGUn4mOxt/pU/ZF5fCrNsg4dEUXJyYMKJpIsvB9jSviJZnkNFEBfcdkvBjrgSXOpZzqGGq7PReol7QU5NEWMdLal1GfTc3flispXUJvbAHo1lxpe2jsNFzOgeFJ5W0AmT7aW4QCckJpnS9dloMsafYYMX9aeYX0TDOh6ArO9y6OGC+lFfH0PhtnW+2xgbJR4hZ3ItYq+Y4TN0LKM7T1/hppud1cxZWkcAFs0qS++3ZxhqVjSJzv3+5Sd4NMgJYUK4TKhRi+AI7Usck/DxJGH67l3+qbljsA5Ijx8XpMx1DtVgZNEBgyMglQgPGX/ZC005vg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637959250; bh=/aNbV3Z/RECuf5g0FBmPDIdQBCMh8aTAWb8bbY9+vtX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tZtEJyytMbwcOUOWEiprvWXlYELEeKtPMJKbYSyrJjv7UrblgnZeAyiq1KTjHketcZcLMgLDep1S9yGpyRiWD9R7iRHWinjWiT8SqyjLzeoQNXnI4O+av7O4pzBi2qTP9MWZqgQWUsjizzjvvzDtT6iONYe10fzD3q+uavHBYXB9ZZGExeqNO4zo8XQuVTnGDOuB005Jr4U9CeOPPFJDPODuoaW955hUyZ5E83ar8fPxe/5VUjuitp7NMKEx4SlSYj/dxFgQtmFk8ocWYagKzT3v8R3z+SvfUoUXZjKs7UIR68Nh2DcmgTFbUyJ7wmmfVjUOr7fNMLJc15ARZ9exww== X-YMail-OSG: Aob4wCUVM1kRn8kg8BVVkuGgN0miOHQPYIs0s_S5qZ92iRc842WJV.EukI2ZyPV _jt4nZXRvmrKhWjWXSvgWD2QmGEGcaUC5s8b5HrlVwMdNByCp0PKuzsQqJ23RDa17K9kwU_5CCk_ yxQiIT1HTM.21GzavzrPj2jUeeZK332w9h3imERhK0lyncgKKUaXGyu_0IqCQxaSY2cjm88WYr4r wCfJEY9jgspFla8VKDc.ZlksxBiMc7nWnAXibL_SQf06_pr9xY5wEB4ixV3kY4fTDY1N9hVLlkb8 49tZ1Icdj9D7kh8X5O2rZwqGjnnetG.5FLkzxletwwwLCevobyMI5_5s.RsOje9MgVu7fBr0tYII nFRXNkGtc3tXfIVlRhcKJ.TXzbxfE1974jzGbrZZmw2uzkLXL_ws1mv17RpaPmfJs_p56p_p9YbB nMFygwb2gkpnNkhpK4WLO8kRm83Lq7ai.U._xS3jmcrugnBgycmAbmNpITlTMciGbsYtJklvWu_k yUowJXKx9iKllOV9AlnULpGM6Vceg5e9bf2.Ih_l8oHLDf2rP24TrzK6ZHlvexO7iIOgp7T11WDQ AWhAAxVUrilXDFUH5HyM3dB3ikx9i1fOlmtYNIKcM9xDlyMcqzdR_wVHLWd1H4kpsx7jk69.5Y4c j9mFubf_oyyTq8zKMlKet7n98aQ8_wiJDr.X9Q3UVfufzgIMMusLdsf_.RZodykq43svx17YqH2U Gy2j9BBwdTrUp6VkEu46_.ieBHLq_xrJ5qMThK5pMsYaIM9gWTcVVEW9p7vdhuYO_CmbNGjAAHNl LyXWeOaMGgcLtLS9P8domT9s0HKeyQP5L7rqtUq.fVLzIhmMSp0jgWTs3l166gZOevxMNMlJErJL 8T4scaheYWYfkwneb8OX8izmyZWVZNMOR6L4hJvr4kDzk71dfDBzU7PVgBd.Gya8doeS27esiVsr GM10vsz3YeNh7cymfUpwZ0J1Qjr6NcPix48gtSDCy1FsbU3lZrSpSzDTQZfaARazi1Bv30xXquq2 GNCvxP1cZatHx59PgqLQpMgD9whopXPZmlyH3Xo0A.DPKK7zhi90i63YHH85Zz.NJ1rQ4kd.ecZ4 knS8bZhwBbAXllsAbrlglx0CYOlNtbGB6frZHb1tdvPzhz9WPIXGPuiKTvLashbZ2xY4MW5DxkUp AMVa0FPtIyFQMfS95KnJ4alyqlUEsOe_scvXLESFfojOlbmxiLHK784aB1znOkytuRDFRczyrXmG E4j5lAlBygPqAhkp08kHiSCvC7Mfky4QgFoMrlEqoDpgkSfIXTRkk0BVewaas2ClAdfMTPNyoRD6 IPjJO3aZ3mwwB.YyUzNocrPNWl.c61HZ28I7sbh_QYZ7q8wxaEcXYqh7OcQen0oN4Pj2KQcEyik3 CT2cjUTKTmpcxNw0mGLoau0nFwokRlS_1eyJGlts3HfTzus5lm7hJdLsaS5vDcYrRD85.cBR_iP5 OiCB2qnNDgG6ra1El57MzLSkkB7t5RjjUdQ5GdIAW8nBfN6daGKV3CEF5mIkWOt266fo26ro9jpW FUEgOK2aK_8H8wGBZhVkQYDrnSlW4N6RZiRh8JXe6WkK.9jjvLYSurAPDMy4nl0yvFt.QRPoVMko ryGOMJWvP9OI2S8TpaquLGTFG4knpAticjo9V2HC_tEHaJDi9YSOp57Je5oHOd3XtP5uiq9kFRrW FyFCtRAIInUqVi7HElo36JWdIejhLvQ55LR_zILI5hj51zcTzhoXsNU1xOBYaP7aWL6YWxNuenRC lnn2khCEkl5nDSfXXaeiFG7M.egr32YhfHl4OFGAPh2G.IqmVDFN7ves_W_Txj578sKeqWR9lLv1 zlsA23YgCDnksz1OyCZ3ePMsZkxms6t1BLvJzVo5arjE9PVy8fSMdpeu5XCsX2zMZeWtqLT8Jr2b 2f6B_A_Hrp7rwthhpGCk_ajToPf0uxFaFR33IoeGlYV1lH3aKqEvolhxchXlX9l.03zm3vnNGLAH q0PGM3FJsQXs6doRhMUVPOhzX1tpRafwS_HKsU6KHK_gORJgGWts8HEWQyX1MB33iU702kGVkzrR 5.yTPwNKQjeYoCP0tanEOlInErDrfRIGoYLJIEEnEzommM_1K0uLTdsBcTCfZaih29zBnW.h0ia5 pbLeVN2GDtnZlc43dQQCKlDD_nUCqW39mYtDl4h3Cowcj6kZ4tseLtEV2ivh5MioLbgC2LGuPVs6 WYYAwG7i6kIbNyFWetZ2WK51k7CpCuXctiy1420PJWLvySwx4h9lNL25hSLPaCBeOHfQk0jFWlxM sxXRGFFADbdzavmZEd.k99Xt6 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 26 Nov 2021 20:40:50 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5ce3e9a56f7f21a25b14349df7a6a477; Fri, 26 Nov 2021 20:40:44 +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: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ In-Reply-To: <0D62833A-295A-4DC7-AC7D-7A86FA06F89B@yahoo.com> Date: Fri, 26 Nov 2021 12:40:42 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <4D1EFC3E-2665-47B6-9A2F-09E7F22907D0@yahoo.com> References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> <0D62833A-295A-4DC7-AC7D-7A86FA06F89B@yahoo.com> To: Juan David Hurtado G X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J168S5rzWz3mGX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=n5rLLdae; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; 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_SPAM_SHORT(0.99)[0.993]; 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.69.83:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-26, at 11:04, Mark Millard wrote: > On 2021-Nov-26, at 10:35, Juan David Hurtado G = wrote: >=20 >> Thank you so much for your time you all. >>=20 >> New microSD arrived today. It is a SanDisk Ultra, see this on the = Raspberry >> pi 3B+: >>=20 >> ``` >> root@generic:~ # dmesg | grep -i mmc >> mmc0: on sdhci_bcm0 >> mmcsd0: 32GB at mmc0 >> 50.0MHz/4bit/65535-block >> ``` >>=20 >> 50 MHz !! What a relief. >>=20 >> Other OS like RaspiOS and NetBSD runs well on the other cards, not = sure >> why. I still don't understand why sandisk is the only brand that = works for >> FreeBSD apparently. >=20 > I have non-sandisk microsd cards that work fine --and other sandisk > models of microsd cards that also work. Mostly I use non-ultra sandisk > ones as it turns out. Some of these are not intended as high performance for the type of context and some may not perform as well as others, even if intended is high performance. I'm just listing ones that have historically seemed to work okay in my use: Transcend High Endurance microSDHC Kingston microSDHC I Industrial Samsung EVO+ microSDHC I Samsung EVO PLUS microSDXC I SanDisk Extreme microSDHC I (A1) SanDisk Extreme microSDXC I (A2) SanDisk Extreme PLUS microSDXC I (A1) SanDisk Ultra microSDHC I SanDisk Ultra microSDXC I SanDisk Ultra microSDXC I (A1) So far all of these have worked. None of them are recent purchases. I've never observed a small MHz figure for any of them, as far as I remember anyway. I'm not claiming RPi* use of the fastest modes some of the miscrosd cards are capable of. > But once I could boot via USB I no longer use microsd cards very > often in the RPi*'s that can boot from USB without a microsd card > involved. >=20 >> I'm willing to give more information if needed or even to open a = ticket in >> bugzilla if you find it useful. >=20 > It does not seem that my direction of activity is > relevant if it is media-type specific for the behavior. > So I'll not be experimenting further with any RPi4B's > (or otherwise). >=20 > But if you make a bugzilla report, various things about > your RPi* configurations that you have reported would be > appropriate to include as context. >=20 >> Have a great weekend !! >>=20 >> PS: I've also bought the usb ttl cable if I can give any more = information >> using the other card via serial console. >=20 > There are various settings for getting more debug > output on the serial console for the RPi* stages > of things. Some go in the config.txt but one goes > in the eeprom content. As stands it does not seem > that such would have helped for the specific problem: > The problem is later, after the RPi* eeprom and > firmware stages. >=20 > You may never need such, but at least you are forwarned > about the possibility if you think it might help > something in the future. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 26 22:43: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 3329518B41E9 for ; Fri, 26 Nov 2021 22:43:55 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J18tM0ddRz3BvM for ; Fri, 26 Nov 2021 22:43:55 +0000 (UTC) (envelope-from jdhurtado@orbiware.com) Received: by mail-ua1-x92f.google.com with SMTP id a14so21450558uak.0 for ; Fri, 26 Nov 2021 14:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orbiware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4mZvndu192rnjHYF10/4OFC37oFyGKBwB0wUn+4i7HU=; b=I/tqFQ/bW7RXq0zu2rGwFTDDcY7n1QcK7eXqmJYQuoBjLwNfhd6ufEjhLdO7MvbG8D /ecvQfTzSD3Ynm9jatLm+ZbsmygTQbI+gV2Zd/eR30CRraXpiM2DuaTtDnGfz0a7wKn6 pw6hapajjq7O8ySH2zrK5GXrAoigfIm6LdAB/3CTPQksVXM5UsZOnd+vB9ymI00BIvg3 oEkmoFlGliiVR/AO5vLDz4zQkni+v/A8RUqOkJ42Ed6teQXzoAd9L7+Ed5sDgQEDHD1a 8P2V0Ae/tFs8m75I+1AJreDbWyTPt1MWGwnCax0KovJTPAZzensnwqPR6ANP2MEgYct4 hSmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4mZvndu192rnjHYF10/4OFC37oFyGKBwB0wUn+4i7HU=; b=UhTblig1Hty9UB+/COxhcPBnkt6Ww0CWd4mDk9g/DWPBqyCv1Z9EIPCzowBjs8fFRt TV+JoPsDO55DVuSp/cypsOMUIagKBCGBIZyzK2i/5QtR9uHNuoB+jYPRJMbIrQu82tie IE1bNweMAhLRmFQEE6jacZUvHFhls9t0j77PtzpCi16RcycsZSfR53RsY/F1miaQXcGq P2pb2k4QcehTPOYK6sfyQhr35ztXtpFOozG0cpuchbY5zSafrZ7LnjrxLuS25veZMFnU iMR0d4s22MX1EOKHZY+NXnwkHUr5sHoFfYO07EJNGdKZPiugDfiBkNsDUnwM4igmicve GGKQ== X-Gm-Message-State: AOAM530kwMg50/Tlse0/yXQETahLPk+tdUVHCR3kXxeO7DWt8lpFH7uI OofltxAA4m/f18/9nydj4xcpkcobPP4G97uc7vvsWxs5Ew== X-Google-Smtp-Source: ABdhPJzOsi7IrqeN20QyyIkQN8x2PNtoRjU/nsmY8gFANAzJ4s7zjCbLDautrjvVVQ0VURi2K5Vk/bqlQD/XmWfSx5E= X-Received: by 2002:a05:6102:3713:: with SMTP id s19mr20674665vst.75.1637966634667; Fri, 26 Nov 2021 14:43:54 -0800 (PST) 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 References: <20211124155352.GA26072@www.zefox.net> <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> <69E3CEF1-87D0-405B-B132-7D6A6A4EA056@yahoo.com> <1229E940-5DAB-4D49-AB14-E804296D10BC@yahoo.com> <0D62833A-295A-4DC7-AC7D-7A86FA06F89B@yahoo.com> <4D1EFC3E-2665-47B6-9A2F-09E7F22907D0@yahoo.com> In-Reply-To: <4D1EFC3E-2665-47B6-9A2F-09E7F22907D0@yahoo.com> From: Juan David Hurtado G Date: Fri, 26 Nov 2021 17:43:43 -0500 Message-ID: Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ To: Mark Millard Cc: Free BSD Content-Type: multipart/alternative; boundary="00000000000069e2c605d1b8d34b" X-Rspamd-Queue-Id: 4J18tM0ddRz3BvM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000069e2c605d1b8d34b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Mark for the list ! A friend has evo and kingston, where are going to try them. El vie, 26 nov 2021 a las 15:40, Mark Millard () escribi=C3=B3: > On 2021-Nov-26, at 11:04, Mark Millard wrote: > > > On 2021-Nov-26, at 10:35, Juan David Hurtado G > wrote: > > > >> Thank you so much for your time you all. > >> > >> New microSD arrived today. It is a SanDisk Ultra, see this on the > Raspberry > >> pi 3B+: > >> > >> ``` > >> root@generic:~ # dmesg | grep -i mmc > >> mmc0: on sdhci_bcm0 > >> mmcsd0: 32GB at mmc0 > >> 50.0MHz/4bit/65535-block > >> ``` > >> > >> 50 MHz !! What a relief. > >> > >> Other OS like RaspiOS and NetBSD runs well on the other cards, not sur= e > >> why. I still don't understand why sandisk is the only brand that works > for > >> FreeBSD apparently. > > > > I have non-sandisk microsd cards that work fine --and other sandisk > > models of microsd cards that also work. Mostly I use non-ultra sandisk > > ones as it turns out. > > Some of these are not intended as high performance for > the type of context and some may not perform as well > as others, even if intended is high performance. I'm > just listing ones that have historically seemed to > work okay in my use: > > Transcend High Endurance microSDHC > Kingston microSDHC I Industrial > Samsung EVO+ microSDHC I > Samsung EVO PLUS microSDXC I > SanDisk Extreme microSDHC I (A1) > SanDisk Extreme microSDXC I (A2) > SanDisk Extreme PLUS microSDXC I (A1) > SanDisk Ultra microSDHC I > SanDisk Ultra microSDXC I > SanDisk Ultra microSDXC I (A1) > > So far all of these have worked. None of them are > recent purchases. I've never observed a small > MHz figure for any of them, as far as I remember > anyway. > > I'm not claiming RPi* use of the fastest modes some > of the miscrosd cards are capable of. > > > But once I could boot via USB I no longer use microsd cards very > > often in the RPi*'s that can boot from USB without a microsd card > > involved. > > > >> I'm willing to give more information if needed or even to open a ticke= t > in > >> bugzilla if you find it useful. > > > > It does not seem that my direction of activity is > > relevant if it is media-type specific for the behavior. > > So I'll not be experimenting further with any RPi4B's > > (or otherwise). > > > > But if you make a bugzilla report, various things about > > your RPi* configurations that you have reported would be > > appropriate to include as context. > > > >> Have a great weekend !! > >> > >> PS: I've also bought the usb ttl cable if I can give any more > information > >> using the other card via serial console. > > > > There are various settings for getting more debug > > output on the serial console for the RPi* stages > > of things. Some go in the config.txt but one goes > > in the eeprom content. As stands it does not seem > > that such would have helped for the specific problem: > > The problem is later, after the RPi* eeprom and > > firmware stages. > > > > You may never need such, but at least you are forwarned > > about the possibility if you think it might help > > something in the future. > > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > --=20 Juan David Hurtado G (+57) 319 252 3773 www.orbiware.com --00000000000069e2c605d1b8d34b-- From nobody Sat Nov 27 17:49:39 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 6925618BC59A for ; Sat, 27 Nov 2021 17:49:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4J1fJf1PqCz3tS2 for ; Sat, 27 Nov 2021 17:49:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638035387; bh=slkC98I3+ObhNWquRarEZsDTwzu+g34hBUvOC8BKTLw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=MU2vNVXSrMzknA3jugAyf5wxC3ZwLk5XENfa3dBW2JG3CfjklbkgGNL7gEkmYFJWDu7YSs24nuRQLJUTEbYurJX0IB0j23Gnk2/ymx58Y5Osvlrr6lHK13HHXADRtnKT2Ky+KHyOvtQCNlls5J5i47PEB/b2VS7lOnQFqEKAiAYup/2vP/1viAnAX/LViv40ioVY+lEk3RIRgsevQlWhviaNS8dGd2ZSDO1Ydm76JHItkrdB76avzNriEhDEmeCN55fDvI5JiPxewfuz7O/tisZ5vU9tro+3TmSszLoRh9opMbCI9XsPJC2Er77YuYKk/HHMniIVxzQxpdnHsX6L5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638035387; bh=2odp3STlsw2xFa2UIclnSHqeoD2rAGU5DxH5UPTBjDd=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VhoJvzcQFYZdwXaWHKbx8T4FIwAt3hmcV6cVyA0kzi4ClRt2BnIzbsc3+ZeCN8BDjh1bri+MDbi3xxYIeoPo5cBOnji7V4fPdbVuU2O//5yLpiamiyFA4tmAwI0gnfeTogc1IosLWrqc/YzCZV9vBnvOLMwl3nLoI0JEvleklljOpYSyYZigJ6NNYYui8GRKl4lXeNeYbBbkmcqy4cTqeLrw2ZT5+24lpbFlqXwjk2b1DLsk9Uzk3CbZq5YkYCmcMY2tXNyR8dGJKr1Up2rHtcR7bmKpwmTjBNTKOPCl12yAJbZ0oK3iVtLIxnDbxkzhHizaOZBmJFUzLbWX7GBxJQ== X-YMail-OSG: YytQojQVM1m.8lk2sx27UwQmqmwvyjNaAujC0fMQx6ISQYxUwfLyVj6FYoOhXkT V.f3V0ixGMxbCD7N3RwuS2UZTmSNK6gzvw0aWGnJdHbCMa_mUILSuHh4BzhpHTCP44erxZPLnpzy gaVZoWxaF_nKS2QoCaAbysiiyED2pMGcAXCPAenpgnz5D_ZnqXFYoIHr9R02AY9TNu5SaRSfpE4a UlVDSzrFTu3dFKZillIgXRwCyz3n08cUlE4FT1Sa08MLrl.Cl_Afg2mt8BCQqiQGxDrHTHZ5oZSE 7L7dJfgPjpudZSzVs7T1lBVyucoa6EVObQBDn5DXbABQBgN.xRHjQRZpmD7u2stSP9W4KSBz6RTR 4AcA79gKpTDgwHNZDasTuWnr5JgyeXaITTkNAM4WJH_YWMjoM2IMQzCvborsmnJUPUouX9i4aA3G uPK4dssxGi6TdkfVtZs4vHWwf8SygqMf7XYhf4DMQO0a3YAnvFw13zOZDUkJS8nhgTHn2II288AN 83tWN9hfLzrmdDDRNggX6nlTcT_xzhuie3xg0Ssd0jtOxVDjXF9HX_ZJcIsQA7_jyER9NNQ.mQLc XfaSjLdHkbRp7oiDZRMY34varzrTy2XnQG5UrBVZhbvPoWiLyl1zcXaTDDAblUV0_Vpr1QWcgVQB cU9tmRKQHjaP5isdrFLTxhEyIuEMWRShvVDQvTxbBB1WRmH7Nzh4hE1rYDz0ixzY_zMNEzBTIGU6 udszLHcppesGtP77wNk3zTSMixzptto8GV745ETu1rYhORjVwOWR0OleYf4rPRUCH5_uLLI5aNRp CrEDry9S5dHCxT8pgtTGn2_VnkUGM5aFV01m8Fhguvoao20OyLIC_ZRNtuSnR6WpYEtQEeQuHLsB uV2TOnkH2YHjflBH0fA7laHhMZR1ygg8N6qCq_00cA6BduEENhOvvs_VKzNBHhZRbspnBqE6YvSB aRTB5BqcjXBh9Qf5kNtp7HAtxYinbdrQt050CQst34QI5sJDSIQ_BHfyQ7iYb.Cvmx0I7YADARVM u04g2JDYBc3MY2cQ077w8SUmTWsIZ.Uw2CAlF_Utzs1DZiWx3MEhtD3WlhsFJa9wfW0axgi3Kgf6 1HF9h661nkY0a0eIn9LPFW9TarS2LpjYcJEP2lAVbgm8g4POKBG5aXent.NtoBvyrYFqFtxH_FcV B_YE2SRnlBqjxzzuK3zxtB6PYJqSen0AbFtC7gqnXSuJq8FjlPSYHlR4m_lkTXnqv4VEl_7.YewH qF.MmzyP0Jg0P2.EYNO6qJB7HeqkTYRZS124qOpd3.6sbRoqc5ieI2QXNjF9AkAK8tsr6iGaI7xO 98ASIIZdydLeTXvzM9KAy.lj..IuRw2hXLoDnaFIfMDn4vfJs0jjFBEMirHpb2CQZMkHRZR0wK6D Redkt8qlZ_bhxJgrf9SqhLJNqtvZcuEnkLyqAjlIhfyA4qlGeoDT7HFj40sMWKD0WznXBFI7UenN R7S9JrpHGjh2bnoQhSqIPcFrEYZBP7FW9i06TcOPIj3CzdQu80._BWdInSQGIIhGrDMlswC9tfQi o4yKUKAk48wNq6jrJ5Wt1hQ9Q2vz4bx34jHISCu1hYOdtx35fV2DCL35wdlwPn_mMPHxN5MK26cJ wmcQ41xXqnvgCFe41ygYoD4Y5E.wSwWUrgiuvQq1IumX1DXPG5hrOrcuSDggoURQC4g88GmJ2ck5 3bGTnw0JlJcvICQLnldpU9XyiNo_KMJkm4NCfI3CTvqXH4U4Vimx7e56IGtwMEQu1jKImCw3rd5e 8sT..OG5hpOJKtYGgZrVftka_5dHyCZ_.Xrq7wpmRJVV.WgrINYpvRTD3ojoRFF4kFTT000drJ.. a2ybWdoeP4rM6ExKpgDBdIynaPEeedvHLFN6hyKh00LElxuQarWBS55KutruvSvTjsIpf_f_P4nf CUB_.Uy32VSV921hO0UhBVk9YL8S4vTCvwrkmM6lTs1ld08cRGUEYDvRdrE0UP4Rkbi_6_TTTKxw xtjyma0v7ZkITkL6JVHP69HCmqCA27v9kEypygkMzjGL9Pa54NLfW8uU0iN.Juiqhz5qsghtsltu mPVy0yb1A5amYIwWu2uQg64Hke8HpwkejRQ6NRbPXBi9YkUeIOWdEB2cTOnTUHM6utxGBsnCy9VY 6MglHjpcBpZTPLKvNxaFnyc.LEX9K1qLODM0XPmFffXbXvZAAHs9fuiPvTuo_QaJA6lNGZU1hkuJ OjFNne2MAdNoWGC_i34j.y1exwlXNFNt.nCtQHa0IMeV52CACy6JU9cEhHOtb.CriWKv.g_y_xx7 AJv6eJbgpXHdKeTAhywLY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Nov 2021 17:49:47 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6b516206b97909cd83620819b9d76e7e; Sat, 27 Nov 2021 17:49:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: main [so: 14]: contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 failure in armv7 context Message-Id: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3@yahoo.com> Date: Sat, 27 Nov 2021 09:49:39 -0800 To: Free BSD , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3.ref@yahoo.com> X-Rspamd-Queue-Id: 4J1fJf1PqCz3tS2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MU2vNVXS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; 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.000]; NEURAL_SPAM_SHORT(0.99)[0.990]; 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.64.83:from]; 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/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N In tracking down a armv7 build failure for some ports the fail during rustc, I managed to get a gdb backtrace for an example .core finally. This is based on not striping (no debug information). (rustc's build in armv7 contexts attempt links that fail for lack of a sufficient process address space.) The thing is that the .core file is generated during rustc itself attempting to do a backtrace for its internal failure. The gdb backtrace shows the top-of-call-stack (larger address) stack frames as being in FreeBSD code. The freeBSD builds involved are a non-debug builds but with debug information present. Note that the thread involved is not the main thread but one created via _pthread_create instead. Also note that the SIGSEGV happened at: /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 which looks like: 915 uint32_t value =3D *sp++; I could get the other source lines for the FreeBSD call frames if needed. gdb reports: Core was generated by `/usr/local/bin/rustc --crate-name tempfile = --edition=3D2018 /wrkdirs/usr/ports/dev'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 _Unwind_VRS_Pop (context=3D0xbfff5b80, regclass=3D_UVRSC_CORE, = discriminator=3D18432, representation=3D_UVRSD_UINT32) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 915 uint32_t value =3D *sp++; [Current thread is 1 (LWP 710038)] (gdb) bt #0 _Unwind_VRS_Pop (context=3D0xbfff5b80, regclass=3D_UVRSC_CORE, = discriminator=3D18432, representation=3D_UVRSD_UINT32) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 #1 _Unwind_VRS_Interpret (context=3D0xbfff5b80, data=3D, = offset=3D4, len=3D4) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:281 #2 0x400c83e0 in libunwind::UnwindCursor::stepWithEHABI (this=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:921 #3 libunwind::UnwindCursor::step (this=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2094 #4 0x400c7134 in (anonymous namespace)::unwindOneFrame = (state=3D, ucbp=3D0xbfff59d8, context=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:190 #5 0x400c7708 in _Unwind_Backtrace (callback=3D0x47346bc0 = , = ref=3D0xbfff5d58) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindLevel1-gcc-ext.c:15= 6 #6 0x47311b58 in std::backtrace::Backtrace::create () from = /usr/local/lib/libstd-21f5f79d0bba7291.so #7 0x47311ac8 in std::backtrace::Backtrace::force_capture () from = /usr/local/lib/libstd-21f5f79d0bba7291.so #8 0x46c61f28 in rustc_errors::Handler::delay_good_path_bug () from = /usr/local/lib/librustc_driver-a196dfc434d07325.so #9 0x46a33998 in = rustc_middle::ty::print::pretty::trimmed_def_paths::h696a2e73b4fe3316 () = from /usr/local/lib/librustc_driver-a196dfc434d07325.so . . . #42 0x401371ac in thread_start (curthread=3D0x40073a00) at = /usr/main-src/lib/libthr/thread/thr_create.c:292 #43 0x40136cdc in _pthread_create (thread=3D0xffffb0b8, attr=3D, start_routine=3D, arg=3D) at = /usr/main-src/lib/libthr/thread/thr_create.c:187 #44 0x40139a4c in _thr_umutex_unlock2 (mtx=3D0x0, id=3D11, defer=3D0x0) = at /usr/main-src/lib/libthr/thread/thr_umtx.h:160 #45 _thr_umutex_unlock (mtx=3D0x0, id=3D11) at = /usr/main-src/lib/libthr/thread/thr_umtx.h:183Backtrace stopped: Cannot = access memory at address 0x4 For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 # poudriere jail -jmain-CA7 -i Jail name: main-CA7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud Jail fs: =20 Jail updated: 2021-06-27 17:58:33 Jail pkgbase: disabled # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm armv7 1400042 1400042 The backtracking also fails for releng/13.0 (-p5) poudriere jail targeting armv7 but some details are different that make it more complicated to deal with. I've only gone after gathering and reporting evidence from the simpler context that gets the somewhat earlier failure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 27 18:04:47 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 8765518ACD23 for ; Sat, 27 Nov 2021 18:04:57 +0000 (UTC) (envelope-from 4250.82.1d4d500052d10e5.ea86cd5956e1a4f53296459f0f17d3dc@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (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 4J1ff13Dtjz4VkT for ; Sat, 27 Nov 2021 18:04:57 +0000 (UTC) (envelope-from 4250.82.1d4d500052d10e5.ea86cd5956e1a4f53296459f0f17d3dc@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1638036297; x=1640628297; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:cc:to:from:date:x-thread-info; bh=yCQIfPFd11FvAJujQm/6ou/1tuEDiXW0pKtGg5BZ4h0=; b=blM2h0C8IYb55ujtMzJ+S2NBrDW1Xf7qd9VqJI/NN7E9z1uuLEeWF1iP5Xl6d14W47vZjVeOuaIECfRpwstm2UiidlZpJPzwjKkFHz9i/4nDhQn5FVDqbND5Vw474ISMoQYc46lpkG9js5mH/RG3HHG5g1lVL51VzchrZt/jBXw= X-Thread-Info: NDI1MC4xMi4xZDRkNTAwMDUyZDEwZTUuZnJlZWJzZC1hcm09ZnJlZWJzZC5vcmc= Received: from r2.us-east-2.aws.in.socketlabs.com (r2.us-east-2.aws.in.socketlabs.com [142.0.189.2]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sat, 27 Nov 2021 13:04:49 -0500 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r2.us-east-2.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Sat, 27 Nov 2021 13:04:49 -0500 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mr247-000OYd-LQ; Sat, 27 Nov 2021 18:04:47 +0000 Date: Sat, 27 Nov 2021 18:04:47 +0000 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Cc: marklmi@yahoo.com Subject: Re: main [so: 14]: contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 failure in armv7 context Message-Id: <20211127180447.0bc2df8f726707f764679096@sohara.org> In-Reply-To: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3@yahoo.com> References: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3.ref@yahoo.com> <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) X-Clacks-Overhead: "GNU Terry Pratchett" 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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J1ff13Dtjz4VkT 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 Sat, 27 Nov 2021 09:49:39 -0800 Mark Millard via freebsd-arm wrote: > Also note that the SIGSEGV happened at: > > /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 > > which looks like: > > 915 uint32_t value = *sp++; Stack overflow ? -- Steve O'Hara-Smith From nobody Sun Nov 28 21:00:58 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 F32C518A9FEB for ; Sun, 28 Nov 2021 21:00:59 +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 4J2LVg0ZJGz4p6Q for ; Sun, 28 Nov 2021 21:00:58 +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 C469D1630D for ; Sun, 28 Nov 2021 21:00:58 +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 1ASL0wOZ055757 for ; Sun, 28 Nov 2021 21:00:58 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1ASL0wQa055756 for freebsd-arm@FreeBSD.org; Sun, 28 Nov 2021 21:00:58 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202111282100.1ASL0wQa055756@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, 28 Nov 2021 21:00:58 +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="16381332583.8FDb6c2.53622" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638133259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=C1K/BMjUIewf2lbMID39YCwnmkFk0xNKif1dK0AhxTo=; b=D93gxWvHo0x2McYnnz/TeR5xeIjjuhsvzq6oxV3PPtJvCa4AZl8a9zicosYBb4zQugk92v wr92Qj6vwfyrE6BopjXrtEA0lmO79j5hbVl3FuO/w/UIiDGrgYHQczs3Gbm0e4a27EEXaF /9QQZOpp2J0Vk2ZMy0DVnO9/mFD2f9gfM991aAwoCaaa2HMvAQX2XMkbOcDcZga5krJEFj 8selwUC5SjhmIaDq2AdMdFRG4Gd3GzbzdJrfl+XD6sJtIUEqirXRKPIBSqDQPFQg/WCzAJ Nhz/tk8gA37GFLR6+RySDMtC0UhN7mpmpQbZfatrOVqni+t8KPCyqtt5QDMmnw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638133259; a=rsa-sha256; cv=none; b=u6w4J1XgJV10JnyMHvYPQ1kp3iQFxnvpBLT1f3tw6cNBsLgcceiUWtcK6U6gcHkz+Za7lz LrZgTLqL175+NUeZCJcM9dhQ5b63vVc7CRE/KqCTbfEwG7PIkhbiNgcGZ/bsIcQpcS1mRP IVSMBQkDd6BWuShHhvIe9K4OgKDsCITjQxJJmKO/1pM0JMPVOjzOYPVtVno1SpFQ8lBlSR FkfRVzSsX2r8kE/5VcrEKAu7TPz7EHkpLXZrREOGXCHTYpU3RKD9Ao/BA7DCJZ9WdkLSkt 8569pjhBEpnIxWCv8rirNmRkq3zzqSgxKjdYH74DDlO+sYFG6RubLYxzaH8N/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --16381332583.8FDb6c2.53622 Date: Sun, 28 Nov 2021 21:00:58 +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. --16381332583.8FDb6c2.53622-- From nobody Mon Nov 29 23:56:07 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 5EFE818B7AD0 for ; Mon, 29 Nov 2021 23:56:07 +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 4J32LH0Flvz4gWG for ; Mon, 29 Nov 2021 23:56:07 +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 DDC4C3C6D for ; Mon, 29 Nov 2021 23:56:06 +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 1ATNu6tB060285 for ; Mon, 29 Nov 2021 23:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1ATNu6Zp060283 for freebsd-arm@FreeBSD.org; Mon, 29 Nov 2021 23:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 260127] Kernel Panic enumerating PI7C9X2G304SV PCIe Switch on Ten64 board (NXP QorIQ LS1088A) Date: Mon, 29 Nov 2021 23:56:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: matt@traverse.com.au X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638230167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aAPQsRmdGHZlPtbKjx2FyPyvWIWYEkb9i78+2y8HE50=; b=irpQ1CdgNTkZmDJcdAa8IA2z+EKuatzx8E0WvUZkO+I3xE35EuuOaTT11W5GBSlIylY5nO uwEpdr37qQWZvZF14v5iqk5KgKI2v4sOPt3L0wkPf4/nur1KlzWpLqP+6GWjG7Bj1/Xb8U euarzU/KHY43zbMxxvqmcFWLIy1IBgq4pNK1+u2uvhvOKlZZOwGshlSFQPYPzRAITMhFp7 hz4/BlS3vkoDCJrrvPzoUUMH00fqDQtCg/qmHpAgwelKyxQNMlNzmqMTgvuLha8mcCIyyz 9NV041uIdJtvX2EU7FDyl02LuTmtuRy2yQn/Uzn3N1cloEwApTd/HQc36uiS4Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638230167; a=rsa-sha256; cv=none; b=AMekkMDJnbEvQNKvtuVHMajhWy46c1f++L8omUPa8kF0dximhUib4uCeOiKNe5ZlYgzK5N RdZESDxMcrfLDk3kQwl9gQse5E363UTmuP7bATyoFlPY42PG3o0/QDvLUdxYknWeCG97tn ZK1nCcHY4AnFh4Ch6Uj4FGteP12wSRxTOhnuA4FfOPFgELJ1G9hhENovkH7/sVpdNpJwxL DHqp1HB+qd6Y5rJr9jvpP+FHFkXyx4l8C+t7XWPpZN0DWPrXDmOXsuUhb3zJGwkBoxQ63B IJNZTQtJfMrmsEr+NL5TvbCUV4TXpWRG1iN5DaUteRs85PJvqdjPmcCiTevbAg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260127 Bug ID: 260127 Summary: Kernel Panic enumerating PI7C9X2G304SV PCIe Switch on Ten64 board (NXP QorIQ LS1088A) Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: matt@traverse.com.au Created attachment 229803 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D229803&action= =3Dedit dmesg kernel panic with PI7C9X2G304SV enabled Thanks to the recent addition of various NXP/Freescale QorIQ drivers, particularly qoriq_dw_pci, as well as the upcoming DPAA2 driver by dsl@mcusim.org, FreeBSD is very close to being usable on the Traverse Technologies Ten64 board. Unfortunately there appears to be an issue enumerating the Diodes (Pericom) PI7C9X2G304SV PCIe switch. This is used on this board to create two PCIe sl= ots from one PCIe 2.0 lane (specifically, the MiniPCIe slots, see https://ten64doc.traverse.com.au/hardware/architecture/) The panic occurs even when there are no downstream devices connected to the PI7C9X2G304SV. When the PCIe controller that the PI7C9X2G304SV is connected to is disabled= in the FDT, FreeBSD is able to boot and use the PCIe controller without issue, including using an NVMe SSD as the boot device. Here is the PCIe topology from Linux: # lspci -nn 0000:00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc Device [1957:80= c0] (rev 10) 0001:00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc Device [1957:80= c0] (rev 10) 0001:01:00.0 PCI bridge [0604]: Pericom Semiconductor Device [12d8:b304] (r= ev 01) 0001:02:01.0 PCI bridge [0604]: Pericom Semiconductor Device [12d8:b304] (r= ev 01) 0001:02:02.0 PCI bridge [0604]: Pericom Semiconductor Device [12d8:b304] (r= ev 01) 0002:00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc Device [1957:80= c0] (rev 10) 0002:01:00.0 Non-Volatile memory controller [0108]: Silicon Motion, Inc. SM2263EN/SM2263XT SSD Controller [126f:2263] (rev 03) # lspci -t -+-[0002:00]---00.0-[01-ff]----00.0 +-[0001:00]---00.0-[01-ff]----00.0-[02-04]--+-01.0-[03]-- | \-02.0-[04]-- \-[0000:00]---00.0-[01-ff]-- Note: The PCIe controller instance that the switch is connected to is at 0x3500000. The NVMe SSD is connected to pcie@3600000 (bus 0002:00:00.0 in Linux), pcie@3400000 is connected to the M.2 Key B ("cellular" slot) which = is empty in this example. By manipulating the FDT in U-Boot pcie@3500000 can be disabled allowing Fre= eBSD to boot: setenv setup_distroboot_efi 'sf read 0x80001000 0x580000 0x40000 && fsl_mc lazyapply dpl 0x80001000; sf read $fdt_addr_r 0x600000 0x40000 && fdt addr $fdt_addr_r && fdt resize 10000 && fdt boardsetup && fdt set "/soc/spi@20c0= 000" "status" "disabled" && fdt set "/soc/pcie@3500000" "status" "disabled"' saveenv reboot --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Nov 30 02:45:19 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 41FC918C0E18 for ; Tue, 30 Nov 2021 02:45:33 +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 4J365l3dYWz4jWv for ; Tue, 30 Nov 2021 02:45:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638240324; bh=NZ5feNB1tJSgMFkgAnoWjuGx4UfFxZqkSA3fB1ozkQ0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=phsu+rNkHpBPN9aJsuUKeC5sYjQsMty+fmosjMgHWx4kjF6m2aHudtqvTU/Tpfe7/mvUqzW/warBqNYp4V/rXghSj4y8rR9BKRzo3ledNsmSWTysmiBAvkEt0rvGj6e66MLwrLAbx0cIG7Byiz1dXmIY6R8i3avtPjufe/RzHmSocK6LUNcUx9tDuUFX+9uQiDGEt3Tw8cCWXwUnCRE/JfYqw+FTAk1uTBmQ7EDmW7yjmCh+Ay0Noo9eqUeg+mWcfu9/PNMXYTnrsIK7aHarCRVhvQaZ9TtqHTkq9YBPXVRcxJfqciOOSBWNUvwg73TdMW85sqLXeAHrgwJbNbaX3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638240324; bh=B374dWFOEVk/xuzuzv4FL4QHitjZzV6cLRcHzvPUFGz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=thsVUhI9Cg+vCMFp0xkKDLHyaE7XeZHgwu0c+9/Frum5uRGzVf7BxFZteVDglIYmSnpKGOQlfE6y7MHh3TpuMmzr7dNYJD7iF/6Whe+CFK1vUA04lWiAbaPdc1HOo9XRfVluR65eEJEDSS8ogdjNGE/7Ih99/HKDaVv1wpW1VPMi7lVJIH3vibkKKs8SFkqYPpwvb6mny+xzgaunC8pNWfEWChBFpXxOKkEcF3IBMmBM8x/uRQ25W3FVUVm2bv4DYHPoZLeBVkN2czrpj3d8t9BkEk/g2o+zXRwqGPqPGRsftNfRPGB21QrbMdZ6spZXsICn2zAfy+EPNYr2HVygnQ== X-YMail-OSG: HMp.IKgVM1nXwhE8cYFAAjArceKW8Jadup_c1kmHZ9ExgwWgaHjjTlwODMn7O9m Wmzi.iNe7aGBbJnbCLAzPS5pkBRgphSfMs.Y0m0cvzh5AVlh2FMW4TdJRz0zAe9fGozyGbHBxfzp jr3LxG8keo9RsN.8ZNWiR94DJh9o.fl0wQAPSou.noVJG8MITz.kssk4DutlWEOJCHpeg6oTP9Zy FwQqpMLQONKQib_wKa_s.a34RtExApmbt0NnHmmuhB4pnsbLg1Pp9Z1ViA8Ko1eUDwBuEBUD.dEe E5UkoVmG8Q1vw55gkLdws9o5ccRFGokEAWhBkswhpXWb76Yw8DTo7Ju4JwpvIib0EFxGmHINhqXY 1A7CD1kEjoaPxfmJ5La6VQ20dPITOhnj2Yd0Ulp4BlDKevovSxg_LeRsD4u..wMl6xH3vgu0J8pc HOOfnTaiM4r2i5kzCImGDk9TDzHt4UIsiZ4mFsewFhYAE1LaN9XfygB9wUJ7Xi6MYwZJO5hY3IUC tdbshrnBdHRyVpYjd.sKGFLbb9DS6yZbSyZ.qPXBAXHbm8VNf_0LfCv_qWk7WTLHlb05nH0xa7h7 DCZYyVkQKbxV.WO0lnM7n_Bp5IFFlL22waNPxcZmfKT9esE376JnwdFPpT.ytzcWvxAXVtZ7ysjs 9xLx4buODl7bMPn9xH7ksOXgUXJUadxG.H0OZag0pdBZIziEkxm1rFurOxISLOCkDt.NPXol8IaP SlSeDFy0z_Uiv2DeIbJC1_qG.KLJLkLUpwEomCXxA9F_JG2FAsvFXizt9m_YgVCAlskbw9m2gxvq KUzZ8pdkp4T5qqYNACw_SKoq1AaoEvJT4sbfNKActljAZPrOURrxONoZzMhM65jblsFD2G7x_kNY kXLgAtsI7IFq_WHOOiGe.5j2O5.md6I8aMyYbIN3i4M0y65uVt2nR9QnVjBaem5vbnt7iDzl9FQd xXNiJyr9Rwb8QHVRMgQqaeASYI8v7Mrq29aVjLb5JJlwT4YGA7P8INuqBZ2mXYwVhjYCLu2UNKLH lEWkhFq17tQPMKXlSFznskuxjkgtRwGI1deICfWgNdiULfoRWVtkcndiZDaFnpEHPlQN0Wq2y8hU VLTXGdoL5hNBMoZd42F9B8vAtUWcjULxo2m6AjH1nxfEsVAIGJ1V96lLlP3NfTW06siYhyPQD8sg oZvjC.lv9uCBsiyy4rNzUfWIx68cbXQQJgPHPvZ0aEEAzgEKs9XxoiGCqo56ttyly_t.3ovd9hY3 yoa37GhhkhwgvAfGmZS98hJNLrjDUG9P7vyahf8TOUaZllGOpZornj9YoYSK19Q68bCkssg1b8JY bpQs3jAQY..2CVqXakZGXfBO69KwKS2ZTpne75IPk7MJeWTmFh1QYW2dhylRv3B_k1.R30vWwEum .TcJoYaRSx2PblcjdfukRLgka02udd0cCLT3FzEYoPvEs13qW6Che3HQ817rizWGjVIozEXHmUHe Bf.hDRTJTzIBHlC1hlASDwVmsyMwiB2ENFNiVR..mAZSWeBrIfowc7X9FvHUaOH17MJs_qe5szx9 2nDfkcp_O7Lx69uH6ZnxB9kdNHKOFeE92yBwW6zQfBFKepQbK0TypI2IzqkKGiSEls8FEhCCiItE osw8kf0cgGRw7yg0wdbeFSk_XjLoOx_vX2zTM0.Vibj5cSPwRtTXQtnsqSeHh..h0wdFQboCgLtU orHkUxmYAN8MJVIw3cHCRGfaaLPlnU_G8WlXtt7e4PQOD86KyQ6esqG8CBBmhWrYE3AMxOiYKy5E Wib.v1q8DWOaBAvD1PSA61zRpJqvrLDDPPJSqBMZmgPJlfGacdT3zcWOtmKfQRtmF9HdiZG.Fi5N BbJhszplvWctvxN5jPZhO5BPrpUuVg4HgJZua4W8E5OMwQkDqqkufpZHWmGvV2xkpIiMIzdpRSH8 hC54cfChkDwcpt02Or7iFhC6tos9TMYH6sLq6bY0pz2lLpSsA6gFQkA72Od.yB.TC4KbBeHSDWaW N6u8ntaGP9Gnkpnt8kGF4bamVe.dW3xla4OWnaz7iDAZNMkwyQ0SdLJ_11qoCw_xkGp_dc1flJsI fAEl6O3lboZZ4dY1JAB8g3fAYJs2MpFkXbpnyHPGT.8OWeIulDMz1cpah4kxNwFYR5Y_VXmh0EHH B_SWEJaSle91YHAWMPVdkOPxYxIgs7sCBrmHFYT6tkkT9JeqsaPipUnbW2WLAFgy07Hu5yX9j81z 2j_IzwVX3p.7KNgXNR.l92J5y6cjzz3mm_y1Fzch.RhfYessklR6rYXtb3wcH.bDXPOHt85vi1oT 7X9jGk0NOCL8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 02:45:24 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID baca60a59644174f7603f3f4ad56ac34; Tue, 30 Nov 2021 02:45:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Message-Id: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> Date: Mon, 29 Nov 2021 18:45:19 -0800 To: Free BSD , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> X-Rspamd-Queue-Id: 4J365l3dYWz4jWv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=phsu+rNk; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.18 / 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(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.68)[-0.682]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N For: uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 building a variant of itself (producing a debug build instead of a non-debug), it generated a bunch of messages of the form: ctfconvert: failed to get mapping for tid ????? in the buildkernel part of the build. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 04:51:19 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 517F018C09A5 for ; Tue, 30 Nov 2021 04:51:19 +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 4J38tt6qNQz4SW4 for ; Tue, 30 Nov 2021 04:51:18 +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 CB1017BC1 for ; Tue, 30 Nov 2021 04:51:18 +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 1AU4pId0027336 for ; Tue, 30 Nov 2021 04:51:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AU4pIPJ027335 for freebsd-arm@FreeBSD.org; Tue, 30 Nov 2021 04:51:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 260131] RPI [ CM4 /io-ref.-board] panics on pcie with nvme connected Date: Tue, 30 Nov 2021 04:51:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: maciphone2@googlemail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638247879; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=EFTBPvrnNUUHqYzjNqQQ6k/Rnmzkk15kbdOGqLjOSKg=; b=Lcw6n58I3VG00zzJ2gJnXlvnCBI1iBpcsNsY0nZwz6zky/E+8uFHyfJXxEGycHWW4qzfsL ZaEPDPSuypNefjaDNdonKGvdaIsodr0ABzEMEOgxOnn2ImHebRP8F7ozt79vrq85EAcFBV 4R6lNBf0M/r9tRuKNWvfed4CBEXSVE0VHIL35XNxDLX8fXatw9ScDKiBHU0l15TcaLO2zb feev7wYhqzaBVyehovJ1l9lk8zLpkiaUQjMIzqScV39bhCLBX85iZdYQM2jv1I/+RvknlZ gWlqNtx/dEzPSl9HC4BNOZLmuJQGuEnphpWDyTL6+gRDFFMMWraB9IUrGMXA9Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638247879; a=rsa-sha256; cv=none; b=mGWeNcvDM4MjIpbBu+BuXbhGSZkMji9XLkIL8y4zkdGlg1vcK2L/YGO5XAk+LEc250AhI6 tl4U12WsAgYLoQDeixBlUO8jdvu3HqFZHf5ZzCOgGh08/noz8QAdmLYyMVdE1Yhg2Et1aL aHenKeFgpaL7RxVsuxCp80wKsIqbWeoJ4pLge6KOtDryeylpbPLve3HlFbjxkvd9p8+vMw kgA/7M01sRpuge+EP5STFIdfTCdyuuN+I3/ooXfn8ZxrRLwndTDeVqW5aBZ4kj2xgXVmHC /JNPoEYPvFleHSjJtKOrzo6n36MQYO8YnRZkKJ+qgwF7RrSZiG7dP3dCCCb3hg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260131 Bug ID: 260131 Summary: RPI [ CM4 /io-ref.-board] panics on pcie with nvme connected Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: maciphone2@googlemail.com well, while the story of "how to boot off of nvme on the RPI CM4 I/O-board"= =20 is quite too long at this place, I booted successfully from nvme and that heavily depends from rpi-foundation`s closed source proprietary software (a= nd from fine-tuned configs) ( this dependence will never end although some devs like dreaming of it ;-).=20 the good news is that only the pcie-driver`s magic numbers have to be adjus= ted to fix this bugzilla. the 'best' debug information I could get for the first is : -------------------------- pcib0: mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2 pcib0: parsing FDT for ECAM0: pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000 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: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0 pcib0: Bus is not cache-coherent pcib0: hardware identifies as revision 0x304. pcib0: note: reported link speed is 5.0 GT/s. pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D0 powerspec 3 supports D0 D3 current D0 secbus=3D0, subbus=3D0 pcib1: irq 91 at device 0.0 on pci0 pcib1: Lazy allocation of 1 bus at 1 pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, count= =3D0x100000 pcib0: Failed to translate resource 0-fffff type 3 for pcib1 pcib1: failed to allocate initial prefetch window: 0-0xfffff pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xc0000000-0xc00fffff pci1: on pcib1 pcib1: allocated bus range (1-1) for rid 0 of pci1 pci1: domain=3D0, physical bus=3D1 x0: ffffa00000f23368 x1: 8 x2: ffff000000846817 (cam_status_table + d8cf) x3: 14a x4: ffffa001ffd95e00 x5: 13c x6: ffff0000007ece68 (bcm_pcib_read_config + 0) x7: 0 x8: ffff000000dd01f8 (thread0_st + 158) x9: ffff000000aded70 (lock_class_mtx_sleep + 0) x10: 1 x11: ffff000000e819c0 (w_locklistdata + 43f78) x12: 1 x13: ffff000000e819f4 (w_locklistdata + 43fac) x14: 10000 x15: 1 x16: 8 x17: ffff00000103923c (initstack + 323c) x18: ffff000000f11a80 (pcpu0 + 0) x19: ffffa00000f23380 x20: 0 x21: ffff000000e819c0 (w_locklistdata + 43f78) x22: ffffa00000f23000 x23: 0 x24: 0 x25: 1 x26: dead x27: ffffa00000e6d350 x28: ffff000040466cd8 (ucom_cons_softc + 3f156718) x29: ffff000001039380 (initstack + 3380) sp: ffff000000b37160 lr: ffff00000044d3e0 (__mtx_unlock_flags + 58) elr: ffff0000004dfb48 (witness_unlock + f8) spsr: 600000c5 far: 0 esr: bf000002 panic: Unhandled System Error cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 do_serror() at do_serror+0x40 handle_serror() at handle_serror+0x94 --- system error, esr 0xbf000002 witness_unlock() at witness_unlock+0xf8 __mtx_unlock_flags() at __mtx_unlock_flags+0x54 bcm_pcib_read_config() at bcm_pcib_read_config+0x160 pci_read_device() at pci_read_device+0x84 pci_add_children() at pci_add_children+0x44 pci_attach() at pci_attach+0xe0 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 bcm_pcib_attach() at bcm_pcib_attach+0x87c 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+0xfc bus_generic_new_pass() at bus_generic_new_pass+0xac bus_generic_new_pass() at bus_generic_new_pass+0xac bus_generic_new_pass() at bus_generic_new_pass+0xac bus_set_pass() at bus_set_pass+0x4c mi_startup() at mi_startup+0x12c virtdone() at virtdone+0x78 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x44: undefined f901811f db> bt Tracing pid 0 tid 100000 td 0xffff000000dd00a0 db_trace_self() at db_trace_self db_stack_trace() at db_stack_trace+0x11c db_command() at db_command+0x368 db_command_loop() at db_command_loop+0x54 db_trap() at db_trap+0xf8 kdb_trap() at kdb_trap+0x1cc handle_el1h_sync() at handle_el1h_sync+0x78 --- exception, esr 0xf2000000 kdb_enter() at kdb_enter+0x44 vpanic() at vpanic+0x1b0 panic() at panic+0x44 do_serror() at do_serror+0x40 handle_serror() at handle_serror+0x94 --- system error, esr 0xbf000002 witness_unlock() at witness_unlock+0xf8 __mtx_unlock_flags() at __mtx_unlock_flags+0x54 bcm_pcib_read_config() at bcm_pcib_read_config+0x160 pci_read_device() at pci_read_device+0x84 pci_add_children() at pci_add_children+0x44 pci_attach() at pci_attach+0xe0 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 bcm_pcib_attach() at bcm_pcib_attach+0x87c 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+0xfc bus_generic_new_pass() at bus_generic_new_pass+0xac bus_generic_new_pass() at bus_generic_new_pass+0xac bus_generic_new_pass() at bus_generic_new_pass+0xac bus_set_pass() at bus_set_pass+0x4c mi_startup() at mi_startup+0x12c virtdone() at virtdone+0x78 ------------ this is with nvme module loaded . excluding Rob`s pcie-driver from /...files.arm64 fixes boot panic to get ab= le to boot from eMMC/uSD which can also be handled by adding devmatch_enable= =3D"NO" to /etc/rc.conf /afaik the VL805 should not be involved no more to pcie(except pcie-usb-car= ds) since the I/o-board has an own USB- controller.=20 since bcm2838_xhci.c contains code to not try to load VL805-firmware if not soldered to pcie: I didn't yet try to exclude bcm2838_xhci.c from kernel.= =20=20 tests were made on CM4108032/CM4IO Board which I received last week. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Nov 30 06:01: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 5299018BB678 for ; Tue, 30 Nov 2021 06:01:26 +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 4J3BRm0m12z4qqV for ; Tue, 30 Nov 2021 06:01:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638252083; bh=8kZa8mRNCrN4yJ/YS+95ZpBYLH/BlJVvV6IPUAGPSfo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Bpbx4H9pR9xF3luQu0kzsoieb+0ZNrIrengKsh3ROeHROX22Iy3Jj07xB1qX4Su3S69Rp3xaNdSVeCmBmOl7UgNQblqG6HDwLZy9xGsELYjmZMB+eH2dWgLAvzFuTK+fW0NS1T0A48eMAppArdoJ9+alZK4TfWdiiF03CdpKq0pJgDSTnRaP6+5vLv4kSvK+lazsq0aWvuSyT+blIah04rT9CaGeH9LpfR0hIw8+LjT86pWKzXgaKCBQhEKF6x7MdpmRe5oL5HDq/ZuyLaUFyhDv6y5oNCAcNvLjMOh4GZ+WWa+1AqZg0eoXCEfoxP9rExd/ZRpc/XN1dYyyWbCmGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638252083; bh=ag6vP7kJHxviytLmt2mYIUeG7NfQtqfQn+wOK3U5qkp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kFp/32byImJ7f/nABEu5GkhnM1A5Tv4nnGyINtjwh54k+XlFT+ZWk28id1leFBbux0z8e0KVWzzwx1q4/YA5dFCWt8oJkQ5bdE/nz5muyN5piQ+H8uHlVUIqxY6ghkp/Q539kfstiJwyk765ufdWHjI+tydMmlOdy0LvDm1btduCeioFU8bbI7MRoXLnu+MiBL8vg/h3RONIgz7n2i2BBcdHaDOWGt0XLQbRbLF8DF3IYa5Ui6HFrfs7eK6+pQZTgJe43ormssNTxwaoix1kJmFIJ7Q/PXwv0DlJq+Qtkfx4eTXAtSNgqframyMeNRvUzlHrX1+FHXaHjD8CTUw5FA== X-YMail-OSG: 9GXXCuQVM1lQ3mXPQpDfKuOw2g5k6n30PnscfYQBMJmyJNQtIDYYvVctHGrsHYj bqL7XmeaZ4GFzCiJc9bCUnjONh0uqtDvp3msZ2iRPBAf0YnrWvg7gippKibex3arOUMewQQ.r32d h39GI7ND6uc9OF9ci40EEDmdXKY1p1cxIJVR4gTHP9eX3xD8kPJc64tt3pth42aH0e5RK3EvLaaO uAWeVNs5xdqRucS_5ahaeSNvhg84u9CI_dNZ7JbKfdg3ucCrGyif5RZKz20Ko_C.VgcW0r8yqsgB y71_7k1BVxKpfMHXleKEtLUqzOlObwJ6xcBsgprCarZAoYd_VSTKwQLisjPRNa0nQ7Spkd34sIxT lVUTi5hKdFa.ERQCV6VsOHmMLzqgcdRLIfYG5lQnCgjvJnjt6YpPPTcPRDMBpOxDO8NIA229B4Zb KfSr.zXmYGmKvuheWL7ZOyFufXs1EZ0Cz_bbBbyebD0Jm.M9nu7dIy0KMLhCQcXnorNNOI2ezBHv zr4B7eUKuyoZVn.uhEU69mD38rBNaRLWzfB40Rb7dyOcVOb2q3ipsdJa2Qia.kAGIzDFBUy9w6wT 4G4NyUQCTLSWIYihpIWKRAz0lDfFBIvUpy7j8rKoZWZNiXsQEiusJ1JDXWfxjBpK8IQGLykQgaIE eDVa3nsBoma65fsbozAb41ZSSp_xmrgYiicDbrdOj2T_VmrOKtLlvM21x4eQ5RVQ2MBjQAlCl2T2 YV1F3MqxDOrjjUVLe349NvBISJW0Za7WxPZMZb9xhjmGlOxcmjlvvZuy9rV0iaEAS_eWN0SkuZv0 vNVkHU6ocCADs4QI5D7WlHJeXqJYPwzPWyIGy2buXFe2VubAgw9dvGHVoko6v8_MseGFj1Zu2Sv3 lvxAOYEi3IT6NzVGAUOqklyZaSNMuNGNUw.oi6QaFPtp68QfP2w046W.9jCaTgbYzacWDguSozDi iEvNTsIQnPM85Fp7DXCbah0Gu3YpyYv0NHioWll7Kql_QvHZaysbnayaEHgt.PhVGs.D1YGwVDuS zbZiIIYbp9wNVhi0ph6cGzY9zGWP5pR.mSzVW8wumqUtcuYaGJAFn5G0XrlnA.U0xqCbKJeTs.yt d1TGjE2efMiEnwsXVYZirmiBS.8_2htoS.4hX8JVzbJO99acQoXKffca7FXXLHNDllfXZGA3N2Dv 5Y6cJHs1AsujV9brFBrhvevP76AJw1Hhw0hIfmzlC1l.Wia5PGHPX6p9aPnwUjzmVdjFLfGzllgW 8bYm_OpJ0RNMSHs9k9iDlzbboEM21PZAd5sth.peJPQG.EDBYcj4YsPmRC8luBSXuwBo4pZMhV.x Yuo9vtmVmIwtJY9REC5SfHIg.8ZosccdBatd4dbfBcvxk0ot9Wg7bayU43vLzSY4g31nxRQqIC47 GObVbxmAe63thTmrNjdWydc6spD.7aIBxS2G3LWix6mN.g4_5xPGAUTJF1Ip.fznqKSn1xtVywKh qTAg.F.qJcUyMWaWZJdjPiIh.afmzZ.s6e3pxz92_0Y6.FK9_PBeIW6DYTcLAlQk4ETeY0i6m77Y 2G5ntTsPYGJ9blvJ3GgrQRGfM.LZ1ZIJ1BXHYx.AKftDX1brNliyDe0prNJHqeKQK9LXGXoB6qSd nI0QS7mKDg8cOUyAWrwmviOaWE53dtQ_t7fMa4kO5nSB5DbAOVzy3R549CRO7MljzIWZtewh6Q2p mx7HyBrXKpI4gU_yo.JZWLpvmche1rw_HLaqIKe.TFw2CJJcgS8h7gq3DwSCm0ZKBgfZIx9836SO XTLwHeA25canaW4ppjR.NVCQleCXgnqCAy.cxG7A3fflFwKdkgfq1_J6xq7I04ry8MTQ3NtkQpw0 f_W7QkR2D7Y2xNoLtSIa_LC0bZ.5kEqOMsPFZI8jh2WEceOcB0.tdgsf0DGOf7gJnoa8WYsb1aCk 66.6UuSaqA6m6QlsdENQjimwspRuzzlomL0U5z4SApBDSCHcQPxc8IAeZ70x1nhT9BHGOUwUbXGZ qi6k7hUFQ4wf_IHxM_NSaYQfdsH.xdPnMPXRbpFuJjTJ6GmVHSzcAJRfIfSDGurBE3Aegm7fLYLw zb3lbRLWiyEb51mOfRSOHlG4OibDg3P5.KT.bOdHdDLZ_KDyxGdVuwtAA7ZFTarOJAb4jfUV9ZQo SJblP5uPqycvOS1uXbBj5..dNEESqNIDIwqb0TsLk6HtrU6i_ZJJaI6Vc_qUjNH2mrGtICk2xi.G 4vcWHZ6DDNw9pn4_u4jM1391.VEkjRO5_Y8fciskim98xkyAhSLrHY40FmDCRNA3h5mJKK3CsIOE Dp4dFj_Vbw1hBtwmm_g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 06:01:23 +0000 Received: by kubenode548.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 35c130540ac9484e6dd0a86c2d74045f; Tue, 30 Nov 2021 06:01:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Date: Mon, 29 Nov 2021 22:01:09 -0800 References: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> To: Free BSD , freebsd-current , FreeBSD Toolchain In-Reply-To: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> Message-Id: <7B9D3178-029F-46F7-AD3B-9C668CB4CB73@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J3BRm0m12z4qqV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Bpbx4H9p; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.57 / 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]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(0.90)[0.904]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-29, at 18:45, Mark Millard wrote: > For: >=20 > uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > building a variant of itself (producing a debug build instead of a > non-debug), it generated a bunch of messages of the form: >=20 > ctfconvert: failed to get mapping for tid ????? >=20 > in the buildkernel part of the build. >=20 There were 98 unique tid values complained about. (The contains a hexadecimal representation.) : # grep "ctfconvert: failed to get mapping for tid" = /usr/obj/BUILDs/main-CA72-dbg-clang/sys-typescripts/typescript-make-main-C= A72-dbg-clang.aarch64-host.2021-11-29:11:34:15 | sort -n -k9 -u ERROR: ctfconvert: failed to get mapping for tid 174 ERROR: ctfconvert: failed to get mapping for tid 245 ERROR: ctfconvert: failed to get mapping for tid 259 <103> ERROR: ctfconvert: failed to get mapping for tid 267 <10b> ERROR: ctfconvert: failed to get mapping for tid 275 <113> ERROR: ctfconvert: failed to get mapping for tid 289 <121> ERROR: ctfconvert: failed to get mapping for tid 333 <14d> ERROR: ctfconvert: failed to get mapping for tid 425 <1a9> ERROR: ctfconvert: failed to get mapping for tid 435 <1b3> ERROR: ctfconvert: failed to get mapping for tid 482 <1e2> ERROR: ctfconvert: failed to get mapping for tid 1120 <460> ERROR: ctfconvert: failed to get mapping for tid 1155 <483> ERROR: ctfconvert: failed to get mapping for tid 1318 <526> ERROR: ctfconvert: failed to get mapping for tid 1671 <687> ERROR: ctfconvert: failed to get mapping for tid 1809 <711> ERROR: ctfconvert: failed to get mapping for tid 2416 <970> ERROR: ctfconvert: failed to get mapping for tid 2538 <9ea> ERROR: ctfconvert: failed to get mapping for tid 2715 ERROR: ctfconvert: failed to get mapping for tid 3107 ERROR: ctfconvert: failed to get mapping for tid 3650 ERROR: ctfconvert: failed to get mapping for tid 3868 ERROR: ctfconvert: failed to get mapping for tid 5151 <141f> ERROR: ctfconvert: failed to get mapping for tid 5342 <14de> ERROR: ctfconvert: failed to get mapping for tid 5499 <157b> ERROR: ctfconvert: failed to get mapping for tid 6075 <17bb> ERROR: ctfconvert: failed to get mapping for tid 6081 <17c1> ERROR: ctfconvert: failed to get mapping for tid 6171 <181b> ERROR: ctfconvert: failed to get mapping for tid 7775 <1e5f> ERROR: ctfconvert: failed to get mapping for tid 8674 <21e2> ERROR: ctfconvert: failed to get mapping for tid 9144 <23b8> ERROR: ctfconvert: failed to get mapping for tid 10608 <2970> ERROR: ctfconvert: failed to get mapping for tid 10638 <298e> ERROR: ctfconvert: failed to get mapping for tid 10794 <2a2a> ERROR: ctfconvert: failed to get mapping for tid 11190 <2bb6> ERROR: ctfconvert: failed to get mapping for tid 12040 <2f08> ERROR: ctfconvert: failed to get mapping for tid 12131 <2f63> ERROR: ctfconvert: failed to get mapping for tid 12232 <2fc8> ERROR: ctfconvert: failed to get mapping for tid 12266 <2fea> ERROR: ctfconvert: failed to get mapping for tid 12293 <3005> ERROR: ctfconvert: failed to get mapping for tid 12604 <313c> ERROR: ctfconvert: failed to get mapping for tid 13072 <3310> ERROR: ctfconvert: failed to get mapping for tid 13622 <3536> ERROR: ctfconvert: failed to get mapping for tid 14453 <3875> ERROR: ctfconvert: failed to get mapping for tid 14981 <3a85> ERROR: ctfconvert: failed to get mapping for tid 15104 <3b00> ERROR: ctfconvert: failed to get mapping for tid 15810 <3dc2> ERROR: ctfconvert: failed to get mapping for tid 16006 <3e86> ERROR: ctfconvert: failed to get mapping for tid 16222 <3f5e> ERROR: ctfconvert: failed to get mapping for tid 16627 <40f3> ERROR: ctfconvert: failed to get mapping for tid 16633 <40f9> ERROR: ctfconvert: failed to get mapping for tid 16849 <41d1> ERROR: ctfconvert: failed to get mapping for tid 16867 <41e3> ERROR: ctfconvert: failed to get mapping for tid 17327 <43af> ERROR: ctfconvert: failed to get mapping for tid 19216 <4b10> ERROR: ctfconvert: failed to get mapping for tid 21146 <529a> ERROR: ctfconvert: failed to get mapping for tid 21200 <52d0> ERROR: ctfconvert: failed to get mapping for tid 23011 <59e3> ERROR: ctfconvert: failed to get mapping for tid 23472 <5bb0> ERROR: ctfconvert: failed to get mapping for tid 25993 <6589> ERROR: ctfconvert: failed to get mapping for tid 26074 <65da> ERROR: ctfconvert: failed to get mapping for tid 26800 <68b0> ERROR: ctfconvert: failed to get mapping for tid 28333 <6ead> ERROR: ctfconvert: failed to get mapping for tid 30366 <769e> ERROR: ctfconvert: failed to get mapping for tid 30798 <784e> ERROR: ctfconvert: failed to get mapping for tid 32196 <7dc4> ERROR: ctfconvert: failed to get mapping for tid 32547 <7f23> ERROR: ctfconvert: failed to get mapping for tid 33724 <83bc> ERROR: ctfconvert: failed to get mapping for tid 34990 <88ae> ERROR: ctfconvert: failed to get mapping for tid 35109 <8925> ERROR: ctfconvert: failed to get mapping for tid 35984 <8c90> ERROR: ctfconvert: failed to get mapping for tid 36204 <8d6c> ERROR: ctfconvert: failed to get mapping for tid 36222 <8d7e> ERROR: ctfconvert: failed to get mapping for tid 36393 <8e29> ERROR: ctfconvert: failed to get mapping for tid 37769 <9389> ERROR: ctfconvert: failed to get mapping for tid 37788 <939c> ERROR: ctfconvert: failed to get mapping for tid 37961 <9449> ERROR: ctfconvert: failed to get mapping for tid 38207 <953f> ERROR: ctfconvert: failed to get mapping for tid 39642 <9ada> ERROR: ctfconvert: failed to get mapping for tid 39935 <9bff> ERROR: ctfconvert: failed to get mapping for tid 42787 ERROR: ctfconvert: failed to get mapping for tid 44571 ERROR: ctfconvert: failed to get mapping for tid 45582 ERROR: ctfconvert: failed to get mapping for tid 45687 ERROR: ctfconvert: failed to get mapping for tid 48695 ERROR: ctfconvert: failed to get mapping for tid 50964 ERROR: ctfconvert: failed to get mapping for tid 51801 ERROR: ctfconvert: failed to get mapping for tid 53177 ERROR: ctfconvert: failed to get mapping for tid 54249 ERROR: ctfconvert: failed to get mapping for tid 55356 ERROR: ctfconvert: failed to get mapping for tid 55795 ERROR: ctfconvert: failed to get mapping for tid 55825 ERROR: ctfconvert: failed to get mapping for tid 55913 ERROR: ctfconvert: failed to get mapping for tid 56821 ERROR: ctfconvert: failed to get mapping for tid 59783 ERROR: ctfconvert: failed to get mapping for tid 66038 <101f6> ERROR: ctfconvert: failed to get mapping for tid 66581 <10415> ERROR: ctfconvert: failed to get mapping for tid 68585 <10be9> ERROR: ctfconvert: failed to get mapping for tid 95223 <173f7> Is there an implication of a problem with the kernel built? If yes, what is the way to make the existing system build an appropriate kernel (as part of getting past the problem)? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 11:28:54 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 F186218A4D22 for ; Tue, 30 Nov 2021 11:28:54 +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 4J3Kjf4r92z4SMd for ; Tue, 30 Nov 2021 11:28:54 +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 828FE15653 for ; Tue, 30 Nov 2021 11:28:54 +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 1AUBSsFr048885 for ; Tue, 30 Nov 2021 11:28:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AUBSsOG048884 for freebsd-arm@FreeBSD.org; Tue, 30 Nov 2021 11:28:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 260127] pci: Panic enumerating PI7C9X2G304SV PCIe Switch on Ten64 board (NXP QorIQ LS1088A): generic_bs_r_2() at generic_bs_r_2+0x4 Date: Tue, 30 Nov 2021 11:28:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? maintainer-feedback? mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638271734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6uIAuaWrwcwGOWXFlyb4wIWRQrJg3UVUQZ8yS+BBtxk=; b=l9cs+BO1khPegEmnSSzXaw5rXBm3mWpNYy4yzuZRh+EhB3nExWLWNIhgeUqK/mU2qp3BS2 D17MTPk57C/hycOruglmW7pb6+A0L82eeb22pVGzZMNRYVfgcZQm1QXlOu0rT+/bu6gpgg WzSqcmpvbFkGG/CGSTtCmXFNKMGIUMRireWR6vzy5F1xn7RXJJUc41QI2mLmQpG7MZATcn 2VgEKoDOdkj9X6xD9QYzpj2A1RCrrbKS4WG3KC3fr6cmygn+9IXa8rN7KyTesw/b78THdQ Ak9jgc396Lz+QFnkMoeIwKFfh7HSNhjMnX6CCvf4nXNpPZ+UUsLutdt0Lg6bZQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638271734; a=rsa-sha256; cv=none; b=yscS0BvjKvAui86LIGG+vJ0s+zWjaH5jAxsaizH1AbUK+jKH1Le5hjb0FiQvcWghTAnh2Q +i2ZGPj7ZGxx71TdU9ydHc4F95ZMjRUOyjhafDGFqMfzCAoHEHDM0ZcXjsuJt/J2eSjVUi TEhRy8ir6Hm0LG9dJZBXVwSQVrO0lOBvH4BAvuztz5azPP8irPADPa0AAm8bH53xFvZBqu TFdgBiyjB2++GndrpqAX9lQhCy7zbOJnSCoaT1yKrde33Y4saKCeEUYKByb055gJGZMmzB MmbZAwYxpE3h95YmZsw/R6OaRwZjFmMiZmZXIzFcj5MgWNhL3duAhv0fC/QsXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260127 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #5 from Bjoern A. Zeeb --- Fixed already in HEAD. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Nov 30 12:22:18 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 5B75B18C2160 for ; Tue, 30 Nov 2021 12:22:28 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4J3LvQ0M9Bz4pDg for ; Tue, 30 Nov 2021 12:22:26 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 6E6F94E687 for ; Tue, 30 Nov 2021 12:22:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1638274939; bh=gA5I4QnvK1dWzF0mfZZsZ3MEv1zTC6l16+DdSoQqxFU=; h=From:Subject:Date:References:To:In-Reply-To; b=cYsApG+cqg012aruzwe6a/b2JXA96ZUtXHV7+JrjMBw5FuMMoTKZ6wM77cyf5ldur Iuhb02FmaFBMgzgv/mz8Yr2AQo0Mre4zfyvM7nrVwr/tnh0BRJKUr7SICyfpa7vcLU D5T1/X9r6Y2iCGygng59yjDkhorcX7aruPecFoQ3i6Ah/aShRgo7Oprg0C3XvolO2c 5aoX6GJfC08mMn2oQwB7Bk8P4YLQ9FU1vKtUvnByC8U8UOLnlfbGmkbBHA1OM3XrOR D7e6IeR3MVITU1j1o1FRVmHTZp1fcPot7e9qRMvcHNlATyZCSnMuw8YCUtXq+C8j0P RPUZeTCgQddmMOdCGNQli0ozS3eHs/eQl5bIrfYyAUxdoZn0pNlv/W5t2wQ3NW1JYh QWC7mx+dfCPQFW5kbd/QSCumBacp1zsXWq5/eDVK6PKbbDlW8Gy25o0IHfvsB2vq30 Oabkf4PCpkOA8gHtKTnZTd82oS/kcJP81oWSytQBv/UntUZhNTN+m8pypZZusRXzdi pElx4FYx0rDyq/VOuwHglVKBUw/3z7rKsQUVjQgwOH6kfCxF+DK4jni7lTBbrg+HCR IDKMjMKQzOyqsWlRI+urm7cOVvAZWl536jIBHpkAUwc1hi+mNEvZGx9hcm/dXMALmq hCTxwAHKGiCDYhK79AREjOLc= From: Andrew Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 12.4 \(3445.104.21\)) Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Date: Tue, 30 Nov 2021 12:22:18 +0000 References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> To: freebsd-arm@freebsd.org In-Reply-To: <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> Message-Id: X-Mailer: Apple Mail (2.3445.104.21) X-Rspamd-Queue-Id: 4J3LvQ0M9Bz4pDg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=cYsApG+c; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-2.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I bisected the detached messages back to 601ee53858f6 [1]. If I revert = this change I no longer see this on the console. I am also unable to reproduce the panic with this change reverted. As = the panic can be difficult to reproduce I am unsure if reverting this = change is enough to fix it, or if it=E2=80=99s just making it less = likely to be triggered. Andrew [1] https://cgit.freebsd.org/src/commit/?id=3D601ee53858f6 > On 23 Nov 2021, at 17:34, Andrew Turner wrote: >=20 > Can you create a bug for this in bugzilla so we can keep track of it? >=20 > Andrew >=20 >> On 21 Nov 2021, at 07:18, Daniel Morante via freebsd-arm = wrote: >>=20 >> Here's the bt: >>=20 >> ugen0.2: at usbus0 (disconnected) >> uhub5: at uhub0, port 1, addr 1 (disconnected) >> uhub5: detached >> ugen0.2: at usbus0 >> uhub5 numa-domain 0 on uhub0 >> uhub5: on usbus0 >> uhub5: 4 ports with 4 removable, self powered >> ugen0.2: at usbus0 (disconnected) >> uhub5: at uhub0, port 1, addr 1 (disconnected) >> uhub5: detached >> panic: data abort with spinlock held >> cpuid =3D 108 >> time =3D 1637478997 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> KDB: enter: panic >> [ thread pid 11 tid 100111 ] >> Stopped at kdb_enter+0x44: undefined f901411f >> db> bt >> Tracing pid 11 tid 100111 td 0xffffa00005619580 >> db_trace_self() at db_trace_self >> db> >>=20 >> On 11/12/2021 5:52 AM, Hans Petter Selasky wrote: >>> On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote: >>>> ugen0.2: at usbus0 (disconnected) >>>> uhub5: at uhub0, port 1, addr 1 (disconnected) >>>> uhub5: detached >>>> ugen0.2: at usbus0 >>>> uhub5 numa-domain 0 on uhub0 >>>> uhub5: on usbus0 >>>> uhub5: 4 ports with 4 removable, self powered >>>>=20 >>>> I suspect these problems are caused by the above = detaching/reattaching. >>>=20 >>> Can you type "bt" in the panic prompt? >>>=20 >>> --HPS >>>=20 >=20 >=20 From nobody Tue Nov 30 12:35:39 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 A1F6E18AB128 for ; Tue, 30 Nov 2021 12:35:53 +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 4J3MBx3dlXz3DTw for ; Tue, 30 Nov 2021 12:35:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (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 65B112606FD; Tue, 30 Nov 2021 13:35:46 +0100 (CET) Message-ID: <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> Date: Tue, 30 Nov 2021 13:35:39 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: Andrew Turner , freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3MBx3dlXz3DTw 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 11/30/21 13:22, Andrew Turner wrote: > I bisected the detached messages back to 601ee53858f6 [1]. If I revert this change I no longer see this on the console. > > I am also unable to reproduce the panic with this change reverted. As the panic can be difficult to reproduce I am unsure if reverting this change is enough to fix it, or if it’s just making it less likely to be triggered. > > Andrew > > [1] https://cgit.freebsd.org/src/commit/?id=601ee53858f6 Hi, Could you verify that you are not running out of kernel stack? May this be due to some code in the .text segment which is not properly aligned? If you compile and load USB as modules, does the panic go away? --HPS From nobody Tue Nov 30 14:16:37 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 3B82418C03B2 for ; Tue, 30 Nov 2021 14:17:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4J3PRn0XDtz4dSH for ; Tue, 30 Nov 2021 14:17:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 7DC934E659; Tue, 30 Nov 2021 14:16:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1638281798; bh=qLS4Lf6zMSn4oVkzPqV9F/vo9M5UDo8h+wdxBuRucIw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Qum2+o9i3uRgaEuTOAF23Yl/kuu/ucJBZRqng6TwdNiuNZjdnSEZ7L4qiged/X/iY uhMqnEGOfQUy9BENgGIkjcuyhogZEczS0/+8274t4LckmnRvRZoQjkSN4em6tqoCsL KLYADhJmC5DAzlS6YHSaWJmlLXyRDEPMBYCHpGBNgu+j16e6whE1d+2NQvaFoMhw2j lpAwN2Dz9xVDAIFyUQHQlyS1G85t/OWiJ47i9ZeWvChtiaEfQbY/vx9x9cBUtUeI+T LrWVRJyvE6LESrRJ+XDsYaAqsdCFf28Ds392nqKfjDMTd/Qj06RtYq1h+eeXQ5iZnI eA3X7T7Kv/1Nqo/P8CAHzvuVHIXI0+FuZD6dAKzH+8nzEWzTPMhLvgwn62kvMoFbbb 9sy2LgKLxi1+L8FbCxvLvsUEMO5xlSecJ9zwNzKFTu8Scg0990hZQMArfhPmvaFJR1 +am/DJktn2XKRlRc/xgpNVv3L6HZydE9rzSB6sfLUaiufQUJ55D4pu4cDZo0CrzeQy wKCDdsID7vofhbGmVneC95KYvY8kb/G6WO1HG4P2/6cpswJbepz1UhB6yaQO4EoUQN X+SscIlYmujPbQidds8i85Ic089ZrITeNV6XVIacwx+uFSlQY65nNvUeKvIGt76Ogu Ep2X5nOJioQGMsiL9qleXotc= Content-Type: text/plain; charset=utf-8 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 12.4 \(3445.104.21\)) Subject: Re: 14-CURRENT Kernel Panic due to USB hub? From: Andrew Turner In-Reply-To: <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> Date: Tue, 30 Nov 2021 14:16:37 +0000 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.104.21) X-Rspamd-Queue-Id: 4J3PRn0XDtz4dSH 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 30 Nov 2021, at 12:35, Hans Petter Selasky wrote: >=20 > On 11/30/21 13:22, Andrew Turner wrote: >> I bisected the detached messages back to 601ee53858f6 [1]. If I = revert this change I no longer see this on the console. >> I am also unable to reproduce the panic with this change reverted. As = the panic can be difficult to reproduce I am unsure if reverting this = change is enough to fix it, or if it=E2=80=99s just making it less = likely to be triggered. >> Andrew >> [1] https://cgit.freebsd.org/src/commit/?id=3D601ee53858f6 >=20 > Hi, >=20 > Could you verify that you are not running out of kernel stack? I can still trigger it after doubling the kernel stack size. >=20 > May this be due to some code in the .text segment which is not = properly aligned? I would expect to have seen the issue on other HW. The issue looks more = like it=E2=80=99s memory corruption. >=20 > If you compile and load USB as modules, does the panic go away? I am unable to trigger it after removing xhci from the kernel, and did = get a panic after loading the xhci module. The xhci controller is one that originated in Broadcom. Linux has a = quirk for it to work around an erratum where attaching a USB 1 device = followed by a USB 2 device the linker the latter will come up as USB 1. = They reset the phy when anything less than USB 3 on a disconnect event.=20= Andrew= From nobody Tue Nov 30 14:34:41 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 5160F18CA9D8 for ; Tue, 30 Nov 2021 14:34:48 +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 4J3Pr81Lmhz4mnY for ; Tue, 30 Nov 2021 14:34:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (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 85413260201; Tue, 30 Nov 2021 15:34:45 +0100 (CET) Message-ID: <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> Date: Tue, 30 Nov 2021 15:34:41 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: Andrew Turner Cc: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3Pr81Lmhz4mnY 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 11/30/21 15:16, Andrew Turner wrote: > > >> On 30 Nov 2021, at 12:35, Hans Petter Selasky wrote: >> >> On 11/30/21 13:22, Andrew Turner wrote: >>> I bisected the detached messages back to 601ee53858f6 [1]. If I revert this change I no longer see this on the console. >>> I am also unable to reproduce the panic with this change reverted. As the panic can be difficult to reproduce I am unsure if reverting this change is enough to fix it, or if it’s just making it less likely to be triggered. >>> Andrew >>> [1] https://cgit.freebsd.org/src/commit/?id=601ee53858f6 >> >> Hi, >> >> Could you verify that you are not running out of kernel stack? > > I can still trigger it after doubling the kernel stack size. > >> >> May this be due to some code in the .text segment which is not properly aligned? > > I would expect to have seen the issue on other HW. The issue looks more like it’s memory corruption. > >> >> If you compile and load USB as modules, does the panic go away? > > I am unable to trigger it after removing xhci from the kernel, and did get a panic after loading the xhci module. > > The xhci controller is one that originated in Broadcom. Linux has a quirk for it to work around an erratum where attaching a USB 1 device followed by a USB 2 device the linker the latter will come up as USB 1. They reset the phy when anything less than USB 3 on a disconnect event. And there is no BIOS / UEFI code still running on that XHCI controller? --HPS From nobody Tue Nov 30 15:27: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 6D2E918BCE91 for ; Tue, 30 Nov 2021 15:27:30 +0000 (UTC) (envelope-from hokan.hokan@gmail.com) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3R0x3nSDz3NYc for ; Tue, 30 Nov 2021 15:27:29 +0000 (UTC) (envelope-from hokan.hokan@gmail.com) Received: by mail-io1-xd2e.google.com with SMTP id y16so26520944ioc.8 for ; Tue, 30 Nov 2021 07:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mime-version:content-disposition :phone:content-language:user-agent; bh=d7g9F8yi1VGaXD7Ab56n89e7ILsnD+zoNXlIykxEGL8=; b=BQTPSWBw+fltClSjo8zWzBWBKWkWvBMd3uq58eGLBZiI8/j1xPcX9unWxJmIW0alfO lEnll6ytXv0h9VnBKpX+PYtF5s3cdM42VguK9bUU5XnWfQzBDEqXU6seRPca5KmsWWfh oNCw0uHoK6koBK76KqGiCs4efniv0gtdWTSzqtH/BYvxH+WXemeq06HW0eMi1UYvXJTo 4ZF9ZmNaPHBoYxGSGWy+HF7SCxzR659BWu/+cN0a3zZTPaO40I9qJVcJ25otAIx92/GQ y1uIqylku0Hp5nNEi48+Mw4qc70IaWV75Bm3qggYe9vuaaI4I5qvPNfd9rRXvtAREwLZ eanw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:phone:content-language:user-agent; bh=d7g9F8yi1VGaXD7Ab56n89e7ILsnD+zoNXlIykxEGL8=; b=8LjEFYbgXcyPuZooIdJuNBrh++uUK4l85riCvPKhaNnWOM9OSc+T75rjbbRwAv/KnD t228/JvOCoiB/fGALgPLGyeI+Zhql43C+UR8leZLWyloL1o9z8H/jcowC1bayk+YrGnt 8HGnOcnHpcY51yApQPDKhx0xZKE8iwLvuwgGWHhRZnZ5Q6NiPBfJ47LK0AIJWfpjysAA sbCTq56mi0jbSdZFsxw+upRVnnXUIZN81N66dYzMV3iZhNY/5Lh2SFacNuqK9Fk3tr8b iw9sjaBohr0E2BG3LvR5N2AIM4GJjOWubeZwC6mahU56Itd4s2GapFMOjwqVANRZ+68p Odaw== X-Gm-Message-State: AOAM531J3wQ1b/bBmGhMUlVpQnVOeVkX3VFslkjuw2XMbV2YnN8ExhMS uZSgfs6po6bTDboQFCYyqarf6n0YjTQ= X-Google-Smtp-Source: ABdhPJxlJgsGDvMTFLQLKED1/Sa0BETRkJy0xwik/zQbiiN8t6saw3O5ByP88TY/xwkOrkye6bGyeQ== X-Received: by 2002:a6b:2bd7:: with SMTP id r206mr8312ior.216.1638286048233; Tue, 30 Nov 2021 07:27:28 -0800 (PST) Received: from gmail.com (72-50-221-202.static.fttp.usinternet.com. [72.50.221.202]) by smtp.gmail.com with ESMTPSA id h11sm11485504ili.30.2021.11.30.07.27.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 07:27:27 -0800 (PST) Date: Tue, 30 Nov 2021 09:27:28 -0600 From: Hokan To: freebsd-arm@freebsd.org Subject: Hang on /sbin/init Message-ID: 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-sha1; protocol="application/pgp-signature"; boundary="RwzlKTAeNwjDA4EI" Content-Disposition: inline Phone: 612.208.3105 X-Face: ?5)b8k!Y}/nvQ\-kvk.g*MwRf]Q|YVx7`wK0Fi~1bB;$VCPb4nP'Z9~YQDo~~~J{97YCbBep1/[kyb4bFo-W5Ulut(i<^L@yIv%c|@$Fd,IZ0zDM^0qY}Rb)yn5KHKF8<0[&u{sq~G*2 X-PGP-Key: http://www.hokan.org/pgp.key.asc Content-Language: en User-Agent: Mutt/2.1.1 (2021-07-12) X-Rspamd-Queue-Id: 4J3R0x3nSDz3NYc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BQTPSWBw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of hokanhokan@gmail.com designates 2607:f8b0:4864:20::d2e as permitted sender) smtp.mailfrom=hokanhokan@gmail.com X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; 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]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2e:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --RwzlKTAeNwjDA4EI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello all, I've been running a Raspberry Pi (8GB) since FreeBSD 13 was released. I'm running ZFS on root with three mirrored USB drives. It's been working fine for months. A few days ago the system hung overnight; the screen was as I left it but the keyboard and network were unresponsive so I power cycled it. It won't complete the boot process. When I boot in "verbose" mode, I see messages that seem normal to me. The last message I see is: "start_init: trying /sbin/init". The keyboard is responsive -- I can use scroll-lock to look at old messages and I can use alt-ctrl-delete to (try to) reboot. Network is not responsive. I've mounted my ZFS pool on another system and it seems like it's OK. SO, I'm unsure how to proceed. I have backups so I can rebuild, I'd really like to recover my system, Help? Advice? Suggestions? --RwzlKTAeNwjDA4EI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQoBhwHmwbZdSwkRc6PHyRAZPp6pwUCYaZC4AAKCRCPHyRAZPp6 p3B0AKDgqrf2+RWOk6QV+YYhuLChOxwS3wCeOI0dENd0nHV+82vAeuaCM7QTVLQ= =S/rw -----END PGP SIGNATURE----- --RwzlKTAeNwjDA4EI-- From nobody Tue Nov 30 17:21:29 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 3B84618ADD4A for ; Tue, 30 Nov 2021 17:21:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4J3TXX0bHPz4m3m for ; Tue, 30 Nov 2021 17:21:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 8D27A4E659; Tue, 30 Nov 2021 17:21:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1638292890; bh=2HRSum9ZRDN581b2CxopNQABSHBqoAMqpWwSBJ6NO54=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=upI/DJzgn07tfX+scCOWSktqf/gX9lmG5IwjhK9L7ttp+qj7JTTz1jmlEax7vKOPb AegC7LGv484OXT2IL8WICN1cI6mATGY8F2C9zqRfo3vasHBX8y5N37eLGvYZSJb98Z Jk2hFysFy1QClNdMQ7Mr0pGtp3Ayo2r6HtfQqFwIgnNj/SaeZNGQky8cHh3zuabH3t /o+/fZrXvwPjL6wCdNy7MX3R0LgteDJJrDsMQrBF/5nBEroiUwbRxBzV3Jy4pkrfKL ewPt62/4+2Mf8hLzd/gssz6AsfiWx9jHm8A63zCSxQkWqId2ZRkMyNNDJFTiOLLGSq LQ1dDFT4hnnR1MCEKHl48re/nRN+S2+132Sr6v3WPqjNQbN+chb6BXcjNfIoaePr/n Ry9aZWTulefRkL6tWWhfeVXtSxLKUWGPF45qAhpbnjp5EOVXEtspi989HyKR2mXvte mbO3AvxiYLfmWMCVVlS8DZnAIprgOG5RK2d0fQe9ciEbFHlmqHdA0rk5Sy8iFsRUSc r+zFdv/AK/DSthpyM+4kwyLjKnNkrEoIxvhD/1D9Jd+401JR00d0IgpLkfe/NOD5va tiJRtZqctx/oRTgJj0R6LmOZdPuElOwNJNyiVDxBxnoOfMDFP0MEnpdHOC13mEwonO d4/kxse0G8PoyTEX0BEWKg1Y= From: Andrew Turner Message-Id: <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_2FC43BF1-1937-4BCE-82CA-884C72B358B5" 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 12.4 \(3445.104.21\)) Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Date: Tue, 30 Nov 2021 17:21:29 +0000 In-Reply-To: <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> Cc: freebsd-arm@freebsd.org To: Hans Petter Selasky References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> X-Mailer: Apple Mail (2.3445.104.21) X-Rspamd-Queue-Id: 4J3TXX0bHPz4m3m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_2FC43BF1-1937-4BCE-82CA-884C72B358B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Nov 2021, at 14:34, Hans Petter Selasky wrote: >=20 > On 11/30/21 15:16, Andrew Turner wrote: >>> On 30 Nov 2021, at 12:35, Hans Petter Selasky = wrote: >>>=20 >>> On 11/30/21 13:22, Andrew Turner wrote: >>>> I bisected the detached messages back to 601ee53858f6 [1]. If I = revert this change I no longer see this on the console. >>>> I am also unable to reproduce the panic with this change reverted. = As the panic can be difficult to reproduce I am unsure if reverting this = change is enough to fix it, or if it=E2=80=99s just making it less = likely to be triggered. >>>> Andrew >>>> [1] https://cgit.freebsd.org/src/commit/?id=3D601ee53858f6 >>>=20 >>> Hi, >>>=20 >>> Could you verify that you are not running out of kernel stack? >> I can still trigger it after doubling the kernel stack size. >>>=20 >>> May this be due to some code in the .text segment which is not = properly aligned? >> I would expect to have seen the issue on other HW. The issue looks = more like it=E2=80=99s memory corruption. >>>=20 >>> If you compile and load USB as modules, does the panic go away? >> I am unable to trigger it after removing xhci from the kernel, and = did get a panic after loading the xhci module. >> The xhci controller is one that originated in Broadcom. Linux has a = quirk for it to work around an erratum where attaching a USB 1 device = followed by a USB 2 device the linker the latter will come up as USB 1. = They reset the phy when anything less than USB 3 on a disconnect event. >=20 > And there is no BIOS / UEFI code still running on that XHCI = controller? I would expect the UEFI code to not be accessing the XHCI controller = after exiting the loader. Andrew --Apple-Mail=_2FC43BF1-1937-4BCE-82CA-884C72B358B5-- From nobody Tue Nov 30 17:50:03 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 4980418BE2C5 for ; Tue, 30 Nov 2021 17:50:13 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4J3V9c3GBXz3FX6 for ; Tue, 30 Nov 2021 17:50:12 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5E19D5C02B6 for ; Tue, 30 Nov 2021 12:50:05 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 30 Nov 2021 12:50:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm1; bh=oO7x/owUR0kPqJGgn0SOw5BRrggr/sCt3ebd/eEUzkw=; b=PemVXPUy JXYHGqX0IwOC5CXpvNpYlH8flQZK4K+5WgSMwoMvA1c90NCWlpCwhZ408IBMInRE C9dfdEK6HYPyzLruxhIX/uYDRDha6WoR+UNaY1ocIUeVhRGyse465FXcjoRxTX90 tsk/9G1QTGkebSJSrNCTNhYaq5V7yueisqlx5DMEAZOlLjPiJC8wnNziC3/lqp+n XcXg/qa+8e/oNjULsTBNJQJS3zolr4pgDPvwQGfqLCyYpCNhKePAaRbuxPjubrgd ukvD+S10QHhWW8sGw2qAADJBVjvqwL6INUYLghKbdXNPDyPdO9WxMIO76WF4Bn2o ZnbBN77072BL4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=oO7x/owUR0kPqJGgn0SOw5BRrggr/ sCt3ebd/eEUzkw=; b=RlGNyMJkdiMWseP6BKJlfQJZOqtDvOcokafoWxF5iWFx9 4ZwPqJORAI5BXt82QMjryZuOEJNJ7SNX1u3QyVgmlKHEvVwM25hUKxo3HNkZWW9t QMQGSR2ggTghYr4iVQ3cAlZ41k7c9p0Bl1CZGzk2epURjVFc5EMcDB0hSek0BxWg vwUqRg3R6zbiJwHzUA6JssGcDam4m13pbeo9nSt25BAYE+58WAwZaTI3OwxdQyYX 5gw24k7MHcaQAxXkU49u59xySy+ouayGioHUirv3N9qFlvmWANgnBherA4OjhEwu n6RpvrF30HDYIXPELtw9m7BkxZtkFdhE72L+bLQdQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedugddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekleehfefgvdetgfeflefgvdekueevve ekgfdtgeevheeugfekveeijeelgfeggeenucffohhmrghinhepfhhrvggvsghsugdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvg gthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 30 Nov 2021 12:50:04 -0500 (EST) Date: Tue, 30 Nov 2021 17:50:03 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: booting recent rpi current/14 snapshots Message-ID: Mail-Followup-To: freebsd-arm@freebsd.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="oCLVYo8BJntsA+8L" Content-Disposition: inline X-Rspamd-Queue-Id: 4J3V9c3GBXz3FX6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=PemVXPUy; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=RlGNyMJk; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.25) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-0.57)[-0.574]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; 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)[]; NEURAL_SPAM_SHORT(0.95)[0.947]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; DMARC_NA(0.00)[zyxst.net]; 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:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --oCLVYo8BJntsA+8L Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello arm@ Has anyone tried booting the recent current snapshots? I've tried these ones. all written to good microsd cards, and sha256 checke= d: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CUR= RENT-arm64-aarch64-RPI-20211111-448bcd01dc5-250603.img.xz https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CUR= RENT-arm64-aarch64-RPI-20211118-4082b189d2c-250820.img.xz https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CUR= RENT-arm64-aarch64-RPI-20211125-3ede04c78c7-251054.img.xz Get a rainbow screen and there it stops. Anyone know of a working version? What I'm trying to do is to run the installer and point it to a connected u= sb3 disk in order to facilitate usb3 boot-to-zfs. But I'm not even getting as f= ar=20 as the installer. thanks, --=20 J. --oCLVYo8BJntsA+8L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGmZEEACgkQs8o7QhFz NAWXgw/9Gys3qDqM/C8wcVRjG6xIRfZ8eteMZFvXK0V0GvQ5egSWfJ3nR3p7zQEU NxyPO1jvQC60iqlo+okukZehhL+LpAPsXJr/zQhtLrbZLA8m7MWv2IDBksufALFk ztmFjdrsTM7iKwOERQ9hJhnltt3EiCzh6v8X/GsRxv6S7sxObCPYp80IaXAAAZAL hxzqOZnSZdAZyuB4pSJ8XcY0IWOfZhGSr6feVZer+caL6hyyfljlCUJMXncbv75J OidAzVhp9qfAcd9vDEoLmwcvyBV7oomKPrUkHkPqjBqjRBsmvYQ8fXu4z4l9E8it sE5oChbNG4g1/QhCIE3L6sN92gxEg56k8DWFqnpMUPMas9afApF/nkWG7HnhxVdM 6aOwHY1cxcYibgBPHqilOYm8wyUERi/izfPdbulWS+5ysKCmVX1EPQlA6alSwGel lAqesEl5wA28/fnnoCpRld7sN/ielJPv75dDJ8hknI2S5/xM+c5/H8Dq8GJf0GkO d1sKMvttYHwCO3T0uafsLDwUSGV63qhgdAKT/PaEhRs1sMc5AWCFnJx7g8FB80O6 SD/GG1wcSbHslKB+gVrtCdVsMTbOWxWKY6Y9dLaLNyeSvOWdwLbm/D3JjdSQ9Yr9 W2zlmg1kzaI/sC/A6KgOim2vuLqrFlFBzRr9/3ux9I7TbxZVRkY= =VP24 -----END PGP SIGNATURE----- --oCLVYo8BJntsA+8L-- From nobody Tue Nov 30 21:06:40 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 4212B18A570D for ; Tue, 30 Nov 2021 21:06:43 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4J3ZXM13lHz3Hym for ; Tue, 30 Nov 2021 21:06:43 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 947B05C0290 for ; Tue, 30 Nov 2021 16:06:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 30 Nov 2021 16:06:42 -0500 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=fm1; bh=den4RZ2IZOxTyq3DX/EAjlPdiNd nYvpnMnO03knfsyE=; b=qEQptBibVZY8qcAQth72khk0poy5PshGdqq2K+a2q3e BUq4kg35pE+p6XvA+cBrSJ8k2jI5KggEqLogYDX9/UbNbjOmwARZTg+XgNNNAYLu TuV4LWkB65nxVYIVD+RWx6F/TZD75wCI8KCeB47SDOWBDZ4tfSu+6s9mf2XaLtyp I7iwRkdrMLlGJdjSoAJyboOzZZA816CSpiX9SF64Qa3OWQqE7IbpCCTXtvajSwAm vql5tCXDJSz025wqyKSApA7yM23eSEJV3sr5BbVLJ1FVZPzDaoWESIWq4gR+tsFR RMfbtnxD9aj4fyzgPmC6jDZQfI49F5x5a5a33SLjSxw== 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=fm1; bh=den4RZ 2IZOxTyq3DX/EAjlPdiNdnYvpnMnO03knfsyE=; b=LuQyhSztuvGoo0lPKlba+S mSjZrnkzSznJyIftZXpXbsQnFs38kjBew0+Qgdcw6kJ93SODltj6KkZV08w9Fe1W NVqXyq5dHgCu6bkm/bn1PYupLa2OeBkfAzQw5N5/7Qh3DJFaabKPS3PuFgg8q+Mm PNBKhsrPxPzuKlP+AF0YxAy2iMgFL5j3+IyGtXXfCmF2leFycXLssCOQ7sKRxYqU mHV44VhbYKCUZMdHYgHI/DhVREWyeh4D2ibOmJTNM131LC4aDLAKqvXftKGaS23O 4cQ8r3ODq/pPsheP+guUMJ07lKyLbmY5fOxA73+rwiETnPAEBPy8TCKBcEaVNZrQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedugddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 30 Nov 2021 16:06:42 -0500 (EST) Date: Tue, 30 Nov 2021 21:06:40 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Hang on /sbin/init 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="c/qAhh0/B17vdyaD" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J3ZXM13lHz3Hym X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --c/qAhh0/B17vdyaD Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Nov 30, 2021 at 09:27:28AM -0600, Hokan wrote: >Hello all, > >I've been running a Raspberry Pi (8GB) since FreeBSD 13 was released. >I'm running ZFS on root with three mirrored USB drives. It's been >working fine for months. > >It won't complete the boot process. When I boot in "verbose" mode, >I see messages that seem normal to me. The last message I see is: >"start_init: trying /sbin/init". I was doing exactly this in the context of wanting to install=20 zfs-on-root, but for current/14 rather than release/13.0. [1] (some context: i already have a usb3-booting -current rpi4 that's=20 used as a testbuild because it has permanently attached a console cable into a rpi1b used as a terminal server. That one, call it machine1,=20 is working fine. The rpi4 I'm trying to install=20 zfs-on-usb3-root-booting-without-a microsd is machine2.) >The keyboard is responsive -- I can use scroll-lock to look at old >messages and I can use alt-ctrl-delete to (try to) reboot. Network >is not responsive. also had the idea of booting to single-user and confirm that the=20 booting gets to the same place "trying /sbin/init". I think something's gone amiss in u-boot. >SO, I'm unsure how to proceed. I have backups so I can rebuild, I'd >really like to recover my system, > >Help? Advice? Suggestions? I'm going to try tarring up /boot on machine1, mounting with=20 mdconfig the msdos part of the installer image, removing the=20 contents of the msdos part and untarring, then booting that image. --=20 J. --c/qAhh0/B17vdyaD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGmklcACgkQs8o7QhFz NAWSpRAAgCVCN7muFOtvcq+O6QKGOxQee21pweba10+kx8bxUbiJQG6LdA/iIjRJ ZiURd0hfdazuRQ3jrYuJqtuCuNeIU8EzL2gLpE5lmQzfn+iqYQenFJNN4HPLDc/e Z+zOoqJmeQfaQJCjLAshSqqt7X5NXzl7yL88wo98Xiipgovb2icS8XJ2q3ficuTC nS9t6/LWf1xo0+AOqs1YCaHZ/hZMVWUKKVNz8IUV8yhp6Qi3eeL5knCvbde8fisE qdQ1omWRaAdQX8+Ffcyf9FudlFTKJtJwxOlQJllBh+Cth/YTN7KNWjDW54n4IEjz nHgBQJSeHohTi99QVjavEnfbgPsx6gi3kGx+Wt1j025oj8zpNr05YMmWNc/2LRTj f/vqTFvRCvK3LiCGDZG2NB5eRFptA7+VtCSrYRJU0Qqv1ziUjtBu2rKTeeLhQTLq XJyrm/NiG+HNdiI/ayrxYZuNjwh+nIeI0j23N4gDrinnIRXxT1JjRlId3PkvY3mt 7IHCw5YGdFcKAAt9H+qbnfOyJjmWTfd4pwiuVj4Qaid05Z0lMLCzykir7YeY1OIB qOCvgLTHXgFRVkGE+Qt3wfkRtJWpDmZMtVl4mFfFsTJC5pswyoTA1XmMWwXtx3nj MQgwMsWIBbukLbCMtGY2nabbmh5jABMJFtPJVFqIRj9/pxd2wok= =MFDh -----END PGP SIGNATURE----- --c/qAhh0/B17vdyaD-- From nobody Tue Nov 30 21:37:47 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 DC46F18B3091 for ; Tue, 30 Nov 2021 21:37:53 +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 4J3bDK5F9Dz3hdb for ; Tue, 30 Nov 2021 21:37:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (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 0C9FD260827; Tue, 30 Nov 2021 22:37:51 +0100 (CET) Message-ID: Date: Tue, 30 Nov 2021 22:37:47 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: Andrew Turner Cc: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> From: Hans Petter Selasky In-Reply-To: <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3bDK5F9Dz3hdb 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 11/30/21 18:21, Andrew Turner wrote: > >> On 30 Nov 2021, at 14:34, Hans Petter Selasky wrote: >> >> On 11/30/21 15:16, Andrew Turner wrote: >>>> On 30 Nov 2021, at 12:35, Hans Petter Selasky wrote: >>>> >>>> On 11/30/21 13:22, Andrew Turner wrote: >>>>> I bisected the detached messages back to 601ee53858f6 [1]. If I revert this change I no longer see this on the console. >>>>> I am also unable to reproduce the panic with this change reverted. As the panic can be difficult to reproduce I am unsure if reverting this change is enough to fix it, or if it’s just making it less likely to be triggered. >>>>> Andrew >>>>> [1] https://cgit.freebsd.org/src/commit/?id=601ee53858f6 >>>> >>>> Hi, >>>> >>>> Could you verify that you are not running out of kernel stack? >>> I can still trigger it after doubling the kernel stack size. >>>> >>>> May this be due to some code in the .text segment which is not properly aligned? >>> I would expect to have seen the issue on other HW. The issue looks more like it’s memory corruption. >>>> >>>> If you compile and load USB as modules, does the panic go away? >>> I am unable to trigger it after removing xhci from the kernel, and did get a panic after loading the xhci module. >>> The xhci controller is one that originated in Broadcom. Linux has a quirk for it to work around an erratum where attaching a USB 1 device followed by a USB 2 device the linker the latter will come up as USB 1. They reset the phy when anything less than USB 3 on a disconnect event. >> >> And there is no BIOS / UEFI code still running on that XHCI controller? > > I would expect the UEFI code to not be accessing the XHCI controller after exiting the loader. > > Andrew > > Hi, Could you try to kldload xhci instead of building it into the kernel config? Maybe you get a different kind of panic that way. --HPS From nobody Tue Nov 30 22:46:40 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 6A04F18B1224 for ; Tue, 30 Nov 2021 22:46:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4J3clv5WTLz4dfY for ; Tue, 30 Nov 2021 22:46:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638312404; bh=nA9oGyH+eX1ECVEdX5gF5EXOgx61sB/B12LGlS9P07k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VNapIRRybZs3pKSWY1QvjEYVX9eL7Oi2yU+9qy/ZOWeWsC4ATzmbBPlXCxnJB6XZab+uYyxxg5kW5AWGHqlJ5rWa7x9WwJbasBplMPeSIPAOM7+7meUG73+QIsbLqZS7IHMiByhuW/SKDWdVSjdxqo+uuTdxqsRuZKzsxZ1kiKoLoJ5Uqz0xVdb5+L59/LVKc+6t4bckumqe6tGQzp6K2sx9uM7kOWJaGKSa8ILg/su5Ftfh22PXiis7948NEDkpVxxOjPSBz9obLE25jkQaKUvp9/LJLlC4lmxRbYB/niI5fK+6h3Vn/Y7bcxE5xN+5q0SJWlgfzZkjZN6stGo8eA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638312404; bh=F3X5LqVfJrtnaL7JhF/PdThvSzOBMTmOT/Y4k5PlqE8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=a7I/BR9YvrxfdkBDJwruraanqc+nXA/PVJ9vcIvt4dJSHjWqSIMUwUyctIk8G8ypX8Oj6Y/fzli3ymjwNEO2sYxK29fblMdWCMV1tAPiIe8vCp+nhPP1XP22e0Nb8oi7RwCNumdAzTnqvB6d/qiphB1HCkUBZ3drWCVEXDNAYo/RPNL17nWHtNDhA0lYJp02UiMF1YOkFAhuw60l09TT3KEgkU6e6FtEB0mA3z0tnRE0jagCUk5QezqZTW/jn+Aq+9I8rAIDbKJ/F0+FSLlltx6snqK8MI+Z7ErwrFZqct9JyO29qkkGatjnus5BEkIKzWlrSlGQXEe1Ubffb+gyYQ== X-YMail-OSG: EfzM9gsVM1nhj5okIV3oCsMOP2Tdx66yQsmEnvFr07asFLAwHSdo_fWWpoetKml rLLiKQuco276T4ozICqsFtsd2H_O8SLoTmbWYK83iex_WzVoRZ2ALleV1FzMVXmjnfEelXbksoFv 9tAsS8LCYdCsrK_aDe6uWy22ZV8KJzTj6WHzxN99TnF1HCh0PK.OlylyThpS809LbmewBirZgADZ fnG.XCNLZQax1QLsleBS8FpirCG_GGnnL52uMJg_E.h5FlfHogHj3rIBcZIf4L5Z5T3MW7mIffzy GPdYtOKUy5nMJzzVXL9dts5LxDBuEirjHndzkzohl0YOZopB5d2.dZfKUBW2kXmYiU_uCk8G_FQ9 pNb9q_pmJS9ZEg9g1Fqvex4Fj8ebTeeHkBhCp171Xg9z2WchrFQ2sL_MaqxtPykQIarKjU9Wucrd cEEczLjChaQ2wqRTqRR8LS.2k80QEDP_Y7pApX.7kkoyA5Ka0TQBdzCj6jPJlKveFH6glBXVv6UJ jtWonoIjOzOf4.FWdxHopoQiyLvb03Hy1yIwZzpRbMpHLSATVDR_KLGVKgHMXtzaFKBi215psKlj 8U9p_dAVDAy9EmA6kd9ioPc9OASiNWT89awCLzXhp7nOvKzdJ2cazkmm1DGG8ps.IegOqKaLtUSS bYhuVY2h2JQZ2UJdIiZMSXYsqlqKwx7bXBaBpWwp_kuuOR1alFovdYdP40KYdU6g3ocY3x6RroMd UWiTXH_qsXHKd8ZWM5zuhXHldNSKQtgVBuZcjEKrNrIRHywNe8xa5DuzAkZkHceSewQPm8Ja1zY2 DTUFZ28_BPJ16_mPIAhLtyobWe8qmY7n7GOMjbEZOlzOSQGFJ4fjJ5zQIWawfuDIctSVrcxbhZG3 oavkXVvwBSeBz1sA42dpOOmSL71G9WMke0qlXLoDxBLtw9PpWSdVXE9o1Q29npz1Cy4HGQu44bdn XxVAx1fc3pC22R8uizSxe80J0Jv48gy9xR2.l80tmJ1agksEbpoQoMzKqpvKNXARRm2TtQzvaSv9 MR41YAO_XP00_2.nIMfD9wTztNgwqYoTfy1.BRhHmeQoxG2hGPGfpBndJv3ogRc9kNBB3Xr6r9WB itQSjTHjpPyd80DegcFJCcAHiqcuoSnZJ6EiT2zY4f8q_onFKeNEh9rfP2bBIDgnu4hn___PmdJ9 Mmh.led6Y0V9fzVFhSH7dEyhdOuavRdlEzla76m6efx90_jacWjRfHW4f2LHWTg.JAYENcVuynnf 1WU_0yt91uRWTsXdEpaBhXuAh4OKKfitaDe2E26bgzmgDPXmKRqA1Yaih0aOG69Ff3sI.K3UdiL6 sLqnG6X5hPOpv_Kslrwhf8ARnKesPqTWSVA.vFbn2HLdr5k5aE3AfQSii9XCnsh_1svfPhH4pS.B BfXzALH1jSg4YMc6pQZxAN9y66I1hq8et7tnCc6aTrvpXTitdXJ7Wjkfj466taetsPDmFa5unCUT tc9bUJnpAcPo3viGr9nGEscv.dgXL9.m13NlpL61Gmi.8al5vsHdHMpPSHYpOsQdC7eeA5nlIB7Y 97yLrbszPPLw9GlFsRjX7OyH__GI8whgsp6jdRv.OEZ2zTDQFNX6geoSo2871ARQNZ79GUedTypf Ztt0gzlGLTanG99TNvq23QdLNGGz8IahLr.PO_NeUyG61YZNeVlN_QKAtblqWBR_lahzFul5DQCd dwFCUVGCQT3D2zt0AwOYRtS6LTLmBaPPsgev8xpKwxtxOWdKRAAdgtzrcoaVpg.7ic.ON81uLu1b X1f.PL9aODRWCKkTG6WRVz2V5rogFJXas5d8bqSZ7XEq3mkD1a_d2Gq01m2RWVAaoWo52gCvDsm9 VMHcqM0MYmLDwCzyLBvjfRGLc1fOgvInhNuAwuBjfM_QAgW.8ZIP.StvfYf_Xve6dNXo.7vbThk6 S1da2iZ8cYDLnIHtIFN5AifK_JVbaIoafzcPziPEfEdZkwRRGFTUmdEU80LwgWi11JJYHK6gdAh8 Z6TkgrweKO1LwNFAgh4A9p36bXNdEI5J_gv60TdJuLf.dLkx9qsPDfW0bZvWZN7T5dxF9woVGgO8 hN1ECCzB3xHsEfg4TGU4HGVWC5WaMQIVZQf94fCvuGYFkuhkk4brmquUShm0yDNftA38FqRq30jI xbTM76rd4dSieJx5_ahbuEUmvF1Q.7lM0NSUhXfOXl6F1YE2voU6Lbplvm7RcZXe3_9rvZo6AS3V EgEXUdFR.78n5dKAl_4jSqQGkDZ5f2obxwn1MHJVAOod5FxyU5rTSfeKhLW8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 22:46:44 +0000 Received: by kubenode503.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7ce626c6ec36caf4daefc3128fbcd8a8; Tue, 30 Nov 2021 22:46:42 +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: booting recent rpi current/14 snapshots In-Reply-To: Date: Tue, 30 Nov 2021 14:46:40 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <55EF15D1-4121-4F12-8167-353C52D3F72F@yahoo.com> References: To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J3clv5WTLz4dfY 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-30, at 09:50, tech-lists wrote: > Hello arm@ >=20 > Has anyone tried booting the recent current snapshots? >=20 > I've tried these ones. all written to good microsd cards, and sha256 = checked: >=20 > = https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CU= RRENT-arm64-aarch64-RPI-20211111-448bcd01dc5-250603.img.xz > = https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CU= RRENT-arm64-aarch64-RPI-20211118-4082b189d2c-250820.img.xz > = https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CU= RRENT-arm64-aarch64-RPI-20211125-3ede04c78c7-251054.img.xz >=20 > Get a rainbow screen and there it stops. >=20 > Anyone know of a working version? >=20 > What I'm trying to do is to run the installer and point it to a = connected usb3 > disk in order to facilitate usb3 boot-to-zfs. But I'm not even getting = as far as the installer. Looks like that last (20211125-3ede04c78c7 put on a microsd card) has: # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /media # strings /media/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) (I ignore armstub8-gic.bin here.) # strings /media/u-boot.bin | grep "U-Boot 2" U-Boot 2021.07 (Nov 25 2021 - 05:58:44 +0000) # more /media/config.txt [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin But I'm modifying it to: # more /media/config.txt [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] #hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # Local additions: [all] enable_uart=3D1 uart_2ndstage=3D1 dtdebug=3D1 disable_commandline_tags=3D1 disable_overscan=3D1 gpu_mem_1024=3D32 [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 [all] Note the disabling of hdmi_safe=3D1 . The 8 GiByte RPi4B's eeprom also has debugging enabled. So with a monitor attached (unusual for me) and a serial console as well, it boots to the login prompt just fine, both on the serial console and the monitor. I logged in to both. # uname -apKU FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n251054-3ede04c78c7: Thu Nov 25 09:59:03 UTC 2021 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400042 1400042 For reference: EFI framebuffer information: addr, size 0x3e402000, 0x7e9000 dimensions 1920 x 1080 stride 1920 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 . . . VT(efifb): resolution 1920x1080 . . . fb0: on simplebus0 fb0: keeping existing fb bpp of 32 fbd0 on fb0 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD = 14.0. VT: Replacing driver "efifb" with new "fb". fb0: 1920x1080(1920x1080@0,0) 32bpp fb0: fbswap: 1, pitch 7680, base 0x3e402000, screen_size 8355840 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 22:50:19 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 6E3D318B243E for ; Tue, 30 Nov 2021 22:50:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4J3cr719bqz4gNf for ; Tue, 30 Nov 2021 22:50:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638312624; bh=0Ja5kWemtAy71m3TrR9NbSP83NkOnSbeOq9STj8K+JU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uQzRfd30H6Xq6bHEubbdK6IcYdR6FcXxu6HXmKqSkE0ekRDwmnzEuz0AUQvHvt5V7l0to7XXeG14uKUEJJ+AZ1CNDXdA99ETQ79+mb6LE13rwE4aPae3BmzMCUQyfvsmcUBMZNph4ZkVdqqEn0thTYpkV9qUWLNS6IQIvwj69JLxsFqkH172GsrgD52P17HF3WqfqAhQ3qdgH8Vg8gLqfRk47VHxYV6fS+l9xC9XSIlcHuzwwr8bsWKbN9IWIgmgTVbhqlU0J67sV54Id8nZi3GikNqZ5I83AGYM99NNZnvosJNiSat8K8zyvmHl8IIxns/QDsA8MwQWeZoEuOcpng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638312624; bh=xi3a1wXcOesaE3jcvc/Zbtq7pSYnOAgLegagktVg7Rz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=L/nechfGG5v2BC6g0EcsOBnhLBlAUXoVItaHnH498xHX5naAxsf/Xc0iV/Jff9WWZ9t2p/yK4OBf3H8R9gMtEdEg6Gs5aQwEYSs30XrJ6QkSccEZFKcQBIKmi904uOhwb/OPR+MyGAI80kF78k5LobVhRFG+v1zLny0gJsrF9UnVn6+abLPnatFvFVjPVsD9ZoMIwwXq4hBQwnu0j5DyLuXDtE4v5DREubO7UzUL8OKGDx3uNFVQH2NvehfYoRX2HsP4D8FDjsxtbsOYcFmp51Bo67AU4ejBhdE3ccMhlrwOCUEx274uN5d5MsMnBZJUiQLVvOhjAcT5H7x57xWB5w== X-YMail-OSG: iv1TZOAVM1mgbQzx2jR2_tHYeMLBTOAtfA8iakzqAbo1zJXLRiFq2Itd_0gEyD0 Wh5np90rPygqertudflHBddWbcee.D4XDiFwhX5PoUJe2Ty.Xf7MTnEtnpCt2JacKX.MzSxwv5yS 2wn.NNVqAED2B9m1x8HLWw3mI74klXxIaUJEe_OL0vzZF1exM2xJVqMfWs9CPpvEQNwULe7QJ4t_ TKeL4EYlSD2pzl7PFQLZqBxHnKloucaMfNkRcWGndJ4rxMhKgx_QuHMB.Pl4uOUlhOEvPWGyIn4O Y71Sd.YVyzdBagIeJrMBGHXwyNBmfc3Pci8lYmS.OdOTYoUky5uKEePlBuHw.6Bx_nlo9TgUbNj_ njEwDrPBBxL56MjoJy0VZJW.VOdKC_ixLqVEsp028mzobyE7P2Zu4uTXfVGw2L5UyHw.iy4BJSkE C_GS3QttYAyrxJrv6EJB_kNThmf28xKGloggHcSi8Jm5uo3NjI.BTvre9wi5r3tgEcS1yXk3se9X 0PXfCZO10sC8ciTL_b5BC.tEbCnZIMHKMtsKx16fElb1LIpjGd69ZIcgOaUcJFbPY643nzQsXXr. gwri5Dk6pRkoRSdxi68V8jRr6G5j_9.Q2wH34ZeR6YUZJojemBHaMxD5M6F4h6Jok3sGmTxHzK8r qlFsN_4AxhqsQgk3LcuzYl8Ba4a1XBZJjTvDU8r1sk4NxVE.1_uLzbiTCy9DUtpG5lDoUCCXBKp5 R4Im2ZKKQJSLDtD_TunS2Yw9dTXJCG6FobJRK0gI3Bbi4cppSdmyYD4QPy.w5Wge8h780JRR8U5J xEN_XJhB0yRBm3Qf2rUVPeyavO1t09xxDoedtSxjr3dMt3mHXtODAkyGSjW8DkgVa9kt_fSTpG.h snzreQ2ZilOOYDS3TLeVb_d0oR9wwD2kYzwN5u8ffL2D0MXxTNq7M2p5AwlENqE7ig2bhlbaE46u bKX8QBMXwFNv9tnNIWh028bLLy85FakJSV7Ofym5Vltx1tdTXeV9d8QtZ4TeMF6dpRj7QSXgHq2m buUptEryZHVQw61UK9VL6r2yI.eNOhkGfGacHf1QJC7QVLlGuAS5OdGQ5KUjJDFlx0Cmf1mGMDdi WTWkqHaFnZJPdtVL0sk2XkbasJD1UfpqeAL449JelkdXsDpQ3VAAT55YvX2nLcb5rBssIlxFIYIc ktfGojyFU_cChVe4EnI9zaP8cqDhXRunZ5rFMWSl_Ux7pJfrAG8VA9s4WfLDa5lxUH77A4SPkK3g vT3lXncr87vnS4h6qNhAeSXbv3cZ5Fq9.1did7.dR9zYeGjYom1GovmIUGig8.hqv2PINNLhhKYM leZsDtgU367DXeg6MoHujxrqj_sMSpOVVwLSqs1F3Cgi0.deB69AF5JgD6D.QzvhscPzt0QMY1Fv _Zs27Gn3MCdkIlaCDGVkvNj4WNA4Nsx9MJ4dE_KXZLjr_kc8H_9c4TtfmYoQeV5wL.RowY1gmCkB 9zxb_1ow6eqPf.VUjtubSSz2BEJ3GEZalO_FZ4azNrOG.DotoVir.VxPJKvtv_Qra_GscRx6tbSC NrJVCVs2gkV.g0Rw8.xdN8JcLFN.i_1FKQT7vgBdgeO0SL.yeH5eaqIhcdEyxA5_KyJU30f0ftKs vkG2VHQqCbv4fmgV0B4BpVQ01peRa55H6eizshnHVd9WY9AkDDwkqCnZCCTKlMj26wawr3w94eHm F.E.RrF1PpdfojFfYegDgM5uU8YQkfYENS4dtFVS174vlBicIRVjeof.prQ2Ucdbp0YAMupg_opx sKQsPbLJnZwAW98OT2xFG8Xy4qbqsWbiK6PpT.VCmyYRB2C_aVSw0PbLgP2hQdYBRyU24UwmHlKz ETVqqS24yoZ1nPRdHJfGMapdpMRD8U7Kp09Henh7iBdHH7wFqewNSOt4RG2GUfgz3AO0HZcgbIrx g28abS0C1YgjIVTVQMtBr6vkWgv2KDU2PAk9GOc0o0osIOdFTrwKCRLMXQ__icvxhEHfWYnEVLMQ 5pGm17kmO12aJJsDwrMNzPtsaGEkUrD6RGLq8mrBr7kx.CVX.N1rFOEUYk2EcIddFdntIDiYjcOE nfBdMP5C2AQ_TAR6DQjp_eSHnNL9F1nStLfCfEQJMYPXX.NDVmOb4eqc1ADSDoTbI_Rbt5qNUeQG MpodUTFzcxz5I1w3NrPgNhQDYhrf9wCZUOQgT96umvB15m52KbKxMi2qPY9PN607CfpZKH3z5Erm bykscyThyz1nU4jwWdKY2_MDkKKVCL4h6VM5TMbTY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 22:50:24 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d7313f0d9cb6821b1b3780d0f13e3ee8; Tue, 30 Nov 2021 22:50:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: 14-CURRENT Kernel Panic due to USB hub? In-Reply-To: Date: Tue, 30 Nov 2021 14:50:19 -0800 Cc: Andrew Turner , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <54AB82D2-3AAE-4314-B42E-B0BB8352C371@yahoo.com> References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J3cr719bqz4gNf 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-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-30, at 13:37, Hans Petter Selasky wrote: > On 11/30/21 18:21, Andrew Turner wrote: >>> On 30 Nov 2021, at 14:34, Hans Petter Selasky = wrote: >>>=20 >>> On 11/30/21 15:16, Andrew Turner wrote: >>>>> On 30 Nov 2021, at 12:35, Hans Petter Selasky = wrote: >>>>>=20 >>>>> On 11/30/21 13:22, Andrew Turner wrote: >>>>>> I bisected the detached messages back to 601ee53858f6 [1]. If I = revert this change I no longer see this on the console. >>>>>> I am also unable to reproduce the panic with this change = reverted. As the panic can be difficult to reproduce I am unsure if = reverting this change is enough to fix it, or if it=E2=80=99s just = making it less likely to be triggered. >>>>>> Andrew >>>>>> [1] https://cgit.freebsd.org/src/commit/?id=3D601ee53858f6 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Could you verify that you are not running out of kernel stack? >>>> I can still trigger it after doubling the kernel stack size. >>>>>=20 >>>>> May this be due to some code in the .text segment which is not = properly aligned? >>>> I would expect to have seen the issue on other HW. The issue looks = more like it=E2=80=99s memory corruption. >>>>>=20 >>>>> If you compile and load USB as modules, does the panic go away? >>>> I am unable to trigger it after removing xhci from the kernel, and = did get a panic after loading the xhci module. Note the above line of text. >>>> The xhci controller is one that originated in Broadcom. Linux has a = quirk for it to work around an erratum where attaching a USB 1 device = followed by a USB 2 device the linker the latter will come up as USB 1. = They reset the phy when anything less than USB 3 on a disconnect event. >>>=20 >>> And there is no BIOS / UEFI code still running on that XHCI = controller? >> I would expect the UEFI code to not be accessing the XHCI controller = after exiting the loader. >> Andrew >=20 > Hi, >=20 > Could you try to kldload xhci instead of building it into the kernel = config? Maybe you get a different kind of panic that way. Looks like that was already done and reported on. May be you want more = detail about how kldload failure went? > --HPS >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 22:59:52 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 E387F18B81CD for ; Tue, 30 Nov 2021 23:00:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 4J3d351HCSz4kTm for ; Tue, 30 Nov 2021 23:00:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 004AC5C020C for ; Tue, 30 Nov 2021 17:59:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 30 Nov 2021 17:59:54 -0500 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=fm1; bh=c7uyz7TnyBIBPpcXVerIGAcoq/W XtBqYdGq+oYaZIqY=; b=NGjIyaSDHJSBRrVCB6Sa3MLogCX/fcPULCbsIuDMW9n O+IdMT2WzmRLAn80pmdzO7Bbz+vxVWDQuRPB3zJc98ptC3cd7cq/zslrkXuMpYzi lmWgM3Ie4LCbvK0oY02HlxjbR5rNSw/vb0wZc7LLJoJSNcVtHi9muraKBy8QoLGQ mVpkqTiqRAno9/sJ7P+ija2HauWnReYnJOQy7DMXr5dEMujfVp37X/E92uGpdMZj pkzSQoyTCjK909aWtwnzlkdWNiBVAK+v7OqKrw3mzHlKW4qDQg6Clke15h1SO+cD z+Ju2+X0LBPNfm7iOm9Zk87YrAcOGY4sAgYQzZCHpmg== 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=fm1; bh=c7uyz7 TnyBIBPpcXVerIGAcoq/WXtBqYdGq+oYaZIqY=; b=QCGeVBb/Bv8MSbUqWecmnx fDJ/gutuUG4yc3VFGtHpKm5cqfs0si2NqYy4tmgo6KC+4UpthOiS09bfNHHwSYae PmveJHrtHX6JZ+G/R07bbkBBgUfvR+pnmIrf+c3QEX+L0aM/f88fLyoaqH4+C5Hn 59HvBqmz9Wxzmc62QFF191+q+dDQ8LY8HaPynh4rS/0Nnmh1eg69V9U++4nePh0P bXopw7k1TfESnCPcdMxlqo62mikzT/teQh0c5nU3pWoo8wDhU0lyQI9eLVFKDovJ y0U73rx3drf6515y/SwQjPdq/mt/L1dS/PlsFYKlAw9e6immAnT2oKeZ4BzXu4hw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedvgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 30 Nov 2021 17:59:54 -0500 (EST) Date: Tue, 30 Nov 2021 22:59:52 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Hang on /sbin/init 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="gwLRsDfm49gFIjT+" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J3d351HCSz4kTm X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=NGjIyaSD; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="QCGeVBb/"; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.28) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994]; 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]; 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:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from] X-ThisMailContainsUnwantedMimeParts: N --gwLRsDfm49gFIjT+ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 30, 2021 at 09:06:40PM +0000, tech-lists wrote: >I'm going to try tarring up /boot on machine1, mounting with >mdconfig the msdos part of the installer image, removing the >contents of the msdos part and untarring, then booting that image. This part worked. I was able to boot up the image on the sd and=20 ran the installer 'bdsinstall' with da0 as the target=20 and it seemed to install there. But sadly the ufs3 boot didn't work. It gets to the bit where=20 it's looking for startelf but doesn't get any further. Maybe=20 I need to set the msdos partition on the hd bootable. I don't recall having had to do that before though. --=20 J. --gwLRsDfm49gFIjT+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGmrOAACgkQs8o7QhFz NAVj5A//QiyNSX7CSQbVD/rXILq1YcUbannGYdv28jXe0zOUQy3FbcyvCsCYOmOm J0tJdyOkzcvBfELOP4QdbTEhTj6p4rlDMkrTMCjjlcid3HEZDtteFP7ZHc2XchxW qYU1Dd6pZMywA0tjyXHroGTnvWFDXPcEuB6JYR6hhbduNfd4bmrZzXZtzeAFfm9S 3fiaR5oBA6qWfkb8mmRiy7Mlq3+E+6lKf9I7uoe0U3Cfj35RBrMbZIlNbL+lF5jt R9e3r7zcxzrGFs0Hx/eBqMsAM7zXdI5xMz9uPG45Qy+1FAJYcGqiGL6ak0AutvSn 57fd0V+C7m+E4ZV/LiZkdVp328OYrkyKJUWGZPEH2K2UTiEJEi+SKWzng9H+6K+D m0oYaI9FWMmqspMBjYOgaIAeWfhDbU/wAjLAd9trTC4l6twJtqPObm7s5TbPm92u TrjaF55qZ5yeiLXpi92dnvi7fKhd2K1Y/P9d8ebm73HF0a3+Pt84HQW040wIqoFQ 35+DGkzBCOI1d1xXBnW6TB6oANcYG2aSYONoCmRwAahYhwLBa1jpfYkYmAIF4LJc thHkPOWT9CndQZ2IAJ6AA2/tZ0RJVMvTmPcTMFw//xuxvGpu1F90CnIH5f3Ru5tU 4S46gW7M/Npb0L/J00KzSQIxxotibo+bjms3BycrMcu+cQSgagk= =adgC -----END PGP SIGNATURE----- --gwLRsDfm49gFIjT+-- From nobody Wed Dec 1 00:21:14 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 B006718BC347 for ; Wed, 1 Dec 2021 00:21:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4J3fs41Y60z3QMH for ; Wed, 1 Dec 2021 00:21:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638318081; bh=GAzNK+Xz1PFHii0BokqxOX4WL7jWpZzYDucbRAt7O7c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fTGmab0o+/TOYAL0EFguyLTetrwq4Sa50tFC1/82CBfaUxksdZhVi5ZKdATU0uDIpG2oJ7OUTyoez6/ed9AKErtbZ52EPl9ad1sdsVHMnvol9CF2F9HxxDNnrmR7z5zvcPmTiL8OommmbbQh03glrUgbP7kqPKjw3iT2W1n9nvrIE54vdoXOuVyHuO0jUE05D284vG+FkSPHJOufMsSgrbPIO0JF9WxYw6h/WwegbtcYQ/h2H56ldt4UOX/nDSzrs6CT667AbkjzX4z/hFZnWUWdyBBm4TJf49fzMaWNxuu/xXIjwvaAV0HQxMFN8BN1gaV+7ZFSpD+V1evXujiuhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638318081; bh=l3g+dKdpLzKgu5pgtNvsEPlJ6BrlNhAQhbmN+4qrpyX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BMs0A/NQV3Ju1f9ymqqDygN/5pASHBmfG+/Ad0IY3zwv2OMQPb5864CrgdxFnJ7ynlHN9wgmZYl45/GkrvT/Ve+Ai2j35Jqlm8ZQlh0C3pi4/uSFJ6b6yCuIpIbZPzf7nyPUSXo/lDw7wiS/J/41sBS8gD/CQe7lcL/zZrDhwt/pZyBCFYkhW29hLOCSO1ZK+TpsLKngxe/T/Jd/vd78B5Aqx8DIqApwEPv40Gan7Jw/hvRXGACpCPSgY6wqmavP8/qIo9xgTX8Z9v/9eB6+Hb5cuz5lK/jhu6cJSNnwWJ2bbNh/pTUypgak6Oj6OmXjufNGZW95GC5SOjTBH8tnWQ== X-YMail-OSG: QbrqdgoVM1m.KB..hxWwYjSmMM.9M3PhYrHMnB3LvupC3sN9J2ZALFohnlrKWKu PelV3teBUDvB6gm6yTQNmzC7hE_h3Irikr3OsPdvZWNXSbiSOg6kUMPa5Gg3zOEamRWyetTaad0d wwr7LHgEO6atPV47R9N1KLzyylJPtufvg9W6auiNEbQ5fXKPTUzOmGW8s.d_Rndoz6juY7yMWvY2 ZwXyvh2VFt1S2IcOFtEwEJaFT7RqHHPq8gMoTOsd3wUxQAH_U3PajSxigCnU81dKeCT1AEpe5OwA dSbQf7.MqIksNTDCuuZvJ3Mt8awluCGXTceh66t.n8f_7xIwniIgP3GUYFy2yw1CSEjHfItfmwLr PvPvtQNXhz0zVthXEZZSjYkXy79FV458smx8uuUlMNUx3g95JS9GIhhkz_I3lYB4Nwaia3eLsz2L a7dsk5VRgGZfG6hvbQBHRVf8DLngEIgS4SEFlfg5FO9jDjFcqpAQbDa89M0mSAuuqHLl_XSmidwL eg0ckowIXy3HVuZJkSCvPukOXibCHm8QxZXhRp9fAq3Yp1ncfzxkAGit40vO8bYKM_.XNnMwNbcl tmnGQ9plZgbQEBuYdM2yHI0MEAcHZKpZMxTbqpqa_IH2tZkALSpCkwwBgAOs9dPQlcZVXidGxn7j rdWfMMAIzNRvpwfUIC2yc_Kjh.8iRYwr0znA.dM5OT5zik5_V61hnWRGu2DMRq6gJl3BYNXrqZba ajD.hd1X41DaToI0uHuYRYrT99dV.LjYk61NjdDEoUBLVWBe00jQ5MwtENS0oDbRtlOT7oYHkfJb L9C0rZnN4JHQ73j.9HEvvUE5sF1fIeAfWjESncXmN6o7PJFTHo8jwOL2EEEVznB9hl.g84PEq7G_ wqBVfBA5wauolYHsQgFhgdLArt_swM8KYIgAc3AAbj2Q38_beHRpt2DjYYvTtiVNzFSCk9a_7AXp OdLagDnP.2dQ6qlouo4dLjd2VATW6862s1lxDKg37cf..tGcY1Vf2Ep5Nk.EDpdaafawINbHzZ5N 4TMBPbg7FIP_OYPOrAYJ46ZYyyizsnCRk_44Jq7MeVzPUb2_IuTwUMaFZFhgY2dd4wPzyE0MNYoa HGCwMJmleUuwA4aEreUFiZ7.AOa.UOy4yehqeoc6UF4.peMmvFmME00KPwcfbSs29vCdDd_6atJE u0FVjrqJzdo_93p3ekL7FBFLOz3ppQa2Bd_yPkmDNKqZjcZizaoQDtjz4F1hTOtJdO0P1DGiwdaa kWFNj6.7vibhQTMvd57c3sdenDXOROPFElnDbr.trXdpNXTSQp3yIRIin3smhFtN2L0IBkhbcuJ8 csYFFYLB2BypvV85KUFOC_P.xQTnCNEm2fSSu7MmzfRh.koiGhaTxlKuZoQkepBRxjVjEOrQMjP6 aCv2oWhIy2cIjtztyivcnqbMHYZ00Ip8GtbGEc28dZzllqjeDy8_w_m8EnhaV1FUErqphsMWKIfl 364lVI8ZZ5lPFfwTsSlmRLWtqcQ8L.MFSJWzD0nrQjDR95o3QuCiHmeN.gdV1cva5UB4g_SZ1.Yi 7ZtMRfZk_IzzzSGJmgOdolfHG4x9c5J_W0hGgXwdtpps2xF5UPkhSllQCiUEqMJJjjg0RXqLaBL2 ASQSRYJq8e5vpCv91NV2c.xexdZa_5rXB7KqE0nw0_6mWzPfn4PZhpninjW5DqOu_kY_ixCNbXNR HaTeFz81akdZwdNvTqIxQr9ucBP_BIe6NyEqs23GhxJ1FQlDH_FaBkJfMlOfSB1HYLYBAM5q5v.5 AqzWO.HNNRpUhVIU1WfupBG31qSOTdmE5xKywS7Yik4EFyAy7yVP.qcpoS10j2FnnvCi_Vo8BHD6 GQjufuH_sTDLdKrZQWqbWH3ev2cpdLoxf4cyFwnvAD_qgUHbTzcCfs42SvE0_17hMA0pS8_MOuUD 06uwbqVE3dndTtU3_lT961lhnWcV8Dj68jWzQqGW42H8v95T8zUdZBWzkRBh6UjM5qDolPeFnnjE mgIU14DUcHTkHuzebD4DnbyQZQ.1Lj__Iw3yxXAH_nsIXf1WWjx2P9OyggxGHCZ1TzsZtiRY.I0J hPe3Pe215DqqbF2dBd0TkAn_cxQznh1YcuT02mYaNGp6iX0aHVlxTlB0O8vlvvPAF8K1ZI5lJm8m VQpr81Hw4u6hI7ARjiNngSYqFTAdT3NTTmw7JpflFWPDNVNUYn277u.ITEDuA1gtYq6FU3jGqUN. BhpI96EoeIFGmRe0BkbUphbWCCfIOfXlR.TkkP8cF00BX5kOirFTqZGs3yRQvr_hSV1l8sFXUkjF YO3iF.yT5MJ91E9R93QRw X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 1 Dec 2021 00:21:21 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 37336ed6442ced019aa8c1dfa3ccb12d; Wed, 01 Dec 2021 00:21:17 +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: Hang on /sbin/init In-Reply-To: Date: Tue, 30 Nov 2021 16:21:14 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <69C84C56-78F0-4AE9-8FF8-BA583BCB80DD@yahoo.com> References: To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J3fs41Y60z3QMH 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-arm X-Original-From: Mark Millard X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-30, at 14:59, tech-lists wrote: > On Tue, Nov 30, 2021 at 09:06:40PM +0000, tech-lists wrote: >> I'm going to try tarring up /boot on machine1, mounting with >> mdconfig the msdos part of the installer image, removing the >> contents of the msdos part and untarring, then booting that image. >=20 > This part worked. I was able to boot up the image on the sd and ran = the installer 'bdsinstall' with da0 as the target and it seemed to = install there. >=20 > But sadly the ufs3 boot didn't work. It gets to the bit where it's = looking for startelf but doesn't get any further. Maybe I need to set = the msdos partition on the hd bootable. > I don't recall having had to do that before though. The only adjustment to the original microsdcard needed should be disabling hdmi_safe=3D1 in config.txt . bsdinstall does not deal with the msdosfs content that is RPi* firmware or that is from the u-boot port used ( armstub8-gic.bin is also not dealt with ). bdsinstall only deals with FreeBSD and possibly FreeBSD's efi loader. The other stuff you can get from the original microsd card since that seems to work just fine for a RPi4B. No need to use older materials as far as I can tell. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 1 00:31:15 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 F022118BF93D for ; Wed, 1 Dec 2021 00:31:24 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4J3g4X1cN8z3jY7 for ; Wed, 1 Dec 2021 00:31:24 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 48D775C01A0 for ; Tue, 30 Nov 2021 19:31:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 30 Nov 2021 19:31:17 -0500 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=fm1; bh=/9feel9KeZvLzVuOikGgvx//XXm CvLNiewS7sJ2eevU=; b=JObnJnBlslhIPTJOYvEjIOej6Mol5r+D/P2ICjozHky RxxLAEZ6GgolHOMMk2atUdwLu7L6dl3V87NsDj/TpnjmLB6MXQSE3g4LoKPl5KVd A9x4CIMbkoCbpwro8UtwH+wBcFOXrulmiCIixBKzF8VxdOiyumdkli3xaFOnQ8QW oCbgMujbXl8bjP+nSBXLdk699NMJZj32rNNPWQvEmf9W0P3C4AWX3qZ5VdTAzMjS c4Pv6t0MlmLs/iDkt6bXjSTamgEgNIOewconO+e3DqfsIfAmUwf1fesH9VXAybjy jJIJTF2MbdZAHLprWiZQWvT9pa44EQPKpsIC7M933eA== 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=fm1; bh=/9feel 9KeZvLzVuOikGgvx//XXmCvLNiewS7sJ2eevU=; b=JMvj+DuVboPGhnXXq7VzBB UaU4WxjwveWFyRXiDJlR+SzCg9CcsCptqjiyNTWtGoPVqviJ3BlI2ZODYE4A+NCk Lo7X2tgt8ZnytuV9lOLkvJZ9QvXSNvHkDQj+2nBrHo5WR4YD7HMv+WCx0EtlMHqd 4avdhk2NZ7CmfqHrwV4dcaa5rQiWiikdMmU9Jn0dI2P1Opz+5KSPhb4G648VSlGN xGn1lrSeB4e+eP8yMPOTc/RWXwUSz+k3kJHJlfmDqlxbMelGgCzUWp7UdsVkUun0 HQ/y+8xdmWwtGKemfaRBGtTSTeHE/1zsQa7E6D9UYl/FpJReusgrh7Vol22E+3lw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedvgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptedttdduuefggeeghfekkeetkeejle efffelheejfffgffdtfeeftdejgeeuieffnecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepth gvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 30 Nov 2021 19:31:16 -0500 (EST) Date: Wed, 1 Dec 2021 00:31:15 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: booting recent rpi current/14 snapshots Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <55EF15D1-4121-4F12-8167-353C52D3F72F@yahoo.com> 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="Sql8a8bxU1wLSbeJ" Content-Disposition: inline In-Reply-To: <55EF15D1-4121-4F12-8167-353C52D3F72F@yahoo.com> X-Rspamd-Queue-Id: 4J3g4X1cN8z3jY7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=JObnJnBl; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=JMvj+DuV; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.26) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; 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]; 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:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from] X-ThisMailContainsUnwantedMimeParts: N --Sql8a8bxU1wLSbeJ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 30, 2021 at 02:46:40PM -0800, Mark Millard via freebsd-arm wrot= e: >On 2021-Nov-30, at 09:50, tech-lists wrote: Thank you Mark, your advice put me in the right direction! I went with this version: >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-= CURRENT-arm64-aarch64-RPI-20211125-3ede04c78c7-251054.img.xz >[pi4] >hdmi_safe=3D1 >But I'm modifying it to: > >[pi4] >#hdmi_safe=3D1 >Note the disabling of hdmi_safe=3D1 . Yes, this allowed it to boot. I was then able to proceed as planned to make it zroot-on-ufs thanks, --=20 J. --Sql8a8bxU1wLSbeJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGmwkoACgkQs8o7QhFz NAXY8w/8CrnqDcqsCdqkriYgb5oCRqrKiW75ejRu+GaXD7t7oKRlQ4B2PYfkXLZN apaVUjZvutpVS0mSpOBQPmzipG/BOBgpSXVnVSlj8n1wb6n+zE/1dMgx+5bgCnSt AVmp+UyhImkrbFAPRugPC+CQlwMNbvUjNCAjdaEwRLLnId0JNpM9s/GTLESSwyYn D6FmQtgaHG3qzmJ+NBXa8Kb/mJsEBY+93WipzX+4lVPiRK3qQmD316leDy4pOYOb L47Q8lRK0Xq8gc+DaduTsYeRlW/IKfD+4pu3h3a6RaVTT4jn7T8hIJxfRAOz/i38 bA8oXXmQ11Zm+csHR3p5/mA34ZiAD9MD82jzJXXhH1jUJLdNbFv3fQU1XATN0+gA 5FvuSG8oIbBZMhoyNyg6M5oY0LmIEzZEQuAKiCLZqkD9gc3Hgjh90bDbimnB++XQ qgb4QGb8YtuMN2CgCv4Q5QwetVGGB3mPwlZAX0ie2mtesTHX5NVmpcTcVz8WLLkw +Fy0WaDegjTTQEvLCpB1fekJyCVZTIn68kV8K6QfzBYxQlbnelx9UvzZRQCmqI0+ /T4dV0C7Nfzppuhs5MwpEeUUc9jU4jSHGHlttIdbrKo9CpV9x4loq12VnTRchIPr FsABGGEVylBtMBEcftWalLD5f0A0ksJ9PZqiK+XjeyjJEXSQles= =Dh5e -----END PGP SIGNATURE----- --Sql8a8bxU1wLSbeJ-- From nobody Wed Dec 1 00:32:59 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 B3C3D18C174B for ; Wed, 1 Dec 2021 00:33:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4J3g706z1Kz3kvn for ; Wed, 1 Dec 2021 00:33:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DD3CD5C0245 for ; Tue, 30 Nov 2021 19:33:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 30 Nov 2021 19:33:32 -0500 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=fm1; bh=JyPH+T19R7af5+e+2HMwLb4Dkgu bbiJVf4znR9Fa/Mw=; b=g9bQQcQlqrLKuR5daFdj9Q1WSGSDI6I0GQHrbl7lwAL gxzMdgfKfz+c6ulDPQBNnf+H4B2hFG0kTpT2sGgGBNXuYa8XBsMIU3BHvaT8fvHY l+XpB31d1GqFF4sn689bRbhcL3jr+tAhnRsMT8++XPykxc8CDZCL1eCaWD1KzQbZ BYAOE0IcUzkP1gDNlBla4JbYYSJW3V4i9TeSkWa6uC0eJBnQJ33NdVC+N5UUl0T3 eW5etSOeSKV5Jw9HjmMOMxZbsUR+FFsMtlMSP04BRgmHqfVT8msZfvfXtda/DcCj PDUXjNTZ1hfOtQaZvTlNXk0654Inqa7L8iPm7+U2RJA== 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=fm1; bh=JyPH+T 19R7af5+e+2HMwLb4DkgubbiJVf4znR9Fa/Mw=; b=Q3y74ARSMJW12YGknWC67B wf9ZLSDPytrursxWEtga0Ci6nKXSB5GRITXZoRYxuG7D4ArM7ni35G1ZeJAKDwCJ azI2bt/2QkJsHfkqxR4iGJyQWhIvs5+OaZmVStpBeNZcrAo9nyJgmVOqqOcDqAud NZ3bTodjAAHyIUcKEOr1zVyrhHFfbqaCaeRO72jvOX01OL+LZ85S6TIQPsvZW20A OawTVd8zEtrVJHehkQBJi1K71rC/mmWAhNghwi0WaKJZ4aU0bOXwnVVZ7AD2v9ba ZpyCajVzAsiiZa1XibfPk7CddneBtG8yONX+DGC+JHd8C+6q4fTvHknLOXuVLQjA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedvgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 30 Nov 2021 19:33:32 -0500 (EST) Date: Wed, 1 Dec 2021 00:32:59 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: booting recent rpi current/14 snapshots Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <55EF15D1-4121-4F12-8167-353C52D3F72F@yahoo.com> 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="O7LEG6K0KFAWKikX" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J3g706z1Kz3kvn X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=g9bQQcQl; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Q3y74ARS; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.26) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; 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)[-0.998]; DMARC_NA(0.00)[zyxst.net]; 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:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from] X-ThisMailContainsUnwantedMimeParts: N --O7LEG6K0KFAWKikX Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 01, 2021 at 12:31:15AM +0000, tech-lists wrote: >proceed as planned to make it zroot-on-ufs agggh! zroot-on-USB3 lol! --=20 J. --O7LEG6K0KFAWKikX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGmwrsACgkQs8o7QhFz NAULPg/9H9JZT8vI4ZgV3AfYClHmMGWfPqakwt3oE8VaebT/peJ58iRhNAJFPt1Z KWTN1IZzCg/iWHyx67PEjCe5qWkEnEYLqp+oHQ9B/wUyoJEowDYOBzICirYgYwbQ AQJ1je8HkMuCxJkkxN4NRFQKacZyl2vzH8jdHXBDW1dclcMooZi8nMJ/DS9vc5Kj yMd+thvTL1FlNDjRtTRMHrOzSS/FR/+MA8FZ/DKFloF84WEqlZeArcIerD5l9YZB SO/i+lJ6FGLCjvYPpOpK48NONvO7WH43L8/HgyCzwygKCfo3TY5APggvux0ODmzt nVrv/wVseuWd4dkTiQSzw9oNlNYR1UD8CLYNLmR/NZmXDa14w6tjcANX7hVsFxNC alBqSIk1Mx4SAn4xV6e9bMP8fYvx+LyTO7TXgWwkJbPPYZ4Xdzv5gOe+CRT0RpEh 7Zl/fIwMl4/ecbYXAY3mq64k61IUD9AfjbVgb4GQG0HRK275PcKUSS/Fall4TXej ryZsgf8d4ymZEdEl5PDlFPqegxOT+fjo/xUon5Vw58OdoavgnxJzKbk8MATVj3Mk mM+JGrxdBeJDvPrAIazE1DpTEQjnloX3VDYeB8slpJp3kz1Aacetv27ckbCxevWs iB6O9QVt6qMCZXPgl8m5oBnKFH5ckrZn3m7glIsTUmL/C11YvqI= =cdis -----END PGP SIGNATURE----- --O7LEG6K0KFAWKikX-- From nobody Wed Dec 1 11:39:17 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 A80A618BD2D8 for ; Wed, 1 Dec 2021 11:39:49 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4J3xvn3nDcz3Br5 for ; Wed, 1 Dec 2021 11:39:49 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id E662D4E663; Wed, 1 Dec 2021 11:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1638358759; bh=aThAiU0T7+uXNKqmJvh51lEsNQRbPqMHqy0CwDcHzDM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=s0YqVTAWGizuXtDj/P/FFcvAjjETe2isQkRYixqKjdYdLMxSN88LtfAZ/7KWaEsr6 mAKFlVpkzt6QQMQKAZqfojX/JhPVNcslK37jdLQe5dwWuuvDXmqCf+jNcDhM+GTDBe HaloZGf5Oh8bxKm+XDl2Mhc+V/GgSdYLsdytd0LeIZ8jpXjOOvNiBP3jbKPA06wF8/ OwVw3g4hqJca+Mf8CuHciRIX2svpOnHmYnlNbhrISUh5xEnZ7XLbjYfmbXKSLuuUrU WUi8JMKXAzGCvgyoSelGSeIfeYjp+qLXjQl5TBUNoso1wgfmAcWOxhqNentLPOM5Te 31F3k0xRy/7csTpXpSxtYCN+j5hNxw54onRLcvhSsHKlER8g/LPp2VM249NOfTg0g8 Grk1lgYVRO4cYAWkkJ5gotwKugYlQkO7pmKoPgdmomnoPY72C5Y7vF4WL43h2huBqh EwhOwhH5IGqPwtYz7birPbDIX8ZMJLtXnS9drbN6L+m+3bivttW9zvf57HEBMUeAEW bwf0HFJhJtCp+QP+TlEJH+OtVtIVu1hjgz73Jcdh22nTCunzMQpBYpYxkBmHPxvtZ5 deuyRVXOUQijabGuYcFnn6iDPzjg2r3JVrSnDfZxRpsvrFA1c+M9Wzz38MhZXQpz+b 7U8GjNvhTWPJitfYzb6owbt8= Content-Type: text/plain; charset=utf-8 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 12.4 \(3445.104.21\)) Subject: Re: 14-CURRENT Kernel Panic due to USB hub? From: Andrew Turner In-Reply-To: Date: Wed, 1 Dec 2021 11:39:17 +0000 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.104.21) X-Rspamd-Queue-Id: 4J3xvn3nDcz3Br5 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 30 Nov 2021, at 21:37, Hans Petter Selasky wrote: >=20 > On 11/30/21 18:21, Andrew Turner wrote: >>> On 30 Nov 2021, at 14:34, Hans Petter Selasky = wrote: >>>=20 >>> On 11/30/21 15:16, Andrew Turner wrote: >>>>> On 30 Nov 2021, at 12:35, Hans Petter Selasky = wrote: >>>>>=20 >>>>> On 11/30/21 13:22, Andrew Turner wrote: >>>>>> I bisected the detached messages back to 601ee53858f6 [1]. If I = revert this change I no longer see this on the console. >>>>>> I am also unable to reproduce the panic with this change = reverted. As the panic can be difficult to reproduce I am unsure if = reverting this change is enough to fix it, or if it=E2=80=99s just = making it less likely to be triggered. >>>>>> Andrew >>>>>> [1] https://cgit.freebsd.org/src/commit/?id=3D601ee53858f6 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Could you verify that you are not running out of kernel stack? >>>> I can still trigger it after doubling the kernel stack size. >>>>>=20 >>>>> May this be due to some code in the .text segment which is not = properly aligned? >>>> I would expect to have seen the issue on other HW. The issue looks = more like it=E2=80=99s memory corruption. >>>>>=20 >>>>> If you compile and load USB as modules, does the panic go away? >>>> I am unable to trigger it after removing xhci from the kernel, and = did get a panic after loading the xhci module. >>>> The xhci controller is one that originated in Broadcom. Linux has a = quirk for it to work around an erratum where attaching a USB 1 device = followed by a USB 2 device the linker the latter will come up as USB 1. = They reset the phy when anything less than USB 3 on a disconnect event. >>>=20 >>> And there is no BIOS / UEFI code still running on that XHCI = controller? >> I would expect the UEFI code to not be accessing the XHCI controller = after exiting the loader. >> Andrew >=20 > Hi, >=20 > Could you try to kldload xhci instead of building it into the kernel = config? Maybe you get a different kind of panic that way. I have. I=E2=80=99m hitting the KASSERT at [1]. Looking at the memory = around td->td_pcb->pcb_fpflags makes me think the memory has been = trashed as there are bits set that could never be so in the flags = fields, and kernel pointer values that point to user memory. Andrew [1] = https://cgit.freebsd.org/src/tree/sys/arm64/arm64/trap.c?id=3D6e9309bd3b04= 501b69593900a14e01114c7f2404#n627 From nobody Wed Dec 1 16:32:37 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 DC21A18B9B64 for ; Wed, 1 Dec 2021 16:32:50 +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 4J44Pt4fh9z3tjm for ; Wed, 1 Dec 2021 16:32:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A57ED2601CA; Wed, 1 Dec 2021 17:32:42 +0100 (CET) Message-ID: Date: Wed, 1 Dec 2021 17:32:37 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US To: Andrew Turner Cc: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J44Pt4fh9z3tjm 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 12/1/21 12:39, Andrew Turner wrote: > I have. I’m hitting the KASSERT at [1]. Looking at the memory around td->td_pcb->pcb_fpflags makes me think the memory has been trashed as there are bits set that could never be so in the flags fields, and kernel pointer values that point to user memory. > > Andrew > > [1]https://cgit.freebsd.org/src/tree/sys/arm64/arm64/trap.c?id=6e9309bd3b04501b69593900a14e01114c7f2404#n627 > Hi, Could you also dump: td->td_name Exactly which thread is this? We do have a user-space build for XHCI at stand/usb/test . It won't attach, but maybe there is some compiler warning there? Did you try do build a kernel with -O0 I.E. no optimization options? --HPS