question on odd APIC behavior

question on odd APIC behavior

[Oliver Neukum]

Hi,

is there a way to so misprogramm an APIC that a physical interrupt results
in two interrupts delivered?

	Regards
		Oliver

Re: question on odd APIC behavior

[Maciej W. Rozycki]

On Thu, 15 Nov 2007, Oliver Neukum wrote:

> is there a way to so misprogramm an APIC that a physical interrupt results
> in two interrupts delivered?

 Certainly.  One possibility is to have multiple processors marked as the 
destination, e.g. a logical delivery mode destination programmed with 
multiple bits set.

  Maciej

Re: question on odd APIC behavior

[Oliver Neukum]

Am Donnerstag 15 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
> 
> > is there a way to so misprogramm an APIC that a physical interrupt results
> > in two interrupts delivered?
> 
>  Certainly.  One possibility is to have multiple processors marked as the 
> destination, e.g. a logical delivery mode destination programmed with 
> multiple bits set.

What would be the consequences?
I am seeing an interrupt for an UHCI on #20 CPU1 also arriving on
#19 CPU0, triggering the spurious interrupt detection.

	Regards
		Oliver

Re: question on odd APIC behavior

[Maciej W. Rozycki]

On Thu, 15 Nov 2007, Oliver Neukum wrote:

> >  Certainly.  One possibility is to have multiple processors marked as the 
> > destination, e.g. a logical delivery mode destination programmed with 
> > multiple bits set.
> 
> What would be the consequences?

 It depends on the exact setup and conditions.

> I am seeing an interrupt for an UHCI on #20 CPU1 also arriving on
> #19 CPU0, triggering the spurious interrupt detection.

 Well, if you see spurious interrupt detection triggered, then it is not a 
problem with the interrupt being delivered multiple times (that's handled 
silently by the interrupt dispatched), but likely the interrupt line being 
deasserted too late.  Does it happen frequently?  If your ERR counter in 
/proc/interrupts increments quite fast, then perhaps a driver does not 
handle interrupts well enough for your system.  Or there is noise on an 
interrupt line.

 You would have to provide more information to get more accurate feedback.

  Maciej

Re: question on odd APIC behavior

[Oliver Neukum]

Am Donnerstag 15 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:

> > I am seeing an interrupt for an UHCI on #20 CPU1 also arriving on
> > #19 CPU0, triggering the spurious interrupt detection.
> 
>  Well, if you see spurious interrupt detection triggered, then it is not a 
> problem with the interrupt being delivered multiple times (that's handled 
> silently by the interrupt dispatched), but likely the interrupt line being 
> deasserted too late.  Does it happen frequently?  If your ERR counter in 
> /proc/interrupts increments quite fast, then perhaps a driver does not 
> handle interrupts well enough for your system.  Or there is noise on an 
> interrupt line.
> 
>  You would have to provide more information to get more accurate feedback.

On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
there's a spurious interrupt on 19. USB devices on bus of the controller on 20
work. So I know all interrupts are seen. ERR does not increase. Interrupts
for devices on the bus of the controller on 19 arrive at 19 only.
As far as I can determine there are really interrupts on both CPUs on
different vectors for one physical interrupt request.

	Regards
		Oliver

Re: question on odd APIC behavior

[Maciej W. Rozycki]

On Thu, 15 Nov 2007, Oliver Neukum wrote:

> On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> there's a spurious interrupt on 19. USB devices on bus of the controller on 20
> work. So I know all interrupts are seen. ERR does not increase. Interrupts
> for devices on the bus of the controller on 19 arrive at 19 only.

 I suggest you try to sort it out with the maintainers of the UHCI and 
EHCI drivers then.

  Maciej

Re: question on odd APIC behavior

[Oliver Neukum]

Am Freitag 16 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
> 
> > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> > there's a spurious interrupt on 19. USB devices on bus of the controller on 20
> > work. So I know all interrupts are seen. ERR does not increase. Interrupts
> > for devices on the bus of the controller on 19 arrive at 19 only.
> 
>  I suggest you try to sort it out with the maintainers of the UHCI and 
> EHCI drivers then.

They are innocent. This laptop really delivers an interrupt twice.

	Regards
		Oliver

Re: question on odd APIC behavior

[Maciej W. Rozycki]

On Fri, 16 Nov 2007, Oliver Neukum wrote:

> > > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> > > there's a spurious interrupt on 19. USB devices on bus of the controller on 20
> > > work. So I know all interrupts are seen. ERR does not increase. Interrupts
> > > for devices on the bus of the controller on 19 arrive at 19 only.
> > 
> >  I suggest you try to sort it out with the maintainers of the UHCI and 
> > EHCI drivers then.
> 
> They are innocent. This laptop really delivers an interrupt twice.

 Perhaps, but these drivers are involved and the device-specific knowledge 
will help tracking down the cause.  I have general experience on how 
interrupts work, including on APIC-based systems, but I have no idea how 
UHCI and EHCI devices work in this area and, in particular, how you know 
an interrupt coming from the line #19 is related to one on the line #20 
and then a spurious one if not recorded as ERR or otherwise unclaimed 
(which would be reported as "irq 19: nobody cared").

  Maciej

Re: question on odd APIC behavior

[Oliver Neukum]

Am Freitag 16 November 2007 schrieb Maciej W. Rozycki:
> On Fri, 16 Nov 2007, Oliver Neukum wrote:
> 
> > > > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> > > > there's a spurious interrupt on 19. USB devices on bus of the controller on 20
> > > > work. So I know all interrupts are seen. ERR does not increase. Interrupts
> > > > for devices on the bus of the controller on 19 arrive at 19 only.
> > > 
> > >  I suggest you try to sort it out with the maintainers of the UHCI and 
> > > EHCI drivers then.
> > 
> > They are innocent. This laptop really delivers an interrupt twice.
> 
>  Perhaps, but these drivers are involved and the device-specific knowledge 
> will help tracking down the cause.  I have general experience on how 
> interrupts work, including on APIC-based systems, but I have no idea how 
> UHCI and EHCI devices work in this area and, in particular, how you know 
> an interrupt coming from the line #19 is related to one on the line #20 
> and then a spurious one if not recorded as ERR or otherwise unclaimed 
> (which would be reported as "irq 19: nobody cared").

I am getting irq 19:nobody cared. Interrupts on 19 and 20 increase with
same rate, disconnecting the device on the bus stops the increase,
reconnecting it makes them increase again.

	Regards
		Oliver

Re: question on odd APIC behavior

[Maciej W. Rozycki]

On Fri, 16 Nov 2007, Oliver Neukum wrote:

> I am getting irq 19:nobody cared. Interrupts on 19 and 20 increase with
> same rate, disconnecting the device on the bus stops the increase,
> reconnecting it makes them increase again.

 Very odd indeed.  I suggest you post the relevant information (like the 
bootstrap log, output from `lspci -v', the contents of /proc/cpuinfo, 
etc.) together with the description of the problem (so that the report is 
self-contained) here and perhaps somebody will be able to diagnose it 
properly.  It could be some ACPI breakage.

  Maciej