Re: [Xen-devel] Hpet interrupt overflow

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/08/13 14:57, Jan Beulich wrote:
>>> 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.
> No, each channel will be used for just one CPU when there are at
> least as many channels as CPUs. The difference between not using
> said command line option and using it is that in the former case a
> new channel would get assigned to a CPU each time it needs one,
> while in the latter case a static (pre-)assignment is used, i.e. each
> CPU will use always the same single channel.
>
> Jan
>

We had another crash, this time with a proper stack trace.  (This was
using an early version stack trace improvements series)

From the stack trace (now correctly with frame pointers), we see 9 calls
to handle_hpet_broadcast().

This indicates that the current logic does not correctly prevent
repeated delivery of interrupts.

~Andrew

Attachment: stack-trace.log
Description: Text Data

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