Re: next take at setting up a dma mask by default for platform devices
On Thu, 15 Aug 2019, Christoph Hellwig wrote: > On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote: > > I've taken the first 2 patches for 5.3-final. Given that patch 3 needs > > to be fixed, I'll wait for a respin of these before considering them. > > I have a respun version ready, but I'd really like to hear some > comments from usb developers about the approach before spamming > everyone again.. I didn't see any problems with your approach at first glance; it looked like a good idea. Alan Stern ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: How to resolve an issue in swiotlb environment?
On Wed, 19 Jun 2019, shuah wrote: > I missed a lot of the thread info. and went looking for it and found the > following summary of the problem: > > == > The issue which prompted the commit this thread is about arose in a > situation where the block layer set up a scatterlist containing buffer > sizes something like: > > 4096 4096 1536 1024 > > and the maximum packet size was 1024. The situation was a little > unusual, because it involved vhci-hcd (a virtual HCD). This doesn't > matter much in normal practice because: > > Block devices normally have a block size of 512 bytes or more. > Smaller values are very uncommon. So scatterlist element sizes > are always divisible by 512. > > xHCI is the only USB host controller type with a maximum packet > size larger than 512, and xHCI hardware can do full > scatter-gather so it doesn't care what the buffer sizes are. > > So another approach would be to fix vhci-hcd and then trust that the > problem won't arise again, for the reasons above. We would be okay so > long as nobody tried to use a USB-SCSI device with a block size of 256 > bytes or less. > === > > Out of the summary, the following gives me pause: > > "xHCI hardware can do full scatter-gather so it doesn't care what the > buffer sizes are." > > vhci-hcd won't be able to count on hardware being able to do full > scatter-gather. It has to deal with a variety of hardware with > varying speeds. Sure. But you can test whether the server's HCD is able to handle scatter-gather transfers, and if it is then you can say that the client-side vhci-hcd is able to handle them as well. Then all you would have to do is preserve the scatterlist information describing the transfer when you go between the client and the server. The point is to make sure that the client-side vhci-hcd doesn't claim to be _less_ capable than the server-side actual HCD. That's what leads to the problem described above. > "We would be okay so long as nobody tried to use a USB-SCSI device with > a block size of 256 bytes or less." > > At least a USB Storage device, I test with says 512 block size. Can we > count on not seeing a device with block size <= 256 bytes? Yes, we can. In fact, the SCSI core doesn't handle devices with block size < 512. > In any case, I am looking into adding SG support vhci-hci at the moment. > > Looks like the following is the repo, I should be working with? > > git://git.infradead.org/users/hch/misc.git It doesn't matter. Your work should end up being independent of Christoph's, so you can base it on any repo. Alan Stern
Re: How to resolve an issue in swiotlb environment?
On Thu, 13 Jun 2019, shuah wrote: > > Great! So all we have to do is fix vhci-hcd. Then we can remove all > > the virt_boundary_mask stuff from usb-storage and uas entirely. > > > > (I'm assuming wireless USB isn't a genuine issue. As far as I know, it > > is pretty much abandoned at this point.) > > > > Valentina and Shua: Adding SG support to vhci-hcd shouldn't be too > > hard. It ought to be possible even without changing the network > > protocol. > > > > I will start taking a look at this. Is there a target release in plan > to drop virt_boundary_mask stuff? Not yet. But since it doesn't do what we want anyway, this should be fixed quickly. Alan Stern
Re: How to resolve an issue in swiotlb environment?
On Thu, 13 Jun 2019, Christoph Hellwig wrote:
> On Wed, Jun 12, 2019 at 10:43:11AM -0400, Alan Stern wrote:
> > Would it be okay to rely on the assumption that USB block devices never
> > have block size < 512? (We could even add code to the driver to
> > enforce this, although refusing to handle such devices at all might be
> > worse than getting an occasional error.)
>
> sd.c only supports a few specific sector size, and none of them is
> < 512 bytes:
>
> if (sector_size != 512 &&
> sector_size != 1024 &&
> sector_size != 2048 &&
> sector_size != 4096) {
> ...
> sdkp->capacity = 0;
Great! So all we have to do is fix vhci-hcd. Then we can remove all
the virt_boundary_mask stuff from usb-storage and uas entirely.
(I'm assuming wireless USB isn't a genuine issue. As far as I know, it
is pretty much abandoned at this point.)
Valentina and Shua: Adding SG support to vhci-hcd shouldn't be too
hard. It ought to be possible even without changing the network
protocol.
Alan Stern
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: How to resolve an issue in swiotlb environment?
On Wed, 12 Jun 2019, Christoph Hellwig wrote: > On Wed, Jun 12, 2019 at 01:46:06PM +0200, Oliver Neukum wrote: > > > Thay is someething the virt_boundary prevents. But could still give > > > you something like: > > > > > > 1536 4096 4096 1024 > > > > > > or > > > 1536 16384 8192 4096 16384 512 > > > > That would kill the driver, if maxpacket were 1024. > > > > USB has really two kinds of requirements > > > > 1. What comes from the protocol > > 2. What comes from the HCD > > > > The protocol wants just multiples of maxpacket. XHCI can satisfy > > that in arbitrary scatter/gather. Other HCs cannot. > > We have no real way to enforce that for the other HCs unfortunately. > I can't really think of any better way to handle their limitations > except for setting max_segments to 1 or bounce buffering. Would it be okay to rely on the assumption that USB block devices never have block size < 512? (We could even add code to the driver to enforce this, although refusing to handle such devices at all might be worse than getting an occasional error.) As I mentioned before, the only HCD that sometimes ends up with maxpacket = 1024 but is unable to do full SG is vhci-hcd, and that one shouldn't be too hard to fix. Alan Stern
Re: How to resolve an issue in swiotlb environment?
On Tue, 11 Jun 2019, Christoph Hellwig wrote: > Hi Alan, > > thanks for the explanation. It seems like what usb wants is to: > > - set sg_tablesize to 1 for devices that can't handle scatterlist at all Hmmm. usb-storage (and possible other drivers too) currently handles such controllers by setting up an SG transfer as a series of separate URBs, one for each scatterlist entry. But this is not the same thing, for two reasons: It has less I/O overhead than setting sg_tablesize to 1 because it sets up the whole transfer as a single SCSI command, which requires much less time and traffic on the USB bus than sending multiple commands. It has that requirement about each scatterlist element except the last being a multiple of the maximum packet size in length. (This is because the USB protocol says that a transfer ends whenever a less-than-maximum-size packet is encountered.) We would like to avoid the extra I/O overhead for host controllers that can't handle SG. In fact, switching to sg_tablesize = 1 would probably be considered a regression. > - set the virt boundary as-is for devices supporting "basic" scatterlist, >although that still assumes they can rejiggle them because for example >you could still get a smaller than expected first segment ala (assuming >a 1024 byte packet size and thus 1023 virt_boundary_mask): > > | 0 .. 511 | 512 .. 1023 | 1024 .. 1535 | > >as the virt_bondary does not guarantee that the first segment is >the same size as all the mid segments. But that is exactly the problem we need to solve. The issue which prompted the commit this thread is about arose in a situation where the block layer set up a scatterlist containing buffer sizes something like: 4096 4096 1536 1024 and the maximum packet size was 1024. The situation was a little unusual, because it involved vhci-hcd (a virtual HCD). This doesn't matter much in normal practice because: Block devices normally have a block size of 512 bytes or more. Smaller values are very uncommon. So scatterlist element sizes are always divisible by 512. xHCI is the only USB host controller type with a maximum packet size larger than 512, and xHCI hardware can do full scatter-gather so it doesn't care what the buffer sizes are. So another approach would be to fix vhci-hcd and then trust that the problem won't arise again, for the reasons above. We would be okay so long as nobody tried to use a USB-SCSI device with a block size of 256 bytes or less. > - do not set any limit on xhci > > But that just goes back to the original problem, and that is that with > swiotlb we are limited in the total dma mapping size, and recent block > layer changes in the way we handle the virt_boundary mean we now build > much larger requests by default. For SCSI ULDs to take that into > account I need to call dma_max_mapping_size() and use that as the > upper bound for the request size. My plan is to do that in scsi_lib.c, > but for that we need to expose the actual struct device that the dma > mapping is perfomed on to the scsi layer. If that device is different > from the sysfs hierchary struct device, which it is for usb the ULDD > needs to scsi_add_host_with_dma and pass the dma device as well. How > do I get at the dma device (aka the HCDs pci_dev or similar) from > usb-storage/uas? >From usb_stor_probe2(): us->pusb_dev->bus->sysdev. >From uas_probe(): udev->bus->sysdev. The ->sysdev field points to the device used for DMA mapping. It is often the same as ->controller, but sometimes it is ->controller->parent because of the peculiarities of some platforms. Alan Stern
Re: How to resolve an issue in swiotlb environment?
On Mon, 10 Jun 2019, Christoph Hellwig wrote: > Hi Yoshihiro, > > sorry for not taking care of this earlier, today is a public holiday > here and thus I'm not working much over the long weekend. > > On Mon, Jun 10, 2019 at 11:13:07AM +, Yoshihiro Shimoda wrote: > > I have another way to avoid the issue. But it doesn't seem that a good way > > though... > > According to the commit that adding blk_queue_virt_boundary() [3], > > this is needed for vhci_hcd as a workaround so that if we avoid to call it > > on xhci-hcd driver, the issue disappeared. What do you think? > > JFYI, I pasted a tentative patch in the end of email [4]. > > Oh, I hadn't even look at why USB uses blk_queue_virt_boundary, and it > seems like the usage is wrong, as it doesn't follow the same rules as > all the others. I think your patch goes in the right direction, > but instead of comparing a hcd name it needs to be keyed of a flag > set by the driver (I suspect there is one indicating native SG support, > but I can't quickly find it), and we need an alternative solution > for drivers that don't see like vhci. I suspect just limiting the > entire transfer size to something that works for a single packet > for them would be fine. Christoph: In most of the different kinds of USB host controllers, the hardware is not capable of assembling a packet out of multiple buffers at arbitrary addresses. As a matter of fact, xHCI is the only kind that _can_ do this. In some cases, the hardware can assemble packets provided each buffer other than the last ends at a page boundary and each buffer other than the first starts at a page boundary (Intel would say the buffers are "virtually contiguous"), but this is a rather complex rule and we don't want to rely on it. Plus, in other cases the hardware _can't_ do this. Instead, we want the SG buffers to be set up so that each one (except the last) is an exact multiple of the maximum packet size. That way, each packet can be assembled from the contents of a single buffer and there's no problem. The maximum packet size depends on the type of USB connection. Typical values are 1024, 512, or 64. It's always a power of two and it's smaller than 4096. Therefore we simplify the problem even further by requiring that each SG buffer in a scatterlist (except the last one) be a multiple of the page size. (It doesn't need to be aligned on a page boundary, as far as I remember.) That's why the blk_queue_virt_boundary usage was added to the USB code. Perhaps it's not the right way of doing this; I'm not an expert on the inner workings of the block layer. If you can suggest a better way to express our requirement, that would be great. Alan Stern PS: There _is_ a flag saying whether an HCD supports SG. But what it means is that the driver can handle an SG list that meets the requirement above; it doesn't mean that the driver can reassemble the data from an SG list into a series of bounce buffers in order to meet the requirement. We very much want not to do that, especially since the block layer should already be capable of doing it for us.
Re: usb HC busted?
On Fri, 20 Jul 2018, Mathias Nyman wrote: > >> But we need to fix this properly as well. > >> xhci needs to be more in sync with usb core in usb_set_interface(), > >> currently xhci > >> has the altssetting up and running when usb core hasn't event started > >> flushing endpoints. > > > > Absolutely. The core tries to be compatible with host controller > > drivers that either allocate bandwidth as it is requested or else > > allocate bandwidth all at once when an altsetting is installed. > > > > xhci-hcd falls into the second category. However, this approach > > requires the bandwidth verification for the new altsetting to be > > performed before the old altsetting has been disabled, and the xHCI > > hardware can't do this. > > > > We may need to change the core so that the old endpoints are disabled > > before the bandwidth check is done, instead of after. Of course, this > > leads to an awkward situation if the check fails -- we'd probably have > > to go back and re-install the old altsetting. > > That would help xhci a lot. > > If we want to avoid the awkward altsetting re-install after bandwidth failure > then adding a extra endpoint flush before checking the bandwidth would > already help a lot. > > The endpoint disabling can then be remain after bandwidth checking. > Does that work for other host controllers? As far as I know, the other host controller drivers don't really care how this is done. xHCI is the only technology where the hardware has to verify the bandwidth requirements. (Maybe some other SuperSpeed controller design also cares, but if so then this change is unlikely to hurt.) Alan Stern ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: usb HC busted?
On Thu, 19 Jul 2018, Mathias Nyman wrote: > xhci driver will set up all the endpoints for the new altsetting already in > usb_hcd_alloc_bandwidth(). > > New endpoints will be ready and rings running after this. I don't know the > exact > history behind this, but I assume it is because xhci does all of the steps to > drop/add, disable/enable endpoints and check bandwidth in a single configure > endpoint command, that will return errors if there is not enough bandwidth. That's right; Sarah and I spent some time going over this while she was working on it. But it looks like the approach isn't adequate. > This command is issued in hcd->driver->check_bandwidth() > This means that xhci doesn't really do much in hcd->driver->endpoint_disable > or > hcd->driver->endpoint_enable > > It also means that xhci driver assumes rings are empty when > hcd->driver->check_bandwidth is called. It will bluntly free dropped rings. > If there are URBs left on a endpoint ring that was dropped+added > (freed+reallocated) then those URBs will contain pointers to freed ring, > causing issues when usb_hcd_flush_endpoint() cancels those URBs. > > usb_set_interface() >usb_hcd_alloc_bandwidth() > hcd->driver->drop_endpoint() > hcd->driver->add_endpoint() // allocates new rings > hcd->driver->check_bandwidth() // issues configure endpoint command, > free rings. >usb_disable_interface(iface, true) > usb_disable_endpoint() >usb_hcd_flush_endpoint() // will access freed ring if URBs found!! >usb_hcd_disable_endpoint() > hcd->driver->endpoint_disable() // xhci does nothing >usb_enable_interface(iface, true) > usb_enable_endpoint(ep_addrss, true) // not really doing much on xhci > side. > > As first aid I could try to implement checks that make sure the flushed URBs > trb pointers really are on the current endpoint ring, and also add some > warning > if we are we are dropping endpoints with URBs still queued. > > But we need to fix this properly as well. > xhci needs to be more in sync with usb core in usb_set_interface(), currently > xhci > has the altssetting up and running when usb core hasn't event started > flushing endpoints. Absolutely. The core tries to be compatible with host controller drivers that either allocate bandwidth as it is requested or else allocate bandwidth all at once when an altsetting is installed. xhci-hcd falls into the second category. However, this approach requires the bandwidth verification for the new altsetting to be performed before the old altsetting has been disabled, and the xHCI hardware can't do this. We may need to change the core so that the old endpoints are disabled before the bandwidth check is done, instead of after. Of course, this leads to an awkward situation if the check fails -- we'd probably have to go back and re-install the old altsetting. Alan Stern ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: usb HC busted?
On Tue, 17 Jul 2018, Sudip Mukherjee wrote: > On Tue, Jul 17, 2018 at 03:40:22PM +0100, Sudip Mukherjee wrote: > > Hi Alan, > > > > On Tue, Jul 17, 2018 at 10:28:14AM -0400, Alan Stern wrote: > > > On Tue, 17 Jul 2018, Sudip Mukherjee wrote: > > > > > > > I did some more debugging. Tested with a KASAN enabled kernel and that > > > > shows the problem. The report is attached. > > > > > > > > To my understanding: > > > > > > > > btusb_work() is calling usb_set_interface() with alternate = 0. which > > > > again calls usb_hcd_alloc_bandwidth() and that frees the rings by > > > > xhci_free_endpoint_ring(). > > > > > > That doesn't sound like the right thing to do. The rings shouldn't be > > > freed until xhci_endpoint_disable() is called. > > > > > > On the other hand, there doesn't appear to be any > > > xhci_endpoint_disable() routine, although a comment refers to it. > > > Maybe this is the real problem? > > > > one of your old mail might help :) > > > > https://www.spinics.net/lists/linux-usb/msg98123.html That message seems to say the same thing as what I just wrote, more or less. > Wrote too soon. > > Is it the one you are looking for - > usb_disable_endpoint() is in drivers/usb/core/message.c No, I'm talking about xhci_endpoint_disable(), which would be called by usb_hcd_disable_endpoint() if it existed. Of course, usb_hcd_disable_endpoint() is called by usb_disable_endpoint(). Alan Stern ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: usb HC busted?
On Tue, 17 Jul 2018, Greg KH wrote:
> > From: Sudip Mukherjee
> > Date: Tue, 10 Jul 2018 09:50:00 +0100
> > Subject: [PATCH] hacky solution to mem-corruption
> >
> > Signed-off-by: Sudip Mukherjee
> > ---
> > drivers/usb/core/message.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > index 7cd4ec33dbf4..7fdf7a27611d 100644
> > --- a/drivers/usb/core/message.c
> > +++ b/drivers/usb/core/message.c
> > @@ -1398,7 +1398,8 @@ int usb_set_interface(struct usb_device *dev, int
> > interface, int alternate)
> > remove_intf_ep_devs(iface);
> > usb_remove_sysfs_intf_files(iface);
> > }
> > - usb_disable_interface(dev, iface, true);
> > + if (!(iface->cur_altsetting && alt))
> > + usb_disable_interface(dev, iface, true);
>
>
>
> This feels like a "correct" patch anyway, why would a driver keep
> calling set_interface to an interface that it was already set to?
>
> But can't we check for this higher up in the function? This hack will
> just not disable an interface but it will do all of the other stuff
> being asked for. Does the patch below also solve this for you? It's
> not a good solution of course, but it might work around the problem a
> bit better.
>
> thanks,
>
> greg k-h
>
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 1a15392326fc..0f718f1a1ca3 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -1376,6 +1376,14 @@ int usb_set_interface(struct usb_device *dev, int
> interface, int alternate)
> return -EINVAL;
> }
>
> + if (iface->cur_altsetting == alt) {
> + /*
> + * foolish bluetooth stack, don't try to set a setting you are
> + * already set to...
> + */
> + return 0;
> + }
> +
> /* Make sure we have enough bandwidth for this alternate interface.
>* Remove the current alt setting and add the new alt setting.
> */
No, neither of these is right. It's possible to use
usb_set_interface() as a kind of "soft" reset. Even when the new
altsetting is specified to be the same as the current one, we still
have to tell the lower-layer drivers and hardware about it.
Alan Stern
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: usb HC busted?
On Tue, 17 Jul 2018, Sudip Mukherjee wrote: > I did some more debugging. Tested with a KASAN enabled kernel and that > shows the problem. The report is attached. > > To my understanding: > > btusb_work() is calling usb_set_interface() with alternate = 0. which > again calls usb_hcd_alloc_bandwidth() and that frees the rings by > xhci_free_endpoint_ring(). That doesn't sound like the right thing to do. The rings shouldn't be freed until xhci_endpoint_disable() is called. On the other hand, there doesn't appear to be any xhci_endpoint_disable() routine, although a comment refers to it. Maybe this is the real problem? Alan Stern > But then usb_set_interface() continues and > calls usb_disable_interface() -> usb_hcd_flush_endpoint()->unlink1()-> > xhci_urb_dequeue() which at the end gives the command to stop endpoint. > > In all the cycles I have tested I see that only in the fail case > handle_cmd_completion() gets called, but in the cycles where the error > is not there handle_cmd_completion() is not called with that command. > > I am not sure what is happening, and you are the best person to understand > what is happening. :) > > But for now (untill you are back from holiday and suggest a proper solution), > I made a hacky patch (attached) which is working and I donot get any > corruption after that. Both KASAN and slub debug are also happy. > > So, now waiting for you to analyze what is going on and suggest a proper > fix. > > Thanks in advance. > > -- > Regards > Sudip > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: WARN_ON(irqs_disabled()) in dma_free_attrs?
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: WARN_ON(irqs_disabled()) in dma_free_attrs?
On Sat, 3 Mar 2018, Fredrik Noring wrote:
> Christoph, Alan,
>
> > If it is allocating / freeing this memory all the time in the hot path
> > it should really use a dma pool (see include/ilinux/dmapool.h).
> > The dma coherent APIs aren't really built for being called in the
> > hot path.
>
> hcd_buffer_free uses a combination of dma pools and dma coherent APIs:
>
> ...
> for (i = 0; i < HCD_BUFFER_POOLS; i++) {
> if (size <= pool_max[i]) {
> dma_pool_free(hcd->pool[i], addr, dma);
> return;
> }
> }
> dma_free_coherent(hcd->self.sysdev, size, addr, dma);
>
> 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.
Alan Stern
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]
On Thu, 16 Apr 2015, Dorian Gray wrote: I have tested the following kernel versions: - 3.18.4, 3.18.6, 3.18.7, 3.19.4 [all affected] - 3.17.1 [unaffected] - 3.17.8 [probably the last unaffected version; I'm using it currently] Also, I've been using the very same configuration (hardware) along with 2.6.x, 3.2.x, 3.4.x, 3.10.x and have never encountered such a behavior before. And the problem is: When at least one external drive is plugged-in AND mounted, after ~2-4 hours the following occurs (@11315.681561): [ 5570.110523] usb 2-1.2: new high-speed USB device number 5 using ehci-pci [ 5570.852917] usb 2-1.2: New USB device found, idVendor=1058, idProduct=0730 [ 5570.852923] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5570.852927] usb 2-1.2: Product: My Passport 0730 [ 5570.852930] usb 2-1.2: Manufacturer: Western Digital [ 5570.852933] usb 2-1.2: SerialNumber: [ 5570.853517] usb-storage 2-1.2:1.0: USB Mass Storage device detected [ 5570.853691] scsi host8: usb-storage 2-1.2:1.0 [ 5572.932659] scsi 8:0:0:0: Direct-Access WD My Passport 0730 1012 PQ: 0 ANSI: 6 [ 5572.933013] sd 8:0:0:0: Attached scsi generic sg5 type 0 [ 5575.306801] scsi 8:0:0:1: Enclosure WD SES Device 1012 PQ: 0 ANSI: 6 [ 5575.307160] sd 8:0:0:0: [sdc] 976707584 512-byte logical blocks: (500 GB/465 GiB) [ 5575.308405] sd 8:0:0:0: [sdc] Write Protect is off [ 5575.308416] sd 8:0:0:0: [sdc] Mode Sense: 47 00 10 08 [ 5575.309772] sd 8:0:0:0: [sdc] No Caching mode page found [ 5575.309776] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 5575.311176] scsi 8:0:0:1: Attached scsi generic sg6 type 13 [ 5575.328540] sdc: sdc1 [ 5575.331026] sd 8:0:0:0: [sdc] Attached SCSI disk [11315.681561] ehci-pci :00:1d.0: swiotlb buffer is full (sz: 32768 bytes) [11315.681565] DMA: Out of SW-IOMMU space for 32768 bytes at device :00:1d.0 [11315.681874] ehci-pci :00:1d.0: swiotlb buffer is full (sz: 32768 bytes) [11315.681876] DMA: Out of SW-IOMMU space for 32768 bytes at device :00:1d.0 [11315.682171] ehci-pci :00:1d.0: swiotlb buffer is full (sz: 32768 bytes) [11315.682174] DMA: Out of SW-IOMMU space for 32768 bytes at device :00:1d.0 [...and so on...] This appears to be a problem with the IOMMU or SWIOTLB subsystems, not the USB subsystem. I have CC'ed the appropriate mailing lists. Alan Stern ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
