Re: [Xen-devel] [RFC Patch] x86/hpet: Disable interrupts while running hpet interrupt handler.

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/08/13 12:44, Jan Beulich wrote:
>>>> On 06.08.13 at 12:32, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> The machine we found this crash on is a Dell R310.  4 CPUs, 16G Ram.
> Not all that big.
>
>> The full boot xl dmesg is attached, but it appears that the are 8
>> broadcast hpets.  This is futher backed up by the 'i' debugkey (also
>> attached)
> Right. And with fewer CPUs than HPET channels, you could get
> the system into a mode where each CPU uses a dedicated channel
> ("maxcpus=4", suppressing registration of all the disabled ones).

Does this setup actually mean that there are 8 hpets which are all
broadcasting to every pcpu?  The affinities listed in debug-keys 'i'
seem to be towards single pcpus, but the order looks peculiar to say the
least.

>
>> Keir: (merging your thread back here)
>>   I see your point regarding IRQ_INPROGRESS, but even with 8 hpet
>> interrupts, there are rather more than 8 occurences of
>> handle_hpet_broadcast() in the stack.  If the occurences were just
>> function pointers on the stack, I would expect to see several
>> handle_hpet_broadcast()+0x0/0x268
> Which further hints at some earlier problem. I suppose you don't
> happen to have a dump of that crash, or else you could inspect
> the IRQ descriptors as well as the stack for whether all instances
> came from the same IRQ/vector.
>
> Jan
>

Sadly no - the crashdump analyser grabbed the double fault IST, rather
than the entire contents of the main stack.  I shall extend the analyser
to pick up the main stack as well; It does cross IST boundaries for call
traces.  I shall how easy it is to make it parse the irq_desc's &
friends as well on crash, although for this case it might be easier just
to tweak the double fault handler.

~Andrew

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