Re: [Xen-devel] [xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times.

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Monday, August 26, 2013, 12:33:16 PM, you wrote:

>>>> On 26.08.13 at 11:51, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> Monday, August 26, 2013, 8:59:24 AM, you wrote:
>>> It also alters a bogus comparison in the original code (note the
>>> extra ! in (!msi_desc->hpet_id != hpet_sbdf.id)) - I can't see why
>>> it would have been coded that way, but double checking the
>>> output with "iommu=debug" for the absence of the respective
>>> message would be very helpful.
>> 
>> With the patch below i end up with:
>> 
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0

> So that's exactly the bogus comparison mentioned above. And
> you say that you do have working HPET MSI on the native kernel,
> without any extra overrides? I ask because I don't see any
> workarounds for apparently broken firmware like here...

> To be sure it's the firmware, could you
> - send the dump of the ACPI HPET table
> - try restoring the bogus "!"

acpidump attached ..
xl-dmesg attached ..

And restoring the bogus "!", makes the stalls go away ..
So it seems your fix is ok, but it was bailing out on another firmware glitch 
previous masked ?


> Jan

Attachment: xl-dmesg.txt
Description: Text document

Attachment: acpidump-hpet
Description: Binary data

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