Date: Tue, 31 Jan 2006 22:00:21 +0000 From: Ian Dowse <iedowse@iedowse.com> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-usb@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h Message-ID: <200601312200.aa58422@nowhere.iedowse.com> In-Reply-To: Your message of "Tue, 31 Jan 2006 20:42:44 %2B0100." <20060131194244.GA75983@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601312200.aa58422>