Date: 19 May 2003 20:24:13 +0100 From: Paul Richards <paul@freebsd-services.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: current@freebsd.org Subject: Re: Interrupt latency problems Message-ID: <1053372251.815.50.camel@cf.freebsd-services.com> In-Reply-To: <20030512130949.GB48440@survey.codeburst.net> References: <22333.1052574519@critter.freebsd.dk> <20030511.134504.85393710.imp@bsdimp.com> <1052684139.4921.3.camel@cf.freebsd-services.com> <20030511.143231.133432780.imp@bsdimp.com> <1052692357.4921.128.camel@cf.freebsd-services.com> <16062.59918.302092.929640@curly.cs.duke.edu> <1052703871.4921.146.camel@cf.freebsd-services.com> <16063.38255.961273.900146@grasshopper.cs.duke.edu> <20030512124753.GA48753@survey.codeburst.net> <16063.39366.930707.980678@grasshopper.cs.duke.edu> <20030512130949.GB48440@survey.codeburst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd-services.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1053372251.815.50.camel>