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())? 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 >
