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

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@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andrew
Lyon
> Sent: Friday, January 02, 2009 1:34 PM
> To: xen-users@lists.xensource.com; 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@gmail.com>
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel