Xen devel - Dec 2008 - BSOD "A clock interrupt was not recevied ona secondary processor within the allocated time interval"

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=xxxxxxxx00010000xxxxxxxxxxxxxxxx'',''4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx'']
keymap=''en-gb''

Andy

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

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=xxxxxxxx00010000xxxxxxxxxxxxxxxx'',''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-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, Jan 5, 2009 at 7:25 PM, Steve Prochniak
<sprochniak@virtualiron.com> 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@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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@gmail.com] 
Sent: Monday, January 05, 2009 3:24 PM
To: Steve Prochniak; Xen-Devel (E-mail); xen-users@lists.xensource.com
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@virtualiron.com> 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@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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

This was never accepted by upstream Xen, as originally submitted by Ky
from Novell:

original submission:
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html



Steve Prochniak wrote on 01/05/2009 03:55 PM:
> 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@gmail.com] 
> Sent: Monday, January 05, 2009 3:24 PM
> To: Steve Prochniak; Xen-Devel (E-mail); xen-users@lists.xensource.com
> 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@virtualiron.com> 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@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
>>
>>     
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

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

Alternative Viridian interface support was checked in. When enabled, it
ought to be sufficient to disable these bugchecks. Œviridian=1¹ needs to be
specified in the domain config file.

 -- Keir

On 05/01/2009 21:32, "Ben Guthro" <bguthro@virtualiron.com>
wrote:
> This was never accepted by upstream Xen, as originally submitted by Ky from
> Novell:
> 
> original submission:
> http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html
> 
> 
> 
> Steve Prochniak wrote on 01/05/2009 03:55 PM:
>>  
>> 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@gmail.com]
>> Sent: Monday, January 05, 2009 3:24 PM
>> To: Steve Prochniak; Xen-Devel (E-mail); xen-users@lists.xensource.com
>> 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@virtualiron.com>
<mailto:sprochniak@virtualiron.com>  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@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>
>>> <mailto: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
>>> 
>>>     
>>>  
>>  
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>   
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

On Mon, Jan 5, 2009 at 8:55 PM, Steve Prochniak
<sprochniak@virtualiron.com> wrote:
> 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
Happy to give it a try, where can I obtain it?
>
> -----Original Message-----
> From: Andrew Lyon [mailto:andrew.lyon@gmail.com]
> Sent: Monday, January 05, 2009 3:24 PM
> To: Steve Prochniak; Xen-Devel (E-mail); xen-users@lists.xensource.com
> 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@virtualiron.com> 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@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
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jan 5, 2009 at 9:51 PM, Keir Fraser <keir.fraser@eu.citrix.com>
wrote:
> Alternative Viridian interface support was checked in. When enabled, it
> ought to be sufficient to disable these bugchecks.
''viridian=1'' needs to be
> specified in the domain config file.
Keir,

Are you sure that the code was checked in? I am running 3.3.1 rc4 but
adding that setting didnt seem to help,  grep -r "viridian"
/usr/lib64/python2.5/site-packages/xen finds nothing, searching for
other config keywords in that folder they are always found in several
files...

Andy

>
>  -- Keir
>
> On 05/01/2009 21:32, "Ben Guthro" <bguthro@virtualiron.com>
wrote:
>
> This was never accepted by upstream Xen, as originally submitted by Ky from
> Novell:
>
> original submission:
> http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html
>
>
>
> Steve Prochniak wrote on 01/05/2009 03:55 PM:
>
> 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@gmail.com]
> Sent: Monday, January 05, 2009 3:24 PM
> To: Steve Prochniak; Xen-Devel (E-mail); xen-users@lists.xensource.com
> 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@virtualiron.com>
<mailto:sprochniak@virtualiron.com>  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@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>
> <mailto: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
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> ________________________________
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/01/2009 09:34, "Andrew Lyon" <andrew.lyon@gmail.com>
wrote:
> On Mon, Jan 5, 2009 at 9:51 PM, Keir Fraser
<keir.fraser@eu.citrix.com> wrote:
>> Alternative Viridian interface support was checked in. When enabled, it
>> ought to be sufficient to disable these bugchecks.
''viridian=1'' needs to be
>> specified in the domain config file.
> 
> Keir,
> 
> Are you sure that the code was checked in? I am running 3.3.1 rc4 but
> adding that setting didnt seem to help,  grep -r "viridian"
> /usr/lib64/python2.5/site-packages/xen finds nothing, searching for
> other config keywords in that folder they are always found in several
> files...
Ah, it''s in xen-unstable only. Not in 3.3.

 -- Keir



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

