Re: ACPI Exception AE_NO_MEMORY

[Andrew Doran <ad%NetBSD.org@localhost>]

On Tue, Apr 20, 2010 at 03:41:22PM +0300, Jukka Marin wrote:
> On Tue, Apr 20, 2010 at 12:31:37PM +0000, Andrew Doran wrote:
> > On Tue, Apr 20, 2010 at 01:38:53PM +0300, Jukka Ruohonen wrote:
> > > As I noted already, this is malloc(9) returning ENOMEM and ACPI 
> > > complaining
> > > about it (ENOMEM -> AE_NO_MEMORY). The path where this occurs in ACPI is
> > > related to interrupts, so it is pretty serious as far as ACPI is 
> > > concerned.
> > 
> > Why is it doing M_NOWAIT allocations?  NOWAIT == fail.
> 
> Will it _always_ fail - even when there's RAM available?  Or only when all
> free RAM is used up by, say, disk buffers?

From a design standpoint one can assume that it will always fail,
because in practice it will fail very often.  There are situations where
that can be tolerated but they are few and far between.  Most places where
we allocate memory, we must get that memory or the user experience will
be terminally compromised.

> I don't know how the ACPI events work, but if works like this, I can see why
> the system dies:
> 
>   1. an interrupt occurs and an ACPI event is generated
> 
>   2. memory allocation for the event fails, so the event
>      can not be enqueued
> 
>   3. the interrupt is not cleared because the event could not be
>      enqueued (so we don't miss the event completely)
> 
>   4. interrupt routine exits
> 
>   5. the interrupt is still active, loop back to 1.
> 
> Again, I don't know if the kernel works like this, but this would explain
> the problem I'm having..

That would be an unusually ugly design. If it's working like this,
then perhaps we need to consider handling ACPI notifications differently.
For example, have the interrupt stub mask off the ACPI interrupt at the 
PIC or wherever, and defer processing of the interrupt to a kthread where
we can safely do WAITOK allocations.

(Although, should be using kmem_alloc() :-)