Subject: allocmem in interrupt context
To: None <>
From: Iain Hibbert <>
List: tech-kern
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 
reaches zero.

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?