Date: Tue, 09 May 2006 13:43:28 -0600 From: Scott Long <scottl@samsco.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: 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: <4460F0E0.5030901@samsco.org> In-Reply-To: <4460EF33.8010909@samsco.org> References: <20060509140312.GA93453@garage.freebsd.pl> <20060509190311.GA710@turion.vk2pj.dyndns.org> <4460EF33.8010909@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4460F0E0.5030901>