Subject: Re: allocmem in interrupt context
To: Iain Hibbert <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/28/2005 11:40:41
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 28, 2005 at 09:51:51AM +0100, Iain Hibbert wrote:
> In this case, it finds that commands have completed on the controller so=
> updates the command count and notices that there are commands queued and=
> the driver is not active, so it restarts the driver - the above message=
> is being triggered inside usbd_transfer someplace, which is now being=20
> called on interrupt context like it says..
> Does this message then, imply that I am not doing the right thing? Should=
> I be disassociating this event processing further than a soft interrupt?

Yes, you're doing something wrong. I'm not 100% sure of the fix.

The main issue is that we use interrupt masks to protect memory allocation=
lists. Some interrupt handlers can still run while these other interrupts=
are blocked. They must NOT allocate memory (which is why they get to run=20

So one of two things is happening. Either you are allocating memory at a=20
time when you shouldn't and the message is correct, or you are ok and the=
message is not differentiating between interrupt context and interrupt=20
context where we can't allocate memory.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)