From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Guthro Subject: Re: 4.3 regression in booting on a particular platform Date: Wed, 10 Jul 2013 06:17:56 -0400 Message-ID: <1638737482981250100@unknownmsgid> References: <51DC29D602000078000E390C@nat28.tlf.novell.com> <51DD40D202000078000E3C51@nat28.tlf.novell.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51DD40D202000078000E3C51@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: Ben Guthro , xen-devel List-Id: xen-devel@lists.xenproject.org On Jul 10, 2013, at 5:09 AM, Jan Beulich wrote: >>>> On 09.07.13 at 18:34, Ben Guthro wrote: >> On Tue, Jul 9, 2013 at 9:18 AM, Jan Beulich wrote: >>>>>> On 09.07.13 at 14:55, Ben Guthro wrote: >>>> While this is pre-release hardware from an OEM, it did work on 4.2, so >>>> I am not (yet) inclined to blame it on being pre-release hardware. >>>> >>>> This is very early in boot, and so does not have a proper stack. >>>> Do you have any thoughts as to where this might be going awry? >>> >>> If you could make the xen-syms available matching the xen.gz that >>> was used when the below log was obtained, I could try to take a >>> look. >>> >>> Perhaps repeating the attempt with "iommu=debug" could reveal >>> further useful details. >> >> I have put xen.gz, the xen-syms, and an updated boot log, with >> iommu=debug at the following location that you may download: >> https://citrix.sharefile.com/d/safbf0b05aac4233a > > This > > (XEN) [VT-D]dmar.c:767: Host address width 39 > (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD: > (XEN) [VT-D]dmar.c:461: dmaru->address = 0 > > is clearly a BIOS bug, and I don't see how 4.2 would get along > with that. It may fail in different ways, but that's not directly > related to how ioremap() is implemented. > > That said, the changeset you pointed at uncovered an always > existing bug in the VT-d code: The mapping of the IOMMU MMIO > register space is being established through map_to_nocache_virt() > (resolving to set_fixmap_nocache()), but iommu_free() calls > iounmap() to undo it (which prior to said changeset wasn't > doing anything). > > Bottom line - this box wants to be booted with "iommu=off" until > you have a fixed BIOS. It would be better if we could detect such a buggy bios, and continue to boot without iommu capability, rather than crash, no? Thank you for the analysis. Is there a wiki page, or the like that might give me a pointer on how to do this analysis for myself in the future, so as not to bother you? (Eg, how to work with Xen-syms) > > Jan >