Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#49773 - [linux] 4.6.x KVM: entry failed, hardware error 0x80000021
Attached to Project:
Arch Linux
Opened by Joseph Knockenhauer (JoeLithium) - Sunday, 19 June 2016, 22:34 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 04 October 2017, 13:05 GMT
Opened by Joseph Knockenhauer (JoeLithium) - Sunday, 19 June 2016, 22:34 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 04 October 2017, 13:05 GMT
|
DetailsRunning a libvirt/qemu machine for about 10 mintues this error arises on the following hardware
i5 6600K Asrock z170 Extreme4 32 Gigs of Corsair DDR4 @ 2400 GTX 980ti I'm not sure if this is hardware related: Steps to reproduce: create a libvirt virtual machine using qemu backend. After a little while the following will happen in the machine's virtlog: KVM: entry failed, hardware error 0x80000021 If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. RAX=fffff801f7a3e410 RBX=0000000000000000 RCX=ffffffffffd0a000 RDX=0000000000000000 RSI=0000000000000000 RDI=ffffda863e97dca0 RBP=ffff800026f10f90 RSP=ffff800026f10f08 R8 =ffff800026f11410 R9 =0000000000000000 R10=7ffff801f752d858 R11=7ffffffffffffffc R12=0000000000000000 R13=ffff800026f11410 R14=000000000000001c R15=fffff801f752d800 RIP=fffff801f7a3e421 RFL=00010082 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] CS =0010 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA] SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] FS =0053 00000000626c8000 00007c00 0040f300 DPL=3 DS [-WA] GS =002b ffff80001f1f0000 ffffffff 00c0f300 DPL=3 DS [-WA] LDT=0000 0000000000000000 ffffffff 00000000 TR =0040 ffff80001f1f6ac0 00000067 00008b00 DPL=0 TSS64-busy GDT= ffff80001f1fdb80 0000006f IDT= ffff80001f1fdbf0 00000fff CR0=80050033 CR2=0000000000000030 CR3=0000000322596000 CR4=001506f8 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000fffe0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=00 00 00 48 8b 0d e1 64 03 00 c7 81 b0 00 00 00 00 00 00 00 cc cc cc cc cc cc 0f 1f 84 00 00 00 00 00 b9 0b 08 00 00 33 c0 33 d2 0f 30 c3 cc cc cc possibly a regression of a previous bug in the linux kernel |
This task depends upon
For anyone else who runs into this problem.
Thanks for the help, I suppose that this can be closed.