> Alternative Viridian interface support was checked in. When enabled, it
> ought to be sufficient to disable these bugchecks. Œviridian=1¹ needs to be
> specified in the domain config file.
Hmm...  In order for the Viridian stuff to actually solve this
problem, you need to set the relaxed-timers bit.  It doesn''t look like
the xen-unstable implementation does so.  Something like this might
help:

diff -r f6b92526e916 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Tue Jan 06 09:14:39 2009 +0000
+++ b/xen/arch/x86/hvm/viridian.c	Tue Jan 06 10:32:26 2009 +0000
@@ -37,6 +37,7 @@
 
 /* Viridian CPUID 4000004, Implementation Recommendations. */
 #define CPUID4A_MSR_BASED_APIC  (1 << 3)
+#define CPUID4A_RELAX_TIMER_INT_HANDLING (1 << 5)
 
 int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
                           unsigned int *ebx, unsigned int *ecx,
@@ -84,7 +85,7 @@
         if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
              (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4) )
             break;
-        *eax = CPUID4A_MSR_BASED_APIC;
+        *eax = CPUID4A_MSR_BASED_APIC | CPUID4A_RELAX_TIMER_INT_HANDLING;
         *ebx = 2047; /* long spin count */
         break;
     }

But note that I haven''t tested this *at all*.

Steven.

> On 05/01/2009 21:32, "Ben Guthro" <bguthro@virtualiron.com>
wrote:
> 
> > This was never accepted by upstream Xen, as originally submitted by Ky
from
> > Novell:
> > 
> > original submission:
> >
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html
> > 
> > 
> > 
> > Steve Prochniak wrote on 01/05/2009 03:55 PM:
> >>  
> >> 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@gmail.com]
> >> Sent: Monday, January 05, 2009 3:24 PM
> >> To: Steve Prochniak; Xen-Devel (E-mail);
xen-users@lists.xensource.com
> >> 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@virtualiron.com>
<mailto:sprochniak@virtualiron.com>  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@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>
> >>> <mailto: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
> >>> 
> >>>     
> >>>  
> >>  
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >>   
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

This is very similar to the patch we have on top of the original Novell stuff.

Steve Ofsthun was digging through the new viridian.c code at the end of the day
yesterday to see if this bit was set. This fix below should do the same thing.



-----Original Message-----
From: Steven Smith [mailto:steven.smith@eu.citrix.com]
Sent: Tue 1/6/2009 5:39 AM
To: Keir Fraser
Cc: Ben Guthro; Steve Prochniak; Andrew Lyon; Xen-Devel (E-mail);
xen-users@lists.xensource.com
Subject: Re: [Xen-devel] Re: BSOD "A clock interrupt was not recevied
onasecondary processor within the allocated time interval"
 
> Alternative Viridian interface support was checked in. When enabled, it
> ought to be sufficient to disable these bugchecks. Oviridian=1¹ needs to be
> specified in the domain config file.
Hmm...  In order for the Viridian stuff to actually solve this
problem, you need to set the relaxed-timers bit.  It doesn''t look like
the xen-unstable implementation does so.  Something like this might
help:

diff -r f6b92526e916 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Tue Jan 06 09:14:39 2009 +0000
+++ b/xen/arch/x86/hvm/viridian.c	Tue Jan 06 10:32:26 2009 +0000
@@ -37,6 +37,7 @@
 
 /* Viridian CPUID 4000004, Implementation Recommendations. */
 #define CPUID4A_MSR_BASED_APIC  (1 << 3)
