Hi, On 11/27/20 5:19 PM, Christoph Hellwig wrote: > On Fri, Nov 27, 2020 at 01:32:16PM +0100, Hans de Goede wrote: >> I ran some more tests, I can confirm that reverting: >> >> 5df7ef7d32fe "uas: bump hw_max_sectors to 2048 blocks for SS or faster drives" >> 558033c2828f "uas: fix sdev->host->dma_dev" >> >> Makes the problem go away while running a 5.10 kernel. I also tried doubling >> the swiotlb size by adding: swiotlb=65536 to the kernel commandline but that >> does not help. >> >> Some more observations: >> >> 1. The usb-storage driver does not cause this issue, even though it has a >> very similar change. >> >> 2. The problem does not happen until I plug an UAS decvice into the dock. >> >> 3. The problem continues to happen even after I unplug the UAS device and >> rmmod the uas module >> >> 3. made me take a bit closer look to the troublesome commit, it passes: >> udev->bus->sysdev, which I assume is the XHCI controller itself as device >> to scsi_add_host_with_dma, which in turn seems to cause permanent changes >> to the dma settings for the XHCI controller. I'm not all that familiar with >> the DMA APIs but I'm getting the feeling that passing the actual XHCI-controller's >> device as dma-device to scsi_add_host_with_dma is simply the wrong thing to >> do; and that the intended effects (honor XHCI dma limits, but do not cause >> any changes the XHCI dma settings) should be achieved differently. >> >> Note that if this is indeed wrong, the matching usb-storage change should >> likely also be dropped. > > One problem in this area is that the clamping of the DMA size through > dma_max_mapping_size mentioned in the commit log doesn't work when > swiotlb is called from intel-iommu. I think we need to wire up those > calls there as well. Ok, but that does not sound like a quick last minute fix for 5.10, so maybe for 5.10 we should just revert the uas and usb-storage changes which trigger this problem and then retry those for 5.11 ? Regards, Hans
