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

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

  • To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  • From: Thomas Goetz <tcgoetz@xxxxxxxxx>
  • Date: Mon, 23 May 2011 14:39:24 -0400
  • Cc: Simon Graham <simon.graham@xxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • Delivery-date: Mon, 23 May 2011 11:40:18 -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=Mo1EFmU9ub2fVmJ9oh6FMn2dyurRoiqysAc8XnwNprL7N1jDJb/G6dUWE7M7sj8JPP YF3xVBbgYQQrq8xJWhxItGOmTyX8mvDrvvvRPNOw4nWiVQwI5FMFeLrG32cmTnlV+6B5 Mf/4slWWsTA4zP4E0HdDmAgJBmhwAQO8hqqnA=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On May 23, 2011, at 1:28 PM, Thomas Goetz wrote:

> On May 23, 2011, at 1:16 PM, Thomas Goetz wrote:
>> 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.
>>>> 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.
>>>> Am I missing something?
>>> 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.
>>> 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.
> pirq_needs_eoi checks info->u.pirq.flags & PIRQ_NEEDS_EOI. PIRQ_NEEDS_EOI is 
> only set by pirq_query_unmask which sets it based on the hypercall 
> PHYSDEVOP_irq_status_query which in Xen 4.0.1 and Xen unstable always returns 
> an EOI is needed. Stefano, I don't see any changes in your 2.6.39 tree that 
> would effect this.

I'm running with the attached workaround and I'm the PS/2 issue is gone.

drivers/xen/events.c :: xen_map_pirq_gsi

        if ((strcmp(name, "ioapic-edge") != 0) && pirq_needs_eoi(irq)) {
                set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
                                handle_fasteoi_irq, name);
        } else {
                set_irq_chip_and_handler_name(irq, &xen_pirq_chip,
                                handle_edge_irq, name);

Tom Goetz

Xen-devel mailing list



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