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

Friday, August 23, 2013, 4:28:43 PM, you wrote:

>>>> On 23.08.13 at 00:51, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> After i got things working on baremetal Linux, i adjusted Xen and hardcoded 
>> it to add a mapping for ioapic[6]=00:14.0.
>> (the entries for ivrs_ioapic[7] and hpet[0] are actually correct in the bios 
>> tables, so they don't need correction for me at the moment)

> Are you sure about the HPET part of this? I ask because that being
> wrong could be an explanation for the stalls you see when using
> cpuidle (as that could mean those HPET interrupts needed for
> waking CPUs don't arrive).

Not entirely sure, but i don't see the stalls booting on baremetal linux with 
iommu enabled by using only ioapic[6]=00:14.0 on the command line.
(just double checked)

Ok and somehow keypresses on the console seem to cause them to do arrive, 
because with a keypress i can make it continu before a stall occurs.

BTW the stalls always start after starting the init process, so *after* loading 
the kernel.
Most of the time the first time is around udevd is started, after that it will 
stall a few times more, at least when ifup/ifdown is setting up the nics.

> Speaking of which - why don't you try whether when not using
> FSB-capable HPET channels, the stalls go away? All you'd need
> to change is hpet_fsb_cap_lookup() - it ought to return without
> doing anything (i.e., if you look at the code, as if
> acpi_gbl_FADT.boot_flags had ACPI_FADT_NO_MSI set).

Will have a go on that ...

> Jan




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