Re: Interrupt latency problems

On Mon, 2003-05-12 at 14:09, Paul Richards wrote:
> On Mon, May 12, 2003 at 08:55:34AM -0400, Andrew Gallatin wrote:
> > 
> > Paul Richards writes:
> >  > 
> >  > I tried shifting the irq around last night, the bios does support this.
> >  > I definitely think there's something to this theory, when I put it on
> >  > irq 10 the problem got a whole lots worse to the point that the machine
> >  > couldn't be used and I had to reboot it (just error messages streaming
> >  > past on the console).
> >  > 
> >  > Unfortunately, I don't know what else was on irq10 at the time since
> >  > they move around when I change the bios settings.
> >  > 
> >  > I'm continuing to poke around to find out exactly what's causing
> >  > what....
> > 
> > I have this vague memory that the acpi always uses irq 9.  Perhaps
> > you inadvertently moved something else which generates more interrupts
> > onto irq 9..
> Yeah, that email wasn't very clear. I moved fxp to irq10, so you're
> right, something else probably ended up on irq9.

I've confirmed this was the cause of my poor interrupt performance.

The acpi interrupt handler doesn't do anything to check whether the
interrupt belongs to it or not and so executes every time there's an
interrupt on irq9. If something busy shares irq9 then it can be called
quite a lot.

Since there's no actual GPE event to handle, it always fails to find a
method and so ends up writing an error message for every irq9 interrupt
that happens.

As you can imagine, that's a lot of error messages and I think the
periodic freezes are a result of the message buffer filling up.

I've hacked the method dispatcher to just return if there's not a valid
method and the box is no longer hanging periodically.

I'm not sure how to fix this properly though. Ideally the interrupt
wrapper should be able to check whether there's been an acpi interrupt
and only call the handler if there has been, but I can find no way of
doing that, there doesn't seem to be a bit that signifies an SCI
interrupt. The only solution would seem to be to check all the status
bits in the GPE registers but I'm not sure that would be correct either
since there could be fixed hardware events that could cause an SCI too.
In any case, you'll still end up calling the acpi handler code for each
irq9 interrupt rather than detecting whether it's acpi related or not
before calling the handler.

I'm also not sure why a lot more people aren't seeing this, unless my
motherboard is odd in sharing the acpi interrupt with a pci slot.

-- 
Paul Richards <paul_at_freebsd-services.com>