+#define CPUID4A_RELAX_TIMER_INT_HANDLING (1 << 5)
 
 int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
                           unsigned int *ebx, unsigned int *ecx,
@@ -84,7 +85,7 @@
         if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
              (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4) )
             break;
-        *eax = CPUID4A_MSR_BASED_APIC;
+        *eax = CPUID4A_MSR_BASED_APIC | CPUID4A_RELAX_TIMER_INT_HANDLING;
         *ebx = 2047; /* long spin count */
         break;
     }

But note that I haven''t tested this *at all*.

Steven.

> On 05/01/2009 21:32, "Ben Guthro" <bguthro@virtualiron.com>
wrote:
> 
> > This was never accepted by upstream Xen, as originally submitted by Ky
from
> > Novell:
> > 
> > original submission:
> >
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00630.html
> > 
> > 
> > 
> > Steve Prochniak wrote on 01/05/2009 03:55 PM:
> >>  
> >> 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@gmail.com]
> >> Sent: Monday, January 05, 2009 3:24 PM
> >> To: Steve Prochniak; Xen-Devel (E-mail);
xen-users@lists.xensource.com
> >> 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@virtualiron.com>
<mailto:sprochniak@virtualiron.com>  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@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>
> >>> <mailto: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
> >>> 
> >>>     
> >>>  
> >>  
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >>   
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

Steven Smith wrote:
>> Alternative Viridian interface support was checked in. When enabled, it
>> ought to be sufficient to disable these bugchecks. Œviridian=1¹ needs
to be
>> specified in the domain config file.
> Hmm...  In order for the Viridian stuff to actually solve this
> problem, you need to set the relaxed-timers bit.  It doesn''t look
like
> the xen-unstable implementation does so.  Something like this might
> help:
> 
> diff -r f6b92526e916 xen/arch/x86/hvm/viridian.c
> --- a/xen/arch/x86/hvm/viridian.c	Tue Jan 06 09:14:39 2009 +0000
> +++ b/xen/arch/x86/hvm/viridian.c	Tue Jan 06 10:32:26 2009 +0000
> @@ -37,6 +37,7 @@
>  
>  /* Viridian CPUID 4000004, Implementation Recommendations. */
>  #define CPUID4A_MSR_BASED_APIC  (1 << 3)
> +#define CPUID4A_RELAX_TIMER_INT_HANDLING (1 << 5)
>  
>  int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
>                            unsigned int *ebx, unsigned int *ecx,
> @@ -84,7 +85,7 @@
>          if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
>               (d->arch.hvm_domain.viridian.guest_os_id.fields.os < 4)
)
>              break;
> -        *eax = CPUID4A_MSR_BASED_APIC;
> +        *eax = CPUID4A_MSR_BASED_APIC | CPUID4A_RELAX_TIMER_INT_HANDLING;
>          *ebx = 2047; /* long spin count */
>          break;
>      }
> 
> But note that I haven''t tested this *at all*.
That appears to work. I have a test setup where I can introduce an 
arbitrary delay in qemu-dm. It''s easy to trigger bug check 0x101 in 
Windows 2008 that way. Using viridian=1, with the relaxed timer bit set, 
I have been unable to crash Windows 2008.

Looks like a good thing to commit.

- Frank

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

