cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h

[Juergen Lock]

On Tue, Jan 31, 2006 at 10:00:21PM +0000, Ian Dowse wrote:
> In message <20060131194244.GA75983 at saturn.kn-bremen.de>, Juergen Lock writes:
> >>  Alright, looks like it was paging: (usb_block_allocmem ending up
> >> calling contigmalloc...  which makes me wonder what would happen
> >> there if someone had swap on a umass device?  swap here is on
> >> ad4s2b which is on the sata card.)
> >
> >Ah, seems the actual problem is that it is sleeping although
> >bus_dmamem_alloc is called with BUS_DMA_NOWAIT, and there even is
> >a pr for that:
> >	http://www.freebsd.org/cgi/query-pr.cgi?pr=78179
> >The pr is still open so i guess there is no fix yet?
> 
> Ok, yes, this is a known problem that occurs if you access USB
> devices for the first time when the physical memory is too fragmented
> for a contiguous allocation to succeed immediately. A workaround
> is to add more RAM or access the USB devices soon after booting.
> Once the USB system has successfully allocated the memory it needs,
> it will then work reliably.
> 
> In the case of USB, there is actually no need for it to perform
> large contiguous allocations because the host controllers all support
> some limited scatter-gather functionality so they can mostly access
> the caller's memory buffer directly via bus_dmamap_load(). This is
> something I implemented a year or to ago but I haven't got around
> to finishing the last few details of the patch yet.

Hmm, couldnt the usb code just pre-allocate the needed memory at,
say, the open() syscall of an umass device instead?