Bug 719299

Summary: System_reset make qemu quit after randomly write /dev/port
Product: Red Hat Enterprise Linux 5 Reporter: Joy Pu <ypu>
Component: kvmAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.7CC: juzhang, mkenneth, rhod, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-27 12:10:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 580948    

Description Joy Pu 2011-07-06 11:47:48 UTC
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 15:32:30 UTC
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 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.