Re: [Xen-devel] Re: Losing PS/2 Interrupts

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 20.05.11 at 20:06, Thomas Goetz <tcgoetz@xxxxxxxxx> wrote:

> On May 20, 2011, at 1:50 PM, Konrad Rzeszutek Wilk wrote:
> 
>> On Fri, May 20, 2011 at 11:53:54AM -0400, Thomas Goetz wrote:
>>> 
>>> On May 19, 2011, at 5:45 PM, Thomas Goetz wrote:
>>> 
>>>> I'm running PVOPs 2.6.38 on Xen 4.0.2 RC3 and while booting a guest I lose 
> interrupts for the PS/2 trackpad. The trackpad stops functioning because the 
> device is waiting for service. I added a work around that calls 
> i8042_interupt form a timer if it hasn't been called in 1s and it started 
> working again. I added some code to Xen to count IRQ 12 and compared that to 
> the IRQ 12 count in //proc/interrupts (I stopped PS/2 activity and waited for 
> PS/2 interrupt activity to stop before taking the counts). I lose one 
> interrupt in Dom0 every time the trackpad freezes.
>>>> 
>>>> 
>>>> (XEN) IRQ 12 count 21048
>>>> 12:      21047          0  xen-pirq-ioapic-edge  i8042   <--- lost an 
>>>> interrupt in 
> dom0
>>>> ...
>>>> 
>>>> (XEN) IRQ 12 count 48540
>>>> 12:      48537          0  xen-pirq-ioapic-edge  i8042   <--- lost 3 
>>>> interrupts in 
> dom0
>>>> 
>>>> 
>>>> I looked at the point at which the trackpad gets it's last interrupt in a 
> trace and the other major activity at that time is the event channel that 
> services the Qemu vcpu io_req code.
>>>> 
>>>> This 2.6.38 tree has a merge of Stafano's 2.6.39 fixes in 
> drivers/xen/events.c.
>>>> 
>>>> Anyone have any ideas or suggestions?
>>>> 
>>> 
>>> 
>>> More data. The number of missing interrupts is equal to the number of times 
> __do_IRQ_guest called send_guest_pirq and incremented already_pending. The 
> number of IRQ 12 interrupts reported by /proc/interrupts is the same as the 
> count of times __xen_evtchn_do_upcall called generic_handle_irq_desc for IRQ 
> 12. So the issue has to be between send_guest_pirq in Xen and  
> __xen_evtchn_do_upcall in dom0.
>> 
>> So extremly hairy code. Not sure if there was any work done in the 
> send_guest_pirq, but I do
>> know that __xen_evtchn_do_upcall had a fair bit of IRQ fair round-robin code 
> added in.
>> 
>> The git commits were
>> 
>> 3b7bcdf xen: events: Remove redundant clear of l2i at end of round-robin loop
>> 24b51c2 xen: events: Make round-robin scan fairer by snapshotting each l2 
> word once only
>> ada6814 xen: events: Clean up round-robin evtchn scan.
>> f1f4a32 xen: events: Make last processed event channel a per-cpu variable.
>> ab7f863 xen: events: Process event channels notifications in round-robin 
> order.
> 
> The PS/2 port has a one character buffer. It will only ever send one 
> interrupt until it has been serviced. When __do_IRQ_guest calls 
> send_guest_pirq and sees that it is already pending, what part of the between 
> the bottom of __do_IRQ_guest and _irq_guest_eoi results in the pending 
> interrupt being issued to the guest? I haven't found that and it looks like 
> Xen is merging the ACKTYPE_NONE edge interrupt resulting in the deice never 
> being serviced when it's buffer is full and never interrupting again.

It would be a bug of the 8042 if it sent a second interrupt when the
first one wasn't serviced (status and data port read) yet. It's the
nature of edge triggered interrupts that secondary instances are
lost when the primary instance doesn't get handled (in time).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel