Re: [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@eikelenboom.it>]

Monday, August 26, 2013, 5:50:41 PM, you wrote:

>>>> On 26.08.13 at 17:37, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> wrote:
>> On 8/26/2013 6:36 AM, Sander Eikelenboom wrote:
>>>> >So as already suspected HPET and IVRS tables conflict with one
>>>> >another in the IDs used for the (apparently) single HPET in the
>>>> >system.
>>> Yes that was wat i meant with another firmware glitch, masking the fact that 
>> your fix seems actually ok.
>>>
>> I have seen many issues with the IVRS table regarding IOAPIC. This is 
>> the first time I see with the HPET, in which case, your patch simply So, 
>> my understanding is the patch still does not solve the issue where the 
>> IVRS and HPET table has conflicts here.  This means we should also have 
>> the override mechanism for the HPET entry of the IVRS (i.e. the variety 
>> 2 as well)?

> Except that the override as is (coming from Linux) won't help afaict,
> as it assumes that at least the ID is correct (and uses the ID to
> associate the rest of the information with the right instance). Let
> me get finished with the first draft of the ported over workaround
> (hopefully tomorrow), and then we should discuss if/how to deal
> with Sander's problem. But we shouldn't forget that he already
> found out that enabling HPET MSI on his system isn't desirable due
> to other errata, so in a way I'm inclined to leave this specific
> unaddressed, thus not risking him to run into further problems
> (with the patch sent earlier at least the stalls he saw went away,
> albeit not in the way that was intended to happen).

Well i don't know that for sure, since serial port etc seems to be handelt by a super i/o chip, and not directly by the southbridge ?


Running with HPET MSI enabled now for the rest of the today .. serial console enabled .. haven't seen any other issues so far.
Linux seems to also provide a way to not only override these special case faults in these tables, but to even completely overrule complete acpi-tables from initrd.

Albeit having it fixed by a bios update would be the best, but MSI seems quite ignorant to requests to fix it.
(first it wasn't supported by the chipset (and hence no bios option even present), then it was supported by the chipset, but not by them since it was a server feature in there mind, and after that a deafening silence)

Which is a shame because the board is actually stable and has a nice amount of pci-e slots and a dual nic.



> Jan