Linux下的USB批量傳輸超時，而它在Windows下工作

Question

[編輯：我找到了原因，見下文]

問題：

我使用 Python（PyUSB 和 libusb-win32）為 Windows 中的設備創建了一個“驅動程序”。 雖然該軟件在 Windows 下的多台 PC 上無縫運行，但使用我的 Linux (Kubuntu 18.10) 測試筆記本電腦，在第二次 512 字節批量傳輸之后，每次長度為 512 字節的批量寫入序列超時。

有趣：我也嘗試過使用 VirtualBox。 事實證明，在同一台 Linux 主機上通過 VirtualBox 使用 Windows 來賓，仍然出現相同的錯誤。 所以這不是因為

問題：

在 Linux 下會發生什么在 Windows 下不會發生導致超時 [Errno 110]？

更多信息，以防萬一：

• 在 Windows 下，Wireshark 顯示兩次批量寫入之間的時間差異，第一次為 6 毫秒，隨后為 5 毫秒，而在 Linux 下，增量僅為約 3 毫秒，這主要是由於睡眠操作（相關 Python附上源代碼）。 將時間加倍沒有任何作用。
• dmesg 顯示諸如“bulk endpoint ## has invalid maxpacket 64”之類的消息，其中## 是 0x01、0x08 和 0x81。
• 該設備只有一種配置。
• 測試筆記本電腦只有 USB 3.0 連接器，而 Windows PC 有 USB 3.0 和 2.0。 我都測試過了。
• 在 Linux 下，Wireshark 在每次批量寫入時顯示設備以另一個（空）批量應答，而在 Windows 下不顯示。 據我了解，那是因為 USBPcap 無法在 Windows 下捕獲握手。 但我不同意，因為我不知道這種類型的響應是否真的會被歸類為“URB_BULK out”。
• 我在 Linux 下嘗試了 libusb0、libusb1 和 OpenUSB 作為后端，但沒有成功。
• 有問題的批量傳輸是將 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 字節大小的數據包。