From owner-freebsd-stable@freebsd.org Tue Jul 21 10:31:47 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C005737E5B6 for ; Tue, 21 Jul 2020 10:31:47 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B9vz56VLmz4RZj for ; Tue, 21 Jul 2020 10:31:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 06LAVZNh080059 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jul 2020 20:31:40 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 06LAVTLL083291 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2020 20:31:29 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 06LAVTPg083290; Tue, 21 Jul 2020 20:31:29 +1000 (AEST) (envelope-from peter) Date: Tue, 21 Jul 2020 20:31:29 +1000 From: Peter Jeremy To: Konstantin Belousov Cc: freebsd-stable@freebsd.org Subject: Re: svn commit: r362848 - in stable/12/sys: net netinet sys Message-ID: <20200721103129.GA58157@server.rulingia.com> References: <202007011803.061I3cTs089322@repo.freebsd.org> <20200719112102.GA15535@server.rulingia.com> <20200719114828.GD44314@kib.kiev.ua> <20200720212044.GA55887@server.rulingia.com> <20200720214723.GP44314@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20200720214723.GP44314@kib.kiev.ua> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 4B9vz56VLmz4RZj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-4.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.053]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.018]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.07)[-0.070]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 10:31:47 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jul-21 00:47:23 +0300, Konstantin Belousov wr= ote: >On Tue, Jul 21, 2020 at 07:20:44AM +1000, Peter Jeremy wrote: >> On 2020-Jul-19 14:48:28 +0300, Konstantin Belousov = wrote: >> >On Sun, Jul 19, 2020 at 09:21:02PM +1000, Peter Jeremy wrote: >> >> The symptoms are that I get: >> >> Mounting from zfs:zroot/ROOT/r363310 failed with error 6; retrying fo= r 3 more seconds >> >> Mounting from zfs:zroot/ROOT/r363310 failed with error 6 >> >>=20 >> >> (r363310 is where I was trying to update to and I didn't change the BE >> >> name as I was searching for the problem and error 6 is ENXIO). >> >>=20 >> >> I tried to reproduce the problem with GENERIC but it hangs after >> >> displaying the EFI framebuffer information (I've seen that before and >> >> suspect it is a loader problem but haven't dug into it). >>=20 >> I've confirmed that particular problem is bug 209821. I've disabled >> EFI and GENERIC r362848 boots and runs successfully. >Did you mis-typed the PR number ? The referenced bug talks about very >early hang, while your report said that kernel boots up to the point of >mounting root. My failure was with a custom kernel. Once I narrowed the problem to a commit that seemed unrelated to my problem, I tried to boot a GENERIC kernel at r362848. The GENERIC kernel boot failed much earlier due to the EFI problem documented in PR 209821. When I disabled EFI, then the GENERIC kernel worked, showing that my problem was due to my custom kernel. >> Since GENERIC worked, I did some more experimenting and tracked the >> problem down to a lack of "options ACPI_DMAR" in my kernel config. >> That makes more sense, though I have no idea why it suddenly became >> mandatory for my system. >No, this does not make too much sense either, since DMAR is disabled >by default. Did you enabled it ? "options ACPI_DMAR" has been in GENERIC since you first submitted the DMAR code was in r257251. I haven't ever set the hw.dmar.enable=3D1 loader tunable but it's not at all obvious that a kernel built without "options ACPI_DMAR" is functionally equivalent to a kernel that has DMAR compiled in but disabled - there's a lot of IOMMU manipulation code that is purely conditional on ACPI_DMAR. That said, I'm not using virtualisation and haven't actually enabled DMAR in the loader so I suspect that I've only masked the real issue. I currently have INVARIANTS and WITNESS but will look into some of the more extensive debugging options. (It looks like I missed the addition of "options ACPI_DMAR" when I was updating my custom kernel config with the differences between r250963 and r259512 about 8 years ago, and it hasn't caused any obvious problems until now. Obviously, I need to do a more careful review of my custom kernel config against GENERIC/NOTES). >BTW, you are using stable, right ? There were some code reorganization >commits in HEAD moving DMAR code around, but they were not merged to >stable. I'm using 12-STABLE. --=20 Peter Jeremy --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl8Ww/tfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLJ//Q/+Oi96z1m8+AZVVuUJIdmINkWuxJJUqXBrsXZVPLZqlDNM5E3UbLq1VdmZ JpnFgeXX2Y93vF+p4lFc28rQTaXkHXHvFKvDKNdF45LlkHD/AhnrHzd/mtZW1IuX GotQgkqSLHs8thhS88kCh6Y0ZmFV3gYqwiWa5hdhWYi06VEz45ukUflc9dlsxb54 cYYYCi/999rdqZ9o0m+aR84M3XMBJoLeVDxFNVykplDmLATGLFw6igqlbXD52hCK KJ92pzmB0ia51cGr3tK0SDBzFfLe0Xirf/K6k8xN0Y/GUxVOcrvMYHW5m1V7hk/U +jP2qtp4yps8AboyYb0B4JCylFFIMiqMsHURuK5uMgPLrdyjIau717Hor606KK94 uDb6OA/zX/TZxGANYQAJWfdZJ3r9skDxzLuZYl1Ql9AVYICRGxmKScz0+IU7VJHz wDzEbydc/yvg4KPdewJPFmxCkypplZOL2y7SrOyAPenhTXmxlNOvez3GChBooIp4 Giu5zNVAI+YrVnyI2ORLbJSa1yKK4rixFl+zKhzK2qnFz+lUbRpJJ8y9mICGDi+q 1PKHOaqweaczCcg0enCLs2Wlie7FntbNldxxwPSU5/PPbJ6AxL4S4OZNmlwFQ0ke bXo0pxY79t30Ga4cI5O98FuR9+NisyG1nO7puIDVK8kpcnNqzDE= =ow9x -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW--