On Tue, Jan 31, 2006 at 10:00:21PM +0000, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, 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? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
