On 2020-Jul-21 00:47:23 +0300, Konstantin Belousov <kostik...@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 <kostik...@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
signature.asc
Description: PGP signature
