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.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.08.13 at 12:44, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
> Friday, August 16, 2013, 11:18:56 AM, you wrote:
>>>>> On 16.08.13 at 10:40, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> 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 ?).

No, much more the ones from the devices that you say the drivers
of which cause the stalls while initializing. The question mainly is
whether the distribution of interrupts between CPUs changed in a
way that made the system more susceptible to missing wakeups
via HPET MSIs.

Along that lines was also the question regarding interrupt counts
for the devices in question, which if I'm not mistaken you didn't
answer yet.

Jan


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