Question

[编辑：我找到了原因，请参见下文]

问题：

我使用Python（PyUSB和libusb-win32）为Windows中的设备创建了一个“驱动程序”。尽管此软件可以在Windows下的多台PC上无缝运行，但使用我的Linux（Kubuntu 18.10）测试笔记本电脑时，在第二次512字节批量传输后，每次写入长度为512字节的批量写入序列都会超时。

有趣：我也使用VirtualBox尝试了相同的操作。事实证明，在同一Linux主机上通过VirtualBox使用Windows guest虚拟机，仍然会发生相同的错误。所以不是因为

问题：

在Linux下会发生什么，而在Windows下不会发生会导致超时的错误[Errno 110]？

更多信息（如果有帮助的话）

在Windows下，Wireshark显示两次批量写入之间的时序差异，前一次为6毫秒，随后的为每5毫秒，而在Linux下，增量仅约为3毫秒，这主要是由于睡眠操作造成的（随附了相关的Python源代码）。将时间加倍无济于事。
dmesg显示诸如“批量端点##具有无效的maxpacket 64”之类的消息，其中##为0x01、0x08和0x81。
该设备只有一种配置。
测试笔记本电脑仅具有USB 3.0连接器，而Windows PC均具有USB 3.0和2.0。我测试了所有。
在Linux下，Wireshark会在每次批量写入时显示设备以另一个（空）批量答复，而在Windows下则不会显示。据我了解，这是因为USBPcap无法捕获Windows下的握手。但是我对此不满意，因为我不知道这种响应是否真的被归类为“ URB_BULK out”。
我尝试将libusb0，libusb1和OpenUSB作为Linux下的后端，但没有成功。
有问题的批量传输是将FPGA固件传输到设备。
在相同端点上仅使用几个字节进行多次512字节大块批量操作之前，我就能与设备进行通信。导致超时的代码是此for循环的第二次迭代中的以下代码：

for chunk in chunks: # chunks: array of bytearrays with 512 bytes each
    self.write(0x01,chunk)
    time.sleep(0.003)

[编辑]原因，我发现这仅发生在使用xhci的测试笔记本电脑上，而不发生在使用ehci的第二台Linux测试计算机上。因此，这可能是由xhci引起的。我还没有解决方法，但这至少可以提供一个解释。

Answer 1

事实证明，设备请求的每个数据包的字节数较少，可以在问题中已经写入的 dmesg 中找到所需的字节数 (64)。由于 xhci 不正式支持，Linux 决定忽略该请求。 Windows 似乎采用了它，并按照请求的数据包大小拆分了较大的数据包。所以解决方案是在传输之前手动将数据拆分为 64 字节大小的数据包。

Windows下可在Linux下使用USB批量传输超时

1 个答案: