Red Hat Bugzilla – Bug 860687
BSOD A clock interrupt was not received on a secondary processor within the allocated time interval
Last modified: 2013-01-09 20:09:33 EST
Created attachment 617561 [details]
Sos report BSOD
Description of problem:
Users have had this just having kvm open and opening an excel file in symphony installed on the linux client.
This is rendering users unable to work reliable.
I am seeing people crash 2 or 3 times a day with BSOD. High cpu utilization, freezes for 2-5 minutes and the BSOD.
A clock interrupt was not received on a secondary processor within the allocated time interval I have seen it in 6.3
with latest patches.
This problem most often occurs when there is memory pressure on the host which causes either swap or forced eviction from the page cache.
Version-Release number of selected component (if applicable):
Host RHEL 6.3
Guest Windows XP or Windows 7.
Would you please provides the qemu-kvm commandline, you can get the command via "ps -aux | grep qemu-kvm", if you are using virtio-win driver, please provide the virtio-win driver version as well, thanks.
Windows 7 64
vdagent/vdservice 20120625 – 0.1-11
List of services running.
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64>net start
These Windows services are started:
AT&T Global Network Client Logging Service
AT&T Network Configuration Service
Base Filtering Engine
COM+ Event System
DCOM Server Process Launcher
Desktop Window Manager Session Manager
Diagnostic Policy Service
Diagnostic Service Host
Diagnostic System Host
Distributed Link Tracking Client
Function Discovery Resource Publication
Group Policy Client
IBM Standard Asset Manager Service
IKE and AuthIP IPsec Keying Modules
IPsec Policy Agent
Microsoft .NET Framework NGEN v4.0.30319_X64
Microsoft .NET Framework NGEN v4.0.30319_X86
Network List Service
Network Location Awareness
Network Store Interface Service
Plug and Play
Program Compatibility Assistant Service
Remote Access Connection Manager
Remote Procedure Call (RPC)
RHEV Spice Agent
RPC Endpoint Mapper
Secure Socket Tunneling Protocol Service
Security Accounts Manager
Shell Hardware Detection
SPP Notification Service
Symantec Endpoint Protection
Symantec Event Manager
Symantec Management Client
Symantec Settings Manager
System Event Notification Service
TCP/IP NetBIOS Helper
User Profile Service
Windows Audio Endpoint Builder
Windows Driver Foundation - User-mode Driver Framework
Windows Event Log
Windows Font Cache Service
Windows Management Instrumentation
WinHTTP Web Proxy Auto-Discovery Service
The command completed successfully.
/usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu SandyBridge,+osxsave,+tsc-deadline,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 -name Virtual_Client_for_Linux_KVM_Windows_7_KVM -uuid dad87ece-89c0-4640-ae72-ba12b6b91d34 -smbios type=0,vendor=LENOVO,version=8BET58WW (1.38 ),date=07/06/2012,release=1.38 -smbios type=1,manufacturer=LENOVO,product=4282A37,version=ThinkPad W520,serial=R9M5KG7,sku=Not Specified,family=ThinkPad W520 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Virtual_Client_for_Linux_KVM_Windows_7_KVM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x8 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x8.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x8.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/Virtual_Client_for_Linux_KVM_Windows_7_KVM.raw,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:03:b6:80,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charchannel0 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=arbitrary.virtio.serial.port.name -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2,bus=usb.0,port=5 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3,bus=usb.0,port=6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
This is probably a dup of:
Is it worth trying with the fix for bug 842211?
(In reply to comment #8)
> Is it worth trying with the fix for bug 842211?
Yes, but if host is really so overcommited that it starts swapping out guest memory it will most likely be no help. The real solution is to not overcommit host memory or do it with ksm and balooning and start to migrate guest out of the server long before host swap kicks in. Even if we will make Windows disable this watchdog with hyper-v relaxed timing the VM will not be usable if its memory is swapped out. Not with current disks speed.
This looks to me like the problem that should be solved in management. Management should not allow swapping to happen.
Swapping is a temporary problem. Once the event causing memory pressure ends, a normal process would continue functioning as expected.
A BSOD is a permanent failure that is only recoverable by rebooting the VM. Hyper-v relaxed timing would at least allow the VM to continue functioning as expected after the memory pressure event ends.
(In reply to comment #10)
> Swapping is a temporary problem. Once the event causing memory pressure
> ends, a normal process would continue functioning as expected.
> A BSOD is a permanent failure that is only recoverable by rebooting the VM.
> Hyper-v relaxed timing would at least allow the VM to continue functioning
> as expected after the memory pressure event ends.
Yes, no argument here, but neither should happen. "Freezes for 2-5 minutes" is not much better than BSOD. How much the host is overcommited (in terms of memory and cpu)?
BTW -cpu parameter in comment 6 looks funny, is it libvirt generated? If not what are you trying to accomplish with it? Most of the added option will not be used and rest will make VM unmigratable between different host cpus and/or different RHEL versions.
Comment 6 - yes it is libvirt generated. If Red Hat think this may cause an issue why does it get added, it should be removed.
Vadim re-assures it's a dup of BZ #801196, closing and will continue there.
*** This bug has been marked as a duplicate of bug 801196 ***