pv_ops parport trouble

pv_ops parport trouble

[Gerd Hoffmann]

  Hi,

I see on my test box _excessive_ irqs for parport0:

[root@xeni ~]# cat /proc/interrupts
           CPU0
[ ... ]
  7:   37316845  xen-pirq-pirq      parport0
[ ... ]
 24:      17698   xen-dyn-virq      timer0
[ ... ]

Something is seriously wrong here ...

cheers,
  Gerd

Re: pv_ops parport trouble

[Gerd Hoffmann]

Gerd Hoffmann wrote:
>   Hi,
> 
> I see on my test box _excessive_ irqs for parport0:
> 
> [root@xeni ~]# cat /proc/interrupts
>            CPU0
> [ ... ]
>   7:   37316845  xen-pirq-pirq      parport0
> [ ... ]
>  24:      17698   xen-dyn-virq      timer0
> [ ... ]
> 
> Something is seriously wrong here ...

More info:

[root@xeni ~]# cat /proc/interrupts
           CPU0
  1:          0  xen-pirq-pirq      i8042
  3:         13  xen-pirq-pirq
  4:         17  xen-pirq-pirq
  7:   17797333  xen-pirq-pirq      parport0
  8:          1  xen-pirq-pirq      rtc0
  9:          0  xen-pirq-pirq      acpi
 16:          0  xen-pirq-pirq      uhci_hcd:usb3, uhci_hcd:usb8
 18:          0  xen-pirq-pirq      uhci_hcd:usb5
 19:      14697  xen-pirq-pirq      ehci_hcd:usb1, uhci_hcd:usb7, ahci
 20:       5142  xen-pirq-pirq      eth0
 21:          0  xen-pirq-pirq      uhci_hcd:usb4
 22:        240  xen-pirq-pirq      HDA Intel
 23:          0  xen-pirq-pirq      ehci_hcd:usb2, uhci_hcd:usb6

(XEN) Guest interrupt information:
(XEN)     IRQ  1 Vec 40: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ  7 Vec 80: type=IO-APIC-level   status=00000010
in-flight=1 domain-list=0(PS-M),
(XEN)     IRQ  8 Vec 88: type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ  9 Vec 96: type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 16 Vec 33: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 18 Vec 49: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 19 Vec208: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 20 Vec 57: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 21 Vec 41: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 22 Vec 65: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),
(XEN)     IRQ 23 Vec216: type=IO-APIC-edge    status=00000010
in-flight=0 domain-list=0(-S--),

Note that IRQ 7 is *level* triggered and we have a bunch of *shared*
irqs which are *edge* triggered.  Given this I wonder my test box is
able to stay up that long.

cheers,
  Gerd

Re: Re: pv_ops parport trouble

[Keir Fraser]

On 19/02/2009 15:28, "Gerd Hoffmann" <kraxel@redhat.com> wrote:

> Note that IRQ 7 is *level* triggered and we have a bunch of *shared*
> irqs which are *edge* triggered.  Given this I wonder my test box is
> able to stay up that long.

Yes, that looks completely backwards. Could pv_ops dom0 be getting the
trigger flag in IO-APIC redir entries inverted somehow?

 -- Keir

Re: Re: pv_ops parport trouble

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> On 19/02/2009 15:28, "Gerd Hoffmann" <kraxel@redhat.com> wrote:
>
>   
>> Note that IRQ 7 is *level* triggered and we have a bunch of *shared*
>> irqs which are *edge* triggered.  Given this I wonder my test box is
>> able to stay up that long.
>>     
>
> Yes, that looks completely backwards. Could pv_ops dom0 be getting the
> trigger flag in IO-APIC redir entries inverted somehow?
>   

I guess that's possible, but the code in question does just pass the 
trigger and polarity straight through.  What does it say about the 
trigger and polarity for those interrupts in the dmesg output?

I guess it would explain quite a few of the "lost interrupt" symptoms 
we've been seeing, but I'm surprised things work at all well if they 
really are reversed.

    J

Re: Re: pv_ops parport trouble

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

Jeremy Fitzhardinge wrote:
> I guess that's possible, but the code in question does just pass the
> trigger and polarity straight through.

Notice:
  #define ACPI_LEVEL_SENSITIVE            (u8) 0x00

