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

["Andrew Lyon" <andrew.lyon@xxxxxxxxx>]

On Mon, Jan 5, 2009 at 9:51 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 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@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