Description of problem:
KVM crashes when booting an MS-DOS 6.22 guest on an Intel host. This happens inside SeaBIOS; apparently SeaBIOS puts the hardware in a state KVM can't handle.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create an MS-DOS 6.22 boot disk
2. Boot it.
kvm: unhandled exit 80000021
kvm_run returned -22
"info registers" in the Qemu console shows that the error happens inside SeaBIOS, immediately after a return to real mode.
Happens with both hard disk and floppy disk images. No config.sys or autoexec.bat needed in the guest.
CPU information (x4 cores x2 threads):
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 940 @ 2.93GHz
stepping : 4
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 5853.09
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
Note: "Plain" Qemu handles the same thing fine.
(qemu) info registers
EAX=00000010 EBX=00000008 ECX=e0100000 EDX=00000508
ESI=00000020 EDI=e0100020 EBP=00000008 ESP=000004d4
EIP=0000f4a7 EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 0000f300
CS =f000 000f0000 0000ffff 0000f300
SS =8e01 0008e010 0000ffff 0000f300
DS =8ec9 0008ec96 0000ffff 0000f300
FS =0000 00000000 0000ffff 0000f300
GS =0000 00000000 0000ffff 0000f300
LDT=0000 00000000 0000ffff 00008200
TR =0000 feffd000 00002088 00008b00
GDT= 0008ec66 0000002f
IDT= 000f8560 00000000
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
Which version of seabios is this using?
Looking through the register dump, one thing that stands out to me is that ds_base is not 16-byte aligned - that is probably the part that makes KVM reject the state.
can you test if latest seabios from git://git.linuxtogo.org/home/kevin/seabios.git works?
Tested it, it works.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.