On Sat, 16 Sep 2006, Hans Petter Selasky wrote:

> On Friday 15 September 2006 21:56, Iain Hibbert wrote:
> > On Thu, 14 Sep 2006, Hans Petter Selasky wrote:
> > > On Thursday 14 September 2006 20:38, Iain Hibbert wrote:
> > > > Is usbd_transfer allowed to be called from interrupt context?
> > >
> > > The answer is no. Deep inside the [old] USB system, usbd_transfer can
> > > allocate memory when it is called, that can sleep
> >
> > That is true but I think 'can' is not 'will' - if the driver wants to call
> > usbd_transfer from interrupt context, the allocation can be arranged
> > safely in advance, so far as I can tell..?
>
> Last time I checked, the NetBSD USB stack will start allocating memory
> at the moment usbd_transfer() is called. This is USB hardware memory
> like transfer descriptors and DMA memory for the data-buffers.s And it
> can sleep! The old system is simply wrong. It is not possible to
> pre-allocate all memory. Only some parts like the "struct usbd_xfer" and
> "struct usbd_xfer -> buffer".

The allocation inside usbd_transfer() seems to be those parts that you
mention can be pre-allocated, and the sleep is only when USBD_SYNCHRONOUS
is set..

Further down _NOWAIT does seem to be used where it is needed (so far as I
can see :)

Without defending the USB stack particularly, I think the real lack is one
of documentation.. There is no indication of what should be done and what
is possible.

> Secondly you will get another headache if you try to modify the USB network
> drivers into using pre-allocated USB transfers. That is, many times the USB
> network drivers will read a value before they write a value, and that has to
> sleep.

My concern is the ubt(4) driver which I wrote, but that seems (to me) to
safely allocate everything in advance and deals transfers asynchronously -
certainly I've had no issues with it in a fairly low memory system and
running Firefox & gcc etc (with painful swapping)

iain