Hello All,
We recently have run into a problem using a USB 3.0 thumb drive over USBIP
where the driver will unlink URBs when trying to mount a FAT partition. This
happens because of the remote XHCI controller returning errno 75 during IN URB
processing. I've traced the failure to the followin
On Apr 5, 2019, at 4:01 PM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
Why is the remote buffer too small? If you can figure that out then
you should be able to fix the problem pretty easily.
The usb-storage driver is doing a 32K read. When it does the read all in one
buffer, it suc
On Apr 6, 2019, at 10:34 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
Why does a 3-KB read cause a failure? It should work perfectly well.
I thought because the scsi command asked to read 32K.
If I’m incorrect in my assumption, and the chunked read should work, do you
have any th
On Apr 6, 2019, at 11:08 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
Can you provide the "lsusb -v" output for the storage device as shown
on both computers? I want to see if the server and the client disagree
on the maxpacket sizes for the bulk endpoints. The key is that 3584 is
a
On Apr 8, 2019, at 9:33 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
So no disagreement; in both cases the maxpacket values are 1024.
Clearly this will not work if a Scatter-Gather component has length
3584.
In fact, this bug has nothing at all to do with VHCI. You would
observe the
On Apr 8, 2019, at 9:33 AM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
In theory, the device should report a block size of 1024. Does it
actually do this? A usbmon trace (on the host) showing what happens
when the device is first plugged in will provide the answer. Can you
collect on
On Apr 8, 2019, at 12:23 PM, Alan Stern
mailto:st...@rowland.harvard.edu>> wrote:
The two big-endian numbers at the end of this line are the logical
block address of the device's last block and the logical block size in
bytes. Thus the device claims to have 512-byte blocks.
I suspect you have r
> To help verify this, can you send a similar usbmon trace on the server
> showing what happens when the EOVERFLOW error occurs? The debug
> messages in your April 6 email don't contain all the detailed
> information.
I verified this one contains the odd read.
80007326d540 3844505987 S Ci:
> On Apr 8, 2019, at 1:59 PM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
> No, that trace did not show any failure. Did you see the corresponding
> error messages in the kernel log while you were collecting the trace?
> Maybe you can try again.
I’m certain the last trace I sent shou
> No, that trace did not show any failure. Did you see the corresponding
> error messages in the kernel log while you were collecting the trace?
> Maybe you can try again.
This xhci debug spew might be helpful.
800073097780 342993897 S Bi:8:003:1[ 341.533219] xhci-hcd xhci-hcd.1.auto:
B
> On Apr 12, 2019, at 1:01 PM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
>
> Any more test results? I need to know that you're confident the patch
> works okay
The patch didn’t apply for me. I figured a copy paste problem, so I made the
changes by hand.
Your changes fix my proble
Hello All,
Recently I’ve been troubleshooting a problem with the host controller dying and
noticed that when the controller dies, the system was unresponsive for a _long_
period of time. When I explored the code a bit, I saw that xhci_handshake will
spin with interrupts disabled for up to 5 se
> On Apr 25, 2019, at 9:22 AM, Alan Stern wrote:
>
> Are you certain that those places with the very long timeouts are
> called with interrupts disabled?
I must admit, I have not reviewed all uses of the long xhci_handshakes. :) I
have reviewed the following instance.
In usb/host/xhci-ring.c
Hello All,
Recently we saw a problem where the device reset will fail due to a
configuration descriptor check in hub.c:5600.
if (memcmp(buf, udev->rawdescriptors[index], old_length)
!= 0) {
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
> On Jun 6, 2019, at 9:36 AM, Greg KH wrote:
>
> If the descriptor changes between resets, that means that something
> changed and we need to start over with it. What is the problem that
> this is causing
We have code doing a USBDEVFS_RESET that fails when the ioctl returns EPERM.
I think the
> On Jun 6, 2019, at 9:37 AM, Alan Stern
> mailto:st...@rowland.harvard.edu>> wrote:
>
> If this is really a problem we can change the code so that the
> iManufacturer, iProduct, iSerialNumber, iConfiguration, and iInterface
> descriptor values are exempt from the change check. It would be a
> li
> On Jun 6, 2019, at 10:03 AM, Alan Stern wrote:
>
> EPERM means that the file descriptor was not opened with write access.
> It has nothing to do with reset failures.
Yes, I was confused by that as well so spent some time instrumenting the
kernel. It definitely is open for writing, and get’
17 matches
Mail list logo
