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

[Thomas Goetz <tcgoetz@xxxxxxxxx>]

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.


---
Tom Goetz
tcgoetz@xxxxxxxxx





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