Description: qemu process will quit because of the system_reset command after run iofuzz test in guest. Error message: (qemu) vdi_port_io_map: base 0xc040 size 0x10 (qemu) vdi_port_ram_map: addr 0xc1000000 size 0x10000 (qemu) ram_map: addr 0xc4000000 size 0x4000000 (qemu) vram_map: addr 0xc8000000 size 0x1000 (qemu) rom_map: addr 0xc8002000 size 0x2000 (qemu) ioport_map: base 0xc050 size 0x8 (qemu) BIOS panic at rombios.c, line 8985 (qemu) interface_audio_fini: (qemu) interface_change_notifier: remove VD_INTERFACE_PLAYBACK (qemu) interface_change_notifier: remove VD_INTERFACE_RECORD (qemu) (Process terminated with status 1) Version-Release number of selected component (if applicable): kernel: 2.6.18-269.el5 kvm&qemu: kvm-83-238.el5 How reproducible: Once Steps to Reproduce: 1.Run iofuzz in guest https://github.com/autotest/autotest/blob/master/client/virt/tests/iofuzz.py 2. Reset the guest when it has no response with system_reset in monitor (qemu)system_reset Actual results: qemu quit Expected results: Guest should resboot normally Additional info: /usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/qemu -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20110625-213914-dRwz',server,nowait -serial unix:'/tmp/serial-20110625-213914-dRwz',server,nowait -drive file='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/images/RHEL-4.9-64-virtio.qcow2',index=0,if=virtio,media=disk,cache=none,boot=on,format=qcow2 -net nic,vlan=0,model=virtio,macaddr='9a:6d:d5:f3:dc:82' -net tap,vlan=0,ifname='t0-213914-dRwz',script='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 33792 -smp 8,cores=1,threads=1,sockets=8 -cpu qemu64,+sse2 -soundhw ac97 -spice port=8000,disable-ticketing -qxl 1 -rtc-td-hack -M rhel5.6.0 -boot c -usbdevice tablet -no-kvm-pit-reinjection
Joy, Was there corruption? Can you run this guest after the "crash"? Can you please try it also with a raw file? Fresh qcow2 is known to be slow in RHEL5. Thanks.
(In reply to comment #1) > Joy, > Was there corruption? Can you run this guest after the "crash"? > Can you please try it also with a raw file? Fresh qcow2 is known to be slow in > RHEL5. > Thanks. Hi Ronen, I think there is no corruption in guest, after this case the qemu-img check is OK. And guest can be boot up for the following tests. I run the test case with raw file, but so far all of the failed was quit in the random write and don't show any panic info from the monitor. It is the same situation with qcow2 image. Most of the tests is failed in random write quit, but not the reset quit, the BIOS panic is not easy to reproduce.
Closing, since it looks like a known performance problem of slow write on a fresh QCOW2 file in RHEL5.