From owner-freebsd-usb@FreeBSD.ORG Tue Jan 31 22:00:28 2006 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E810116A420 for ; Tue, 31 Jan 2006 22:00:28 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 87CD643D48 for ; Tue, 31 Jan 2006 22:00:25 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 31 Jan 2006 22:00:22 +0000 (GMT) To: Juergen Lock In-Reply-To: Your message of "Tue, 31 Jan 2006 20:42:44 +0100." <20060131194244.GA75983@saturn.kn-bremen.de> Date: Tue, 31 Jan 2006 22:00:21 +0000 From: Ian Dowse Message-ID: <200601312200.aa58422@nowhere.iedowse.com> Cc: freebsd-usb@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 22:00:29 -0000 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