From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Kinzler Subject: Re: Instability with Xen, interrupt routing frozen, HPET broadcast Date: Thu, 30 Sep 2010 12:16:55 +0200 Message-ID: <4CA46397.2060206@hfp.de> References: <4C88A6F3.9020207@hfp.de> <20100921115604.GP2804@reaktio.net> <4CA38093.9070802@hfp.de> <4CA39898.8080304@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080701070004030100000001" Return-path: In-Reply-To: <4CA39898.8080304@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Keir Fraser , JBeulich@novell.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------080701070004030100000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 29.09.2010 21:50, Jeremy Fitzhardinge wrote: >> It is a Supermicro X8SIL-F, Intel Xeon 3450 system. > The big problem I had initially was instability with the integrated > ethernet until I disabled PCIe ASPM. The symptom was that the ethernet > devices would disappear (ie, their PCI config space would start to read > all 0xff...) I know that this is a known problem of Intel 82574L chips (on X8SIL) - it is discussed on "Intel Wired Ethernet" (http://sourceforge.net/projects/e1000/). That is why I tested different NICs (Intel ET Server Adapter (82576 [igb]) and Realtek 8168) and the problem remained. So I can say with certainty that the NIC and/or its power management is not the problem. I also spend extensive time changing hardware components. I used a different mainboard (ASUS P7F-M), a different power supply, changed CPU, changed NICs (see above) - problems remained. > That's exactly what my main test/devel machine is. It has been very > stable for me with xen-unstable. We have a second Supermicro X8SIL-F, Intel Xeon 3450 system which only runs Linux PVM domains and it is totally stable (without my HPET patch). So I think as with all timing/race/deadlock/... issues it depends on what you do on your system. Let me give you my crash "recipe" [quite reliable ;-)] Have two HVMs (called win1, win2) with Windows 7 x64 installed (do install everything twice, never clone, VM config attached). Install GPLPV 0.11.0.213, iometer 2006.07.27, prime95 25.11 x64. On both systems: start prime95 torture test (in-place large FFT) and using Windows task manager set CPU affinity on win1 of process prime95 to use only CPU1. On win2 do the same thing but to use only CPU0. Then start iometer on both VMs using the following parameters: have a second virtual disk in both VMs (so every windows has 2 virtual disks, one for Windows and one for iometer), use "# of outstanding I/Os" = 4, access spec = "All in one". Wait some minutes. Crash! Regards Andreas --------------080701070004030100000001 Content-Type: text/plain; name="win1.hvm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="win1.hvm" # -*- mode: python; -*- #============================================================================ # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. #============================================================================ 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 in MB memory = 2048 # A name for your domain. All domains must have different names. name = "win1" # The number of cpus guest platform has, default=1 vcpus=2 # List of which CPUS this domain is allowed to use, default Xen picks #cpus = "" # leave to Xen to pick #cpus = "0" # all vcpus run on CPU0 #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5 #cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 #cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 # network card #vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=e1000' ] vif = [ 'type=ioemu, model=e1000' ] # HDD/cdrom #disk = [ 'tap2:tapdisk:aio:/dev/sda9,hda,w', 'tap2:tapdisk:aio:/root/win7.iso,hdc:cdrom,r' ] disk = [ 'tap2:tapdisk:aio:/dev/sda9,hda,w', 'tap2:tapdisk:aio:/dev/sda10,hdc,w' ] #---------------------------------------------------------------------------- # Configure the behaviour when a domain exits. There are three 'reasons' # for a domain to stop: poweroff, reboot, and crash. For each of these you # may specify: # # "destroy", meaning that the domain is cleaned up as normal; # "restart", meaning that a new domain is started in place of the old # one; # "preserve", meaning that no clean-up is done until the domain is # manually destroyed (using xm destroy, for example); or # "rename-restart", meaning that the old domain is not cleaned up, but is # renamed and a new domain started in its place. # # In the event a domain stops due to a crash, you have the additional options: # # "coredump-destroy", meaning dump the crashed domain's core and then destroy; # "coredump-restart', meaning dump the crashed domain's core and the restart. # # The default is # # on_poweroff = 'destroy' # on_reboot = 'restart' # on_crash = 'restart' # #on_poweroff = 'preserve' #on_reboot = 'preserve' #on_crash = 'preserve' #============================================================================ # Device Model to be used device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm' #----------------------------------------------------------------------------- # boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d) # default: hard disk, cd-rom, floppy boot="dc" vnc=1 vnclisten="0.0.0.0" vncdisplay=0 vncunused=0 vncpasswd='' stdvga=0 serial='pty' localtime=1 # in der Sommerzeit -7200 sonst -3600 rtc_timeoffset=-7200 viridian=1 keymap='de' usbdevice='tablet' --------------080701070004030100000001 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080701070004030100000001--