On Thu, Apr 16, 2015 at 06:57:46PM +0200, Dorian Gray wrote: > On 16 April 2015 at 16:15, Alan Stern wrote: > > This appears to be a problem with the IOMMU or SWIOTLB subsystems, not > > the USB subsystem. I have CC'ed the appropriate mailing lists. > > Thanks, I'm far from being a kernel expert, so was expecting it could > be wrong subsection. > > > > On 16 April 2015 at 16:24, Suman Tripathi wrote: > > Try increasing the SWIOTLB size to 128MB .Default is 64MB. > > Ok, so I'm back to k3.18.7 (default in the latest Fatdog), although > I'm not sure what should be the exact value of swiotlb boot param? > Got totally mixed results from uncle Google - some says the unit is in > MiB, some that it's 4k pages and another that 128MiB = 65536, so I > played it safe and used swiotlb=131072. > Is this correct? > It may take a few days, but I'll let you know if it worked (or for how > long, if not). > > > > On 16 April 2015 at 16:54, Alexander Duyck wrote: > > More likely would be a device driver that is DMA mapping memory but not > > unmapping it after it is done resulting in the bounce buffer pool being > > depleted. > > You might want dump the list of drivers loaded on the system with lsmod, > > and then possibly look at doing a git bisect for something introduced > > between 3.17 and 3.18 since that seems to be when you started seeing > > this issue. > > Ok, I'll (try to) look at this, but like I said - I'm not a kernel > (nor git) expert. > Anyway, I guess I'm gonna start with this: > https://wiki.gentoo.org/wiki/Kernel_git-bisect > Who knows...perhaps I'll find something... And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG and then load the attached module. That should tell you who and what else is holding on the buffers. > > > > Thank you all for the replies. > Jake > _______________________________________________ > iommu mailing list > iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu