第二十五篇:找微软的麻烦--在微软提供的MUTT中发现的软件与硬件问题

本文主要是介绍第二十五篇:找微软的麻烦--在微软提供的MUTT中发现的软件与硬件问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Tools in the MUTT software package

http://msdn.microsoft.com/en-US/library/windows/hardware/dn376875(v=vs.85).aspx

这几天在用微软的MUTT USB Device测试针对于USB3.0高带宽(high bandwidth, 48KB/125us) ISO EP的测试用WDF USB功能驱动.

结果发现MUTT设备中的问题.

微软针对于USB3.0这个新生事物, 提供了四个测试设备, 分别是Super MUTT, MUTT, Super MUTT pack, MUTT pack.

Super MUTT是USB3.0的设备, MUTT是USB2.0

Super MUTT PACK则是一个复合设备, 包括了一个USB3.0的HUB与连在该SUPER SPEED HUB下面的一个USB2.0设备

MUTT Pack也是一个复合设备, 不同于Super MUTT PACK的是它包括一下USB2.0的HUB.

这个问题在Super MUTT上没有发生, 但在其它三种设备上均发生, 即所有的USB2.0设备均有相同的问题.

当我们将这些设备接到EHCI USB HOST上时, 可以看到设备的高带宽ISO EP的描述符:

其中, 它们的ISO IN EP是支持一个service interval (125us) 768*3 BYTES的数据传输的.

------------------------------

USB_ENDPOINT_DESCRIPTOR for Pipe04
bLength = 0x7
bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )
bEndpointAddress= 0x8 ( OUTPUT )
bmAttributes= 0x1 ( USB_ENDPOINT_TYPE_ISOCHRONOUS )
wMaxPacketSize= 0x300, decimal 768
High Bandwidth number= 0x2, decimal 2
bInterval = 0x1, decimal 1
------------------------------
USB_ENDPOINT_DESCRIPTOR for Pipe05
bLength = 0x7
bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )
bEndpointAddress= 0x86 ( INPUT )
bmAttributes= 0x1 ( USB_ENDPOINT_TYPE_ISOCHRONOUS )
wMaxPacketSize= 0x300, decimal 768
High Bandwidth number= 0x2, decimal 2
bInterval = 0x1, decimal 1

------------------------------

这一点, 在ISO OUT上是正确的行为: 即每一个SERVICE INTERVAL为3笔事务(TRANSACTION)

而在ISO IN上则不正确: 如下图:

这也就导致驱动方面出现数据接收数量为0的情况:

-----------------------------------------------------------------------------------------------------------------------

read-write irp failed with status C0000001

urb header status C0000B00

IsoPacket[0].offset = 0 IsoPacket[0].Length = 0 IsoPacket[0].Status = c0000011

IsoPacket[1].offset = 2304 IsoPacket[1].Length = 0 IsoPacket[1].Status = c0000011

IsoPacket[2].offset = 4608 IsoPacket[2].Length = 0 IsoPacket[2].Status = c0000011

IsoPacket[3].offset = 6912 IsoPacket[3].Length = 0 IsoPacket[3].Status = c0000011

IsoPacket[4].offset = 9216 IsoPacket[4].Length = 0 IsoPacket[4].Status = c0000011

IsoPacket[5].offset = 11520 IsoPacket[5].Length = 0 IsoPacket[5].Status = c0000011

IsoPacket[6].offset = 13824 IsoPacket[6].Length = 0 IsoPacket[6].Status = c0000011

IsoPacket[7].offset = 16128 IsoPacket[7].Length = 0 IsoPacket[7].Status = c0000011

-----------------------------------------------------------------------------------------------------------------------

正确的行为的USB TRACE(Lecory Advisor T3)为: (在SUPER MUTT 跑在USB2.0 EHCI HOST上的TRACE)

该问题已经提交给微软的USB TEAM.

第二个问题:

该问题是在2013年八月期间, 在测试USB3.0 XHCI HOST的时候发现的.

测试设备的TOPOLOGY为:

xhci host root hub --> SuperMutt Pack --> SuperMUTT device 1

--> MUTT device 2

问题的表现形式为, USB3.0的SUPER MUTT device 1在正确的状态下, 是运行在SUPER SPEED MODE下的, 但在运行MUTT TOOL中的 runTest.bat的时候, 会导致SUPER MUTT DEVICE 1降到USB2.0 HIGH SPEED MODE下去.

将该问题提交给微软USB TEAM后, 他们很快给了我回复, 并在几天后, 发现了软件中的问题.

这也就是大家看到的, 在最新版的

Tools in the MUTT software package页面, 更新的内容:

Changes for version 1.9.1

In version 1.9 and earlier, on some systems, the SuperMutt device enumerated at high speed (when connected to an xHCI controller) after the system resumed from S4. Version 1.9.1 corrects that issue.

从这两个问题上来看, 微软在软件方面确实非常强悍, 光从一个WDM驱动模型来讲, 就设计得非常完美；在WDDM, AVSTREAM这些DEVICE PORT驱动架构上来讲, 也是非常精妙.

但从微软的硬件方面来讲(虽然这些MUTT设备并非使用微软自己的USB3.0 DEVICE CONTROLLER芯片, 而是CYPRESS的FX3, FX2), 但出现这两个问题, 至少, 在测试方面, 就是不及格的, 即使硬件不是微软自己的东西, 但作为打上MICROSOFT LOGO的测试设备, 实在与微软这样的高大上公司的形象不符.

这篇关于第二十五篇:找微软的麻烦--在微软提供的MUTT中发现的软件与硬件问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！