svn commit: r362848 - in stable/12/sys: net netinet sys
Peter Jeremy
peter at rulingia.com
Tue Jul 21 10:31:47 UTC 2020
On 2020-Jul-21 00:47:23 +0300, Konstantin Belousov <kostikbel at gmail.com> wrote:
>On Tue, Jul 21, 2020 at 07:20:44AM +1000, Peter Jeremy wrote:
>> On 2020-Jul-19 14:48:28 +0300, Konstantin Belousov <kostikbel at gmail.com> 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 for 3 more seconds
>> >> Mounting from zfs:zroot/ROOT/r363310 failed with error 6
>> >>
>> >> (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).
>> >>
>> >> 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).
>>
>> 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=1
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.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20200721/1a9390fb/attachment.sig>
More information about the freebsd-stable
mailing list