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

Friday, August 16, 2013, 11:18:56 AM, you wrote:

>>>> On 16.08.13 at 10:40, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm only the "no-cpuidle" is needed (cpufreq=xen can stay) to make the stalls 
>> disappear,
>> but makes me wonder how that is related to the commit the bisection found ..
>> machine has been running with cpuidle enabled for ages ..

> That's odd indeed. If you're up to do a little bit of debugging here,
> why don't you log the sequence of interrupts arriving both with
> and without said commit. This might end up being a lot of data, so
> you may want to filter out uninteresting stuff and/or log only to
> a memory buffer which then gets dumped upon some debug key
> press.

Hmm making said debug patch is getting probably a bit out of my league ..
since the generated interrupts will probably outpace flushing to the console.

And i'm not sure in what things you are actually interested around the irq flow (probably the hpet msi ones ?).


>  Similarly, checking whether the issue is reproducible with
> Xen running on only a single pCPU might help reducing the amount
> of data, or at least the time needed to analyze it.

Nope unfortunately it doesn't seem to be reproducible with "nosmp".

Also tried some other options (with cpuidle enabled) and to see if that could narrow it down more:

- limiting the max_cstate to 2 instead of the possible 3 states .. but still stalls
- using "tickle_one_idle_cpu".. but still stalls



> Jan