Summary: | Panic on booting 12 on Jetway JNF9HG | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Christian Ullrich <chris> | ||||
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Closed Not A Bug | ||||||
Severity: | Affects Some People | CC: | abob, emaste, janm, roel | ||||
Priority: | --- | Keywords: | regression | ||||
Version: | 12.0-STABLE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Christian Ullrich
2018-11-26 15:44:51 UTC
Data point: Same behavior with 12-RC3. Ugh. Found it. The hardware needs "efi.rt.disabled" set, that's all. I just spent two days bisecting around, and at some point I became aware of this tunable, except in that commit it was still called "efi.rt_disabled", with an underscore. I then obviously missed when it was renamed in r336924, and that invalidated the bisect results. Anyway, with the variable set, and correctly spelled, releng/12.0 boots perfectly fine. I'm glad you've found a workaround, although we should really fix the underlying issue (at least adding a quirk to disable it automatically). I thought, since the option is documented in UPDATING, that it was meant to be this way. Should I open a new bug for creating this quirk specifically for my hardware? I confirm exactly the same problem. Motherboard with J1900 CPU. FreeBSD-12.0-RELEASE-amd64. Try on 2019-Feb-21 FreeBSD-12.0-STABLE-amd64 and FreeBSD-13.0-CURRENT-amd64. With same result. Workaround work for me: add to /boot/loader.conf efi.rt.disabled=1 The proposed workaround did not work for me. Boot still freezes at the same point, kernel never loads. I've rolled back to 11.2-RELEASE. Other bugs with seem to be describing exactly the same issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235017 Neither your issue nor either of the two you linked look very similar to this one. Here, the kernel loads and starts just fine, and then it crashes while initializing the hardware. In particular, your kernel apparently just freezes, i.e. stops. Mine panics, producing a backtrace. Do you have a backtrace that passes through any of the functions mine does (in frame #3 and below)? For completeness, the underlying problem is fixed in r348539. |