svn commit: r324109 - in head: sys/contrib/dev/acpica sys/contrib/dev/acpica/common sys/contrib/dev/acpica/compiler sys/contrib/dev/acpica/components/dispatcher sys/contrib/dev/acpica/components/ha...

[Cy Schubert]

In message <20170930161624.GK95911 at kib.kiev.ua>, Konstantin Belousov writes:
> On Sat, Sep 30, 2017 at 05:42:55PM +0300, Andriy Gapon wrote:
> > On 30/09/2017 15:04, Konstantin Belousov wrote:
> > > On Sat, Sep 30, 2017 at 10:58:41AM +0000, Li-Wen Hsu wrote:
> > >> On Fri, Sep 29, 2017 at 23:02:49 +0000, Jung-uk Kim wrote:
> > >>> Author: jkim
> > >>> Date: Fri Sep 29 23:02:49 2017
> > >>> New Revision: 324109
> > >>> URL: https://svnweb.freebsd.org/changeset/base/324109
> > >>>
> > >>> Log:
> > >>>   Merge ACPICA 20170929.
> > >>>
> > >>> Added:
> > >>>   head/sys/contrib/dev/acpica/compiler/aslallocate.c
> > >>>      - copied, changed from r324104, vendor-sys/acpica/dist/source/comp
> iler/aslallocate.c
> > >>
> > >> Hi Jung-uk,
> > >>
> > >> After this change, the test machine booting in bhyve panics with this
> > >> message:
> > >>
> > >>   panic: acpi: timer op not yet supported during boot
> > >>
> > >> Could you help to check what happened here?  The full boot log can be
> > >> found here:
> > >>
> > >>   https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4496/console
> > >>
> > > 
> > > This happens for me on the real hardware as well.
> > > 
> > > SMP: passed TSC synchronization test
> > > Timecounter "TSC" frequency 2095144854 Hz quality 1000
> > > random: entropy device external interface
> > > io: <I/O>
> > > nfslock: pseudo-device
> > > mem: <memory>
> > > null: <full device, null device, zero device>
> > > nexus0
> > > random: harvesting attach, 8 bytes (4 bits) from ram0
> > > acpi0: <ALASKA A M I > on motherboard
> > > ACPI: 4 ACPI AML tables successfully acquired and loaded
> > > panic: acpi: timer op not yet supported during boot
> > 
> > Seems like it's triggered by the code that's supposed to limit execution ti
> me of
> > loops.
> > 
> After your comment I thought that this is another case of an update requiring
> EARLY_AP_STARTUP option, but apparently the kernel config on this box does
> contain it already.

I have disabled EARLY_AP_STARTUP (due to an issue in a local bge WOL patch, 
which I have yet to resolve). My kernel boots, so EARLY_AP_STARTUP is 
likely not involved.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.