Peter Jeremy
2020-Jul-20 21:20 UTC
svn commit: r362848 - in stable/12/sys: net netinet sys
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>
Konstantin Belousov
2020-Jul-20 21:47 UTC
svn commit: r362848 - in stable/12/sys: net netinet sys
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.