Re: Interrupt latency problems

From: Paul Richards <paul_at_freebsd-services.com>
Date: 11 May 2003 21:15:41 +0100
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.

-- 
Paul Richards <paul_at_freebsd-services.com>
Received on Sun May 11 2003 - 11:20:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC