From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: Xen 4.2.1 boot failure with IOMMU enabled Date: Tue, 12 Feb 2013 10:20:35 -0500 Message-ID: <511A5DC3.4010106@oracle.com> References: <7d6022b9-fff5-4cca-b091-347d3e869909@default> <511A224A02000078000BDA7B@nat28.tlf.novell.com> <511A2FA402000078000BDAF7@nat28.tlf.novell.com> <511A33F302000078000BDB2B@nat28.tlf.novell.com> <511A35C402000078000BDB47@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <511A35C402000078000BDB47@nat28.tlf.novell.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: Jan Beulich Cc: povder , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 02/12/2013 06:29 AM, Jan Beulich wrote: >>>> On 12.02.13 at 12:22, "Jan Beulich" wrote: >>>>> On 12.02.13 at 12:15, povder wrote: >>> 2013/2/12 Jan Beulich : >>>> With the above, the patch is unlikely to address your problem, >>>> but will likely provide better debugging output. So please >>>> nevertheless try building with that patch included, assuming >>>> the problem first started after you built Xen from a recent >>>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which >>>> case the problem is obviously unrelated to the recent changes >>>> I'm thinking of). >>>> >>> I haven't built Xen myself, I use binaries from >>> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess >>> that builds in this repository are from plain 4.2.1. >>> xl info (when I boot with iommu disabled) shows: >>> xen_major : 4 >>> xen_minor : 2 >>> xen_extra : .1 >>> >>> I just started using Xen when 4.2.1 already was released so this >>> problem appeared to me from the beginning. I can try with 4.2-testing >>> though. >> No, there's no point I'm afraid. We really need to analyze the >> debugging output to first understand what's missing. > All there is for bus 7 is > > (XEN) AMD-Vi: IVHD Device Entry: > (XEN) AMD-Vi: Type 0x2 > (XEN) AMD-Vi: Dev_Id 0x700 > (XEN) AMD-Vi: Flags 0x0 > > i.e. a single device at 07:00.0, yet from the register dump at the > crash it's fairly clear that we're talking about 07:00.1 here. I'm > afraid only a firmware update can help you here (or passing > "iommu=off" to Xen); in particular I can't see how we could work > around that problem in software. I don't see any devices on bus 7 in lspci output (http://pastebin.com/raw.php?i=3wpKPQT9 from original report). However the log shows pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' .. (XEN) PCI add device 0000:07:00.0 -boris