Hi Tom, On 11/28/20 2:25 AM, Tom Yan wrote: > Should we still be clamping max_sectors to dma_max_mapping_size(dev) > (for now)? with dev being us->pusb_dev->bus->sysdev and > devinfo->udev->bus->sysdev respectively (i.e. revert only > scsi_add_host_with_dma() to scsi_add_host())? I would expect that to work / avoid the regression, so yes that is a good option. If you can provide me with a patch doing that, then I can test it to make sure it does indeed fix the regression. Regards, Hans > > On Sat, 28 Nov 2020 at 02:12, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> 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 >> >
