From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?H=c3=a5kon_Alstadheim?= Subject: Re: [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163 Date: Fri, 15 Jan 2016 13:32:52 +0100 Message-ID: <5698E6F4.4050703@alstadheim.priv.no> References: <5698D0C1.6000808@alstadheim.priv.no> <5698D297.8030700@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <5698D297.8030700@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/15/2016 12:05 PM, Andrew Cooper wrote: > On 15/01/16 10:58, H=E5kon Alstadheim wrote: >> This is just a preliminary report, mostly just for the record. >> >> I will report again if this keeps happening after 4.7 is out, or upon >> request. Anyone working on this, please mail me and request more >> information. I have available logs from dom0 boot (I dump dmesg and xl >> dmesg to disk after every boot, and log dom0 serial console to disk). >> I will send boot logs if requested. I will turn on maximum verbosity >> and provide all output. My serial console is very slow, so I can not >> keep running at max verbosity all the time. >> >> At the end of this mail there is "xl info" and output from dom0 serial >> console. >> >> CPUINFO: >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 63 >> model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz >> >> # smbios-sys-info >> Libsmbios version: 2.2.28 >> Product Name: Z10PE-D8 WS >> Vendor: ASUSTeK COMPUTER INC. >> BIOS Version: 3101 >> >> Dom0 OS: >> Linux gentoo 4.1.12-gentoo #1 SMP Sat Jan 2 09:36:31 CET 2016 x86_64 >> Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz GenuineIntel GNU/Linux. >> Kernel is gentoo-sources, with experimental use-flag. Cpu type set to >> Haswell. Issue also happened without experimental. >> # cat /proc/cmdline >> placeholder root=3DLABEL=3Dssdroot ro >> xen-pciback.hide=3D(02:00.*)(08:00.*)(00:1b.*)(81:00.*)(82:00.*)(83:00.*= ) console=3Dhvc0 >> console=3Dvga domodules domdadm dolvm intel_iommu=3Don earlyprintk=3Dxen >> usbcore.autosuspend=3D-1 >> >> The system is mostly built with stable packages, xen and xen-tools >> keyworded to ~amd64. >> >> I have been experiencing issues with domains with passed through PCIe >> devices since I first installed xen. Then at version 4.5.x , I'm now >> at 4.6.0 with gentoo patches. Crashes SEEM mostly related to this pci >> pass through and interrupts (usb-cards, sound cards). >> >> Recently the system has been more stable, whether it is because I pass >> through as few things as possible, or because of improvements in Xen I >> do not know. I have also taken to building with debug, which leads to >> more abrupt but less mysterious failures. Earlier (w/o debug and under >> xen 4.5 ) stuff would just gradually stop working and end up in total >> hang of everything. So, hey, things are improving :-b > This isn't the first time we have seen this on Haswell processors. Do > you have microcode loading set up? Not entirely sure to be honest. Is microcode : 0x31 the newest? I AM running the very latest bios from Asus, but I do not have = confidence in my microcode loading setup, so I have not had one in place. Trying now. Downloading microcode.dat from Intel Installing iucode_tool, which in its --help states: -w, --write-to=3Dfile Write selected microcodes to a file in bina= ry format. The binary format is suitable to be uploaded to the kernel Ran "iucode_tool microcode.dat -w microcode.bin" ---- # ls -l micro* -rwxr-xr-x 1 root root 693248 Jan 15 12:40 microcode.bin -rwxr-xr-x 1 root root 2081807 Nov 6 04:04 microcode.dat ---- placed microcode.bin in /boot/microcode.bin booted with : --- xen_commandline : ssd-xen-debug-marker console_timestamps=3Ddate = loglvl=3Dall guest_loglvl=3Dall sync_console iommu=3D1,verbose,debug = iommu_inclusive_mapping=3D1 com1=3D115200,8n1 console=3Dcom1 dom0_max_vcpus= =3D4 = dom0_vcpus_pin=3D1 dom0_mem=3D8G,max:8G cpufreq=3Dxen:performance,verbose = tmem=3D1 sched_smt_power_savings=3D1 apic_verbosity=3Ddebug e820-verbose=3D= 1 = core_parking=3Dpower ucode=3Dmicrocode.bin --- #cat /proc/cpuinfo | grep micro says: microcode : 0x31 This is no change from previous boot. Now: How do I know wheter 0x31 is the newest? Grepping the console output reveals no reference to ucode or microcode = other than the Xen command-line. --- H=E5kon