[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • From: Thomas Goetz <tcgoetz@xxxxxxxxx>
  • Date: Fri, 20 May 2011 14:06:48 -0400
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 20 May 2011 11:08:00 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=t0Ayey9tGwyyuzK8ob6JDARcK+4lC5dhWwSlg6Dn4JqwEzVkHDgSo/9kCbEox8ZQVw Lsi7Mc4eFRFdM+tE0sPyzUcX5ad5PYeyKQGL8dkHU7wfjPgZ3kGzY7QkejUAnVmcCAk6 VVDwe9hgWRv5EIi/V3tmlaGxAt4JVuqiQo718=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.