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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.07.13 at 12:17, Ben Guthro <ben.guthro@xxxxxxxxx> wrote:
> On Jul 10, 2013, at 5:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> 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?

Just sent a patch to that effect.

> 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)

There's no magic here: Disassemble xen-syms, and work your way
through the raw stack dump.

Jan


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