From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Goetz Subject: Re: Re: Losing PS/2 Interrupts Date: Mon, 23 May 2011 13:16:38 -0400 Message-ID: <04C6DFB0-08C8-4A8B-968F-FFE712BCABA1@gmail.com> References: <3E2050B5-59DC-4E4F-9C8D-8C04A6B465EB@gmail.com> <20110520175044.GA30367@dumpdata.com> <5D477258-8216-48BD-8A93-186E044118B9@gmail.com> <4DDA366E0200007800042C71@vpn.id2.novell.com> <1D3BFCDD-9D53-48BA-9ECD-D009AD535C2B@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: 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: Stefano Stabellini Cc: Simon Graham , "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On May 23, 2011, at 9:45 AM, Stefano Stabellini wrote: > On Mon, 23 May 2011, Thomas Goetz wrote: >> My assumption is that at the point that the i8042 driver reads the = data register a new interrupt happens. There is gap in >> time between when the data register is read and when the event = channel pending state is cleared. Since the hypervisor >> ACKed the previous real interrupt before delivering it to the guest, = there is nothing to stop the i8042 device from >> interrupting immediately after the data register is read. If it = interrupt before the event channel pending state is >> cleared, then it will not be delivered to the guest and the EOI = mechanism will be set up, but I haven't found anything in >> that that will set up a delayed delivery of the second interrupt. >>=20 >> In this situation the i8042 device has every reason to believe the = second interrupt will be delivered. The previous >> interrupt was received and handled. Nothing is masked. >>=20 >> Am I missing something? >=20 >=20 > I am assuming you have the latest version of my fixes to > drivers/xen/events.c I'll have a version ported from your 2.6.39 tree to my 2.6.38 tree. I'll = update my copy of your tree and make sure it's up to date. >=20 > The problem you are describing shouldn't happen because the interrupt > handler returned by request_irq to i8042 is handle_edge_irq that calls > chip->irq_ack() before handle_irq_event(). I checked on which method it is using and it's using handle_fasteoi_irq. = In fatc all of the IRQs under 16 are despite most being edge. Log = snippet below. I'm looking into why pirq_needs_eoi is returning the = wrong answer now. > We implement irq_ack with a clear_evtchn() so by the time > i8042_interrupt is called the event channel should have already been > cleared. >=20 > If a second interrupt is asserted right after i8042_interrupt reads = the > data port, handle_edge_irq is called again and this time because = another > interrupt of the same kind is already being handled, it will call > mask_ack_irq(). > On Xen this translates to mask_evtchn() and clear_evtchn(), so once > again the event channel pending bit should be cleared. May 23 16:52:00 jcf kernel: [ 35.075367] [] ? = i8042_interrupt+0x221/0x410 May 23 16:52:00 jcf kernel: [ 35.075373] [] ? = radix_tree_lookup+0xb/0x10 May 23 16:52:00 jcf kernel: [ 35.075379] [] ? = handle_IRQ_event+0x54/0x180 May 23 16:52:00 jcf kernel: [ 35.075384] [] ? = handle_fasteoi_irq+0x84/0x110 May 23 16:52:00 jcf kernel: [ 35.075389] [] ? = __xen_evtchn_do_upcall+0x1a7/0x270 May 23 16:52:00 jcf kernel: [ 35.075395] [] ? = xen_restore_fl_direct_end+0x0/0x1 May 23 16:52:00 jcf kernel: [ 35.075399] [] ? = xen_evtchn_do_upcall+0x2f/0x50 May 23 16:52:00 jcf kernel: [ 35.075404] [] ? = xen_do_hypervisor_callback+0x1e/0x30 May 23 16:52:00 jcf kernel: [ 35.075407] [] = ? hypercall_page+0x2eb/0x1000 [ 0.000000] xen_map_pirq_gsi: irq 1 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 2 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 3 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 4 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 5 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 6 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 7 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 8 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen_map_pirq_gsi: irq 10 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 11 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 12 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 13 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 14 handle_fasteoi_irq [ 0.000000] xen_map_pirq_gsi: irq 15 handle_fasteoi_irq 1: 8 0 xen-pirq-ioapic-edge i8042 3: 1 0 xen-pirq-ioapic-edge 4: 1 0 xen-pirq-ioapic-edge 5: 1 0 xen-pirq-ioapic-edge 7: 1 0 xen-pirq-ioapic-edge 8: 0 0 xen-pirq-ioapic-edge rtc0 9: 1129 0 xen-pirq-ioapic-level acpi 10: 1 0 xen-pirq-ioapic-edge 11: 1 0 xen-pirq-ioapic-edge 12: 4032 0 xen-pirq-ioapic-edge i8042 14: 153 0 xen-pirq-ioapic-edge ata_piix 15: 0 0 xen-pirq-ioapic-edge ata_piix --- Tom Goetz tcgoetz@gmail.com