From Frank van der Linden:
> I cooked up a patch that implements a workaround for runtime attachment
> of USB devices that need more than one page of contiguous memory, and

So, here's a question.  When the problem occurs (pre-patch), is it because
1) the usb_mem manager has fragmented its own pool of dinky blocks that it
   manages on top of what it allocates from bus_dmamem_alloc(),  OR
2) usb_allocmem has made a call for a fresh allocation from bus_dmamem_alloc
   that has failed because _the system_ can't supply the requested memory
   contiguously?

I suspect it's (2).  That would explain why, e.g., cardbus devices have the
same problem.  If I'm right, then a patch that generalized USB_MEM_RESERVE
to BUS_MEM_RESERVE, and pushed the implementation down into bus_dmamem_alloc,
would eliminate the mods to specific drivers like uhci, and at the same time
solve the whole problem for other things like cardbus devices that also suffer
from it.

I'm not yet sure if the configuration for BUS_MEM_RESERVE might have to be
per instance of a bus, for example to solve my usb and cardbus problems I
would specify a value for pci0-MEM_RESERVE because my cbbs and uhci all hang
off pci0 so I want reserved memory in a pci0-addressable range.  If I sound
a little vague on that it's because I'm still getting up to speed on the
details.

-Chap