我正在尝试为一块硬件制作一个开源的libusb驱动程序 . 遗憾的是，Linux上的时间和数据准确数据包重放会导致某些批量读取重复超时而不返回批量数据（LIBUSB_ERROR_TIMEOUT，URB状态：-ENOENT） . 根据Wireshark的说法，Windows应用程序是可预测的，并且在通过相同的Linux笔记本电脑在VMWare Workstation上执行时始终返回此数据 .
我使用Wireshark从Windows应用程序和我的应用程序生成数据包捕获，据我所知，它们是相同的错误 . 我更进一步，借用USB协议分析仪（Total Phase Beagle 12）并在线上捕获数据 . 我以前的测试速度很快，但我能够全速制作一个等效的测试用例，以便我可以使用分析仪 . 它表明该设备实际上正确地回复了控制请求，但不知何故没有将其发送到用户空间（或者就此而言是URB） .
错误之前的一些数据包，有一个非常相似的数据包（请求中的相同批量和返回的相同数据） . python libusb代码不会抛出错误，但URB状态为-EREMOTEIO . 据我所知，这可能是正常的，可能只是VMWare和libusb如何设置Linux内核USB参数之间的区别 . 但这仍然可能是一个暗示：一些不同的设置正在产生重大影响 .
我在Ubuntu 12.04下的Linux 3.5 x64和Linux 3.18 x64系统上试过这个 . 如果这看起来像是一个内核错误，我可以设置一个更新的内核 . 两个系统都配有Intel 82801H USB控制器 .
该设备执行一些奇怪的启动魔术，它可重复地重置设备并清除一些批量 endpoints . 无论我是否跳舞，都会在以后发生错误 .
我希望有人之前见过这个，可以给我一些指示 . 否则，我想我的下一步将是尝试找到变通方法（我可能有一个解决方法，但它会产生其他问题）或者更多地使用Linux USB子系统 .
数据：
-Full Wireshark和Total Phase日志可以在这里找到：http://siliconpr0n.org/uv/bpm/so/
-
全速测试代码：bp1410_rst_12.py
-
显示请求的完整阶段截图：failed_reply.png（来自12_04_mein_startup_cold.tdc）
-Wireshark screenshot（Windows参考）：ws_ref.png
-Wireshark screenshot（我的Linux libusb）：ws_mine.png
1 回答
你的代码是故意设置URB_SHORT_NOT_OK，而Windows代码不是吗？ IIRC，短数据包将导致IN令牌停止发送，直到下一个SOF或直到下一个URB被提交 .