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

[Peter Jeremy]

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.

>> 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.

-- 
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/cf86be16/attachment.sig>