Interrupt latency problems

[Paul Richards]

On Sun, 2003-05-11 at 21:32, M. Warner Losh wrote:
> In message: <1052684139.4921.3.camel at cf.freebsd-services.com>
>             Paul Richards <paul at freebsd-services.com> writes:
> : On Sun, 2003-05-11 at 20:45, M. Warner Losh wrote:
> : > In message: <22333.1052574519 at critter.freebsd.dk>
> : >             "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> : > : In message <1052570246.27195.6.camel at cf.freebsd-services.com>, Paul Richards wr
> : > : ites:
> : > : >I'm having real problems with current with heavy disk activity.
> : > : >
> : > : >When working in X and updating ports which causes a lot of disk activity
> : > : >I get *very* poor interactive responses. Keypresses can not appear for
> : > : >seconds and mouse movement is very jerky and unresponsive.
> : > : >
> : > : >I'm wondering if something is holding locks a long time in interrupt
> : > : >handlers and causing mouse/keyboard interrupts to be lost?
> : > : 
> : > : We have this lock called "Giant" which we're trying to get rid off...
> : > 
> : > Actually, this may be a problem in the acpi code.  I have at least one
> : > battery that causes my system to 'freeze' for a while.  The mouse
> : > interrupts aren't lost, per se, but just deferred too long.  That was
> : > before the latest acpi upgrade, and I've not tried the offending
> : > battery since then (I think that the zero length messages are related
> : > to querrying the battery status, but haven't booted windows to find
> : > out for sure).
> : 
> : Hmm, that an intersting line of thought. The symptoms sound similar,
> : that interrupts aren't necessarily been missed, since I can type when
> : things seem locked up then it all appears.
> : 
> : I get boatloads of these, they stream past continuously.
> : 
> : ACPI-0448: *** Error: AcpiEvGpeDispatch: No handler or method for
> : GPE[0], disabling event
> : 
> : I have no idea what they mean though :-)
> : 
> : I wonder if that might have something to do with it, or if it's
> : triggering a problem somewhere in the dmesg buffer that's causing locks
> : to be held too long.
> 
> Is this a laptop?  I've only seen problems on the laptop.  I've seen
> shorter hangs from heavy ata disk activity, but my only ata systems
> are laptops and they don't have the high performance necssary to
> trigger things.

No, it's a Supermicro DLE, with 2 P3-800 processors.

-- 
Paul Richards <paul at freebsd-services.com>