在Windows下工作时，USB批量传输超时在Linux下进行

Question

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

问题：

我使用python（pyusb和libusb-win32）为Windows创建了一个"驱动程序"。虽然该软件在Windows下的多个PC上无缝工作，但使用我的Linux（Kubuntu 18.10）测试笔记本电脑，在第二个512字节散装传输之后，每次均为512个字节的散装序列。

。

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

问题：

在引起超时的Windows下不会发生Linux下发生什么[ERRNO 110]？

更多信息，以防万一：

• 在Windows下，Wireshark显示了第一个批量写入中的两个批量写入和每次以下的5毫秒之间的定时差异，而在Linux下，Delta仅圆形大约3毫秒，这主要是由睡眠操作造成的（附有相关的Python源代码）。加倍的时间无济于事。
• dmesg显示诸如"散装端点##的麦克斯帕特64"之类的消息，其中##是0x01、0x08和0x81。
• 该设备只有一种配置。
• 测试笔记本电脑只有USB 3.0连接器，其中Windows PC具有USB 3.0和2.0。我测试了所有。
• Wireshark显示了设备在Linux下每个散装写入的另一个（空）散装的响应，而在Windows下没有显示该设备。据我所知，这是因为USBPCAP无法在Windows下捕获握手。但是我并不是这样，因为我不知道这种类型的响应是否真的将被归类为" urb_bulk out"。
• 我尝试了libusb0，libusb1和openusb作为Linux下的后端，没有成功。
• 所讨论的批量转移是将FPGA固件传输到设备。
• 我能够在仅使用少数字节的相同端点上的多个512字节链块操作之前与设备进行通信。然后导致超时的代码是此循环的第二个迭代中的以下一个：

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

[编辑]原因我发现这仅发生在我的测试笔记本电脑上，而不是使用EHCI的第二台Linux测试机上发生。因此，这可能是由XHCI引起的。我还没有解决方法，但这至少给出了解释。

Answer 1

事实证明，每个数据包的设备要求较少的字节，所需的字节数（64）可以在dmesg中找到，如问题所在。由于XHCI不正式支持这一点，因此Linux决定忽略该请求。Windows似乎随之而来，并在请求的数据包大小中将较大的数据包拆分。因此，解决方案是在传输之前将数据手动将数据分开为64个字节大小。