svn commit: r362848 - in stable/12/sys: net netinet sys

[Konstantin Belousov]

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:
> >> I'm sending this to -stable, rather than the src groups because I
> >> don't believe the problem is the commit itself, rather the commit
> >> has uncovered a latent problem elsewhere.
> >> 
> >> On 2020-Jul-01 18:03:38 +0000, Michael Tuexen <tuexen at FreeBSD.org> wrote:
> >> >Author: tuexen
> >> >Date: Wed Jul  1 18:03:38 2020
> >> >New Revision: 362848
> >> >URL: https://svnweb.freebsd.org/changeset/base/362848
> >> >
> >> >Log:
> >> >  MFC r353480: Use event handler in SCTP
> >> 
> >> I have no idea how, but this update breaks booting amd64 for me (r362847
> >> works and this doesn't).  I have a custom kernel with ZFS but no SCTP so I
> >> have no real idea how this could break booting - presumably the
> >> eventhandler change has uncovered a bug somewhere else.
> >> 
> >> 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.

> 
> >> Does anyone have any ideas?
> >
> >Did you checked that the physical devices where your ZFS pool is located,
> >are detected, and that kernel messages for their drivers are as usual ?
> >Overall, is there anything strange in the verbose dmesg ?
> 
> There's nothing obviously strange (in particular, I can see the physical
> boot/root disk) but the faulty kernel appears to have moved the msgbuf
> somewhere unexpected so it's not saved across reboots and I'm limited to
> eyeballing the messages via DDB.
> 
> 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 ?

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.