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

["Steve Prochniak" <sprochniak@xxxxxxxxxxxxxxx>]

Andrew - you can run the "Novell Shim" which makes the hypervisor
conform to the Microsoft spec enough that the guest OSs will turn off
watchdog timeouts (0x101 BSoDs)...

Steve

-----Original Message-----
From: Andrew Lyon [mailto:andrew.lyon@xxxxxxxxx] 
Sent: Monday, January 05, 2009 3:24 PM
To: Steve Prochniak; Xen-Devel (E-mail); xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: BSOD "A clock interrupt was not recevied
onasecondary processor within the allocated time interval"

On Mon, Jan 5, 2009 at 7:25 PM, Steve Prochniak
<sprochniak@xxxxxxxxxxxxxxx> wrote:
> All Microsoft 6.0 and beyond Operating Systems have a sense of
> 'enlightment' which means they try to talk to the underlying
hypervisor
> - and if there is one, they do certain things like turn off 101
> bugchecks.  The only real way to get Vista and beyond to work
correctly
> with SMP is to make Xen conform to Microsoft's hypervisor spec.

I vaguely recall there being a way to make xen "lie" to the OS about
the type of hypervisor, it might only be a feature on the commercial
citrix xenserver?

So basically there is no way to run Windows Vista or 2008 on Xen
without risk of a 101 BSOD under load?

If that is true then its a severe problem and Xen is useless for newer
MS OS's :(

Has anybody else had this problem and found a solution?

Andy


>
> -----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
>

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