From owner-freebsd-current@FreeBSD.ORG Tue May 9 19:43:41 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 87BC816A56E; Tue, 9 May 2006 19:43:41 +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 CF82243D53; Tue, 9 May 2006 19:43:40 +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 k49JhZAM094178; Tue, 9 May 2006 13:43:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4460F0E0.5030901@samsco.org> Date: Tue, 09 May 2006 13:43:28 -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> <4460EF33.8010909@samsco.org> In-Reply-To: <4460EF33.8010909@samsco.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: 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:43:42 -0000 Scott Long wrote: > 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. > One thing I forgot to mention about this is that I still firmly believe that the umass SIM should be a per-USB bus entity, not a per-USB device entity. I.e. when you load umass.ko, it should create a SIM for every USB bus. Then when umass devices are plugged in, they should just attach as periph devices on the appropriate SIM. The current practice of treating a umass device as a per-instance SIM definitely complicates memory handling like this. Scott