Bug 719299 - System_reset make qemu quit after randomly write /dev/port
Summary: System_reset make qemu quit after randomly write /dev/port
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.7
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
Depends On:
Blocks: Rhel5KvmTier2
TreeView+ depends on / blocked
Reported: 2011-07-06 11:47 UTC by Joy Pu
Modified: 2011-07-27 12:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-27 12:10:50 UTC

Attachments (Terms of Use)

Description Joy Pu 2011-07-06 11:47:48 UTC
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):

How reproducible:

Steps to Reproduce:
1.Run iofuzz in guest
2. Reset the guest when it has no response with system_reset in monitor

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

Comment 1 Ronen Hod 2011-07-17 15:32:30 UTC
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.

Comment 2 Joy Pu 2011-07-27 11:42:57 UTC
(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.

Comment 3 Ronen Hod 2011-07-27 12:10:50 UTC
Closing, since it looks like a known performance problem of slow write on a fresh QCOW2 file in RHEL5.

Note You need to log in before you can comment on or make changes to this bug.