<div dir="ltr">Very nice on the sleuthing! <div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 14, 2017 at 5:16 AM, Anderson, Dave <span dir="ltr"><<a href="mailto:daveanderson@wsu.edu" target="_blank">daveanderson@wsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">List moderator: feel free to delete my previous large message with attachments that's in the moderation queue...it's now obsolete anyway.<br>
<br>
<br>
I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 + Kernel 4.9.13:<br>
<br>
Once I finally got serial output all the way through the boot process (xen+dom0) I discovered the stack trace:<br>
<br>
[Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0 APIC: 7<br>
installing Xen timer for CPU 8<br>
[Firmware Bug]: CPU8: APIC id mismatch. Firmware: 0 APIC: 20<br>
smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.<br>
------------[ cut here ]------------<br>
kernel BUG at arch/x86/kernel/cpu/common.c:<wbr>997!<br>
invalid opcode: 0000 [#1] SMP<br>
Modules linked in:<br>
CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.13-22.el7.x86_64 #1<br>
Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015<br>
random: fast init done<br>
task: ffff880058a8c4c0 task.stack: ffffc900400b4000<br>
RIP: e030:[<ffffffff8103e527>]  [<ffffffff8103e527>] identify_secondary_cpu+0x57/<wbr>0x80<br>
RSP: e02b:ffffc900400b7f08  EFLAGS: 00010086<br>
RAX: 00000000ffffffe4 RBX: ffff88005d80a020 RCX: ffffffff81c5be68<br>
RDX: 0000000000000001 RSI: 0000000000000005 RDI: 0000000000000005<br>
RBP: ffffc900400b7f18 R08: 00000000000000cb R09: 0000000000000004<br>
R10: 0000000000000000 R11: 0000000000000006 R12: 0000000000000008<br>
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br>
FS:  0000000000000000(0000) GS:ffff88005d800000(0000) knlGS:0000000000000000<br>
CS:  e033 DS: 002b ES: 002b CR0: 0000000080050033<br>
CR2: 0000000000000000 CR3: 0000000001c07000 CR4: 0000000000042660<br>
Stack:<br>
 0000000000000008 0000000000000000 ffffc900400b7f28 ffffffff8104e94e<br>
 ffffc900400b7f40 ffffffff81029925 0000000000000000 ffffc900400b7f50<br>
 ffffffff810299a0 0000000000000000 0000000000000000 0000000000000000<br>
Call Trace:<br>
 [<ffffffff8104e94e>] smp_store_cpu_info+0x3e/0x40<br>
 [<ffffffff81029925>] cpu_bringup+0x35/0x90<br>
 [<ffffffff810299a0>] cpu_bringup_and_idle+0x20/0x40<br>
Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 bb da 00 00 00 44 89 e6 e8 24 03 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 0f b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 98 87 a6 81<br>
RIP  [<ffffffff8103e527>] identify_secondary_cpu+0x57/<wbr>0x80<br>
 RSP <ffffc900400b7f08><br>
---[ end trace dc5563100443876e ]---<br>
<br>
I surmised that reducing the number of dom0 vcpu might solve this issue (they were unbounded)<br>
<br>
In testing adding "dom0_max_vcpus=4 dom0_vcpus_pin" to the GRUB_CMDLINE_XEN_DEFAULT line in /etc/defaults/grub and re-running grub2-mkconfig has resulted in the system I have that never booted Xen 4.6.3-12 + Kernel 4.9.13, booting every single time out of 5-10 tests.<br>
<br>
<br>
So...I don't know if there's a race condition somewhere, or what...but...so far this workaround has not failed me.<br>
<br>
Thanks,<br>
-Dave<br>
<br>
<br>
<br>
> On Fri, Apr 7, 2017 at 6:58 AM, PJ Welsh <pjwelsh at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a><br>
<span class="im HOEnZb">>> wrote:<br>
>> I've not gotten any bites from my posting on the xen-devel mailing list.<br>
>> Here is the only one to-date:<br>
>> <a href="https://lists.xen.org/archives/html/xen-devel/2017-04/msg01069.html" rel="noreferrer" target="_blank">https://lists.xen.org/<wbr>archives/html/xen-devel/2017-<wbr>04/msg01069.html</a><br>
>><br>
>> From that email, there needs to be some hypervisor messages.<br>
>><br>
>> Does anyone know how to produce the hypervisor messages? I've already<br>
><br>
>> removed the rhgb and quiet options from the boot.<br>
><br>
>><br>
>> Thanks<br>
>> PJ<br>
><br>
><br>
> I spoke too soon. To get more information: Please see<br>
><br>
> <a href="https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project" rel="noreferrer" target="_blank">https://wiki.xenproject.org/<wbr>wiki/Reporting_Bugs_against_<wbr>Xen_Project</a><br>
><br>
> and<br>
><br>
> <a href="https://wiki.xenproject.org/wiki/Xen_Serial_Console" rel="noreferrer" target="_blank">https://wiki.xenproject.org/<wbr>wiki/Xen_Serial_Console</a><br>
><br>
> or alternatively at least add "vga=keep".<br>
><br>
> pjwelsh<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
CentOS-virt mailing list<br>
<a href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-virt" rel="noreferrer" target="_blank">https://lists.centos.org/<wbr>mailman/listinfo/centos-virt</a><br>
</div></div></blockquote></div><br></div>