Subject: Re: allocmem in interrupt context
To: Iain Hibbert <plunky@rya-online.net>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/28/2005 11:40:41
--rS8CxjVDS/+yyDmU
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:
>=20
> In this case, it finds that commands have completed on the controller so=
=20
> updates the command count and notices that there are commands queued and=
=20
> the driver is not active, so it restarts the driver - the above message=
=20
> is being triggered inside usbd_transfer someplace, which is now being=20
> called on interrupt context like it says..
>=20
> Does this message then, imply that I am not doing the right thing? Should=
=20
> 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=
=20
lists. Some interrupt handlers can still run while these other interrupts=
=20
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=
=20
message is not differentiating between interrupt context and interrupt=20
context where we can't allocate memory.
Take care,
Bill
--rS8CxjVDS/+yyDmU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFDYnCpWz+3JHUci9cRAjE0AJ4yxKwWl9G8aX/LHyYmbaILO71mNQCeKnBk
BwzJD8I6o1cYkCZScL8W/ck=
=pb8q
-----END PGP SIGNATURE-----
--rS8CxjVDS/+yyDmU--