[Xen-devel] Re: RE: Re: BSOD "A clock interrupt was not recevied onasecondary processor within the allocated time interval"

["James Song" <jsong@xxxxxxxxxx>]

yes, the cause of BSOD 0x101 is that watchdog time interrupt was not received by the vcpu in a certain timeout in Windows kernel . this is taken place especially in vista kernel. Generally speaking, we have some ways to fix this, one is that we an write a programme whitch can intercept the trigger of BSOD 0x101, on the other word, we make kernel don't care the watchdog time interrrupt. the second way, we try make vcpu of windows get more physical cpu slice which can make window take watchdog time interrupt back from io-apic when vmexit happened.
   In my view, optimize the scheduler and io process and irq injects process can make BSOD 0x101 reduced mostly.

thanks.
-- Song Wei

>
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Andrew
Lyon
> Sent: Friday, January 02, 2009 1:34 PM
> To: xen-users@xxxxxxxxxxxxxxxxxxx; Xen-Devel (E-mail)
> Subject: [Xen-devel] Re: BSOD "A clock interrupt was not recevied
> onasecondary processor within the allocated time interval"
>
> On Mon, Dec 29, 2008 at 9:32 AM, Andrew Lyon <andrew.lyon@xxxxxxxxx>
> wrote:
>> Hi,
>>
>> When dom0 is under heavy load any Vista or Windows 2008 HVM's that
are
>> running and have multiple cpu's assigned often BSOD with code
>> 0x00000101 "A clock interrupt was not recevied ona secondary
>> processor within the allocated time interval"
>>
>> It only happens if the load in dom0 is high enough to make the mouse
>> pointer lagged, once the mouse fails to track in realtime the hvm's
>> start to bsod within a few seconds.
>>
>> I have tried several versions of Xen including 3.2, 3.3 and 3.3.1
rc4,
>> and various kernels including the 2.6.18 xensource and 2.6.27-xen.hg.
>>
>> Here is a example config from one of my vista hvms, is there a
>> timer/rtc setting that I need to add to avoid this problem?
>>
>> import os, re
>> arch = os.uname()[4]
>> if re.search('64', arch):
>> arch_libdir = 'lib64'
>> else:
>> arch_libdir = 'lib'
>> kernel = "/usr/lib/xen/boot/hvmloader"
>> builder='hvm'
>> memory = 2048
>> name = "Vistax86"
>> uuid = "b7bd2f2f-169f-4789-8aee-eaa77c543c99"
>> vcpus=8
>> vif = [ 'mac=00:16:3e:7d:bc:b1' ]
>> disk = [ 'phy:/dev/vg_raptor/lv_vistax86,hda,w', ',hdc:cdrom,r' ]
>> device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
>> boot="d"
>> sdl=0
>> vnc=1
>> vnclisten="127.0.0.1"
>> vncdisplay=11
>> vncpasswd='vv8176a'
>> stdvga=0
>> serial='pty'
>> usbdevice='tablet'
>>
>
cpuid=['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,ebx=xxxxxxxx00010000xxxxx
> xxxxxxxxxxx','4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx']
>> keymap='en-gb'
>>
>> Andy
>>
>
> I think this is a known issue which has incorrectly been marked as
> FIXED in bugzilla:
>
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1117
>
> there is a second bug report of the same problem, this time with more
> details:
>
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1065
>
> Is there a fix?
>
> Andy
>
> _______________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel