From owner-freebsd-current@FreeBSD.ORG Tue May 9 19:36:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99AE316A453; Tue, 9 May 2006 19:36:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA89543D46; Tue, 9 May 2006 19:36:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k49JaQtt094116; Tue, 9 May 2006 13:36:27 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4460EF33.8010909@samsco.org> Date: Tue, 09 May 2006 13:36:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20060509140312.GA93453@garage.freebsd.pl> <20060509190311.GA710@turion.vk2pj.dyndns.org> In-Reply-To: <20060509190311.GA710@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: scottl@freebsd.org, Mark Tinguely , freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: contigmalloc(9) doesn't honour M_NOWAIT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2006 19:36:36 -0000 Peter Jeremy wrote: > On Tue, 2006-May-09 16:03:12 +0200, Pawel Jakub Dawidek wrote: > >>Using a USB pendrive can lead to kernel panic because of the issue >>mentioned in the subject. > > > See kern/78179. Mark Tinguely and I have spent a far amount of time > fighting it. We have made some improvement - bus_dmamem_alloc() > correctly supports BUS_DMA_NOWAIT so you get a runtime error instead > of a panic. At this stage, the umass device needs to be re-written so > that it doesn't issue large contiguous mallocs at interrupt level. > The way forward would seem to be to make the USB subsystem support > scatter-gather (skeleton code already exists) to avoid the need for > contigmalloc(). Yes, this is the correct solution. Unfortunately, it looks to require a significant amount of code for UHCI controllers. But then, the whole point of UHCI is to have the OS do all the work anyways =-/ I need to look at your PR some, but I'm not sure that I want to encourage bad practices with bus_dmamem_alloc and contigmalloc. I know that this doesn't help you solve the problem. A possible workaround might be to pre-allocate a pool of buffers and tell CAM to limit the number of outstanding transactions to that number of buffers. You could also just set the max transfer size to PAGE_SIZE and let the block layer split the i/o's up for you. Page sized allocations use malloc instead of contigmalloc (though there are problems with this when dealing with restrictive dma tags, don't get me started on how half-assed some of the busdma implementation still is). Pre-allocating a pool is what I would do. > > Note that there are lots of other drivers that assume bus_dmamem_alloc() > can't fail, even when called with BUS_DMA_NOWAIT. The common case is for drivers to load either at boot or shortly after boot, and thus contig memory should always be available. The bus_dmamem_alloc API certainly was not meant to be used within normal I/O paths, just at driver initialization. Not checking return values is obviously an error, but in practice it's rarely a problem. Scott