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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx> 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@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> <mailto: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> <mailto: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
  

---

_______________________________________________
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