Re: [Xen-devel] 4.3 regression in booting on a particular platform

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.07.13 at 18:34, Ben Guthro <ben@xxxxxxxxxx> wrote:
> On Tue, Jul 9, 2013 at 9:18 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 09.07.13 at 14:55, Ben Guthro <ben@xxxxxxxxxx> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel