Hi Zide,
I've checked all the menus and settings in our BIOS, unfortunately I couldn't find anything that looks like the mentioned setting or similar or related to it.
We are using coreboot, built according to instructions from https://software.intel.com/en-us/firmware/sites/default/files/intelatome3900-0.71-buildinstructions.txt, plus we added support for our board (the link apparently no longer works). In general it works very well.
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p: +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com <https://exorint.com/>

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Wednesday, February 12, 2020 6:47 PM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
In the meantime, is there something like "AP Thread Idle Manner" in your BIOS? And changing its setting makes any difference?
Best Regards,
Zide
On 2/12/20 8:02 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:

Hello,
Please find attached the log file and my acrn.conf.
My old BIOS didn't have any settings related to Mwait, so I've installed newer BIOS which has "Monitor Mwait Enable" and
I've ensured it's set to "Disabled". Changing the BIOS seems to have also changed some data in logs, but the overall
behavior is the same.
New acrn.efi seems to work reasonably well. Our custom board is obviously specific, but in general it is similar to
reference Leaf Hill CRB.
After the last printout from the log, everything stops working (there is nothing on the screen attached to the board and
the keyboard doesn't do anything; also typing in the serial terminal doesn't do anything).
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
w:     exorint.com <https://exorint.com/>
   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Wednesday, February 12, 2020 1:04 AM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
"Spurious vector" could because of external interrupts not registered in hypervisor. This may not be an issue and can be
ignored for now.
For the repeating "Starting VCPU 3" issue, it seems some thing related to SIPI delivery. But nothing is obvious to me and
need to debug it.
I built a Clear Linux kernel with additional logs showing how it's bringing up APs. Could you please try the attached
bzImage?
Also please enable early printk by adding "ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep" to the options in
acrn.conf; And use the attached acrn.efi (I enabled some additional logs and print out Linux logs even before ACRN console
is operational). If acrn.efi doesn't boot, which is highly possibly since it's not built against your custom board, you
may need to apply the attached patch to ACRN hypervisor.
Hopefully the full logs can give us some clues.
Best Regards,
Zide
zide.chen@...