Subject: allocmem in interrupt context
To: None <firstname.lastname@example.org>
From: Iain Hibbert <email@example.com>
Date: 10/28/2005 09:51:51
I bought a Bluetooth USB dongle and have been rewriting the ubt driver
to fit with my scheme of things, and get a message that I dont completely
[caveat: I'm still working with NetBSD 2.0 sources as I have been having
trouble updating to -current, sup keeps timing out on me as my signal is
not that great]
the message is:
Oct 28 08:38:59 galant /netbsd: usb_block_allocmem: in interrupt context, size=4096
and I can see where this message comes from (usb_mem.c) and I can see why
I get that message, thus:
outgoing commands are queued, then the driver is activated if not already
active and the process sleeps for completion.
for host->controller flow control, I have a number of command packets that
may be sent. The driver decreases this and stops transmitting when it
incoming events get put on a queue and a soft interrupt (IPL_SOFTNET) is
triggered to disassociate it from the hardware.
now, this incoming soft interrupt passes packets to sockets, and also
interprets HCI events.
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
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?