[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Steve Prochniak" <sprochniak@xxxxxxxxxxxxxxx>
  • From: "Andrew Lyon" <andrew.lyon@xxxxxxxxx>
  • Date: Mon, 5 Jan 2009 22:07:52 +0000
  • Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 05 Jan 2009 14:08:31 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LFUipcWvnafuMJB3GIgBgpYYAaA8MAt/kwvqV3uT/Gc9ne/ywKNDFcgmtDGe2rU9f1 uM/sPbzNgEcAJqrIT1jhJeG/DzD7Djf5xfhMj8tb9ZEiJu4eIcBR6Lg/s8a3UJd329eH lg/XL6lAvKvgKWy91+F0T52UQklDOkZLoLtCc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Mon, Jan 5, 2009 at 8:55 PM, Steve Prochniak
<sprochniak@xxxxxxxxxxxxxxx> 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@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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.