On Sun, 4 Mar 2018, Fredrik Noring wrote: > Hi Alan Stern, > > > > Alan, can dma_free_coherent be delayed to a point when IRQs are enabled? > > > > Yes, subject to the usual concerns about not being delayed for too > > long. Also, some HCDs are highly memory-constrained. I don't know if > > they use this API, but if they do then delaying a free could result in > > not enough memory being available when an allocation is needed. > > The PS2 HCD in this case is limited to 256 KiB and memory allocation > failures can be observed frequently in USB traces (102 subsequent failures > in the trace below involving mass storage transactions, for example). Is > there any smartness to the allocations? Not as far as I know. > My impression is that the USB core > loops until it gets what it wants, and then happily resumes. Does it busy > wait? No, it doesn't loop and it doesn't busy-wait. It just fails if memory can't be allocated immediately. Maybe the higher-level driver has a retry loop of some sort. > The RT3070 wireless USB device driver, for example, has hardcoded buffer > limits that exceed the total amount of available memory. It refuses to > accept devices unless adjusted in the source (as in the patch below), after > which it works nicely. > > Other USB device drivers such as the one for the AR9271 wireless device > trigger endlessly repeating kernel warnings claiming > > BOGUS urb xfer, pipe 1 != type 3 > > as shown in this kernel backtrace: ... > I don't know if this is related to memory limitations or some other problem > though. Another problem. This message indicates there's a bug in the ath9k driver; it says that the driver submitted an interrupt URB for a bulk endpoint. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
