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

[Steven Smith <steven.smith@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.
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@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

Attachment: signature.asc
Description: Digital signature

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