From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: Losing PS/2 Interrupts Date: Fri, 20 May 2011 13:50:44 -0400 Message-ID: <20110520175044.GA30367@dumpdata.com> References: <3E2050B5-59DC-4E4F-9C8D-8C04A6B465EB@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Thomas Goetz Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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.