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

[Thomas Goetz <tcgoetz@xxxxxxxxx>]

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
tcgoetz@xxxxxxxxx





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