Date: Tue, 09 May 2006 13:36:19 -0600 From: Scott Long <scottl@samsco.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: scottl@freebsd.org, Mark Tinguely <tinguely@casselton.net>, freebsd-current@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: contigmalloc(9) doesn't honour M_NOWAIT. Message-ID: <4460EF33.8010909@samsco.org> In-Reply-To: <20060509190311.GA710@turion.vk2pj.dyndns.org> References: <20060509140312.GA93453@garage.freebsd.pl> <20060509190311.GA710@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4460EF33.8010909>