whereas for the io apic 0 == edge.

cheers,
  Gerd



[-- Attachment #2: fix --]
[-- Type: text/plain, Size: 428 bytes --]

diff --git a/arch/x86/xen/pci.c b/arch/x86/xen/pci.c
index d661c74..62ab389 100644
--- a/arch/x86/xen/pci.c
+++ b/arch/x86/xen/pci.c
@@ -53,7 +53,7 @@ int xen_register_gsi(u32 gsi, int triggering, int polarity)
 	printk(KERN_DEBUG "xen: --> irq=%d\n", irq);
 
 	if (irq > 0)
-		xen_set_io_apic_routing(irq, triggering, polarity);
+		xen_set_io_apic_routing(irq, triggering == ACPI_LEVEL_SENSITIVE, polarity);
 
 	return irq;
 }

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Re: pv_ops parport trouble

[Jeremy Fitzhardinge]

Gerd Hoffmann wrote:
> Notice:
>   #define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>
> whereas for the io apic 0 == edge.
>   

Yeah, just noticed that :/

Sometimes its amazing how badly you can screw things up and they keep 
staggering on.  I wonder if this will help our mysterious ahci problem.

    J

Re: Re: pv_ops parport trouble

[Gerd Hoffmann]

Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> Notice:
>>   #define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>
>> whereas for the io apic 0 == edge.
>>   
> 
> Yeah, just noticed that :/
> 
> Sometimes its amazing how badly you can screw things up and they keep
> staggering on.

Yep.

> I wonder if this will help our mysterious ahci problem.

IRQ7 storm is gone.
Box is up and running.  Doing a kernel build right now.
Usually it isn't able to finish it before ahci says goodbye,
lets see how it works out now ...

cheers,
  Gerd

Re: Re: pv_ops parport trouble

[Jeremy Fitzhardinge]

Gerd Hoffmann wrote:
> IRQ7 storm is gone.
> Box is up and running.  Doing a kernel build right now.
> Usually it isn't able to finish it before ahci says goodbye,
> lets see how it works out now ...
>   

I booted to usermode with ahci, which is a first - it never managed to 
probe the drives before.

Good work,
    J

Re: Re: pv_ops parport trouble

[Gerd Hoffmann]

Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> IRQ7 storm is gone.
>> Box is up and running.  Doing a kernel build right now.
>> Usually it isn't able to finish it before ahci says goodbye,
>> lets see how it works out now ...
> 
> I booted to usermode with ahci, which is a first - it never managed to
> probe the drives before.

Finished two kernel rebuilds, still up'n'running ...

cheers,
  Gerd

Re: Re: pv_ops parport trouble

[Keir Fraser]

On 19/02/2009 16:56, "Gerd Hoffmann" <kraxel@redhat.com> wrote:

> Jeremy Fitzhardinge wrote:
>> Gerd Hoffmann wrote:
>>> IRQ7 storm is gone.
>>> Box is up and running.  Doing a kernel build right now.
>>> Usually it isn't able to finish it before ahci says goodbye,
>>> lets see how it works out now ...
>> 
>> I booted to usermode with ahci, which is a first - it never managed to
>> probe the drives before.
> 
> Finished two kernel rebuilds, still up'n'running ...

Great news that bug is finally dead. :-)

 K.

Re: Re: pv_ops parport trouble

[Keir Fraser]

On 19/02/2009 16:23, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

>> Yes, that looks completely backwards. Could pv_ops dom0 be getting the
>> trigger flag in IO-APIC redir entries inverted somehow?
>>   
> 
> I guess that's possible, but the code in question does just pass the
> trigger and polarity straight through.  What does it say about the
> trigger and polarity for those interrupts in the dmesg output?
> 
> I guess it would explain quite a few of the "lost interrupt" symptoms
> we've been seeing, but I'm surprised things work at all well if they
> really are reversed.

Comparing with a non-pv_ops dom0 on that same system would be an obvious
next step.

 -- Keir

Re: Re: pv_ops parport trouble

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> Comparing with a non-pv_ops dom0 on that same system would be an obvious
> next step.

Yeah, that was it.  I was passing the ACPI triggering value directly to 
the APIC, but they have reversed senses.  Seems to have fixed the AHCI 
problem for both Gerd and me.

    J