contigmalloc(9) doesn't honour M_NOWAIT.
Scott Long
scottl at samsco.org
Tue May 9 19:43:42 UTC 2006
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
More information about the freebsd-current
mailing list