Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Feb 2006 00:57:15 +0100
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        Ian Dowse <iedowse@iedowse.com>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
Message-ID:  <20060131235715.GA81439@saturn.kn-bremen.de>
In-Reply-To: <200601312200.aa58422@nowhere.iedowse.com>
References:  <20060131194244.GA75983@saturn.kn-bremen.de> <200601312200.aa58422@nowhere.iedowse.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 31, 2006 at 10:00:21PM +0000, Ian Dowse wrote:
> In message <20060131194244.GA75983@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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060131235715.GA81439>