On Wed, Jan 7, 2009 at 5:42 PM, Frank van der Linden
<Frank.Vanderlinden@sun.com> wrote:
> Steven Smith wrote:
>>>
>>> Alternative Viridian interface support was checked in. When
enabled, it
>>> ought to be sufficient to disable these bugchecks. Œviridian=1¹
needs to
>>> be
>>> specified in the domain config file.
>>
>> Hmm...  In order for the Viridian stuff to actually solve this
>> problem, you need to set the relaxed-timers bit.  It doesn''t
look like
>> the xen-unstable implementation does so.  Something like this might
>> help:
>>
>> diff -r f6b92526e916 xen/arch/x86/hvm/viridian.c
>> --- a/xen/arch/x86/hvm/viridian.c       Tue Jan 06 09:14:39 2009 +0000
>> +++ b/xen/arch/x86/hvm/viridian.c       Tue Jan 06 10:32:26 2009 +0000
>> @@ -37,6 +37,7 @@
>>   /* Viridian CPUID 4000004, Implementation Recommendations. */
>>  #define CPUID4A_MSR_BASED_APIC  (1 << 3)
>> +#define CPUID4A_RELAX_TIMER_INT_HANDLING (1 << 5)
>>   int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
>>                           unsigned int *ebx, unsigned int *ecx,
>> @@ -84,7 +85,7 @@
>>         if ( (d->arch.hvm_domain.viridian.guest_os_id.raw == 0) ||
>>              (d->arch.hvm_domain.viridian.guest_os_id.fields.os <
4) )
>>             break;
>> -        *eax = CPUID4A_MSR_BASED_APIC;
>> +        *eax = CPUID4A_MSR_BASED_APIC |
CPUID4A_RELAX_TIMER_INT_HANDLING;
>>         *ebx = 2047; /* long spin count */
>>         break;
>>     }
>>
>> But note that I haven''t tested this *at all*.
>
> That appears to work. I have a test setup where I can introduce an
arbitrary
> delay in qemu-dm. It''s easy to trigger bug check 0x101 in Windows
2008 that
> way. Using viridian=1, with the relaxed timer bit set, I have been unable
to
> crash Windows 2008.
>
> Looks like a good thing to commit.
How do you introduce the delay? I''d like to try xen-unstable with
viridian=1 but I want to be absolutely sure that the issue is fixed so
if you have a patch for qemu-dm I''d appreciate it if you could post
it, the BSOD 101 issue causes serious problems for me because I am
using pci passthrough, I''ve found  if the domain using passthru
crashes, I issue "xm pci-detach", or "xm destroy" a domain
that is
using a passthru pci device, will cause the entire machine to lockup ,
I''ve tried Xen 3.2.1/2/3 and 3.3.0/1 with various different kernels
but it always happens, so if my Vista or 2008 domains that are using
pci passthru usb2 cards BSOD at all it takes down the entire box,
usually resulting in data loss :(

Perhaps that problem might be fixed in unstable too, I will try it
tomorrow but it would really help to have a way to trigger a bsod 101.

Thanks
Andy
>
> - Frank
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Andrew Lyon wrote:
> How do you introduce the delay? I''d like to try xen-unstable with
> viridian=1 but I want to be absolutely sure that the issue is fixed so
> if you have a patch for qemu-dm I''d appreciate it if you could
post
> it, the BSOD 101 issue causes serious problems for me because I am
> using pci passthrough, I''ve found  if the domain using passthru
> crashes, I issue "xm pci-detach", or "xm destroy" a
domain that is
> using a passthru pci device, will cause the entire machine to lockup ,
> I''ve tried Xen 3.2.1/2/3 and 3.3.0/1 with various different
kernels
> but it always happens, so if my Vista or 2008 domains that are using
> pci passthru usb2 cards BSOD at all it takes down the entire box,
> usually resulting in data loss :(
> 
> Perhaps that problem might be fixed in unstable too, I will try it
> tomorrow but it would really help to have a way to trigger a bsod 101.
I use the attached change to qemu. In cpu_handle_ioreq, if send_vcpu != 
0,, it checks for the presence of a file called /tmp/qemu_delay. If it 
exists, it opens it and reads a delay value from it. Then it sleeps for 
that duration (in microseconds).

What I do is boot windows 2008, then open an editor to edit 
/tmp/qemu_delay. From the editor, I write various values to it. An easy 
way to trigger the issue is to write a large value (say, 8000000 for 8 
seconds), wait a little while, and then write 0 to make the domain come 
back to life. It should bluescreen at this point. Sometimes the 
procedure has to be repeated a few times.

If you want to do "echo $value > /tmp/qemu_delay", you''ll
need to change
the hack to re-open the file each time, probably.

- Frank


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