Bug 719299 - System_reset make qemu quit after randomly write /dev/port
System_reset make qemu quit after randomly write /dev/port
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.7
Unspecified Linux
low Severity medium
: rc
: ---
Assigned To: Virtualization Maintenance
Virtualization Bugs
:
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2011-07-06 07:47 EDT by Joy Pu
Modified: 2011-07-27 08:10 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-27 08:10:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joy Pu 2011-07-06 07:47:48 EDT
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
Comment 1 Ronen Hod 2011-07-17 11:32:30 EDT
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.
Comment 2 Joy Pu 2011-07-27 07:42:57 EDT
(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 08:10:50 EDT
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.