Subject: Re: allocmem in interrupt context
To: Iain Hibbert <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/28/2005 11:40:41
Content-Type: text/plain; charset=us-ascii
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----